Skip to main content

EigenDA Overview

EigenDA is a hyper scalable data availability store built for Ethereum rollups. Live on mainnet, with 15MB/s of write throughput.

EigenDA stores rollup transactions until their computed state is finalized on the rollup bridge, and is...

  • Scalable. EigenDA write throughput scales linearly with number of operators. With 15 MB/s of write throughput today it is the most scalable DA layer with a path to 100 MB/s then GB/s.

  • Secure. Operators of EigenDA are registered and stake to participate, imposing an economic cost to misbehavior. EigenDA is secured by billions of dollars in economic security today.

  • Cost efficient. Spend cents per MB, not dollars. See our tiered pricing.

  • Decentralized. EigenDA is operated by hundreds of operators running the EigenDA client. The design is inspired by Danksharding, reducing the overhead for operators enablings high participation.

  • Built for Ethereum. EigenDA blob writes are registered with contracts on Ethereum, which natively subject operators to certain slashing risks. Ethereum L2s using EigenDA avoid any trust assumption on another chain's light client, which can be fooled by dishonest validator sets.

How EigenDA Works​

The core insight of EigenDA is that the problem of data availability does not require independent consensus to solve. In building a decentralized transient data store for Ethereum rollups, Ethereum can be used for aspects of coordination required, and data storage can be handled by EigenDA operators directly.

This approach gives EigenDA the ability to scale linearly. In the context of an L1 blockchain, increasing throughput means either increasing block size or decreasing block times. Beyond a certain point, increases in scalability come at the cost of security or decentralization (see "blockchain trilemma"). One way around this trilemma is through an emphasis on L2s, where DA can be moved off-chain such that transaction data need not be replicated to every node. Instead, only DA metadata and accountability processes are processed on-chain. This enables DA to scale with respect to the bandwidth of the operator set.

EigenDA works on the basis of three components:

  • Operators
  • The Disperser (untrusted)
  • Retrievers (untrusted)

EigenDA operators are third-parties running the EigenDA node software, registered in EigenLayer with stake delegated to them. EigenDA operators are responsible for storing blobs associated with valid storage requests. Valid storage requests are requests where fees are paid and the provided blob chunk verifies against the provided KZG commitment and proof. In the case of a successful verification the operator stores the blob and signs a message with the KZG commitment and the chunk index they hold, and sends it back to the disperser. EigenDA operators are collectively trusted – when writing a blob to EigenDA clients must choose the exact threshold of stake with which they would like their blob to be stored.

The EigenDA disperser is an untrusted service hosted by EigenLabs which is responsible for interfacing between EigenDA clients, operators, and contracts. EigenDA clients make dispersal requests to the disperser, which Reed-Solomon encodes the blob, calculates the encoded blob's KZG commitment, and generates a KZG proof for each chunk. Then the disperser sends chunks, KZG commitment, and KZG proofs to operators, who return signatures. The disperser then aggregates these signatures and uploads it to Ethereum in the form of calldata to the EigenDA contract. This step is a necessary precondition for slashing operators for misbehavior.

The EigenDA retriever is a service that queries EigenDA operators for blob chunks, verifies that blob chunks are accurate, and reconstructs the original blob for the user. EigenDA hosts a retriever service but client rollups may also host their own retriever as a sidecar to their sequencer.

How Rollups Integrate​

EigenDA Architecture

The diagram above shows the basic flow of data through EigenDA:

  1. The rollup sequencer sends a batch of transactions as a blob to the EigenDA disperser sidecar.
  2. The EigenDA disperser sidecar erasure encodes the blob into chunks, generates a KZG commitment and multi-reveal proofs for each chunk, and disperses chunks to EigenDA Operators, receiving signatures certifying storage in return.
  3. After aggregating the received signatures, the disperser registers the blob onchain by sending a transaction to the EigenDA Manager contract with the aggregated signature and blob metadata.
  4. The EigenDA Manager contract verifies the aggregated signature with the help of the EigenDA Registry contract, and stores the result onchain.
  5. Once the blob has been stored offchain and registered onchain, the sequencer posts the EigenDA blob ID to its inbox contract in a transaction. A blob ID is no more than 100 bytes long.
  6. Before accepting the blob ID into the rollup's inbox, the inbox contract consults the EigenDA manager contract on whether blob was certified available. If it was, the blob ID is allowed into the inbox contract. If not, the blob ID is discarded.

For more on how rollups integrate with EigenDA, check out Integrations Overview.