EIP-4844：Proto-Danksharding
Reducing Fees for Ethereum Layer 2 Rollups
Executive summary
EIP-4844, also known as proto-danksharding, aims to curtail gas fees on the Ethereum network by 10 to 100 times through the utilization of Blob-carrying transactions.
These Blobs represent an new way of storing data uploaded from L2 to L1 on the consensus layer (Beacon Chain) and will be pruned after ~1 month.
EIP-4844 will make the transition to full sharding easier since all future upgrades will happen on the consensus layer only.
With the implementation of EIP-4844, users will enjoy a significant reduction in gas fees on Layer 2s.
Background
Ethereum has implemented Layer 2 rollups as a scaling solution, allowing for transaction batching and sending the output to the Ethereum Mainnet.
Layer 2 solutions have reduced transaction costs significantly, with transactions being 10 times cheaper than those made on the Ethereum main network.
However, there is still potential for further optimization of Layer 2 rollups, which would benefit end-users by reducing costs even further.
As rollups collect large numbers of transactions, they execute them off-chain and submit the compressed transaction data and results to Ethereum. The open availability of this data is crucial for verifying that the rollup operator acted honestly. In the event of data discrepancies, challenges can be raised using the data. This concept is known as data availability (DA), and it's a critical aspect of the security of blockchains.
The current structure of Ethereum presents a challenge for optimizing Layer 2 rollups.
The data that L2 sends to L1 is stored in the Calldata of the transaction, which can be very expensive, often accounting for over 90% of the L2 transaction fees. This is because Calldata is originally designed as storing parameters for smart contract functions, and must be synced and downloaded by all nodes. However, the compressed data that L2 uploads to L1 is only needed for data availability, not for execution.
To reduce this transaction cost, a potential solution is to design a separate data type especially for the data uploaded from L2 to L1 called a 'Blob' - standing for “binary large objects”, introduced in EIP-4844.
EIP-4844, also known as the Cancun upgrade, is a proposal for improving the Ethereum network by reducing high transaction costs. This proposal introduces a new transaction type called a Blob-carrying transaction, which is aimed at lowering gas fees and improving overall network efficiency.
Blob?
A Blob is designed for storing compressed data from L2.
These Blobs are considerably large (~128 kB) and cheaper than the current calldata. After The Merge, Ethereum separated the execution layer (original one) and consensus layer (Beacon Chain).
The Blobs are stored on the consensus layer (Beacon Chain) instead of the execution layer and thus remain inaccessible from EVM.
With this method data availability is guaranteed while no further expenses would be consumed on these data.
Blob data is cheaper because it is inaccessible by the Ethereum Virtual Machine (EVM), which can only view a commitment to the Blob. Blobs are disseminated separately, using what is commonly referred to as "sidecars."
Blobs will get deleted once they are no longer needed.
This makes storing rollup data long-term the responsibility of the people that need it, such as rollup operators, exchanges, indexing services, etc.
The following is a walkthrough of Blob's lifecycle.
First, the L2 sequencer confirms a transaction and provides the result and proof (yellow), as well as the relevant data (blue), to the L1 transaction pool.
The Beacon Proposer on L1 then separates the Blobs and stores them in the consensus layer before broadcasting the transaction to other Beacon Peers.
These Peers receive the latest block proposal and transaction results, and if they wish to become an L2 verifier, they can download any data from Blob's sidecar for verification.
To conclude, proto-danksharding increases the payload that a transaction carries without incurring extra costs. This fact alone makes it feasible for Ethereum to process more data at the same rate. And because the network can suddenly scale and process more transactions, gas fees become cheaper.
Why Blob?
Why do Ethereum developers want to build a new type of (blob-carrying) transaction to reduce gas when they can simply work on making calldata 10x cheaper? This is because:
Cheaper calldata could result in an average case/worst case load mismatch.
While the average Ethereum block size is currently around 90 kB, the maximum block size can reach up to approximately 1.8 MB. During times of high network activity, more transactions can be accommodated in a block, but this would require significantly higher gas fees.
Simply lowering the cost of calldata may result in unaffordable payload to Ethereum.
If calldata were to become 10 times cheaper, transaction volume would likely increase by the same factor, resulting in larger block sizes, with a worst-case scenario of 18 MB. As Ethereum's network cannot accommodate such large blocks, this would cause significant issues.
With Proto-danksharding, the maximum size of each block is limited to 2 MB.
Proto-danksharding introduces a new transaction type that stores data in large, fixed-size Blobs. Each block has an upper limit on the number of blobs that can be included, with current limits set at 16 blobs per block. Currently, a transaction can carry up to 2 blobs using this method. By utilizing this new transaction type, gas costs can be reduced without causing issues with block sizes that would otherwise occur with cheaper calldata.
After proto-danksharding, even though sharding will still require a significant effort, the complexity will be primarily limited to the consensus layer. As a result, execution layer client teams and rollup developers won't need to put in any additional work to transition from proto-danksharding to full sharding.
How does Proto-Danksharding impact L2 fees?
In order to understand how we cut costs we first need to understand what makes up a transaction fee on Layer 2s.
Gas consumed on Layer 2 is actually the sum of
Rollup Costs: The cost of rolling up transactions into batches and submitting them to L1
and L2 Execution Costs: The cost to run the transaction on a L2.
Rollup Cost
Rather than paying L1 Ethereum gas prices for your entire transaction execution, on L2 you only pay those prices for the portion of your transaction data that is submitted to L1 in a transaction batch.
This cost includes the actual Calldata (input data) for your transaction, as well as a Fixed Overhead cost, which is the additional processing required to add an additional transaction to the largerbatch.
The Layer 1 Gas Fee represents these rollup costs:
Layer 1 Gas Fee =Fee Scalar * L1 Gas Price * (Calldata + Fixed Overhead)
L2 Execution Cost
Like all Layer 1 networks, L2s incur costs for execution, storage, and data availability.
This gas price can increase slightly during high usage periods, but usually only makes up <1% (e.g., 0.4% on Optimism) of the total transaction fee on average.
The Layer 2 Gas Fee represents the execution cost:
Layer 2 Gas Fee = L2 Gas Price * L2 Gas Used
As previously mentioned, the implementation of EIP-4844 would result in reduced transaction fees on Ethereum by separating Blobs from calldata. It is important to note that the current L1 gas fee is largely proportionate to calldata, which is significantly higher than fixed overhead.
By reducing calldata, fees will decrease proportionally, potentially attracting more users and this would result in a decrease in fixed overhead, leading to an overall decrease in transaction fees on L2 by up to 100 times!
Reference:
EIP-4844: https://eips.ethereum.org/EIPS/eip-4844
EIP-4844 website: https://www.eip4844.com/
The Road to Sub-dollar Transactions Part 1: Slashing Fees by 30%: https://medium.com/ethereum-optimism/fancy-numbers-how-we-lowered-fees-for-optimism-users-a3bb80cbc65f