OP consumer implementation

[bap2pecs]

QueryFinalityProviderVotingPower

per my discussion w @SebastianElvis, we can just hardcode to a positive value b/c so this interface function is only used for checking if the FP is eligible for submitting sigs but it's still useful. at least honest FPs won't submit useless data so post-mvp we can do this per @SebastianElvis 's suggestion > A possible algorithm is as follows: instead of querying the exact voting power, the FP queries BTC delegations page by page, and if there is >=1 active BTC delegation, then it can vote. > Another way is that FP leverages backend service that indexes voting power for Babylon. This introduces some unnecesasry coupling though we can think more later

QueryActivatedHeight

currently we manually set the height in the CW contract and query it from there. but per definition at https://github.com/babylonchain/babylon/blob/dev/x/btcstaking/types/query.pb.go#L1774-L1775: > ActivatedHeight queries the height when BTC staking protocol is activated, i.e., the first height when there exists 1 finality provider with voting power we need to 1. Get all fp list via consumer_id: `/babylon/btcstkconsumer/v1/finality_providers/{consumer_id}` 2. Iterate each fp and get its delegations: `/babylon/btcstaking/v1/finality_providers/{fp_btc_pk_hex}/delegations` 3. For each active delegations, get the start_height(it is the btc height), find the earliest start_height 4. Get the last L2 block number(in 10mins) for the btc height at which the earliest active BTC delegation

[SebastianElvis]

QueryFinalityProviderVotingPower sounds good to me

The proposed QueryActivatedHeight might not work as the start_height is not necessarily the height that BTC delegation becomes active. To become active, it needs to satisfy 1) the staking tx is k-deep in Bitcoin, i.e., start_height + k and 2) it receives a quorum number of covenant committee signatures

[bap2pecs]

note that for QueryFinalityProviderVotingPower, one problem is if we always return 1, it will cause issue

2024-06-29T17:15:40.891-0400    FATAL   service/fp_manager.go:110   terminating the finality-provider instance due to critical error    {"pk": "12b1058e00115ea41f28582db7fb684c03113933c630ffbfb5baea91beec6cc1", "error": "reached max failed cycles with err: failed to get inclusion proof of public randomness 983078c40dea8dfb765005d207092437f867bc881e1e45220cf15bfff2b056cd for FP 12b1058e00115ea41f28582db7fb684c03113933c630ffbfb5baea91beec6cc1 for block 2: public randomness proof not found"}
github.com/babylonchain/finality-provider/finality-provider/service.(*FinalityProviderManager).monitorCriticalErr
    /Users/zidong/Documents/Projects/babylon-finality-provider/finality-provider/service/fp_manager.go:110
FAIL    github.com/babylonchain/finality-provider/itest/opstackl2   58.684s
FAIL

due to submission loop trying to submit sig for a height missing PR. so we added https://github.com/babylonchain/babylon-contract/pull/196 and used it in QueryFinalityProviderVotingPower (see https://github.com/babylonchain/finality-provider/pull/447)