Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

finality: refactor voting power table and APIs #222

Merged
merged 19 commits into from
Oct 25, 2024

Conversation

SebastianElvis
Copy link
Member

@SebastianElvis SebastianElvis commented Oct 23, 2024

Second half of #24

This PR moves the voting power table/cache and relevant APIs to x/finality. This includes the following

  • move voting power table KV store to x/finality
  • move voting power dist cache to x/finality
  • move 4 APIs ActiveFinalityProvidersAtHeight, FinalityProviderPowerAtHeight, FinalityProviderCurrentPower, ActivatedHeight to x/finality
  • fix fuzz tests
  • fix e2e tests
  • fix doc
  • fix changelog

Note that this affects many LoCs since it touches a bunch of proto files. The actual modification is much smaller than it looks like.

First step of #24

This PR moves the voting power distribution update algorithm to
`x/finality`. This is a major refactoring that includes

- moving `max_active_finality_providers` parameter to `x/finality`
- moving many functions in `x/btcstaking/power_dist_change.go` and
relevant tests to `x/finality`
- moving test utilities under `x/btcstaking/keeper_test.go` to a new
module `testutil/btcstaking-helper`, and use it for existing tests of
`x/btcstaking` and `x/finality`
- removing the cyclic dependency between `x/btcstaking` and
`x/finality`, as well as their hooks. Now the hooks in these 2 modules
are not necessary, as the only dependency between them is that
`x/finality` will invoke `x/btcstaking`, but not the other way

TODOs in subsequent PRs:

