Eigenlayer supports EigenDA's storage of rollup data in recoverable chunks
Eigenlayer supplies the restaking foundation for EigenDA, a data availability service distributing rollup blobs as erasure-coded chunks. Reed-Solomon encoding adds redundancy, allowing reconstruction from enough distinct, valid chunks when some validators cannot serve data. Each validator stores assigned pieces without necessarily keeping the entire blob. Rollups receive availability attestations backed by participating validator stake, while their own execution rules establish transaction correctness. EigenDA V2 separates validator storage from full-blob retrieval through relays. That separation affects storage overhead, read performance, and integration requirements. Fault tolerance depends on encoding parameters, chunk assignments, and accepted signing thresholds. The availability guarantee also has a storage window.
The short version: A rollup needs retrievable, valid blob data during its verification window, even when validator signatures satisfy its certificate threshold.
Erasure Coding and Storage Overhead
Reed-Solomon erasure coding expands a blob into redundant polynomial evaluations, allowing recovery even when some pieces are unavailable. The encoder represents blob symbols as polynomial coefficients and evaluates that polynomial at distinct points. It groups those evaluations into chunks for distribution. A qualifying collection gives the decoder enough information to reconstruct the polynomial and recover the blob. Simply splitting data into unprotected slices would leave each missing slice as a gap. Erasure coding adds information across the encoded data, creating storage overhead in exchange for recovery capacity.
Stake-Weighted Chunk Assignments
Chunk assignment distributes encoded pieces using validator stake and quorum membership at the reference Ethereum block. A quorum defines a participating validator group and its associated stake. Validators receive different chunk assignments, so a sufficient honest stake share collectively holds recoverable data. Counting responsive nodes alone does not establish this condition. Their stake weights and assigned chunk indices matter. For validators belonging to multiple quorums, the assignment algorithm can reuse chunk indices to reduce duplicated storage while preserving each quorum's reconstruction guarantee.
Encoding Expansion and Reconstruction
The V2 architecture described in September 2025 used eightfold encoding redundancy: 8 192 chunks, of which 1 024 distinct valid chunks reconstruct a blob. EigenDAThresholdRegistry stores versioned blob parameters, so an integration must use the values applicable to its blob version. Proofs, metadata, and duplicated storage add overhead beyond the encoded data itself.
Dispersal Attestations and Rollup Acceptance
EigenDA V2 separates accepting a dispersal request from demonstrating sufficient validator participation, so a successful submission reply does not establish usable data availability.
Payload Preparation
The rollup client converts payload bytes into EigenDA's blob representation before submitting a request. Its blob header specifies commitments and required quorums. Compatible payment metadata and the configured certificate verifier form part of the submission requirements. The disperser encodes the blob and makes chunks available through relays. Validators download their assignments, validate proofs and lengths, and sign the batch header after successful checks. The client needs the required quorum configuration before submitting data; selecting incompatible quorums cannot produce a certificate its verifier accepts.
Certificate Checks
The disperser aggregates validator signatures and supplies signed batch information plus a blob inclusion proof. These support certificate construction and verification through EigenDACertVerifier. The verifier checks inclusion, signatures, and the applicable security parameters. Each required quorum must contribute enough signing stake. In the V2 API, COMPLETE means signature collection has ended; it does not guarantee the rollup's required signing percentage. A blob key tracks the request, while a verified availability certificate establishes the accepted attestation.
Optimistic integrations may verify certificates during a challenge. Pessimistic integrations check them before inbox inclusion. Secure rollup consensus must cover the complete blob derivation logic, including verification and decoding.
Integration Options and Required Support
EigenDA V2 exposes separate choices for paying for dispersal, verifying certificates, and retrieving data; compatible choices combine within a rollup integration. Reservations allocate bandwidth over an active period for specified quorums. On-demand dispersal consumes prefunded payments under its supported quorum rules. Verification placement follows the rollup's inbox and proof design. Retrieval can use a relay, a retained copy of the committed blob, or enough distinct valid chunks from validators. These choices concern different layers of the service, so choosing a payment method does not establish how the rollup verifies or downloads its data.
| Integration Option | Required Support |
|---|---|
| Reservation-funded dispersal | An active bandwidth reservation covering the selected quorums, with available capacity. |
| On-demand dispersal | Funds in PaymentVault and submission through the EigenDA disperser; ETH and EIGEN quorums are supported, while custom quorums are excluded. |
| Pre-inclusion certificate verification | Inbox logic verifying the certificate before accepting its data commitment. |
| Challenge-time certificate verification | A proof system securing certificate verification within the rollup's challenge mechanism. |
| Full-blob relay retrieval | The blob key, an associated relay serving the blob, and commitment verification. |
| Validator-chunk reconstruction | Chunk assignments, responding validators, proof verification, and enough distinct valid chunks. |
A relay outage changes the read path without automatically invalidating the underlying validator attestation. Recovery needs either an accessible copy of the committed blob or a client able to reconstruct it from enough distinct valid chunks.
Relay Reads and Validator Reconstruction
EigenDA V2 usually serves complete blobs through relays, while validator retrieval supplies a reconstruction path when relay access fails.
Full-Blob Retrieval
The blob certificate identifies relays associated with its data. A full-blob read avoids fetching and reconstructing many separately hosted chunks. The retrieval client still checks the returned blob against its KZG polynomial commitment before decoding the rollup payload. This check detects content differing from the committed blob. It does not establish whether the rollup transactions produce a valid state transition. Relays therefore improve access to stored data while the validator network supplies the underlying storage guarantee, subject to its security assumptions.
Verified Chunk Reconstruction
EigenDA V2 supports blob reconstruction from a sufficient set of valid chunks retrieved from validators. The client derives chunk assignments and queries validators until it collects enough distinct pieces. Each opening proof binds its chunk to the committed polynomial at the expected position. Duplicate chunk indices add no independent information, and invalid chunks cannot count toward recovery. The client reconstructs the blob and reverses payload encoding. Recovery remains conditional on sufficient valid chunks actually arriving, even when a certificate passes its checks.
Does EigenDA Provide Permanent Rollup History?
EigenDA certifies availability within a storage window, while preserving rollup history beyond that window requires an archival arrangement. The September 2025 V2 design specified two-week validator chunk retention. Rollup nodes or archival services may retain downloaded data longer under separate storage and access arrangements. Historical replay then depends on those surviving copies. An availability certificate does not renew expired storage duties. A system requiring older transaction history therefore needs a retention plan beyond the validator network's bounded obligation.
Certificate recency helps preserve time for retrieving data after a commitment enters the rollup inbox. Certificate formats V4 and later carry an off-chain derivation version controlling the recency window. Earlier formats skip this version-controlled check. Where it applies, derivation compares inbox inclusion with the certificate's reference block and rejects certificates outside the allowed window. A zero configured window disables the check, allowing commitments to reference data the network has already pruned. Rollup challenge timing must also leave honest participants enough time to obtain the necessary payloads.
Failed Dispersal and Unavailable Data
Dispersal failures and retrieval failures need different responses because an invalid attestation and temporarily missing bytes represent different protocol states. An in-progress V2 request can continue gathering signatures. A terminal result with insufficient signing stake requires a new dispersal. Invalid payment details or unavailable assigned chunks can prevent validators from signing. After configured retries fail, an integration with an implemented native data-availability fallback can switch publication methods. That behavior belongs to the rollup's integration; chunking alone does not provide it.
During derivation, a certificate failing validity checks must not supply a rollup payload. A valid certificate whose blob cannot currently be fetched presents a different problem: derivation stalls while data remains unavailable. The retrieval implementation can retry supported sources, including validator reconstruction where its client supports that route. Erasure coding tolerates missing pieces only within its recovery conditions. It cannot recreate a blob when all accessible sources together supply fewer valid, unique chunks than the encoding requires.
Before you start with Eigenlayer
Does Chunking Encrypt EigenDA Rollup Data?
Erasure coding does not encrypt an EigenDA blob or make its transaction contents confidential. It transforms data into redundant pieces for reconstruction, while KZG commitments support integrity checks. Anyone recovering an unencrypted blob can read its payload in the applicable data format. An application needing private data must provide separate protection compatible with its execution and verification design.
Must a Rollup Restake ETH Before Submitting EigenDA Blobs?
A rollup does not need to restake ETH merely to submit a paid EigenDA blob. Restaked collateral backs validator participation, while the submitting client's account pays for data dispersal through reserved capacity or supported on-demand payments. Payment eligibility, available capacity, and the required quorum configuration still govern whether validators accept that submission.
What Happens When an EigenDA V2 Retry Reuses the Same Blob Key?
The V2 disperser may reject a retry reusing a previously submitted blob key. The key derives from the blob header, and each dispersal request needs a unique key even when its payload bytes remain unchanged. A terminal failure therefore calls for a new request with a distinct header and its corresponding key, not repeated polling of the failed request.
Can a KZG Length Proof Establish an EigenDA blob's Exact Size?
A KZG length proof bounds an EigenDA blob's size without proving its exact length. The proof limits the degree of the committed polynomial, which constrains the blob representation. Payload-format rules separately govern decoding into the original rollup bytes. A valid upper bound therefore cannot substitute for the length and formatting checks required by payload decoding.
Will a Verifier Upgrade Invalidate Older EigenDA Certificates?
A verifier upgrade can preserve older certificates when the integration routes each certificate to the verifier active at its reference block. EigenDACertVerifierRouter maps activation blocks to verifier instances, allowing historical certificates to retain their applicable rules. For EigenDACertV4, the verifier also enforces the embedded off-chain derivation version. The rollup's software must support the corresponding derivation logic.