EIP-7594 PeerDAS (Peer Data Availability Sampling) (PeerDAS - Peer Data Availability Sampling)
Final · Scaling & data · EIP status Final · created 2024-01-12
A networking protocol that lets a node check only part of the blob data, without downloading all of it, and still be confident the data was actually published. It newly defines how blobs are propagated, stored and sampled.
Why it is needed
The biggest bottleneck for rollups (layer 2 roll-ups) running on Ethereum is layer 1 data availability, that is, how much blob data can be carried. EIP-4844 introduced blobs, but in the current design every node must download all the blob data to verify that it was published to the network. If the number of blobs is increased under this design, the bandwidth and storage burden on every node grows with it, which weakens decentralization. PeerDAS solves this with data availability sampling (DAS), in which each node downloads and spot-checks only part of the full data. Each node checks different pieces in a near-random way, so across the network as a whole it is possible to verify that all the data was published while keeping the burden on each individual node small.
What changes
Today
- Every node downloads all the blob data in a block to check availability
- Raising blob throughput raises node bandwidth and storage requirements by the same amount
- The blob transaction mempool wrapper carries per-blob proofs
After EIP-7594
- A node downloads only a part of the full data (1/8 at current parameters) to check availability
- Blob throughput can be raised safely without raising node requirements
- The sender of a blob transaction computes the cell proofs itself and sends them along
- A single transaction can carry at most 6 blobs
Who is affected
- L2 (rollups): The path opens for the layer 1 data availability bottleneck to grow, which becomes the basis for scaling throughput.
- Node operators: A node stores only the columns assigned by its own node ID instead of all the blob data, and checks them by receiving samples from peers every slot.
- Wallet and app developers (blob senders): When sending a blob transaction, they must compute and include the cell proofs themselves and must respect the limit of 6 blobs per transaction.
- Validators: They carry an extra requirement to store more data than a regular full node, and this requirement grows in proportion to the number of validators.
In depth
The row, cell and column structure from extending blobs with erasure coding
The blobs of EIP-4844 are extended with one-dimensional erasure coding. Each row consists of the blob data and its erasure code, and rows are split into cells. A cell is the smallest unit that can be authenticated with the KZG commitment of its blob. A column is a cross-section that collects the cells of all rows at a particular index, and each column corresponds to a particular gossip subnet. Data is split along the column direction, not the blob (row) direction, and spread across the network.
Node ID based custody, per-slot sampling and 50% reconstruction
Each node maintains a set of column subnets determined as a function of its own node ID and stores (custody) that data. A node finds and maintains a diverse set of peers and performs DAS by sampling columns from peers every slot. A node that holds at least 50% of all columns can reconstruct the entire data matrix, and if it holds less than 50% it can request the needed columns from peer nodes. The detailed specification is in the fulu specification of ethereum/consensus-specs.
Limit of 6 blobs per transaction
The number of blobs a single transaction can carry is limited to 6. Clients MUST apply this limit at all three points where a blob transaction is validated: at submission, when received from the network, and during block production and processing. This is a new per-transaction cap that did not exist in EIP-4844, so senders that bundle multiple blobs must take this limit into account.
Cell KZG proofs and the mempool wrapper change
A cell KZG proof proves that a KZG commitment opens to the cell at a particular index. Computing the proof is expensive, verification is much cheaper, and the proof size is negligible compared with a cell, so the blob transaction sender, not the block producer, computes the proofs and includes them in the mempool wrapper. The wrapper in a PooledTransactions response becomes rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]). wrapper_version is 1 byte and the current version is 1. cell_proofs holds CELLS_PER_EXT_BLOB proofs per blob, including the extension indices, and cell_proofs[i * CELLS_PER_EXT_BLOB + j] is the proof for cell j of compute_cells(blobs[i]). The blobs themselves are sent unextended (CELLS_PER_EXT_BLOB / 2 cells per blob), because the receiving node can compute the extension data quickly and this avoids sending redundant data.
Validation rules for the receiving node
A node MUST validate tx_payload_body and check the wrapped data against it. There are four conditions. First, tx_payload_body.blob_versioned_hashes, blobs and commitments must have the same length. Second, cell_proofs must contain exactly CELLS_PER_EXT_BLOB * len(blobs) entries. Third, kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] must hold. Fourth, commitments must match the corresponding blobs and cell_proofs, which is a process of computing the extended cells of all blobs with compute_cells or similar and then checking all cell proofs. All cell proofs can be batch-verified at once with verify_cell_kzg_proof_batch or similar.
Why sample by column rather than by row
A sample is defined not as a row, which is an entire single blob, but as a column, which is a cross-section across all blobs. With row sampling, reconstruction would have to happen over extended blobs that do not exist in the network to begin with. With columns, most blobs are in the public mempool, so a node can be assumed to already hold a substantial part of the full data, which makes reconstruction much easier. Also, row sampling requires the column-direction extension to be done at block construction time, that is, on the busiest path (critical path), whereas the row-direction extension needed for column sampling can be done in advance, and proof computation can be left to the blob transaction sender.
The 1/8 node burden and extra custody for validators
At current parameters, a node only needs to download 1/8 of the full data (the blobs in a block) to check local availability. Reducing the sample size and increasing the number of columns can lower this to 1/16 and 1/32 in the future. Because peers are the basic unit, redundancy arises, so even if one peer fails to respond, another peer can take over the same sampling. A node can also voluntarily store more data than the minimum requirement to improve overall performance. Validators are subject to a higher custody requirement than full nodes, and this requirement grows in proportion to the number of validators, so that well-resourced nodes contribute to a more stable backbone that supports the network.
Security analysis against data withholding attacks
The main failure mode of DAS is a data withholding attack, in which a block producer does not release the data while pretending it was published. PeerDAS prevents this with pseudorandom sampling, and the larger the network, the lower the attack success probability. In the analysis, n is the number of sampling nodes, m is the total number of possible samples (NUMBER_OF_CUSTODY_GROUPS), and k is the minimum number of samples a node must download (SAMPLES_PER_SLOT). Assuming 10,000 nodes with mainnet parameters, the upper bound on the probability of fooling 2% of all nodes (200) is 10^-20.04, for 3% (300) it is 10^-101.55, and for 5% (500) it is 10^-306.34, falling sharply, so it is judged safe against withholding attacks.