- moving some relevant query APIs to `x/finality`
- moving the voting power dist cache and voting power table KV stores to
`x/finality`
@SebastianElvis SebastianElvis changed the title finality: move voting power dist update to finality module (#216) finality: move voting power table and APIs to finality module Oct 23, 2024
@SebastianElvis SebastianElvis changed the title finality: move voting power table and APIs to finality module finality: refactor voting power table and APIs Oct 23, 2024
First step of #24

This PR moves the voting power distribution update algorithm to
`x/finality`. This is a major refactoring that includes

- moving `max_active_finality_providers` parameter to `x/finality`
- moving many functions in `x/btcstaking/power_dist_change.go` and
relevant tests to `x/finality`
- moving test utilities under `x/btcstaking/keeper_test.go` to a new
module `testutil/btcstaking-helper`, and use it for existing tests of
`x/btcstaking` and `x/finality`
- removing the cyclic dependency between `x/btcstaking` and
`x/finality`, as well as their hooks. Now the hooks in these 2 modules
are not necessary, as the only dependency between them is that
`x/finality` will invoke `x/btcstaking`, but not the other way

TODOs in subsequent PRs:

- moving some relevant query APIs to `x/finality`
- moving the voting power dist cache and voting power table KV stores to
`x/finality`
@SebastianElvis SebastianElvis force-pushed the feat/voting-power-table-refactor branch from a2dd350 to 32295d2 Compare October 23, 2024 04:44
@SebastianElvis SebastianElvis marked this pull request as ready for review October 23, 2024 06:47
@SebastianElvis SebastianElvis requested a review from a team as a code owner October 23, 2024 06:47
Comment on lines +22 to +25
// 0x05 was used for something else in the past
BTCHeightKey = []byte{0x06} // key prefix for the BTC heights
// 0x07 was used for something else in the past
PowerDistUpdateKey = []byte{0x08} // key prefix for power distribution update events
Copy link
Member Author

@SebastianElvis SebastianElvis Oct 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NOTE: this is needed for making software upgrade to work. The new version will have trouble accessing KV store in the old version if we change the keys of KV store.

@SebastianElvis SebastianElvis force-pushed the feat/voting-power-table-refactor branch from 32295d2 to 2b726b2 Compare October 23, 2024 23:53
@SebastianElvis SebastianElvis added consensus breaking change modifies `appHash` of the application api breaking breaks grpc api in non-compatible way labels Oct 24, 2024
Copy link
Member

@gitferry gitferry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the heavy lifting! Great work! No blocker from my side. My major question is given that we have already introduce activation height into the parameter, not sure the old activated height (first height with at least 1 fp with positive voting power) is till useful.

CHANGELOG.md Outdated Show resolved Hide resolved
proto/babylon/finality/v1/genesis.proto Outdated Show resolved Hide resolved
x/btcstaking/types/errors.go Outdated Show resolved Hide resolved
x/btcstaking/types/errors.go Outdated Show resolved Hide resolved
x/finality/keeper/grpc_query.go Outdated Show resolved Hide resolved
x/finality/keeper/grpc_query.go Outdated Show resolved Hide resolved
x/finality/keeper/power_table.go Outdated Show resolved Hide resolved
proto/babylon/finality/v1/query.proto Show resolved Hide resolved
x/finality/keeper/tallying.go Show resolved Hide resolved
@SebastianElvis
Copy link
Member Author

My major question is given that we have already introduce activation height into the parameter, not sure the old activated height (first height with at least 1 fp with positive voting power) is till useful.

I was thinking about this as well, and my answer is that the BTC staking activation height is still needed. There is actually no guarantee when the first BTC delegation will come to the network, so it's possible that it comes before or after the finality activation height.

Probably due to this reason, the IsFinalityActive is defined as finality activation height is reached AND BTC staking activation height is set (ref), and only when IsFinalityActive function returns true the finality module will index/tally blocks and handle jailing. @RafilxTenfen correct me if I'm wrong

@gitferry
Copy link
Member

I was thinking about this as well, and my answer is that the BTC staking activation height is still needed. There is actually no guarantee when the first BTC delegation will come to the network, so it's possible that it comes before or after the finality activation height.
Probably due to this reason, the IsFinalityActive is defined as finality activation height is reached AND BTC staking activation height is set (ref), and only when IsFinalityActive function returns true the finality module will index/tally blocks and handle jailing. @RafilxTenfen correct me if I'm wrong

I think our expectation of introducing this parameter is that after activation, fps can submit votes immediately. Even if there are no delegations or no timestamped pub rand after activation, we should still enable finality-related functionalities.

Maybe it's better to move to https://github.com/babylonlabs-io/pm/pull/85 for discussion as this is out of the scope of this PR. Sorry about that 😅

@SebastianElvis
Copy link
Member Author

Merging this PR now. Any further review could go to #24

@SebastianElvis SebastianElvis merged commit 1be8537 into feat/voting-power-table-refactor Oct 25, 2024
19 checks passed
@SebastianElvis SebastianElvis deleted the move-apis-to-finality branch October 25, 2024 04:26
SebastianElvis added a commit that referenced this pull request Oct 25, 2024
Second half of #24 

This PR moves the voting power table/cache and relevant APIs to
`x/finality`. This includes the following

- [x] move voting power table KV store to `x/finality`
- [x] move voting power dist cache to `x/finality`
- [x] move 4 APIs `ActiveFinalityProvidersAtHeight`,
`FinalityProviderPowerAtHeight`, `FinalityProviderCurrentPower`,
`ActivatedHeight` to `x/finality`
- [x] fix fuzz tests
- [x] fix e2e tests
- [x] fix doc
- [x] fix changelog

Note that this affects many LoCs since it touches a bunch of proto
files. The actual modification is much smaller than it looks like.
SebastianElvis added a commit that referenced this pull request Oct 29, 2024
Second half of #24

This PR moves the voting power table/cache and relevant APIs to
`x/finality`. This includes the following

- [x] move voting power table KV store to `x/finality`
- [x] move voting power dist cache to `x/finality`
- [x] move 4 APIs `ActiveFinalityProvidersAtHeight`,
`FinalityProviderPowerAtHeight`, `FinalityProviderCurrentPower`,
`ActivatedHeight` to `x/finality`
- [x] fix fuzz tests
- [x] fix e2e tests
- [x] fix doc
- [x] fix changelog

Note that this affects many LoCs since it touches a bunch of proto
files. The actual modification is much smaller than it looks like.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api breaking breaks grpc api in non-compatible way consensus breaking change modifies `appHash` of the application
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants