Data Availability via EigenDA
Last updated
Last updated
The OP Stack batcher is the part of the sequencer responsible for posting batches of L2 transaction data to DA. We updated this component to write batches to EigenDA instead of Ethereum calldata. When a batch is successfully written to EigenDA, the EigenDA disperser returns a unique blob key, which can be used to later retrieve the data that was written. The batcher then posts this blob key to Ethereum calldata, so that Ethereum remains the source of truth for the L2 ordering of EigenDA blobs.
Importantly, the OP Stack x EigenDA fork supports writing each batch to multiple EigenDA quorums, enabling redundant security and mitigating data withholding attacks.
OP Stack full nodes derive the L2 state from transaction data posted to DA. In a loop, they download L2 transaction batches from DA and execute them. To add EigenDA support, we modified the OP Stack node to seamlessly handle retrieving EigenDA blobs using blob keys indexed in the Ethereum calldata. This involves a set of scatter-gather requests to EigenDA Operators storing chunks of the blob requested. If the retrieval of the blob from one quorum fails, the next will be tried, until the blob is retrieved or there are no more quorums to try.
To implement this server spec, EigenDA provides EigenDA Proxy which is ran as a dependency alongside OP Stack sequencers and full nodes to securely communicate with the EigenDA disperser.
Shown below is a high level flow of how proxy is used across a rollup stack by different network roles (i.e, sequencer, verifier). Any rollup node using an eigenda integration who wishes to sync directly from the parent chain inbox or a safe head must run this service to do so.
Usage
Different actors in the rollup topology will have to use proxy for communicating with EigenDA in the following ways:
Rollup Sequencer: posts batches to proxy and submits accredited DA certificates to batch inbox
Rollup Verifier Nodes: read batches from proxy to update a local state view (assuming syncing from parent chain directly)
Prover Nodes: both rollup types (i.e, optimistic, zero knowledge) will have some way of deriving child chain state from the parent's inbox for the purpose of generating child --> parent bridge withdraw proofs. These "proving pipelines" will also read from proxy as well; either for settling disputes in optimistic rollups with working fraud proofs or for generating zero knowledge proofs attesting to the validity of some batch execution.
