EigenDA
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,
- EigenLayer core contracts (DelegationManager, StrategyManager) receive a malicious code upgrade. There is no delay on code upgrades,
- 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. However, there is no slashing mechanism 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.
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 204 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
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 DA attestations are bridged to Ethereum through the EigenDAServiceManager smart contract.
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 204 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.
The system consists of the following permissions on Ethereum:
The contract authorized to upgrade the core EigenDA contracts.
Those are the participants of the EigenDAProxyAdmin.
The list of addresses authorized to pause the EigenDAServiceManager contract.
The address authorized to approve the replacement of churned EigenDA operators from a quorum.
The list of addresses authorized to eject EigenDA operators from a quorum.
The contract authorized to upgrade the core EigenLayer contracts.
Those are the participants of the EigenLayerProxyAdmin.
A Gnosis Safe with 1 / 2 threshold. The proxy contract authorized to unpause the EigenDAServiceManager contract and upgrade core contracts through the EigenDAProxyAdmin contract.
Those are the participants of the EigenLayerExecutorMultisig.
Those are the participants of the EigenLayerOperationsMultisig.
A Gnosis Safe with 9 / 13 threshold. This multisig is one of the owners of EigenLayerExecutorMultisig and can upgrade EigenLayer core contracts without delay.
Those are the participants of the EigenLayerCommunityMultisig.
The timelock contract for upgrading EigenLayer core contracts via EigenLayerOperationsMultisig.
The system consists of the following smart contracts on Ethereum:
The EigenDAServiceManager contract is the 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.
Upgrade delay: No delay
Contract used by operators to register with the EigenDA AVS. The coordinator has three registries: a StakeRegistry that keeps track of operators’ stakes, a BLSApkRegistry that keeps track of operators’ BLS public keys and aggregate BLS public keys for each quorum, and an IndexRegistry that keeps track of an ordered list of operators for each quorum.
Upgrade delay: No delay
The StakeRegistry contract keeps track of the total stake of each operator.
Upgrade delay: No delay
The BLSApkRegistry contract keeps track of the BLS public keys of each operator and the quorum aggregated keys.
Upgrade delay: No delay
The EjectionManager contract is responsible for ejecting operators from a quorum for violating the Service Legal Agreement (SLA).
Upgrade delay: No delay
Defines and stores pauser and unpauser roles for EigenLayer contracts and the EigenDAServiceManager.
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.
Upgrade delay: 10d delay via EigenLayerOperationsMultisig, no delay via EigenLayerCommunityMultisig.
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.
Upgrade delay: 10d delay via EigenLayerOperationsMultisig, no delay via EigenLayerCommunityMultisig.
The EigenStrategy contract is responsible for managing the bEIGEN token strategy, representing the stake for the second EigenDA quorum.
Upgrade delay: 10d delay via EigenLayerOperationsMultisig, no delay via EigenLayerCommunityMultisig.
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.
Upgrade delay: 10d delay.
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 EigenLayer core contracts (DelegationManager, StrategyManager) receive a malicious code upgrade. There is no delay on code upgrades.
Funds can be lost if 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.