EigenDA
Users can be censored if
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.
There is no committee attesting to the availability of data.
The relayer does not contribute to the DA bridge liveness since data availability attestations are not integrated in the scaling solution’s proof system.
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.
The risk profile in this page refers to L2s that do not integrate with a data availability bridge.
There is no committee attesting to the availability of data.
The relayer does not contribute to the DA bridge liveness since data availability attestations are not integrated in the scaling solution’s proof system.
No DA bridge is selected. Without a DA bridge, Ethereum has no proof of data availability for this project.