From cca8420d88e31435fd1ccf7e022fbcfd511fc0f3 Mon Sep 17 00:00:00 2001 From: wadealexc Date: Wed, 6 Dec 2023 21:00:25 +0000 Subject: [PATCH] docs: add docs very wip --- docs/BLSRegistryCoordinatorWithIndices.md | 278 ++++++++++++++---- docs/Middleware-registration-operator-flow.md | 15 - ...eyRegistry.md => Old_BLSPubkeyRegistry.md} | 0 docs/Old_BLSRegistryCoordinatorWithIndices.md | 86 ++++++ ...{IndexRegistry.md => Old_IndexRegistry.md} | 0 ...{StakeRegistry.md => Old_StakeRegistry.md} | 0 docs/README.md | 78 +++++ docs/{ => experimental}/AVS-Guide.md | 8 +- docs/registries/BLSPubkeyRegistry.md | 83 ++++++ docs/registries/IndexRegistry.md | 83 ++++++ docs/registries/StakeRegistry.md | 83 ++++++ 11 files changed, 633 insertions(+), 81 deletions(-) delete mode 100644 docs/Middleware-registration-operator-flow.md rename docs/{BLSPubkeyRegistry.md => Old_BLSPubkeyRegistry.md} (100%) create mode 100644 docs/Old_BLSRegistryCoordinatorWithIndices.md rename docs/{IndexRegistry.md => Old_IndexRegistry.md} (100%) rename docs/{StakeRegistry.md => Old_StakeRegistry.md} (100%) create mode 100644 docs/README.md rename docs/{ => experimental}/AVS-Guide.md (98%) create mode 100644 docs/registries/BLSPubkeyRegistry.md create mode 100644 docs/registries/IndexRegistry.md create mode 100644 docs/registries/StakeRegistry.md diff --git a/docs/BLSRegistryCoordinatorWithIndices.md b/docs/BLSRegistryCoordinatorWithIndices.md index 5acd89e1..d9642dfe 100644 --- a/docs/BLSRegistryCoordinatorWithIndices.md +++ b/docs/BLSRegistryCoordinatorWithIndices.md @@ -1,86 +1,240 @@ -# BLSRegistryCoordinatorWithIndices +## BLSRegistryCoordinatorWithIndices -This contract is deployed for every AVS and serves as the main entrypoint for operators to register and deregister from the AVS. In addition, it is where the AVS defines its operator churn parameters. +| File | Type | Proxy? | +| -------- | -------- | -------- | +| [`BLSRegistryCoordinatorWithIndices.sol`](../src/BLSRegistryCoordinatorWithIndices.sol) | Singleton | Transparent proxy | -## Flows +TODO -### registerOperator + -The RegistryCoordinator then -1. Registers the operator's BLS public key with the [BLSPubkeyRegistry](BLSPubkeyRegistry.md) and notes the hash of their public key as their operator id -2. Registers the operator with the [StakeRegistry](./StakeRegistry.md) -3. Registers the operator with the [IndexRegistry](./IndexRegistry.md) -4. Stores the quorum bitmap of the operator using the following struct: +#### High-level Concepts + +This document organizes methods according to the following themes (click each to be taken to the relevant section): +* [Registering and Deregistering](#registering-and-deregistering) +* [Updating Registered Operators](#updating-registered-operators) +* [System Configuration](#system-configuration) + +#### Important State Variables + +TODO + + + +#### Important Definitions + +TODO + + + +--- + +### Registering and Deregistering + +These methods allow operators to register for/deregister from one or more quorums, and are the primary entry points to the middleware contracts as a whole: +* [`registerOperator`](#registeroperator) +* [`registerOperatorWithChurn`](#registeroperatorwithchurn) +* [`deregisterOperator`](#deregisteroperator) +* [`ejectOperator`](#ejectoperator) + +#### `registerOperator` + +```solidity +function registerOperator( + bytes calldata quorumNumbers, + string calldata socket +) + external + onlyWhenNotPaused(PAUSED_REGISTER_OPERATOR) ``` -/** - * @notice Data structure for storing info on quorum bitmap updates where the `quorumBitmap` is the bitmap of the - * quorums the operator is registered for starting at (inclusive)`updateBlockNumber` and ending at (exclusive) `nextUpdateBlockNumber` - * @dev nextUpdateBlockNumber is initialized to 0 for the latest update - */ -struct QuorumBitmapUpdate { - uint32 updateBlockNumber; - uint32 nextUpdateBlockNumber; - uint192 quorumBitmap; -} + +Allows an operator to register for one or more quorums, if they + +*Effects*: +* + +*Requirements*: +* + +#### `registerOperatorWithChurn` + +```solidity +function registerOperatorWithChurn( + bytes calldata quorumNumbers, + string calldata socket, + OperatorKickParam[] calldata operatorKickParams, + SignatureWithSaltAndExpiry memory churnApproverSignature +) + external + onlyWhenNotPaused(PAUSED_REGISTER_OPERATOR) ``` -Operators can be registered for certain quorums and later register for other (non-overlapping) quorums. +TODO + +*Effects*: +* + +*Requirements*: +* -### If quorum full +#### `deregisterOperator` -The following struct is defined for each quorum +```solidity +function deregisterOperator( + bytes calldata quorumNumbers +) + external + onlyWhenNotPaused(PAUSED_DEREGISTER_OPERATOR) ``` -/** - * @notice Data structure for storing operator set params for a given quorum. Specifically the - * `maxOperatorCount` is the maximum number of operators that can be registered for the quorum - * `kickBIPsOfOperatorStake` is the multiple (in basis points) of stake that a new operator must have, as compared the operator that they are kicking out of the quorum - * `kickBIPsOfTotalStake` is the fraction (in basis points) of the total stake of the quorum that an operator needs to be below to be kicked. - */ -struct OperatorSetParam { - uint32 maxOperatorCount; - uint16 kickBIPsOfOperatorStake; - uint16 kickBIPsOfTotalStake; -} + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `ejectOperator` + +```solidity +function ejectOperator( + address operator, + bytes calldata quorumNumbers +) + external + onlyEjector ``` -If any of the quorums is full (number of operators in it is `maxOperatorCount`), the newly registering operator must provide the public key of another operator to be kicked. The new and kicked operator must satisfy the two conditions: -1. the new operator has an amount of stake that is at least `kickBIPsOfOperatorStake` multiple of the kicked operator's stake -2. the kicked operator has less than `kickBIPsOfTotalStake` fraction of the quorum's total stake +TODO + +*Effects*: +* + +*Requirements*: +* + +--- + +### Updating Registered Operators + +TODO -The provided operators are deregistered from the respective quorums that are full which the registering operator is registering for. Since the operators being kicked may not be the operators with the least stake, the RegistryCoordinator requires that the provided operators are signed off by a permissioned address called a `churnApprover`. Note that the quorum operator caps are due to the cost of BLS signature (dis)aggregation onchain. +#### `updateOperators` -Operators register with a list of +```solidity +function updateOperators( + address[] calldata operators +) + external + onlyWhenNotPaused(PAUSED_UPDATE_OPERATOR) ``` -/** -* @notice Data structure for the parameters needed to kick an operator from a quorum with number `quorumNumber`, used during registration churn. -* Specifically the `operator` is the address of the operator to kick, `pubkey` is the BLS public key of the operator, -*/ -struct OperatorKickParam { - uint8 quorumNumber; - address operator; - BN254.G1Point pubkey; -} + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `updateSocket` + +```solidity +function updateSocket(string memory socket) external +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +--- + +### System Configuration + +TODO + +#### `createQuorum` + +```solidity +function createQuorum( + OperatorSetParam memory operatorSetParams, + uint96 minimumStake, + IStakeRegistry.StrategyParams[] memory strategyParams +) + external + virtual + onlyServiceManagerOwner ``` -For each quorum they need to kick operators from. This list, along with the id of the registering operator needs to be signed (along with a salt and expiry) by an actor known as the *churnApprover*. Operators will make a request to the churnApprover offchain before registering for their signature, if needed. -### deregisterOperator +TODO -When deregistering, an operator provides -1. The quorums they registered for -2. Their BLS public key -3. The ids of the operators that must swap indices with the [deregistering operator in the IndexRegistry](./IndexRegistry.md#deregisteroperator). +*Effects*: +* -The RegistryCoordinator then deregisters the operator with the BLSPubkeyRegistry, StakeRegistry, and IndexRegistry. It then ends the block range for its stored quorum bitmap for the operator. +*Requirements*: +* -Operators can deregister from a subset of quorums that they are registered for. +#### `setOperatorSetParams` + +```solidity +function setOperatorSetParams( + uint8 quorumNumber, + OperatorSetParam memory operatorSetParams +) + external + onlyServiceManagerOwner + quorumExists(quorumNumber) +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `setChurnApprover` + +```solidity +function setChurnApprover(address _churnApprover) external onlyServiceManagerOwner +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `setEjector` + +```solidity +function setEjector(address _ejector) external onlyServiceManagerOwner +``` -## Upstream Dependencies +TODO -Operators register and deregister with the AVS for certain quorums through this contract. +*Effects*: +* -EigenLabs intends to run the EigenDA churnApprover. \ No newline at end of file +*Requirements*: +* \ No newline at end of file diff --git a/docs/Middleware-registration-operator-flow.md b/docs/Middleware-registration-operator-flow.md deleted file mode 100644 index 4faf78bf..00000000 --- a/docs/Middleware-registration-operator-flow.md +++ /dev/null @@ -1,15 +0,0 @@ -# Middleware Registration Operator Flow - -EigenLayer is a three-sided platform, bringing together middlewares/services, operators, and stakers. Middlewares have an attached risk-reward profile, based on the risk of getting slashed while running their service, and the rewards that they offer operators taking on those risks. Operators have full control over the middlewares that they decide to register with and run, and have an aggregated risk-reward profile of their own, based on these choices and their personal reputation. All of a users' assets that are deposited into EigenLayer are delegated to a single operator. - -Operators must thus make an informed decision as to which middlewares to run. This document is meant to give a high-level overview of the registration process that they must then follow in order to register with the middlewares that they have decided to operate. - -## Registration Process - -Any operator must go through the following sequence of steps: -- [Register as an operator](./EigenLayer-delegation-flow.md#operator-registration) in EigenLayer -- Get stakers to [delegate to them](./EigenLayer-delegation-flow.md#staker-delegation) -- For each middleware: - - Opt into [slashing](./EigenLayer-tech-spec.md#slasher) by the middleware's [ServiceManager](../src/contracts/interfaces/IServiceManager.sol) contract - - Make sure to respect any other preconditions set by the middleware — for [EigenDA](https://docs.eigenda.xyz/), these are registering a BLS key in the [BLSPublicKeyCompendium](](../src/contracts/interfaces/IBLSPublicKeyCompendium.sol) and having sufficient (delegated) stake in EigenLayer to meet the minimum stake requirements set by EigenDA - - Call a function on one of the middleware's contracts to complete the registration — for EigenDA, this is registering on its [BLSRegistry](../src/contracts/interfaces/IBLSRegistry.sol) \ No newline at end of file diff --git a/docs/BLSPubkeyRegistry.md b/docs/Old_BLSPubkeyRegistry.md similarity index 100% rename from docs/BLSPubkeyRegistry.md rename to docs/Old_BLSPubkeyRegistry.md diff --git a/docs/Old_BLSRegistryCoordinatorWithIndices.md b/docs/Old_BLSRegistryCoordinatorWithIndices.md new file mode 100644 index 00000000..5acd89e1 --- /dev/null +++ b/docs/Old_BLSRegistryCoordinatorWithIndices.md @@ -0,0 +1,86 @@ +# BLSRegistryCoordinatorWithIndices + +This contract is deployed for every AVS and serves as the main entrypoint for operators to register and deregister from the AVS. In addition, it is where the AVS defines its operator churn parameters. + +## Flows + +### registerOperator + +When registering the operator must provide +1. The quorums they are registering for +2. Their BLS public key that they registered with the [BLSPubkeyCompendium](./BLSPublicKeyCompendium.md) +3. The socket (ip:port) at which AVS offchain actors should make requests + +The RegistryCoordinator then +1. Registers the operator's BLS public key with the [BLSPubkeyRegistry](BLSPubkeyRegistry.md) and notes the hash of their public key as their operator id +2. Registers the operator with the [StakeRegistry](./StakeRegistry.md) +3. Registers the operator with the [IndexRegistry](./IndexRegistry.md) +4. Stores the quorum bitmap of the operator using the following struct: +``` +/** + * @notice Data structure for storing info on quorum bitmap updates where the `quorumBitmap` is the bitmap of the + * quorums the operator is registered for starting at (inclusive)`updateBlockNumber` and ending at (exclusive) `nextUpdateBlockNumber` + * @dev nextUpdateBlockNumber is initialized to 0 for the latest update + */ +struct QuorumBitmapUpdate { + uint32 updateBlockNumber; + uint32 nextUpdateBlockNumber; + uint192 quorumBitmap; +} +``` + +Operators can be registered for certain quorums and later register for other (non-overlapping) quorums. + +### If quorum full + +The following struct is defined for each quorum +``` +/** + * @notice Data structure for storing operator set params for a given quorum. Specifically the + * `maxOperatorCount` is the maximum number of operators that can be registered for the quorum + * `kickBIPsOfOperatorStake` is the multiple (in basis points) of stake that a new operator must have, as compared the operator that they are kicking out of the quorum + * `kickBIPsOfTotalStake` is the fraction (in basis points) of the total stake of the quorum that an operator needs to be below to be kicked. + */ +struct OperatorSetParam { + uint32 maxOperatorCount; + uint16 kickBIPsOfOperatorStake; + uint16 kickBIPsOfTotalStake; +} +``` + +If any of the quorums is full (number of operators in it is `maxOperatorCount`), the newly registering operator must provide the public key of another operator to be kicked. The new and kicked operator must satisfy the two conditions: +1. the new operator has an amount of stake that is at least `kickBIPsOfOperatorStake` multiple of the kicked operator's stake +2. the kicked operator has less than `kickBIPsOfTotalStake` fraction of the quorum's total stake + +The provided operators are deregistered from the respective quorums that are full which the registering operator is registering for. Since the operators being kicked may not be the operators with the least stake, the RegistryCoordinator requires that the provided operators are signed off by a permissioned address called a `churnApprover`. Note that the quorum operator caps are due to the cost of BLS signature (dis)aggregation onchain. + +Operators register with a list of +``` +/** +* @notice Data structure for the parameters needed to kick an operator from a quorum with number `quorumNumber`, used during registration churn. +* Specifically the `operator` is the address of the operator to kick, `pubkey` is the BLS public key of the operator, +*/ +struct OperatorKickParam { + uint8 quorumNumber; + address operator; + BN254.G1Point pubkey; +} +``` +For each quorum they need to kick operators from. This list, along with the id of the registering operator needs to be signed (along with a salt and expiry) by an actor known as the *churnApprover*. Operators will make a request to the churnApprover offchain before registering for their signature, if needed. + +### deregisterOperator + +When deregistering, an operator provides +1. The quorums they registered for +2. Their BLS public key +3. The ids of the operators that must swap indices with the [deregistering operator in the IndexRegistry](./IndexRegistry.md#deregisteroperator). + +The RegistryCoordinator then deregisters the operator with the BLSPubkeyRegistry, StakeRegistry, and IndexRegistry. It then ends the block range for its stored quorum bitmap for the operator. + +Operators can deregister from a subset of quorums that they are registered for. + +## Upstream Dependencies + +Operators register and deregister with the AVS for certain quorums through this contract. + +EigenLabs intends to run the EigenDA churnApprover. \ No newline at end of file diff --git a/docs/IndexRegistry.md b/docs/Old_IndexRegistry.md similarity index 100% rename from docs/IndexRegistry.md rename to docs/Old_IndexRegistry.md diff --git a/docs/StakeRegistry.md b/docs/Old_StakeRegistry.md similarity index 100% rename from docs/StakeRegistry.md rename to docs/Old_StakeRegistry.md diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 00000000..61f8c789 --- /dev/null +++ b/docs/README.md @@ -0,0 +1,78 @@ + +[core-contracts-repo]: https://github.com/Layr-Labs/eigenlayer-contracts +[core-docs-m2]: https://github.com/Layr-Labs/eigenlayer-contracts/tree/m2-mainnet/docs + +## EigenLayer Middleware Docs + +EigenLayer AVSs ("actively validated services") are protocols that make use of EigenLayer's restaking primitives. AVSs are validated by EigenLayer operators, who are backed by delegated restaked assets via the [EigenLayer core contracts][core-contracts-repo]. AVSs deploy or modify instances of the contracts in this repo to hook into the core contracts and ensure their service has an up-to-date view of its currently-registered operators. + +**Currently, each AVS needs to implement one thing on-chain:** registration/deregistration conditions that define how an operator registers for/deregisters from the AVS. This repo provides building blocks to support these functions. + +*Eventually,* the core contracts and this repo will be extended to cover other conditions, including: +* payment conditions that define how an operator is paid for the services it provides +* slashing conditions that define "malicious behavior" in the context of the AVS, and the punishments for this behavior + +*... however, the design for these conditions is still in progress.* + +TODO - also missing the servicemanagerbase and maybe other contracts? + +### Contents + +* [Important Concepts](#important-concepts) + * [Quorums](#quorums) + * [Strategies and Stake](#strategies-and-stake) + * [Operator Sets and Churn](#operator-sets-and-churn) +* [System Components](#system-components) + * [Registries](#registries) + +--- + +### Important Concepts + +##### Quorums + +A quorum is a grouping and configuration of specific kinds of stake that an AVS considers when interacting with operators. When operators register for an AVS, they select one or more quorums within the AVS to regsiter for. The purpose of having a quorum is that an AVS can customize the makeup of its security offering by choosing which kinds of stake/security it would like to utilize. + +As an example, an AVS might want to support primarily native ETH stakers. It would do so by configuring a quorum to only weigh operators that control shares belonging to the native eth strategy (defined in the core contracts). + +The Service Manager Owner initializes quorums in `BLSRegistryCoordinatorWithIndices`, and may configure them further in both the `BLSRegistryCoordinatorWithIndices` and `StakeRegistry` contracts. + +##### Strategies and Stake + +Each quorum has an associated list of `StrategyParams`, which the Service Manager Owner can configure via the `StakeRegistry`. + +`StrategyParams` define pairs of strategies and multipliers for the quorum: +* Strategies refer to the `DelegationManager` in the EigenLayer core contracts, which tracks shares delegated to each operator for each supported strategy. Basically, a strategy is a wrapper around an underlying token - either an LST or Native ETH. +* Multipliers determine the relative weight given to shares belonging to the corresponding strategy. + +When the `StakeRegistry` updates its view of an operator's stake for a given quorum, it queries the `DelegationManager` to get the operator's shares in each of the quorum's strategies and applies the multiplier to the returned share count. + +For more information on the `DelegationManager`, see the [EigenLayer core docs][core-docs-m2]. + +##### Operator Sets and Churn + +Quorums define a maximum operator count as well as parameters that determine when a new operator can replace an existing operator when this max count is reached. The process of replacing an existing operator when the max count is reached is called "churn," and requires a signature from the Churn Approver. + +These definitions are contained in a quorum's `OperatorSetParam`, which the Service Manager Owner can configure via the `BLSRegistryCoordinatorWithIndices`. A quorum's `OperatorSetParam` defines both a max operator count, as well as stake thresholds that the incoming and existing operators need to meet to qualify for churn. + +### System Components + +#### Registries + +| File | Type | Proxy | +| -------- | -------- | -------- | +| [`BLSRegistryCoordinatorWithIndices.sol`](../src/BLSRegistryCoordinatorWithIndices.sol) | Singleton | Transparent proxy | +| [`BLSPubkeyRegistry.sol`](../src/BLSPubkeyRegistry.sol) | Singleton | Transparent proxy | +| [`StakeRegistry.sol`](../src/StakeRegistry.sol) | Singleton | Transparent proxy | +| [`IndexRegistry.sol`](../src/IndexRegistry.sol) | Singleton | Transparent proxy | + +The `BLSRegistryCoordinatorWithIndices` is the primary entry point for operators as they register for and deregister from an AVS's quorums. When operators register or deregister, the registry coordinator updates that operator's currently-registered quorums, and pushes the registration/deregistration to each of the three registries it controls: +* `BLSPubkeyRegistry`: tracks the aggregate BLS pubkey hash for the operators registered to each quorum. Also maintains a history of these aggregate pubkey hashes. +* `StakeRegistry`: interfaces with the EigenLayer core contracts to track historical state of operators per quorum. +* `IndexRegistry`: assigns indices to operators within each quorum, and tracks historical indices and operators per quorum. Used primarily by offchain infrastructure to fetch ordered lists of operators in quorums. + +Both the registry coordinator and each of the registries maintain historical state for the specific information they track. This historical state tracking can be used to query state at a particular block, which is primarily used in offchain infrastructure. + +See full documentation for the registry coordinator in [`BLSRegistryCoordinatorWithIndices.md`](./BLSRegistryCoordinatorWithIndices.md), and for each registry in [`registries/`](./registries/). \ No newline at end of file diff --git a/docs/AVS-Guide.md b/docs/experimental/AVS-Guide.md similarity index 98% rename from docs/AVS-Guide.md rename to docs/experimental/AVS-Guide.md index 7734d52c..46dc9a64 100644 --- a/docs/AVS-Guide.md +++ b/docs/experimental/AVS-Guide.md @@ -10,7 +10,7 @@ This document aims to describe and summarize how actively validated services (AV We are currently in the process of implementing the API for payment flow from AVSs to operators in EigenLayer. Details of this API will be added to this document in the near future. The following figure summarizes scope of this document: -![Doc Outline](./images/middleware_outline_doc.png) +![Doc Outline](../images/middleware_outline_doc.png) # Introduction In designing EigenLayer, the EigenLabs team aspired to make minimal assumptions about the structure of AVSs built on top of it. If you are getting started looking at [EigenLayer][eigenlayer-repo-link]'s codebase, the `Slasher.sol` contains most of the logic that actually mediates the interactions between EigenLayer and AVSs. This repo contains code that can be extended, used directly, or consulted as a reference in building an AVS on top of EigenLayer. Note that there will be a single, EigenLayer-owned, `Slasher.sol` contract, but all the `middleware` contracts are AVS-specific and need to be deployed separately by AVS teams. @@ -47,7 +47,7 @@ In order for any EigenLayer operator to be able to opt-in to an AVS, EigenLayer 2. Next, the operator needs to register with the AVS on chain via an AVS-specific registry contract (see [this][middleware-guide-link] section for examples). To integrate with EigenLayer, the AVS's Registry contract provides a registration endpoint that calls on the AVS's `ServiceManager.recordFirstStakeUpdate(..)` which in turn calls `Slasher.recordFirstStakeUpdate(..)`. On successful execution of this function call, the event `MiddlewareTimesAdded(..)` is emitted and the operator has to start serving the tasks from the AVS. The following figure illustrates the above flow: -![Operator opting-in](./images/operator_opting.png) +![Operator opting-in](../images/operator_opting.png) ### *Recording Stake Updates* EigenLayer is a dynamic system where stakers and operators are constantly adjusting amounts of stake delegated via the system. It is therefore imperative for an AVS to be aware of any changes to stake delegated to its operators. In order to facilitate this, EigenLayer offers the `Slasher.recordStakeUpdate(..)`. @@ -58,13 +58,13 @@ Let us illustrate the usage of this facility with an example: A staker has deleg - The AVS provider now is aware of the change in stake, and the staker can eventually complete their withdrawal. Refer [here](https://github.com/Layr-Labs/eigenlayer-contracts/blob/master/docs/EigenLayer-withdrawal-flow.md) for more details The following figure illustrates the above flow: -![Stake update](./images/staker_withdrawing.png) +![Stake update](../images/staker_withdrawing.png) ### *Deregistering from AVS* In order for any EigenLayer operator to be able to de-register from an AVS, EigenLayer provides the interface `Slasher.recordLastStakeUpdateAndRevokeSlashingAbility(..)`. Essentially, in order for an operator to deregister from an AVS, the operator has to call `Slasher.recordLastStakeUpdateAndRevokeSlashingAbility(..)` via the AVS's ServiceManager contract. It is important to note that the latest block number until which the operator is required to serve tasks for the service must be known by the service and included in the ServiceManager's call to `Slasher.recordLastStakeUpdateAndRevokeSlashingAbility`. The following figure illustrates the above flow in which the operator calls the `deregister(..)` function in a sample Registry contract. -![Operator deregistering](./images/operator_deregister.png) +![Operator deregistering](../images/operator_deregister.png) ### *Slashing* As mentioned above, EigenLayer is built to support slashing as a result of an on-chain-checkable, objectively attributable action. In order for an AVS to be able to slash an operator in an objective manner, the AVS needs to deploy a DisputeResolution contract which anyone can call to raise a challenge against an EigenLayer operator for its adversarial action. On successful challenge, the DisputeResolution contract calls `ServiceManager.freezeOperator(..)`; the ServiceManager in turn calls `Slasher.freezeOperator(..)` to freeze the operator in EigenLayer. EigenLayer's Slasher contract emits a `OperatorFrozen(..)` event whenever an operator is (successfully) frozen diff --git a/docs/registries/BLSPubkeyRegistry.md b/docs/registries/BLSPubkeyRegistry.md new file mode 100644 index 00000000..8b5b030f --- /dev/null +++ b/docs/registries/BLSPubkeyRegistry.md @@ -0,0 +1,83 @@ +## BLSPubkeyRegistry + +| File | Type | Proxy? | +| -------- | -------- | -------- | +| [`BLSPubkeyRegistry.sol`](../src/BLSPubkeyRegistry.sol) | Singleton | Transparent proxy | + +TODO + +#### High-level Concepts + +TODO + +This document organizes methods according to the following themes (click each to be taken to the relevant section): + +TODO + + +#### Important State Variables + +TODO + + + +#### Important Definitions + +* Churn: TODO + + + +--- + +### Theme + +TODO + + + +#### `methodName` + +```solidity + +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `methodName` + +```solidity + +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +--- \ No newline at end of file diff --git a/docs/registries/IndexRegistry.md b/docs/registries/IndexRegistry.md new file mode 100644 index 00000000..12e8d894 --- /dev/null +++ b/docs/registries/IndexRegistry.md @@ -0,0 +1,83 @@ +## IndexRegistry + +| File | Type | Proxy? | +| -------- | -------- | -------- | +| [`IndexRegistry.sol`](../src/IndexRegistry.sol) | Singleton | Transparent proxy | + +TODO + +#### High-level Concepts + +TODO + +This document organizes methods according to the following themes (click each to be taken to the relevant section): + +TODO + + +#### Important State Variables + +TODO + + + +#### Important Definitions + +* Churn: TODO + + + +--- + +### Theme + +TODO + + + +#### `methodName` + +```solidity + +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `methodName` + +```solidity + +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +--- \ No newline at end of file diff --git a/docs/registries/StakeRegistry.md b/docs/registries/StakeRegistry.md new file mode 100644 index 00000000..01f98b86 --- /dev/null +++ b/docs/registries/StakeRegistry.md @@ -0,0 +1,83 @@ +## StakeRegistry + +| File | Type | Proxy? | +| -------- | -------- | -------- | +| [`StakeRegistry.sol`](../src/StakeRegistry.sol) | Singleton | Transparent proxy | + +TODO + +#### High-level Concepts + +TODO + +This document organizes methods according to the following themes (click each to be taken to the relevant section): + +TODO + + +#### Important State Variables + +TODO + + + +#### Important Definitions + +* Churn: TODO + + + +--- + +### Theme + +TODO + + + +#### `methodName` + +```solidity + +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +#### `methodName` + +```solidity + +``` + +TODO + +*Effects*: +* + +*Requirements*: +* + +--- \ No newline at end of file