EIP-4844 explained: How to reduce L2 transaction costs by 10 times

Imagine that transaction costs on Arbitrum, Optimism, and various L2s will be reduced by 10 times. How can this be done? The answer is EIP-4844. Below is a comprehensive guide to EIP-4844.

What is EIP -4844 ?

EIP-4844 is the first iteration of Ethereum's sharding design. Sharding is a way for Ethereum to allow more data to pass through the network. Ethereum has already introduced sharding as one of its scalability solutions in 2016. Over time, sharding has shifted from full implementation sharding to data-only sharding, which Vitalik describes as "enhanced pragmatism."

In fact, the data availability problem on the Ethereum network is one of the main expansion bottlenecks. Data availability can be defined as "proving that the underlying data behind a specific hash value has actually been published to the public ledger and that people can freely obtain this data and verify it." EIP-4844 attempts to increase the data availability capacity on Ethereum without destroying the composability and execution layer on L1.

Reason for choosing EIP-4844: To create a low-cost venue for L2 solutions to publish data on Ethereum and significantly reduce the total transaction fees paid by users on L2.

Problem: L2 is generating more and more data. If there is a way to publish this information in a low-cost way, it will immediately reduce the transaction fees charged by the network to users.

Solution: Introduce a new transaction type called “blob-carrying transactions” that contain a large amount of data that cannot be accessed through the EVM execution, but whose promises can be accessed.

Instead of embedding the entire content into the body, the contents of the blob are propagated separately as a "sidecar". This is probably one of the most interesting EIPs for users, as users will directly benefit by paying less fees on their favorite L2 to use. This is a simpler implementation of sharding on Ethereum and another step forward for Ethereum's "rollup-centric roadmap".

EIP-4844 introduces:

A new transaction type with the exact same format required for “full sharding”.

All execution layer logic required for full sharding.

All execution/consensus cross-validation logic required for full sharding.

· Layer separation between BeaconBlock verification and data availability sampling blobs.

Most of the BeaconBlock logic required for full sharding.

A self-regulating independent gas price for blobs.

Shard blocks will not contain transactions executed in Ethereum blocks, but only "data blobs", and L2 will be responsible for the use of this data space in order to create a secure and more scalable experience for its users.

What is a Blob ?

An opaque raw string attached to a transaction as it enters the Ethereum system. Content attached to a "sidecar" has an additional lifecycle: a blob transaction pays a fee and promises sufficient proof that some data exists — but the data itself is separate.

Fee payments and references are handled by Ethereum, while commitments and blobs are stored elsewhere before being pruned: there is no direct access to blob contents in the Ethereum EVM, they are kept in beacon nodes, not in the execution layer.

• Ethereum: non-scalable computing, scalable data (execution engine);

•L2: Convert non-scalable data and non-scalable computation to scalable computation (data availability + execution checks).

This design choice was strategic to ensure that future sharding work only requires changes to the beacon nodes, allowing the execution layer to handle other activities in parallel.

The beacon node updates involved in this EIP are as follows:

Beacon chain: processes updated beacon blocks and ensures blob availability.

P2P network: broadcasts and synchronizes updated beacon block types and new blob sidecars.

Honest validator: generates beacon block with blob, publishes blob sidecar.

Why are L2 fees going down?

The fees for transaction computation and storage are separate: L2 will submit a "blob" to Ethereum using a different function. Instead of using "CALLDATA" which stores the data forever, a blob is used which will be pruned after a predefined period of time. The blob data does not need to be available forever, but it needs to be available for a period of time (e.g. 1-3 months), enough time to allow L2 to ensure that at least one honest participant reconstructs the state and challenges or replaces the bad sequencer. The data is then pruned.

EIP-4844 greatly reduces the scaling burden of rollups by allowing rollups to initially scale to 0.25 MB per slot, providing a separate, extremely low-fee market for blobs. As a result, transaction costs will be lower, by an order of magnitude.

How will L2 use the Blob?

Storing data in blobs can ensure data availability while being less expensive. L2 uses KZG to verify the validity of blobs.

So, what is KZG? KZG "means that the specific value at that point is equal to the declared value".

•When a fraud proof is submitted, Optimistic Rollup provides the underlying data. The fraud proof can verify validity "by calling the data to load at most several values ​​of the blob at a time." For each value, it will provide a KZG proof and use the point calculation precompile to verify the value against the previously submitted hash version.

•ZK rollup needs to provide 2 commitments: KZG in the blob and some commitment using ZK’s proof system. They then need to prove that KZG (which the protocol ensures points to available data) and ZK rollup’s own commitment refer to the same data.

Some thoughts

I’m not actually sure I’ve done a good job explaining the complexity behind EIP-4844. This involves several technical aspects of Ethereum, and it’s hard to include them all in an explanation of EIP-4844 without constantly referencing and explaining new concepts. The important thing about EIP-4844 is that its value will trickle down to users, as we will all be able to benefit from lower L2 fees.

The reasoning behind this proposal is consistent with Ethereum’s rollup-centric roadmap, further improving L2 scalability while being compatible with future sharding. The door to future EVM-enforced sharding is still open, but this is really just the first step.

EIP-4844 is expected to be implemented in the second half of this year.