search

babylonlabs-io / finality-provider

Other
1 stars 3 forks source link

feat: accomodate BTC-timestamping #40

Closed gitferry closed 2 weeks ago

gitferry commented 4 weeks ago

This PR closes #4.

The change in Babylon removed voting power from a finality provider if it has no timestamped pub rand for a certain height. Therefore, from the finality provider side, as long as it has voting power, the existence of a timestamped pub rand is ensured. No need to do an extra query to check it. This PR accommodates this change

gitferry commented 3 weeks ago

One question is that should we add some code for handling/testing the edge case where FP somehow used all timestamped pub rand (eg when BTC gets highly congested). When this happens at height h, FP needs to wait until a later height h' where it has positive voting power, and then start voting at height h', without voting for h to h'. This seems not handled in the current PR

I think after we connect randomness commit with voting power, the two threads of sending finality signatures and sending pub rand commit can be independent, i.e., the voting thread does not need to know whether the pub rand commit is there. So I think the current code already covers this case.

Nevertheless, I agree that we should do a major refactoring and add comprehensive tests after the feature is shipped, which is planned in #6 and #8