All Ethereum L2s Fees Are About to get Cheaper Thanks to EIP-4844

Are you ready to protodankshard?

EIP-4844 is the first iteration of the sharding design of Ethereum.

Sharding is a way for Ethereum to have more data go through the network.

Famously Ethereum already mentioned sharding as one of the scalability updates in 2016. Eventually, with time, they have shifted from full-execution sharding to only data sharding in what Vitalik describes as “increased pragmatism”, considering how complex would be to bring full sharding into production.

In fact, the issue of data availability on the Ethereum network is one of the primary scaling bottlenecks.

Data availability can be defined as “proof that the underlying data behind a particular hash has actually been published to this public board where if people want they can get it and verify it”.

EIP-4844 is trying to add data availability capacity on Ethereum without breaking composability and the execution layer on L1.

---

Why EIP-4844: to create a cheap place for L2 solutions to post data on Ethereum and reduce overall transaction fees users pay on L2 by a lot.

Problem: L2s produce an increasing amount of data. If there’s a way to post that in a cheap way, it will immediately reduce how much the networks charge users to transact.

Solution: new transaction format for “blob-carrying transactions”. It contains a large amount of data that “cannot be accessed by EVM execution, but whose commitment can be accessed”. Instead of embedding the full contents in the body, the contents of the blobs are propagated separately, as a “sidecar”.

This is probably one of the most interesting EIP for users, as they will directly benefit as they will be paying fewer fees on their favorite L2.

So.. Yes! EIP4844 reduces transaction fees on L2s.

This is the simpler implementation of sharding on Ethereum and another step forward in the Ethereum “rollup-centric roadmap”.

EIP4844 introduces:

Instead of containing transactions being executed in the Ethereum blocks, shard blocks would just contain “blobs of data” and would be the responsibility of L2 to use that data space in order to create a secure and more scalable experience for their users.

WTF IS A BLOB?

An opaque, raw, byte string attached to a transaction, that makes its way to the Ethereum system. The attached content has this additional lifetime:

The blob transactions pay the fee and include a commitment to sufficiently prove that some data exists — but the data itself is separated.

The fee payment and references are processed by Ethereum, while the commitment and the blobs are stored elsewhere until pruned: there is no direct blob content in Ethereum EVM, they persist in beacon nodes, not in the execution layer.

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

• L2s: convert non-scalable data and non-scalable computation into scalable computation (data availability + execution check).

This design choice has been strategic to make sure that future sharding work will only require changes to the beacon node, enabling the execution layer to work on other initiatives in parallel.

These are the beacon-node changes involved in this EIP:

---

Why will L2s Fees be Lower?

Separate fees for transaction computation and storage

L2 will use a different function to submit “blobs” to Ethereum.

Instead of using “CALLDATA”, which stores data forever, they would use blobs, which are pruned after a pre-defined period.

The blobs data does not have to be available forever, but for a certain period (e.g. 1-3 months), long enough that allow L2s to ensure at least 1 honest actor to reconstruct the state and challenge or replace the bad sequencer. The data gets then pruned.

EIP-4844 provides significant scaling relief for rollups by allowing them to initially scale to 0.25 MB per slot, with a separate fee market for blobs allowing fees to be very low.

Read: transactions will be 10x cheaper.

---

How would L2 use Blobs?

Putting data into blobs guarantees data availability while being much cheaper. L2s use KZG points in order to verify the validity of blobs.

A KZG point “shows that a specific value at that point is equal to a claimed value”.

• Optimistic Rollups would provide the underlying data when fraud proofs are submitted. The fraud proofs can verify the validity, “loading at most a few values of the blob at a time through call data”:

  For each value it would provide a KZG proof and use the point evaluation precompile to verify the value against the versioned hash that was submitted before.

• ZK Rollups would need to provide 2 commitments: the KZG in the blob and some commitment using the ZK proof system.

  They would then need to prove that:

  the KZG (which the protocol ensures points to available data) and the ZK rollup’s own commitment refer to the same data.

---

Food for Thought

I honestly don’t know if I did a good job of explaining the complexities behind EIP-4844. It touches on several technical aspects of Ethereum and it’s pretty hard to condense them all in a comprehensive introduction of EIP-4844 without constantly having to introduce and explain new concepts.

What is important 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 in line with Ethereum rollup-centric roadmap and further improves L2s scalability while being forward compatible with future sharding.

The door remains open for EVM execution shards in the future, but this is pragmatically the first step.

EIP-4844 is expected to be implemented sometime in the second half of 2023.