feat: slashing release

[8sunyuan]

Updated 1/03/2025

Contract Descriptions

AVSDirectory

• Currently on mainnet, all operator<>AVS registration takes place on the AVSDirectory contract which AVS contracts call into along with an operator signature to confirm operator registration in the EigenLayer protocol. This registration/deregistration flow will change in the Slashing release with the introduction of operatorSets. More on this below...
• The AVSDirectory contract will be unchanged and allow for backwards compatibility. It will be deprecated (all data indexing ignored) at some future date when AVSs have migrated their systems over to the newly defined contract, the AllocationManager.

New Core contract: AllocationManager! (basically the Slasher contract)

• Operator<>AVS registration/deregistration should be migrated here for existing AVSs if they wish to utilize Slashing functionality within EigenLayer. In addition to a different address entrypoint(previously AVSDirectory), the flow has actually changed to an operator registering themselves with the AllocationManager, and the AllocationManager will then call the corresponding callback setup by the AVS themselves. This is contrary to what exists today on the AVSDirectory which expects to be called by an AVS with an operator signature providing "registration consent".
• AVSs now have the ability to define subsets of operators called operatorSets. This allows for more granularity around defining slashing and rewards conditions for their different operators and their tasks. An operator can be exclusively in one operatorSet or many all at once. It is up to the AVS to determine their own registration/deregistration conditions and the Strategies that are in each of their operatorSets.
• The AllocationManager is the Slasher contract, pending decision on rename or just changing back to Slasher.
• This implements "unique security", stake is not reused across AVSs/operatorSets and operators allocate slashable proportions to each operatorSet. Imagine this as a pie chart where each slice gets given to a different operatorSet.
• modifyAllocations can be called by an operator to configure for a given operatorSet, the slashable proportions for each Strategies in the operatorSet. Ex. If an AVS operatorSet has stETH and rETH Strategies in their operatorSet, as an operator I can allocate 50% of my delegated stETH shares and 25% of my delegated rETH shares to be slashable by this operatorSet. An allocation can be thought of as the slashable proportion defined over the tuple (operator, operatorSet, Strategy).
• slashOperator, called by an AVS, slashes an operator for the specific operatorSet. The AVS will pass in as calldata an array of Strategies and wadsToSlash respsectively to slash the operator for. Note that the Strategies passed in must already be in the operatorSet’s list of Strategies. This function slashes from current magnitude as well as queued deallocations. Whatever magnitude is slashed is also decremented from the maxMagnitude from the (operator, Strategy) tuple.
• Deallocations are slashable while pending. Pending allocations on the other hand are not slashable (referring to the increased amount) because allocations are increases that come existing proportional amounts that are not slashable. This is kept track of by the encumberedMagnitude value, increasing on any allocations, which can go up to a maximum of your maxMagnitude(by default maxMagnitude is 1e18, but decreases every time slashed).
• Deallocation delays are fixed across all operators, providing a minimum security guarantee for AVSs about how much stake they have securing their systems.
• Allocation delays are configurable on a per operator basis. Updating the allocationDelay has a delay for it to take effect itself. Open PR for this is here.

StrategyManager/EigenPodManager/DelegationManager - Changes to Deposits/Withdrawals

Shares are changed in a lot of ways with the introduction of Slashing with a lot more complex accounting, most of which can be found in SlashingLib.sol and the deposit/withdrawal flows. Below is an explanation on the types of 'shares' in the system.

1. depositShares: These are the shares representing the amount of Strategy shares a staker has added to the system, either through deposits in the StrategyManager or positive shares increases in the EigenPodManager. Note that these can be compared 1:1 with the shares of the underlying Strategies. If you are delegated and deposit or you delegate with existing shares, then your operator shares will increase by the exact amount of these depositShares.
   The amount you can withdraw is dependent however on withdrawableShares, see more below...
   Location: StrategyManager - stakerDepositShares mapping
   EigenPodManager - podOwnerDepositShares mapping

