release: rewards v2.1 #214
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
seanmcgary
force-pushed
the
testnet-slashing
branch
from
9418865 to
8e7a974
Compare
Rewards v2.1 state models
# Motivation We need to support Rewards v2.1 calculation. This PR builds on top of #197 which supported the Eigen state models for `OperatorDirectedOperatorSetRewardSubmissions`, `OperatorSetSplits`, `OperatorSetOperatorRegistrations`, `OperatorSetStrategyRegistrations`. # Modifications * Snapshot generation for: `OperatorDirectedOperatorSetRewardSubmissions`, `OperatorSetSplits`, `OperatorSetOperatorRegistrations`, `OperatorSetStrategyRegistrations`. * Refactoring Staging and Final numbering from 11 and 12 to 15 and 16. * Mississippi hard fork for Rewards v2.1. * New Operator Directed Operator Set rewards calculation to be triggered after Mississippi hard fork. * Updated Rewards For All Earners (Programmatic Incentives) calculation to include operators registered to operator sets after Mississippi hard fork. * Staker-operator calculation for Rewards v2.1. # Results Rewards v2.1 calculation. # Tests Existing Rewards tests passing. <img width="660" alt="Screenshot 2025-01-31 at 1 33 38 PM" src="https://github.com/user-attachments/assets/876c2d7c-be22-48b6-a046-55ead8a12530" />
seanmcgary
force-pushed
the
release/rewards-v2.1
branch
from
5b9d766 to
b1e4568
Compare
This PR introduces the concept of a state migration. When introducing new features, it's possible that there is existing transaction data that was not codified into a model that now needs to be. Rather than truncating the database, re-indexing blocks resulting in modifying existing StateRoots, this migration construct allows us to populate new models with existing data, leaving existing StateRoots unchanged, and codifying the changes in a sub-tree whos root is represented in the top-level StateRoot tree.  The StateMigrator specifies which migrations run at which block height for a given chain. Multiple migrations can be run for a single block and will be run in the order specified. Each migration will produce a root representing the changes made. Each of those roots are composed of the same StateRoot structure used at the very top-level, one for each block that was touched in the migration process. In the majority of cases where we're populating models with only a few events, these StateRoot trees will be rather sparse and only include the new model. Each migration works by: * Creating a new instance of the StateManager * Querying the database for the TransactionLogs that need to be processed * Groups them by block number * In the order of blockNumber ascending, feeds each log through the StateManager as it would have if it came through in real time. The same lifecycle of HandleLogStateChange --> CommitFinalState --> GenerateStateRoot is followed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TODO:
staker-operatortable needsoperatorSetId.