Proto-Danksharding (EIP-4844): What's next for Ethereum?

The Ethereum Layer 2 revolution has begun. We are already seeing transaction fees dropping orders of magnitude, alongside considerable increases in speed. However, roll-ups only address the execution side of the problem, not the data storage. As L2's scale even further, they will be creating enormous amounts of data which could result in hugely expensive transactions.

​

Hence, Ethereum needs solutions for data scalability. That is where we turn to the "what's next" of Ethereum development. The Ethereum core devs have set this out as a 3 part plan:

​

1) Proto-Danksharding (EIP-4844)

2) Enshrined PBS

3) Danksharding

​

Of course, these are only planned developments and hence are subject to change. But this is the current roadmap.

Sharding is the process of splitting a database horizontally to spread the load. In an Ethereum context, sharding will reduce network congestion and increase transactions per second by creating new chains, known as “shards.” This will also lighten the load for each validator who will no longer be required to process the entirety of all transactions across the network.

​

unsharded vs sharded network schematic

Proto-danksharding (EIP-4844) proposes to implement transaction formats and verification rules but not actually implementing any sharding. Rather, all validators and users will still have to validate the availability of the full data sets directly. A new transaction type will be introduced by proto-danksharding, a 'blob-carrying transaction'.

​

'Data Blobs'

This is like a normal transaction, except it has an extra piece of information called a blob. Blobs are large (around 125 kB of data) and are cheaper than the equivalent amount of calldata. However, the Ethereum virtual machine (EVM) cannot access the blob data contents, only viewing the blob's commitment.

The evolution from Proto-Danksharding to Danksharding will involve 2 further changes:

• The number of blobs per block will increase from 1 to 64
• Blob data will be distributed across the network, so no single node needs to download them all

​

Obviously increasing from 1 to 64 blobs is a huge increase in network capacity but also would require a huge step up in computational power needed to build each block. Most low-spec Ethereum nodes would not be able to manage this.

​

That's where the next big development comes in: protocol-enshrined Proposer-Builder Separation (PBS). In simple terms, the process of building and proposing a block is separated.

PBS improves scalability by allowing for stateless validators. If all builders include a witness for each transaction, then the proposer can just select the header with the highest fee, without having to process any data. This means that validators wouldn't need to keep track of the entire blockchain history.

This data could be shared on the Peer-2-Peer network:

https://typefully.com/SalomonCrypto/danksharding-f4UhffE

In short: every individual node would download only a small data sample from each blob. If requested, the network can then quickly and efficiently recreate any single blob.

​

So these updates would bring about fundamental changes to Ethereum and its data storage. I am no expert but learning about these technological developments is super interesting to me. It's going to be fun to see this play out as L2 demand continues to grow rapidly, alongside the data demands that will generate. As I said, I am far from an expert so if I have got anything confused please do let me know and hopefully we can all learn together!