Special thanks to Brecht Devos and Ben Wan for review. Special special thanks to Dani for the meme.
TL;DR
Two core changes are coming with EIP-4844:
-
Increased amount of data that can be posted in one Ethereum block. So, rollup throughput will grow.
-
Introduction of a new transaction type, blob transaction, and a separate fee market. So, the data transactions won’t compete with regular transactions.
Both these changes will decrease the data posting cost for rollups. However, today, it’s impossible to say how huge the cost drop will be as this will be an open market based on congestion.
In this note, we briefly explain what EIP-4844 is and explore how it will affect rollups. For the history of danksharding, mathematical details, and mechanism choice explanation, check an article by Dom or Proto-Danksharding FAQ.
Content
-
Introduction: very quick retrospective
-
Data Availability (DA)
-
Proto-danksharding: EIP-4844
Introduction: very quick retrospective
The idea behind scaling Ethereum is to have more blockspace without increasing the burden on the nodes that constitute the network. After many debates, the chosen solution is that Ethereum (Layer 1) will scale data, and Rollups (Layers 2) will convert this scalable data into scalable execution.
Before the Rollup-centric roadmap, Ethereum explored sharding as a scaling solution. Sharding is a horizontal scaling method where each shard is its own mini-blockchain running in parallel to each other on the Beacon Chain. However, when rollups appeared, they were assumed to be much more efficient and flexible for scaling Ethereum than sharding. The pure sharding was dropped.
Instead of it, Dankrad Feist suggested danksharding, which allows validators to do a very small amount of work to check that all the data is available using DAS, Data Availability Sampling (without having to download all the data as it happens today). It solves the problem of rollup sequencers potentially withholding data: just like nodes won’t follow a fork that contains invalid transactions, nodes won’t follow a fork where data isn’t available – even if 99% of validators are maliciously trying to withhold data.
As danksharding is still pretty complex, protolambda suggested an intermediate step – proto-danksharding, introducing the blob-carrying transaction type that rollup sequencers will use, but without data availability checks (DAS) for now. Proto-danksharding was wrapped up in EIP-4844, which is expected to go live in Q4 2023.
Data Availability (DA)
Rollups post data of each block to the L1. This data should be available for everyone.
Data Availability means that no network participant, including a colluding supermajority of full nodes, has the ability to withhold data.
When the data is available, anyone can derive the chain state from the posted data and check that the derived state matches the state provided by the rollup.
DA problem is a primary scaling bottleneck for Ethereum. Now, it’s done through CALLDATA, which is pretty expensive. To provide some estimation, posting data to L1 constitutes roughly 80% of rollup operating costs.
Proto-danksharding: EIP-4844
Blobs and blob-carrying transactions
EIP-4844 replaces CALLDATA with a new “Blob layer” to increase rollup throughput and make posting data cheaper. With EIP-4844, data is posted as a “blob” and a new transaction type is introduced, a blob-carrying transaction, that rollup sequencers will use.
With this new transaction type, blob data is stored on the Beacon Chain. That is, the EVM doesn’t have access to this data directly. The L2 nodes can retrieve the data (to use it in a smart contract if needed) from Beacon Clients within 2 weeks and derive the L2 chain from this data. To retrieve the data, one makes a request to the Ethereum node. Then they use that data in a transaction (using CALLDATA) and verify if that data matches the data in a blob using the blob hash (that is directly available in the EVM).
What new things should we consider about EIP-4844?
New pre-compile: point evaluation pre-compile
For ZK proofs, a new pre-compile will be added: point evaluation pre-compile. It uses the data commitment made available in the EVM (as a “source of truth”), a point on the blob, its expected value, and the proof. The opcode checks that this blob point matches the expected value. That is, the committed block data is equivalent to the data that the rollup is importing.
New type of gas: data gas
A new gas type will be introduced to price the blob data: data gas. It works similarly to the EIP-1559 mechanism with several changes:
-
basefee is derived from
excess_data_gassimilar to EIP-1559 mechanism. -
max_fee_per_blob_gas is the bid for how much the sender is willing to pay for the blob. -
blob_version_hashes is a list of the hashes of blobs (as a single transaction can come with multiple blobs).
Thanks to the introduction of the new transaction type and separate fee market, blob transactions don’t compete with regular L1 transactions. That is, blob transaction pricing does not depend on the L1 network fees of regular transactions.
Node requirements
Nodes are expected to serve blob data as requested for 4,096 epochs, which is roughly 18 days. After this period, nodes can prune the data from their hard drive and stop serving it.
Letting blobs expire puts an upper bound on the extra storage requirements. Today, each block provides ~ 1 kb of data storage space. After EIP-4844, it will be ~ 384 kb with a target of 3 blobs per block. It results in a bit under 50 gigabytes of extra data storage requirement for the node if it deletes old blobs as new ones come in (computed as max_amount_of_blobs/block * num_blocks_in_4096_epochs).
Once blobs have expired, the data will still be retrievable by some out-of-protocol means (e.g., TheGraph, block explorers, node providers, etc.)
Other details
-
KZG commitments are used instead of Merkle Proofs as they are more succinct and cheaper to verify than to recompute the hash commitments.
-
EIP-4844 requires an Ethereum Consensus upgrade. However, for further danksharding upgrades, only Beacon Chain upgrades will be required.
Sources: