A Quick Guide to EIP-4844 for Beginners

To address the high gas fee problem on Ethereum, EIP-4844 has been proposed as a temporary solution. But what is it and how does it work? Here we’ll explain this technical term specifically!

The high gas fee issue on Ethereum has led to EIP-4844 (also known as proto-danksharding), an attempt to introduce a temporary solution to increase the block space within the network by implementing a transaction format that should have been implemented in sharding, a strategy for scaling Ethereum. Since deploying shards can take a while, to reduce the high gas fees users currently are paying, this new transaction format is being implemented. Since this is a temporary solution, there is only a capped amount of block space that has been added, which would add approximately 16 MB of block space in the full deployment of shard chains.

To understand more about this Ethereum improvement proposal and how it helps the chain, let’s dig a little deeper!

How Will EIP-4844 Work?

The EIP 4844 proposal is attempting to create a “stop-gap” solution so that the network can relieve itself from the ever-increasing transactions by adding roughly 2 MB worth of space to the blocks. As you can imagine, this only gives some relief to both the network and the users who can now rely on the lower gas fees.

When rollups are implemented, they will rely on the sharded data (which is also known as a blob) to ensure that the network has been eased off and the users don’t incur extremely high gas fees. Another thing to note here is that several different versions of this EIP have been talked about previously. However, this version aims to only introduce the format that will be used for sharded data, without actually sharding it.

One of the main challenges to this is the implementation itself. If only a part of the sharding process is being implemented in this round, then how would the remainder of it be implemented? While the process may seem simple, it would depend on how the community decides to take this forward. So far, several ground-level changes have already been implemented, while some of them are still in the works.

The main tradeoff in designing this EIP is that of implementing more now versus having to implement more later: do we implement 25% of the work on the way to full sharding, or 50%, or 75%?

Prior to this, most of these updates have been reliant on the rollupcentric roadmap for Ethereum. Proto-danksharding, on the other hand, only provides the transaction formats and verification rules for the process to execute, without implementing it completely. As part of this, a new transaction type is created here. It is known as the “blob-carrying transaction”. It attempts to include the blobs as data within the blocks. These are utilized by layer-2 solutions to help scale Ethereum, without relying on the Ethereum Virtual Machine (EVM) to access it.

EIP-4488 and Proto-danksharding

Currently, the network has been designed to accommodate transactions that make up roughly 90 Kb of block space for each block. Even if the gas fee model were to be tweaked in a way to accommodate larger block sizes, the maximum size could potentially balloon up to 18 MB. However, that in itself would be too costly both for the participating validators and users. On the other hand, if we utilize the dynamic fee market that has already been implemented as part of EIP 1559, then that helps us accommodate more transactions without burdening the network too much.

Proto-danksharding makes things slightly less complicated. The process entails the creation of a transaction that holds data in relatively fixed-size blobs by also introducing an upper limit to the number of blobs that can be included in the block. These are then stored by the beacon chain, and only require a commitment confirmation from the Ethereum Virtual Machine (EVM).

There is just one significant difference between EIP-4488 and proto-danksharding, which is in terms of implementation. While the former introduces minimal changes today so as to create an interim solution, the latter requires a more thorough implementation so that the amount of effort needed to be put in later is minimized. The complexity of implementing sharding is only limited to the beacon chain and not the execution layer.

The increasing block size can also have repercussions on the block size and the ability of validators to store data on their hardware resources. As per estimates, there can be a rise to over 2.5TB of data per year. One of the ways of reducing this is to delete the blob data that gets old after a certain period of time, say 30 days or more.

How Will Users Access the Old Blobs After EIP-4844 Is Implemented?

It can be but the aim of EIP-4844 is not to guarantee permanent storage of historical data of the blockchain as it can accrue a lot of expenses on the network participants. Rather, it has been proposed that the data can be stored elsewhere in a way that it is easily accessible like several applications/protocols that provide that service. This way, the historical data can be accessed by those needing it.

Conclusion

The EVM is going through some changes as we get closer to the Merge. Some of these changes will help scale Ethereum, enabling it to support more transactions and provide greater scalability. One of them is undoubtedly proto-danksharding.