chore: add refence count to FinalityProviderHistoricalRewards
#362
Assignees
Comments
RafilxTenfen
added a commit
that referenced
this issue
Dec 24, 2024
`EventPowerDistUpdate_SlashedFp` and [`RewardBTCStaking`](https://github.com/babylonlabs-io/babylon/blob/b132d16483d2e12ac68be74a524a4b7121edac65/x/incentive/keeper/btc_staking_gauge.go#L19) are called at different blocks. The rewards are being called a few blocks behind and if the slashed fp is pruned in BTC reward tracker data, it fails to find and panics On babylond-deployments an fp is being slashed at block height 46, the call of `RewardBTCStaking` happens at Babylon block 48 but is called to distribute rewards of voting power table from block 44 (which didn't had the FP slashed yet) which then checks for fp rewards for the FP that was pruned at the slashing processed event. ``` 6:04PM INF finalizing commit of block hash=153E869F7B0056A9CD8208301F2019FFACA2BEFBBB35AEADF70DCA14C15F3972 height=47 module=consensus num_txs=2 root=62B5F025459DEEBE2EE6F5D869C5BCBE903299FF80825FB9DE62551E6B725D52 ERR CONSENSUS FAILURE!!! err="failed to add fp rewards for btc delegation bbn1wwkaq6z3kdkekm7ltwxng4ftvzux8gzp2xjx8d at height 44: finality provider current rewards not found ``` ```shell $~ babylond q btcstaking finality-providers -o json | jq ... { "description": { "moniker": "Finality Provider 0", "identity": "", "website": "", "security_contact": "", "details": "" }, "commission": "0.050000000000000000", "addr": "bbn1wwkaq6z3kdkekm7ltwxng4ftvzux8gzp2xjx8d", "btc_pk": "6ba387c315dc6105ec02b50684593505103a9f13452d3a597c16ac2f22b924dc", "pop": { "btc_sig_type": "BIP340", "btc_sig": "Q3PcfiKT0fwWOVx95rjV+mQvI/juTbYIV84Hfz2NAmQByiHRXz8OWnFbyugJgOrd/TrqR+6BOgtr10bZUFDFbA==" }, "slashed_babylon_height": "46", "slashed_btc_height": 131, "height": "46", "jailed": false, "highest_voted_height": 45 }, ``` Basically, this means we are processing the rewards a few blocks down the road after the slash and then it is not possible to prune the data for reward tracker until that fp slashed height is processed. The fix for the time being: do nothing at the btc reward tracker structures if some fp gets slashed just continue to store that data. In the future during the issue #362 we can properly handle the pruning of slashed finality provider data
RafilxTenfen
added a commit
that referenced
this issue
Dec 24, 2024
`EventPowerDistUpdate_SlashedFp` and [`RewardBTCStaking`](https://github.com/babylonlabs-io/babylon/blob/b132d16483d2e12ac68be74a524a4b7121edac65/x/incentive/keeper/btc_staking_gauge.go#L19) are called at different blocks. The rewards are being called a few blocks behind and if the slashed fp is pruned in BTC reward tracker data, it fails to find and panics On babylond-deployments an fp is being slashed at block height 46, the call of `RewardBTCStaking` happens at Babylon block 48 but is called to distribute rewards of voting power table from block 44 (which didn't had the FP slashed yet) which then checks for fp rewards for the FP that was pruned at the slashing processed event. ``` 6:04PM INF finalizing commit of block hash=153E869F7B0056A9CD8208301F2019FFACA2BEFBBB35AEADF70DCA14C15F3972 height=47 module=consensus num_txs=2 root=62B5F025459DEEBE2EE6F5D869C5BCBE903299FF80825FB9DE62551E6B725D52 ERR CONSENSUS FAILURE!!! err="failed to add fp rewards for btc delegation bbn1wwkaq6z3kdkekm7ltwxng4ftvzux8gzp2xjx8d at height 44: finality provider current rewards not found ``` ```shell $~ babylond q btcstaking finality-providers -o json | jq ... { "description": { "moniker": "Finality Provider 0", "identity": "", "website": "", "security_contact": "", "details": "" }, "commission": "0.050000000000000000", "addr": "bbn1wwkaq6z3kdkekm7ltwxng4ftvzux8gzp2xjx8d", "btc_pk": "6ba387c315dc6105ec02b50684593505103a9f13452d3a597c16ac2f22b924dc", "pop": { "btc_sig_type": "BIP340", "btc_sig": "Q3PcfiKT0fwWOVx95rjV+mQvI/juTbYIV84Hfz2NAmQByiHRXz8OWnFbyugJgOrd/TrqR+6BOgtr10bZUFDFbA==" }, "slashed_babylon_height": "46", "slashed_btc_height": 131, "height": "46", "jailed": false, "highest_voted_height": 45 }, ``` Basically, this means we are processing the rewards a few blocks down the road after the slash and then it is not possible to prune the data for reward tracker until that fp slashed height is processed. The fix for the time being: do nothing at the btc reward tracker structures if some fp gets slashed just continue to store that data. In the future during the issue #362 we can properly handle the pruning of slashed finality provider data
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FinalityProviderHistoricalRewardscan have a reference count (How many structures are using it) and when it reaches zero it should delete from the databaseJust like it is done in the cosmos-sdk
The text was updated successfully, but these errors were encountered: