Skip to content

docs: wip slashing docs #925

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Jan 1, 2025
Merged

docs: wip slashing docs #925

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a9aac4e
docs: add slashing docs
nadir-akhtar Dec 4, 2024
adf2f33
chore: bindings
wadealexc Dec 30, 2024
2545132
docs: fixed commenting and updated queue withdrawal docs
wadealexc Dec 31, 2024
487d4a5
docs: minor cleanup
wadealexc Jan 1, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 26 additions & 12 deletions docs/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,11 @@
[middleware-repo]: https://github.com/Layr-Labs/eigenlayer-middleware/
[elip-002]: https://github.com/eigenfoundation/ELIPs/blob/main/ELIPs/ELIP-002.md

## EigenLayer Docs - v0.4.0 Release
## EigenLayer Docs - v1.0.0 Release

This repo contains the EigenLayer core contracts, which enable restaking of liquid staking tokens (LSTs) and beacon chain ETH to secure new services, called AVSs (actively validated services). For more info on AVSs, check out the EigenLayer middleware contracts [here][middleware-repo].
This repo contains the EigenLayer core contracts, which enable restaking of liquid staking tokens (LSTs), beacon chain ETH, and permissionlessly deployed ERC20 Strategies to secure new services called AVSs (actively validated services). For more info on AVSs, check out the EigenLayer middleware contracts [here][middleware-repo].

This document provides an overview of system components, contracts, and user roles. Further documentation on the major system contracts can be found in [/core](./core/).
This document provides an overview of system components, contracts, and user roles and is up-to-date with the latest [ELIP-002][elip-002]. Further documentation on the major system contracts can be found in [/core](./core/).

#### Contents

Expand All @@ -14,7 +15,7 @@ This document provides an overview of system components, contracts, and user rol
* [`DelegationManager`](#delegationmanager)
* [`RewardsCoordinator`](#rewardscoordinator)
* [`AVSDirectory`](#avsdirectory)
* [`Slasher`](#slasher)
* [`AllocationManager`](#allocationmanager)
* [Roles and Actors](#roles-and-actors)
* [Common User Flows](#common-user-flows)
* [Depositing Into EigenLayer](#depositing-into-eigenlayer)
Expand Down Expand Up @@ -53,7 +54,7 @@ See full documentation in:
These contracts work together to enable restaking for ERC20 tokens supported by EigenLayer:
* The `StrategyManager` acts as the entry and exit point for any supported tokens in EigenLayer. It handles deposits into LST-specific strategies, and manages accounting+interactions between users with restaked LSTs and the `DelegationManager`.
* `StrategyFactory` allows anyone to deploy strategies to support deposits/withdrawals for new ERC20 tokens
* `StrategyBaseTVLLimits` is deployed as multiple separate instances, one for each supported token. When a user deposits into a strategy through the `StrategyManager`, this contract receives the tokens and awards the user with a proportional quantity of shares in the strategy. When a user withdraws, the strategy contract sends the LSTs back to the user.
* `StrategyBaseTVLLimits` is deployed as multiple separate instances, one for each supported token. When a user deposits into a strategy through the `StrategyManager`, this contract receives the tokens and awards the user with a proportional quantity of deposit shares in the strategy. When a user withdraws, the strategy contract sends the LSTs back to the user.

See full documentation in [`/core/StrategyManager.md`](./core/StrategyManager.md).

Expand All @@ -63,7 +64,8 @@ See full documentation in [`/core/StrategyManager.md`](./core/StrategyManager.md
| -------- | -------- | -------- |
| [`DelegationManager.sol`](../src/contracts/core/DelegationManager.sol) | Singleton | Transparent proxy |

The `DelegationManager` sits between the `EigenPodManager` and `StrategyManager` to manage delegation and undelegation of Stakers to Operators. Its primary features are to allow Operators to register as Operators (`registerAsOperator`), to keep track of shares being delegated to Operators across different strategies, and to manage withdrawals on behalf of the `EigenPodManager` and `StrategyManager`.
The `DelegationManager` sits between the `EigenPodManager` and `StrategyManager` to manage delegation and undelegation of Stakers to Operators. Its primary features are to allow Operators to register as Operators (`registerAsOperator`), to keep track of delegated shares to Operators across different strategies, and to manage withdrawals on behalf of the `EigenPodManager` and `StrategyManager`.
The `DelegationManager` is tightly coupled with the `AllocationManager` as withdrawable shares for a Staker is dependent on reading state from the `AllocationManager`. That is, a staker's withdrawable shares is decreased in the event their delegated Operator was slashed by an AVS (more specifically an operatorSet but more on this later).

See full documentation in [`/core/DelegationManager.md`](./core/DelegationManager.md).

Expand All @@ -86,21 +88,33 @@ See full documentation in [`/core/RewardsCoordinator.md`](./core/RewardsCoordina
| -------- | -------- | -------- |
| [`AVSDirectory.sol`](../src/contracts/core/AVSDirectory.sol) | Singleton | Transparent proxy |

The `AVSDirectory` handles interactions between AVSs and the EigenLayer core contracts. Once registered as an Operator in EigenLayer core (via the `DelegationManager`), Operators can register with one or more AVSs (via the AVS's contracts) to begin providing services to them offchain. As a part of registering with an AVS, the AVS will record this registration in the core contracts by calling into the `AVSDirectory`.
##### Note: This contract is left unchanged for backwards compatability. Operator<>AVS Registrations are to be replaced entirely with the `AllocationManager` and this contract will be deprecated(no longer indexed) in a future release.

The `AVSDirectory` handles interactions between AVSs and the EigenLayer core contracts. Once registered as an Operator in EigenLayer core (via the `DelegationManager`), Operators can register with one or more AVSs (via the AVS's contracts) to begin providing services to them offchain. As a part of registering with an AVS, the AVS will record this registration in the core contracts by calling into the `AVSDirectory`.

See full documentation in [`/core/AVSDirectory.md`](./core/AVSDirectory.md).

For more information on AVS contracts, see the [middleware repo][middleware-repo].

#### Slasher
#### AllocationManager

| File | Type | Proxy |
| -------- | -------- | -------- |
| [`Slasher.sol`](../src/contracts/core/Slasher.sol) | - | - |
| [`AllocationManager.sol`](../src/contracts/core/AllocationManager.sol) | Singleton | Transparent proxy |

The `AllocationManager` is meant to replace the AVSDirectory with the introduction of OperatorSets as well as introduce the core functionality of Slashing. It handles several use cases:
* AVSs can create OperatorSets and can define the EigenLayer Strategies within them
* Operators can register/deregister with AVS operatorSets
* Operators can make slashable security commitments to an operatorSet by allocating a proportion of their total delegated stake for a Strategy to be slashable. Ex. As an operator, I can allocate 50% of my stETH to be slashable by a specific OperatorSet
* AVSs can slash an operator (without being objectively attributable) who has slashable allocations to the AVS's corresponding OperatorSet.

See full documentation in [`/core/AllocationManager.md`](./core/AllocationManager.md).

---

#### Shares Accounting

<p align="center"><b>
🚧 The Slasher contract is under active development and its interface expected to change. We recommend writing slashing logic without integrating with the Slasher at this point in time. Although the Slasher is deployed, it will remain completely paused/unusable during M2. No contracts interact with it, and its design is not finalized. 🚧
</b><p>
TODO

---

Expand Down
167 changes: 116 additions & 51 deletions docs/core/AVSDirectory.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,80 +1,145 @@
[middleware-repo]: https://github.com/Layr-Labs/eigenlayer-middleware/
# AVSDirectory

## AVSDirectory
## Overview

| File | Type | Proxy |
| -------- | -------- | -------- |
| [`AVSDirectory.sol`](../../src/contracts/core/AVSDirectory.sol) | Singleton | Transparent proxy |
The AVSDirectory contract is where registration relationships are defined between AVSs, operatorSets, and operators. Registration and deregistration are used in the protocol to activate and deactivate slashable stake allocations. They're also used to make the protocol more legible to external integrations.

The `AVSDirectory` handles interactions between AVSs and the EigenLayer core contracts. Once registered as an Operator in EigenLayer core (via the `DelegationManager`), Operators can register with one or more AVSs (via the AVS's contracts) to begin providing services to them offchain. As a part of registering with an AVS, the AVS will record this registration in the core contracts by calling into the `AVSDirectory`.
The slashing release introduces the concept of operatorSets, which are simply an (address, uint32) pair that the define an AVS and an operator set ID. OperatorSets are used to group operators by different tasks and sets of tokens. For example, EigenDA has an ETH/LST operatorSet and an Eigen operatorSet. A bridge may have on operatorSet for all operators that serve a particular chain. Overall, operatorSets are mainly used for protocol legibility.

For more information on AVS contracts, see the [middleware repo][middleware-repo].
Functionality is provided for AVSs to migrate from an pre-operatorSet registration model to an operatorSet model. Direct to AVS registration is still supported for AVSs that have not migrated to the operatorSet model, but is slated to be deprecated soon in the future.

Currently, the only interactions between AVSs and the core contracts is to track whether Operators are currently registered for the AVS. This is handled by two methods:
* [`AVSDirectory.registerOperatorToAVS`](#registeroperatortoavs)
* [`AVSDirectory.deregisterOperatorFromAVS`](#deregisteroperatorfromavs)
## `becomeOperatorSetAVS`
```solidity
/**
* @notice Sets the AVS as an operator set AVS, preventing legacy M2 operator registrations.
*
* @dev msg.sender must be the AVS.
*/
function becomeOperatorSetAVS() external;
```

AVSs call this to become an operator set AVS. Once an AVS becomes an operator set AVS, they can no longer register operators via the legacy M2 registration path. This is a seperate function to help avoid accidental migrations to the operator set AVS model.

In a future release, this contract will implement additional interactions that relate to (i) rewarding Operators for the services they provide and (ii) slashing Operators that misbehave. Currently, these features are not implemented.
## `createOperatorSets`
```solidity
/**
* @notice Called by an AVS to create a list of new operatorSets.
*
* @param operatorSetIds The IDs of the operator set to initialize.
*
* @dev msg.sender must be the AVS.
*/
function createOperatorSets(
uint32[] calldata operatorSetIds
) external;
```

---
AVSs use this function to create a list of new operator sets.They must call this function before they add any operators to the operator sets. The operator set IDs must be not already exist.

#### `registerOperatorToAVS`
This can be called before the AVS becomes an operator set AVS. (TODO: we should make this so that it can only be called after the AVS becomes an operator set AVS?)

## `migrateOperatorsToOperatorSets`
```solidity
function registerOperatorToAVS(
address operator,
ISignatureUtils.SignatureWithSaltAndExpiry memory operatorSignature
)
external
onlyWhenNotPaused(PAUSED_OPERATOR_REGISTER_DEREGISTER_TO_AVS)
/**
* @notice Called by an AVS to migrate operators that have a legacy M2 registration to operator sets.
*
* @param operators The list of operators to migrate
* @param operatorSetIds The list of operatorSets to migrate the operators to
*
* @dev The msg.sender used is the AVS
* @dev The operator can only be migrated at most once per AVS
* @dev The AVS can no longer register operators via the legacy M2 registration path once it begins migration
* @dev The operator is deregistered from the M2 legacy AVS once migrated
*/
function migrateOperatorsToOperatorSets(
address[] calldata operators,
uint32[][] calldata operatorSetIds
) external;
```

Allows the caller (an AVS) to register an `operator` with itself, given the provided signature is valid.
AVSs that launched before the slashing release can use this function to migrate operators that have a legacy M2 registration to operator sets. Each operator can only be migrated once for the AVS and the AVS can no longer register operators via the legacy M2 registration path once it begins migration.

*Effects*:
* Sets the `operator's` status to `REGISTERED` for the AVS

*Requirements*:
* Pause status MUST NOT be set: `PAUSED_OPERATOR_REGISTER_DEREGISTER_TO_AVS`
* `operator` MUST already be a registered Operator (via the `DelegationManager`)
* `operator` MUST NOT already be registered with the AVS
* `operatorSignature` must be a valid, unused, unexpired signature from the `operator`. The signature is an ECDSA signature by the operator over the [`OPERATOR_AVS_REGISTRATION_TYPEHASH`](../../src/contracts/core/DelegationManagerStorage.sol). Expiry is a utc timestamp in seconds. Salt is used only once per signature to prevent replay attacks.
## `registerOperatorToOperatorSets`
```solidity
/**
* @notice Called by AVSs to add an operator to list of operatorSets.
*
* @param operator The address of the operator to be added to the operator set.
* @param operatorSetIds The IDs of the operator sets.
* @param operatorSignature The signature of the operator on their intent to register.
*
* @dev msg.sender is used as the AVS.
*/
function registerOperatorToOperatorSets(
address operator,
uint32[] calldata operatorSetIds,
ISignatureUtils.SignatureWithSaltAndExpiry memory operatorSignature
) external;
```

*As of M2*:
* Operator registration/deregistration does not have any sort of consequences for the Operator or its shares. Eventually, this will tie into rewards for services and slashing for misbehavior.
AVSs use this function to add an operator to a list of operator sets. The operator's signature is required to confirm their intent to register. If the operator has a slashable stake allocation to the AVS, it takes effect when the operator is registered (and up to `DEALLOCATION_DELAY` seconds after the operator is deregistered).

#### `deregisterOperatorFromAVS`
The operator set must exist before the operator can be added to it and the AVS must be an operator set AVS.

## `deregisterOperatorFromOperatorSets`
```solidity
function deregisterOperatorFromAVS(
address operator
)
external
onlyWhenNotPaused(PAUSED_OPERATOR_REGISTER_DEREGISTER_TO_AVS)
/**
* @notice Called by AVSs to remove an operator from an operator set.
*
* @param operator The address of the operator to be removed from the operator set.
* @param operatorSetIds The IDs of the operator sets.
*
* @dev msg.sender is used as the AVS.
*/
function deregisterOperatorFromOperatorSets(address operator, uint32[] calldata operatorSetIds) external;
```

Allows the caller (an AVS) to deregister an `operator` with itself
AVSs use this function to remove an operator from an operator set. The operator is still slashable for its slashable stake allocation to the AVS until `DEALLOCATION_DELAY` seconds after the operator is deregistered.

The operator must be registered to the operator set before they can be deregistered from it.

*Effects*:
* Sets the `operator's` status to `UNREGISTERED` for the AVS

*Requirements*:
* Pause status MUST NOT be set: `PAUSED_OPERATOR_REGISTER_DEREGISTER_TO_AVS`
* `operator` MUST already be registered with the AVS
## `forceDeregisterFromOperatorSets`
```solidity
/**
* @notice Called by an operator to deregister from an operator set
*
* @param operator The operator to deregister from the operatorSets.
* @param avs The address of the AVS to deregister the operator from.
* @param operatorSetIds The IDs of the operator sets.
* @param operatorSignature the signature of the operator on their intent to deregister or empty if the operator itself is calling
*
* @dev if the operatorSignature is empty, the caller must be the operator
* @dev this will likely only be called in case the AVS contracts are in a state that prevents operators from deregistering
*/
function forceDeregisterFromOperatorSets(
address operator,
address avs,
uint32[] calldata operatorSetIds,
ISignatureUtils.SignatureWithSaltAndExpiry memory operatorSignature
) external;
```

*As of M2*:
* Operator registration/deregistration does not have any sort of consequences for the Operator or its shares. Eventually, this will tie into rewards for services and slashing for misbehavior.
Operators can use this function to deregister from an operator set without requiring the AVS to sign off on the deregistration. This function is intended to be used in cases where the AVS contracts are in a state that prevents operators from deregistering (either malicious or unintentional).

#### `cancelSalt`
Operators can also deallocate their slashable stake allocation seperately to avoid slashing risk, so this function is mainly for external integrations to interpret the correct state of the protocol.

## `updateAVSMetadataURI`
```solidity
function cancelSalt(bytes32 salt) external
/**
* @notice Called by an AVS to emit an `AVSMetadataURIUpdated` event indicating the information has updated.
*
* @param metadataURI The URI for metadata associated with an AVS.
*
* @dev Note that the `metadataURI` is *never stored* and is only emitted in the `AVSMetadataURIUpdated` event.
*/
function updateAVSMetadataURI(
string calldata metadataURI
) external;
```

Allows the caller (an Operator) to cancel a signature salt before it is used to register for an AVS.
This function allows an AVS to update the metadata URI associated with the AVS. The metadata URI is never stored on-chain and is only emitted in the `AVSMetadataURIUpdated` event.

*Effects*:
* Sets `operatorSaltIsSpent[msg.sender][salt]` to `true`
## View Functions

*Requirements*:
* Salt MUST NOT already be cancelled
See the [AVS Directory Inteface](../../../src/contracts/interfaces/IAVSDirectory.sol) for view functions.
Loading
Loading