2. operatorShares: This is the delegated stake an operator has from all their delegated stakers; this can also be termed 'delegated' shares. An operator's operatorShares is also the summation of all their delegated stakers withdrawable shares. This is because operatorShares increase on each delegated staker deposit and decreases from withdrawals and slashed shares. The amount decreased from withdrawals are also scaled down depending on if any slashing has applied to the staker and their depositShares.
   Location: DelegationManager - operatorShares mapping

3. withdrawableShares: This is the amount of withdrawable shares a staker can queue withdraw. Now if a staker is not delegated, then the following is true withdrawableShares == depositShares because they cannot be slashed. However if they are delegated to an operator and their operator got slashed while they had depositShares delegated to them, then their withdrawableShares are less than their depositShares. This value is not in storage but read by taking the staker's depositShares and scaling it down depending on if any slashing has affected their stake.
   Location: DelegationManager - getWithdrawableShares() function
   3a. scaledShares: You can see this in struct Withdrawal when queuing a withdrawal. We calculate withdrawableShares by some clever scaling factors and accounting but one thing we want to ensure is that withdrawals are still slashable while in the queue. This is done by dividing withdrawableShares at queue time by the delegated operator's maxMagnitude, and upon completion multiplying it by the maxMagnitude at the earliest withdrawal completion time. This will account for the proportional amount of shares slashed and decrement from withdrawn shares accordingly.
   Since we read the maxMagnitude while queuing the withdrawal, this design is more for convenience and optimizing reads.
   Note: If the strategy is the beaconChainStrategy this is also accounted for in a similar way.
   Location: IDelegationManager - struct Withdrawal

Additional Notes:

• DM: EIGEN strategy delay is currently set to 7 days so all the strategies currently have the same delay. We remove strategy specific delays entirely here but all withdrawals will be configured to be the same as the deallocation delay.
• DM: We've abstracted the EPM and SM behind a unified IShareManager interface
• Accounting NOTEs:
  • depositScalingFactor is the k value used in the accounting docs
  • stakerDepositShares is s
  • operatorShares is op
  • maxMagnitude is m read from the AllocationManager
• Using OZ CheckpointsUpgradeable library in the AllocationManager to keep track of historically timestamped magnitude values. This is required for staker withdrawal completion where the timestamped maxMagnitude value at completion may not be the current so we have a lookup for that. We renamed the Checkpoints library to Snapshots to avoid confusion with EigenPod checkpoints.
• 0.8.27 custom errors with requires (saves a lot of bytecode size)
• thirdPartyTransfersForbidden is removed entirely. This mapping will be deprecated and never read from again.

TODOs:

• burning of slashed shares
  • EigenPodManager shares: requires scoping with Pectra
• EigenPodManager: Pectra related changes to EigenPod proofs as well as EIP7002 and burning of shares. Scope for first version of Slashing TBD

[ypatil12]

Review on alloc/dealloc

[MinisculeTarantula]

require allocationDelay being set when calling modifyAllocations. Based on current implementation of a default allocation delay, if a shorter delay is set, it is possible to create a pending magnitudeUpdate that has a timestamp thats earlier than a already existing pending update. We need the checkpoints history to be asc sorted and figuring out some insertion method instead of pushing the history seems like too much overhead complexity.

Would it be bad / hard / undesirable to enforce this ordering on the checkpoints history level?

I would suggest that if an attempt is made to push an entry with a timestamp that is earlier than the timestamp of the previous entry, either (a) it's simply not allowed or (b) the new entry has its timestamp modified to match (or be 1 higher? not sure if the ascending ordering you have is strict or non-strict).

Perhaps some option (c) could work where you keep the original timestamp but overwrite the intentions of the other entry? IDK if that would be incompatible with other aspects of the storage model though.

I was initially thinking option (b) was the most logical but modifying entries before pushing them can be messy, especially if the entry or its contents is used elsewhere (e.g. if the timestamp is emitted in events, its hard to make sure the event emits the correct timestamp when you have conditional logic for modifying it).

[ypatil12]

Minor slashing comments