chore: set versions to test btc activation height

[RafilxTenfen]

Modified versions:

• vigilante: chore(*): bump babylon to v0.13.0 vigilante#80
• babylon: chore: add check in finality for block height finality parameter to accept finality vote/pubrand babylon#204
• covenant-emulator: chore: Bump babylon and fix pre-approval covenant-emulator#23
• btc-staker: chore: update babylon v0.13 btc-staker#66

Test to check if gov param finality activation height for x/finality works

How to test

$~ make start-deployment-btcstaking-bitcoind-demo

Open the logs for the finality provider and Babylon node

$~ docker logs -f babylondnode0
$~ docker logs -f finality-provider1

At the Babylon node logs at each block you should see that the btc staking module is not activated yet and will be when it reaches the block height of 40

1:07AM INF received complete proposal block hash=610D8322EA9A3BE8F6974B170ED7708A2B556310917C900114646E5A582897E1 height=36 module=consensus
1:07AM INF finalizing commit of block hash=610D8322EA9A3BE8F6974B170ED7708A2B556310917C900114646E5A582897E1 height=36 module=consensus num_txs=1 root=4302C366CA86B21B942ED7EE9343C7F7A18D3F3CA83A670C0743F4C07735FC7E
1:07AM INF module not active yet activationHeight=40 currHeight=36 module=x/btcstaking

When it reaches the block height 40 in Babylon it should process all the events that happened until that block

1:08AM INF received complete proposal block hash=5761A94F5962112E3B98DCFF339480DCEC49E7ABEA7A365116465991C6BCF1BF height=40 module=consensus
1:08AM INF successfully sent BLS signature in vote extension epoch=4 height=40 module=server
1:08AM INF successfully verified vote extension epoch=4 height=40 module=server signer_address=bbnvaloper162glfcphwdwzzjlcz0vyze94v57ed2607z72td
1:08AM INF finalizing commit of block hash=5761A94F5962112E3B98DCFF339480DCEC49E7ABEA7A365116465991C6BCF1BF height=40 module=consensus num_txs=1 root=A46BE350013941786FE03DF0CB72B5134BED6E9BFF4B0B0144002FB8B8081603
1:08AM INF processing events eventsLen=4 module=x/btcstaking
1:08AM INF a new finality provider becomes inactive module=x/btcstaking pk=76b541f579dd9475da3aa5b36c1a16d496fde6ea8a2406219a9099e2c1e95390
1:08AM INF a new finality provider becomes inactive module=x/btcstaking pk=b22d158c5a657317d0f9454f06b6d277d9056a7588351c3598adb3ac347356c7
1:08AM INF a new finality provider becomes inactive module=x/btcstaking pk=25c102ed2db6a541d7fa30c6123b4987db5e0a98766ae093567a3481a168c76b
1:08AM INF Epoching: validator set update of epoch 4: [] module=server

Not sure why it shot out logs that the finality provider become inactive, since it should be the first run of UpdatePowerDist

It becomes inactive because once an fp is registered, it starts with status inactive.
Later at height 44 it is possible to see the logs where the FP becomes active

1:36AM INF finalizing commit of block hash=12CB215B56E146B2CE09A5A03A860AC52AD2718B197B2F532D8046243FA66BC7 height=44 module=consensus num_txs=0 root=80D189352F66FDB42CEA4FA64968ABE07138F13D186A4A10392D16859285A202
1:36AM INF processing events eventsLen=0 module=x/btcstaking
1:36AM INF a new finality provider becomes active module=x/btcstaking pk=0106bacd003e11b2c3441504a109871834750d8d106310630abc3dd887dc2b7e
1:36AM INF a new finality provider becomes active module=x/btcstaking pk=2ca8492f625608a4b81f52cb78c3f964a58a376fdc2cac559a3c0ac597e511d8
1:36AM INF a new finality provider becomes active module=x/btcstaking pk=7fcd4931e36f010c2610a9708138b266c763ffff29df460703972002de037b2e

[RafilxTenfen]

@gitferry any idea on the a new finality provider becomes inactive log?

[gitferry]

@gitferry any idea on the a new finality provider becomes inactive log?

I think the log should be a new finality provider becomes active there. Could you rebase babylon to latest main as the logic is refactored in babylonlabs-io/babylon@35610ce

[gitferry]

In an off-line discussion, this is expected because the fp has not gained any voting power due to pub rand not timestamped after protocol activation, so fp inactive will be first emitted. This will not cause any protocol to subscribers as newly registered fps are considered inactive by default

[gitferry]

Nice work!

[RafilxTenfen]

tests were done and version are already at main