To tackle the high gas fee issue on Ethereum, EIP-4844 has been proposed as an interim solution. But what is it and how does it work? A not-so-technical guide to explain a technical term!
The high gas fee problem on Ethereum has led to EIP-4844 (also known as proto-danksharding), an attempt to introduce an interim solution for increasing the block space within the network by implementing a format of transactions that are otherwise supposed to be implemented in sharding, a strategy for scaling Ethereum. Since deploying shards can take a while, to reduce the high amount of gas fees that users are paying currently, this new transaction format is being implemented. Since this is an interim solution, there is only a capped amount of block space that has been added, which, in the full deployment of shard chains, would add roughly 16 MB of block space.
To understand more about this Ethereum improvement proposal and how it helps the chain, let’s dig a little deeper!
How Will EIP-4844 Help Users?
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.
The Need for 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 Old Blobs After the Implementation of EIP-4844?
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.
Closing Thoughts
As we move closer to the Merge, there are several changes that the EVM is going through. Some of these changes will help in scaling Ethereum so that it can be enabled to support more transactions and offer more scalability. Proto-danksharding is one of them.
This article contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of CoinMarketCap, and CoinMarketCap is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. CoinMarketCap is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by CoinMarketCap of the site or any association with its operators. This article is intended to be used and must be used for informational purposes only. It is important to do your own research and analysis before making any material decisions related to any of the products or services described. This article is not intended as, and shall not be construed as, financial advice. The views and opinions expressed in this article are the author’s [company’s] own and do not necessarily reflect those of CoinMarketCap. CoinMarketCap is not responsible for the success or authenticity of any project, we aim to act as a neutral informational resource for end-users.
