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

feat: slashing #167

Open
wants to merge 31 commits into
base: master
Choose a base branch
from
Open

feat: slashing #167

wants to merge 31 commits into from

Conversation

seanmcgary
Copy link
Member

@seanmcgary seanmcgary commented Dec 19, 2024

TODO:

  • Add AllocationManageraddress for mainnet to config
  • Add/Update ABIs for mainnet
  • Update fork dates and height for mainnet appropriately

@seanmcgary seanmcgary requested a review from a team as a code owner December 19, 2024 19:16
@seanmcgary seanmcgary requested a review from 0xrajath December 19, 2024 19:16
@seanmcgary seanmcgary changed the title Release: Slashing Mainnet Release: Slashing Dec 19, 2024
@seanmcgary seanmcgary changed the base branch from master to testnet December 19, 2024 19:17
@seanmcgary seanmcgary force-pushed the testnet-slashing branch 4 times, most recently from ba0c45a to 929564e Compare December 20, 2024 05:59
@seanmcgary seanmcgary force-pushed the testnet-slashing branch 6 times, most recently from 836430e to 683ab25 Compare January 9, 2025 22:03
@seanmcgary seanmcgary changed the title Mainnet Release: Slashing feat: slashing Jan 14, 2025
@seanmcgary seanmcgary force-pushed the testnet branch 2 times, most recently from 79adfb0 to b8462c9 Compare January 16, 2025 14:45
Base automatically changed from testnet to master January 16, 2025 21:23
@seanmcgary seanmcgary added this to the v3.0.0 - Slashing milestone Jan 27, 2025
@seanmcgary seanmcgary force-pushed the testnet-slashing branch 3 times, most recently from be50e7d to 9418865 Compare January 29, 2025 15:47
seanmcgary and others added 29 commits February 13, 2025 22:51
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"
/>
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.

![Screenshot 2025-02-04 at 8 25
47 AM](https://github.com/user-attachments/assets/149021bc-7457-49f0-b4f2-2091a4d0b46c)

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.
rewards v2.1 implementation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants