Search
Search for projects by name
EigenDA
EigenDA launch on mainnet
2024 Apr 9th
EigenLayer and EigenDA launch on the Ethereum mainnet.
Users can be censored if
Funds can be lost if
- the bridge (EigenDAServiceManager) contract receives a malicious code upgrade. There is no delay on code upgrades,
- the EigenLayer core contracts (DelegationManager, StrategyManager) receive a malicious code upgrade. There is no delay on code upgrades,
- the EigenLayer EIGEN token contract receives a malicious code upgrade. There is a 10d delay on code upgrades,
- the churn approver or ejectors act maliciously and eject EigenDA operators from a quorum without cause,
- the bridge accepts an incorrect or malicious data commitment provided by node operators,
- the relayer posts an invalid commitment and EigenDA operators do not make the data available for verification.
EigenDA is a data availability solution built on Eigen Layer.
Node operators are required to stake a minimum of 32 ETH (first quorum) or 1 EIGEN (second quorum) to become members of the DA network. Although slashing is enabled at EigenLayer protocol level, individual AVSs like EigenDA need to activate it by migrating to Operators Sets and defining slashing conditions. Currently, there is no slashing condition in place for misbehaving nodes. The EIGEN token social forking protocol for intersubjective attributable faults is under active development.
There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer.
Architecture
EigenDA is composed by three types of off-chain entities: node operators, a disperser and a retriever.
- EigenDA operators are node operators running the EigenDA node software and are registered to the EigenDA AVS in EigenLayer.
- The disperser is the entity responsible for collecting the blobs from the sequencer, erasure coding them and generating the encoded blob’s KZG commitments for each chunk. Although the disperser could be rollup-operated, it is currently a centralised entity operated by Eigen Labs.
- Lastly, the retriever client is responsible for querying the EigenDA operators to retrieve blob chunks, verifying their integrity and reconstructs the original blob.
Operators Registration
Operators register with the EigenDAServiceManager via the registerOperatorToAVS() function, enabling them to participate in the data availability network. They are responsible for holding and serving blobs data, and earn rewards for their participation in the network.
Operators Stake Update
EigenDA operators’ stake for quorum verification is fetched from the EigenDA StakeRegistry contract. To keep the stake in sync with changes in share balances in the EigenLayer DelegationManager (e.g., due to tokens delegated/undelegated to operators), the permissionless updateOperators() function on the RegistryCoordinator contract needs to be called periodically. This function updates the operators’ quorum weight in the StakeRegistry contract based on the operators’ shares in the EigenLayer DelegationManager contract.
Operators Blob Storage and Retrieval
The process of storing a blob on EigenDA works as follows. A sequencer submits blobs to the EigenDA Disperser, which erasure codes the blobs into chunks and generates KZG commitments and proofs for each chunk, certifying the correctness of the data. The disperser then sends the chunks, KZG commitments, and KZG proofs to the operators. Multiple operators are responsible for storing chunks of the encoded data blobs and their associated KZG commitment and proof. Once the chunks, KZG commitments, and KZG proofs are sent to the operators, each of them generates a signature certifying that they have stored the data. These signatures are then sent to the Disperser which aggregates them and submits them to Ethereum by sending a transaction to the EigenDAServiceManager (the DA bridge).
L2 Data Availability
The Disperser collects the operators’ signatures and submits them to the EigenDAServiceManager contract via the confirmBatch() function. This submission includes a call to the BLSRegistry contract to verify signatures and check whether the required quorum of operators’ stake has been achieved. Threshold BLS signatures are not used. Instead, the threshold check is performed on the signers’ total stake fetched by the StakeRegistry, and the stake threshold percentage to reach is provided in the batch header input data. The EigenDARollupUtils.sol library’s verifyBlob() function can then be used by L2s to verify that a data blob is included within a confirmed batch in the EigenDAServiceManager. This function is not used by the EigenDAServiceManager contract itself, but rather by L2 systems to prove inclusion of the blob in the EigenDAServiceManager contract, and that their trust assumptions (i.e., batch confirmation threshold) were as expected.
Users can be censored if the disperser does not distribute data to EigenDA operators.
EigenDA is a data availability solution built on Eigen Layer.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. There are 161 operators currently registered in the committee, but entry or exit of members is partially controlled by a centralized entity.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
Architecture
The EigenDAServiceManager acts as a DA bridge smart contract verifying data availability claims from operators via signature verification. The checkSignatures() function checks that the signature of all signers plus non-signers is equal to the registered quorum aggregated public key from the BLS registry. The quorum aggregated public key gets updated every time an operator is registered. The bridge requires a threshold of signatures to be met before the data commitment is accepted. To verify the threshold is met, the function takes the total stake at the reference block for the quorum from the StakeRegistry, and it subtracts the stake of non signers to get the signed stake. Finally, it checks that the signed stake over the total stake is more than the required stake threshold.
Although thresholds are not enforced onchain by the confirmBatch method, the minimum thresholds that the disperser would need to reach before relaying the batch commitment to Ethereum are set to 55% of the registered stake for the ETH quorum and 55% for the EIGEN token quorum. Meeting these dispersal thresholds allows the system to tolerate up to 33% (quorum 1) and 33% (quorum 2) of the total stake being adversarial, achieving this with approximately 4.5 data redundancy.
The quorum thresholds are set on the EigenDAServiceManager contract and can be changed by the contract owner.
There is a maximum of 200 operators that can register for the ETH quorum and 200 for the EIGEN token quorum. Once the cap is reached, new operators must have 10% more weight than the lowest-weighted operator to join the active set. Entering the quorum is subject to the approval of the churn approver. Operators can be ejected from a quorum by the ejectors without delay should they violate the Service Legal Agreement (SLA).
Ejectors can eject maximum 33.33% of the total stake in a 7d window for the ETH quorum, and the same stake percentage over a 3d window for the EIGEN quorum. An ejected operator can rejoin the quorum after 3d.
Funds can be lost if the relayer posts an invalid commitment and EigenDA operators do not make the data available for verification.
Funds can be frozen if excluding L2-specific DA fallback - the permissioned relayers are unable to submit DA commitments to the bridge contract.
Funds can be frozen if the bridge (EigenDAServiceManager) contract is paused by the pausers.
Ethereum
Roles:
Can store and serve both unencoded blobs as well as encoded chunks.
Actors:
- A Multisig with 3/7 threshold.
- Can upgrade with no delay
- StakeRegistry
via
- acting via ProxyAdmin - BLSApkRegistry
via
- acting via ProxyAdmin - RegistryCoordinator
via
- acting via ProxyAdmin - EjectionManager
via
- acting via ProxyAdmin - SocketRegistry
via
- acting via ProxyAdmin - EigenDADisperserRegistry
via
- acting via ProxyAdmin - EigenDAServiceManager
via
- acting via ProxyAdmin - PaymentVault
via
- acting via ProxyAdmin - IndexRegistry
via
- acting via ProxyAdmin - EigenDARelayRegistry
via
- acting via ProxyAdmin - EigenDAThresholdRegistry
via
- acting via ProxyAdmin
- StakeRegistry
- Can interact with RegistryCoordinator
- can add and remove strategies
- Can interact with EigenDAServiceManager
- can transfer ownership of the contract, update the metadata URI, set reward initiator and set batch confirmer
Defines and stores pauser and unpauser roles for EigenDA contracts.
- Can interact with EigenDAServiceManager
- can pause the DA bridge
- A Multisig with 3/5 threshold.
- Can interact with EigenDAServiceManager
- can create rewards submissions
- A Multisig with 3/5 threshold.
- Can upgrade with 10d delay
- AVSDirectory
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - PermissionController
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - DelegationManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - StrategyFactory
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - RewardsCoordinator
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - StrategyManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - EigenPodManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - AllocationManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - EIGEN token
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin
- AVSDirectory
- Can upgrade with 24d delay
- bEIGEN token
via
- acting via TimelockControllerBeigen with 24d delay → EigenLayerBeigenOwningMultisig → ProxyAdmin
- bEIGEN token
- Can interact with TimelockControllerBeigen
- executes scheduled operations after the delay
- Can interact with TimelockControllerOwning
- executes scheduled operations after the delay
- A Multisig with 3/6 threshold.
- Can upgrade with 10d delay
- AVSDirectory
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - PermissionController
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - DelegationManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - StrategyFactory
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - RewardsCoordinator
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - StrategyManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - EigenPodManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - AllocationManager
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin - EIGEN token
via
- acting via TimelockControllerOwning with 10d delay → EigenLayerOwningMultisig → EigenLayerProxyAdmin
- AVSDirectory
- Can upgrade with 24d delay
- bEIGEN token
via
- acting via TimelockControllerBeigen with 24d delay → EigenLayerBeigenOwningMultisig → ProxyAdmin
- bEIGEN token
- Can interact with TimelockControllerBeigen
- can cancel scheduled operations
- Can interact with TimelockControllerOwning
- can cancel scheduled operations
- A Multisig with 9/13 threshold.
- Member of EigenLayerOwningMultisig, EigenLayerBeigenOwningMultisig.
- Can upgrade with no delay
- AVSDirectory
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - PermissionController
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - DelegationManager
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - StrategyFactory
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - RewardsCoordinator
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - bEIGEN token
via
- acting via EigenLayerBeigenOwningMultisig → ProxyAdmin - StrategyManager
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - EigenPodManager
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - AllocationManager
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin - EIGEN token
via
- acting via EigenLayerOwningMultisig → EigenLayerProxyAdmin
- AVSDirectory
- A Multisig with 1/2 threshold.
- A Multisig with 1/10 threshold.
- A Multisig with 1/1 threshold.
- Member of EigenLayerCommunityMultisig.
Participants (1):
0x5e6a…d3B5- A Multisig with 1/2 threshold.
- A Multisig with 4/6 threshold.
- Can interact with EigenDAServiceManager
- can confirm batches to the DA bridge
- Can interact with EigenDAServiceManager
- can confirm batches to the DA bridge
- Can interact with EjectionManager
- can eject DA operators from a quorum
- Can interact with EigenDAServiceManager
- can confirm batches to the DA bridge
- Can interact with EjectionManager
- can eject DA operators from a quorum
- Can interact with RegistryCoordinator
- can approve the replacement of churned operators from a quorum
Ethereum
Keeps track of the total stake of each operator.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
Keeps track of the BLS public keys of each operator and the quorum aggregated keys.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
Operators register here with an AVS The coordinator has three registries 1) a StakeRegistry that keeps track of operators’ stakes, 2) a BLSApkRegistry that keeps track of operators’ BLS public keys and aggregate BLS public keys for each quorum, 3) an IndexRegistry that keeps track of an ordered list of operators for each quorum.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
- churnApprover: EOA 1
- owner: EigenDAOperationsMultisig
Contract used for ejection of operators from the RegistryCoordinator for violating the Service Legal Agreement (SLA).
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
- ejectors: EOA 2, EOA 3
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
Registry for EigenDA disperser info such as disperser key to address mapping.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
- dispersers: EOA 4
- Roles:
- owner: EigenDAOperationsMultisig
Bridge contract that accepts blob batches data availability attestations. Batches availability is attested by EigenDA operators signatures and relayed to the service manager contract by the EigenDA disperser.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
- batchConfirmers: EOA 5, EOA 6, EOA 7
- owner: EigenDAOperationsMultisig
- pauserRegistry: PauserRegistry
- rewardsInitiator: EigenLayerRewardsInitiatorMultisig
Entrypoint for making reservations and on demand payments for EigenDA.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
A registry contract that keeps track of an ordered list of operators for each quorum.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
Registry for EigenDA relay keys, maps key to address.
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
- relayers: EOA 8
Registry of EigenDA threshold (i.e, adversary and confirmation threshold percentage for a quorum)
- Roles:
- admin: ProxyAdmin; ultimately EigenDAOperationsMultisig
Ethereum Beacon Chain deposit contract.
A strategy implementation allowing to deposit a specific token as a restakable asset.
UpgradeableBeacon managing the single implementation for all strategies deployed via StrategyFactory.
Minter of the bEIGEN (and thus EIGEN) token. Can execute a predefined payload in predefined intervals (configured by the Owner).
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
Contract that enables AVSs and operators to delegate the ability to call certain core contract functions to other addresses.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
The DelegationManager contract is responsible for registering EigenLayer operators and managing the EigenLayer strategies delegations. The EigenDA StakeRegistry contract reads from the DelegationManager to track the total stake of each EigenDA operator.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
- Roles:
- owner: EigenLayerBeigenOwningMultisig
UpgradeableBeacon managing the single implementation for all strategies deployed via StrategyFactory.
Factory contract for permissionless strategy creation via beacon proxies.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
A timelock that allows scheduling calls and executing or cancelling them with a delay.
- Member of EigenLayerBeigenOwningMultisig.
- Roles:
- cancellers: EigenLayerOperationsMultisig
- executors: EigenLayerOperationsMultisig2
- proposers: EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
Manages the distribution of rewards (arbitrary tokens, EIGEN) to restakers and commission to operators.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
- Roles:
- admin: ProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
The StrategyManager contract is responsible for managing the EigenLayer token strategies. Each EigenDA quorum has at least one strategy that defines the operators quorum stake.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
- Roles:
- owner: EigenLayerOwningMultisig
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
Contract used to create Operator Sets, and used by Operators to register to them. The Allocation Manager tracks allocation of stake to a Operator Set, and enables AVSs to slash that stake.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
Generates calldata for the TokenHopper to mint EIGEN and send it to the RewardsCoordinator for distribution to all stakers.
Defines and stores pauser and unpauser roles for EigenLayer contracts.
- Roles:
- pausers: EigenLayerOperationsMultisig, EigenLayerOwningMultisig, EigenLayerPauserMultisig
A timelock that allows scheduling calls and executing or cancelling them with a delay.
- Member of EigenLayerOwningMultisig.
- Roles:
- cancellers: EigenLayerOperationsMultisig
- executors: EigenLayerOperationsMultisig2
- proposers: EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
The EIGEN token can be socially forked to slash operators for data withholding attacks (and other intersubjectively attributable faults). EIGEN is a wrapper over a second token, bEIGEN, which will be used solely for intersubjective staking. Forking EIGEN means changing the canonical implementation of the bEIGEN token in the EIGEN token contract.
- Roles:
- admin: EigenLayerProxyAdmin; ultimately EigenLayerCommunityMultisig, EigenLayerOperationsMultisig, EigenLayerOperationsMultisig2
The current deployment carries some associated risks:
Funds can be lost if the bridge (EigenDAServiceManager) contract receives a malicious code upgrade. There is no delay on code upgrades.
Funds can be lost if the EigenLayer core contracts (DelegationManager, StrategyManager) receive a malicious code upgrade. There is no delay on code upgrades.
Funds can be lost if the EigenLayer EIGEN token contract receives a malicious code upgrade. There is a 10d delay on code upgrades.
Funds can be lost if the churn approver or ejectors act maliciously and eject EigenDA operators from a quorum without cause.
Funds can be lost if the bridge accepts an incorrect or malicious data commitment provided by node operators.