What Is EIP-4844, and How Will EIP-4844 Help Users?

• Blockchain Council
• June 03, 2022

EIP-4844 (also known as proto-danksharding) is an effort to propose an intermediate solution for the high gas fees issue on Ethereum. The solution proposes expanding block space inside the network by implementing a transaction format that is otherwise planned to be implemented in sharding, an Ethereum scaling approach.

Due to the time it takes to deploy shards, this new transaction type is being adopted to minimize the high gas prices that customers are now paying. In addition, because this is an interim solution, only a limited amount of block space has been added, which would contribute around 16 MB of block space if shard chains are fully deployed.

In a nutshell, this proposal would establish a more efficient method of organizing data logistics in order to enable high transaction throughput. In addition, it may be viewed as a method of increasing data availability.
Let’s delve a bit further into this Ethereum upgrade suggestion to learn more about how it benefits the chain.

What is EIP 4844 or Proto-danksharding?

Proto-danksharding, also known as EIP-4844, is a proposal to implement the bulk of the logic and “scaffolding” (e.g., transaction formats, verification criteria) that make up a full Danksharding standard, but no sharding yet. All validators and users must still directly confirm the availability of the whole data in a proto-danksharding implementation.

The main feature of proto-danksharding is the addition of a new transaction type called a blob-carrying transaction. A blob-carrying transaction is similar to a conventional transaction, except it also includes an additional piece of data known as a blob. Blobs are incredibly huge (up to 125 kB) and can be substantially less expensive than call data. However, EVM execution does not have access to blob data; the EVM can only see a commitment to the blob.

Because validators and clients must still download complete blob contents, proto-danksharding data bandwidth is limited to 1 MB per slot rather than the full 16 MB. However, because this data does not compete with the gas use of regular Ethereum transactions, there are significant scalability improvements.

What is danksharding?

Danksharding is a new sharding concept suggested for Ethereum that simplifies the process significantly over prior versions.

The main difference between all recent Ethereum sharding proposals (both Danksharding and pre-Danksharding) and most non-Ethereum sharding proposals since 2020 is Ethereum’s rollup-centric roadmap: instead of providing more space for transactions, Ethereum sharding provides more space for blobs of data, which the Ethereum protocol does not attempt to interpret. Checking that a blob is accessible – that it can be retrieved from the network – is all that is required to verify it. Layer-2 rollup protocols that allow high-throughput transactions are intended to leverage the data space in these blobs.

Danksharding’s key innovation is the merged fee market: instead of having a predetermined number of shards, each with its own set of blocks and block proposers, Danksharding has just one proposer who decides all transactions and data that go into that slot.

To prevent this design from putting additional system requirements on validators, Ethereum developers have created a proposer/builder split: a specialized class of actors known as block builders bids on the right to define the contents of the slot, and the proposer simply chooses the valid header with the highest bid.

Only the block builder (and even then, third-party decentralized oracle protocols may be used to establish a distributed block builder) must process the entire block; all other validators and consumers can swiftly validate blocks via data availability sampling.

How Can EIP-4844 Assist Users?

The EIP 4844 proposal attempts to offer a “stop-gap” solution to alleviate the network of the ever-increasing transactions by adding around 2 MB of space to the blocks. As you can expect, this only provides modest comfort to both the network and the consumers who can now count on cheaper gas prices.

When rollups are implemented, sharded data (also known as a blob) will be used to ensure that the network has been eased off and that users are not paid high gas charges. Another thing to keep in mind is that various distinct versions of this EIP have been discussed earlier.

This version, on the other hand, aims to just offer the sharded data structure without actually sharding the data. The implementation is one of the more difficult components of this.

How would the remainder of the sharding process be implemented if only a portion of it is done in a round? 

While the procedure may appear straightforward, it all depends on how the community decides to proceed. Several ground-level adjustments have already been implemented, while others are currently being developed.

The key trade-off in developing this EIP is between implementing more now and needing to implement more later: should we implement 25%, 50%, or 75% of the work on the path to complete sharding?

Most of these adjustments were previously based on Ethereum’s rollup-centric strategy. Proto-danksharding, on the other hand, just supplies the transaction forms and verification criteria required to perform the process without completely implementing it. As part of this, a new transaction type is created. It’s known as the “blob-carrying transaction.” Within the blocks, the blobs are attempted to be incorporated as data. These are used by Layer-2 solutions to help scale Ethereum without relying on the Ethereum Virtual Machine (EVM).

The Importance of Proto-danksharding

Currently, the network is set up to support transactions that take up about 90 kilobytes of block space every block. Even if the gas charge scheme were changed to allow for greater block sizes, the maximum size might theoretically increase to 18 MB. However, this would be prohibitively expensive for both the validators and the consumers. However, if we use the dynamic fee market that was previously introduced as part of EIP 1559, we can handle more transactions without putting too much strain on the network.

Proto-danksharding simplifies things a little bit. The procedure comprises creating a transaction that stores data in relatively fixed-size blobs while also imposing a maximum number of blobs that may be included in the block. The beacon chain then stores them, and all that is required is a commitment confirmation from the Ethereum Virtual Machine (EVM).

The implementation of EIP-4488 and proto-danksharding differ just slightly. While the former requires just minor alterations today in order to provide a temporary solution, the latter demands a more complete implementation in order to reduce the amount of effort required hereafter. Only the beacon chain, not the execution layer, is complicated enough to implement sharding.

The increased block size may have an impact on the block size as well as validators’ capacity to store data on their hardware resources. According to projections, annual data volumes might reach over 2.5 terabytes. One option to mitigate this is to destroy blob data that has become obsolete after a particular length of time, such as 30 days or longer.

After EIP-4844 is implemented, how will users be able to access old blobs?

It is possible, however, the goal of EIP-4844 is not to provide permanent preservation of blockchain historical data since this would incur high costs for network participants. Rather, numerous applications/protocols that provide such service have advocated that the data be kept elsewhere in a fashion that is easily accessible. Those that want historical data will be able to access it in this manner.

What aspects of full danksharding does proto-danksharding implement, and what aspects of full danksharding remain unimplemented?

The following is a list of the work that has already been completed as part of this EIP:

• A new transaction type with the same format as the “full sharding” transaction type.
• For complete sharding, all of the execution-layer logic is necessary.
• For complete sharding, all of the execution/consensus cross-verification logic is required.
• BeaconBlock verification and data availability are separated by a layer. blobs for sampling
• For complete sharding, the majority of the BeaconBlock logic is required.
• Blobs have their own self-adjusting gas price.

The following tasks must be completed before full sharding may be achieved:

• To facilitate 2D sampling, a low-degree extension of the blob _kzgs in the consensus layer was added.
• To avoid forcing individual validators to evaluate 32 MB of data in one slot, real-world implementation of data availability sampling PBS (proposer/builder separation).
• Each validator must provide proof of possession or another in-protocol requirement to validate a specific section of the sharded data in each block.
• It’s worth noting that the remaining work is entirely consensus-layer tweaks that don’t need any more effort from the execution client teams, users, or rollup developers.

Conclusion

The EVM is undergoing a variety of changes as we approach closer to the Merge. Some of these modifications will help Ethereum scale, allowing it to process more transactions and give higher scalability. Proto-danksharding is one of them.

If you want to know all that is about cryptocurrency trading, then you are at the right spot. Blockchain Council offers some of the best cryptocurrency courses with certification. These courses are extensively designed keeping in mind the current industry standards. Also, these courses are budget friendly.