Search

Search for projects by name

SummaryRisk summaryEigenDADA Bridge

EigenDA logoEigenDA

  • Type
    DA Service
  • Total value secured
    $1.69 K
  • Economic security
    —
  • Duration of storage
    Flexible
  • Used by
    • Select a bridge
    No bridge
    $1.69 K
    ServiceManager
    $0.00

    Risk summary
    EigenDA risks
    EigenDA

    EigenDA is a data availability solution built on Eigen Layer.

    Risk analysis
    Economic security
    No slashing

    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.

    Fraud detection
    None

    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.

    Technology

    Architecture

    EigenDA 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 resposible 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 resposible for holding and serving blobs data, and earn rewards for their participation in the network. EigenDA operator registration

    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. EigenDA operator stake sync

    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).

    EigenDA storing/retrieving

    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.

    1. EigenDA - Documentation
    2. EigenDA Disperser - Source Code
    3. EigenDA Rollup Utils - Source Code
    No bridge

    The risk profile in this page refers to L2s that do not integrate with a data availability bridge.

    Risk analysis

    There is no committee attesting to the availability of data.

    Without the bridge, users cannot react in time to malicious actions by the sequencer.

    The relayer does not contribute to the DA bridge liveness since data availability attestations are not integrated in the scaling solution’s proof system.

    Technology

    No DA bridge is selected. Without a DA bridge, Ethereum has no proof of data availability for this project.