What Is EIP-4844 in Ethereum and How Can It Benefit Users?

Introduction

EIP-4844 (also known as proto-dank sharding) 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.

This new transaction type is being used to reduce the high gas prices that consumers are now paying because it takes time to deploy shards. A small amount of block space has also been added because this is simply a temporary fix; if shard chains are completely implemented, they would contribute about 16 MB of block space.

In order to support high transaction throughput, this idea would create a more effective system for coordinating data logistics. Also, it could be seen as a way to improve data accessibility.

Let’s explore this Ethereum upgrade idea a little more to find out how it helps 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 makes 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.

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 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

1. 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.

2. 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).

3. 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.

4. The increased block size may have an impact on the block size as well as the 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 who 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:

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

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

1. To facilitate 2D sampling, a low-degree extension of the blob _kzgs in the consensus layer was added.
   
2. 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).

3. Each validator must provide proof of possession or another in-protocol requirement to validate a specific section of the sharded data in each block.
   
4. 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

EIP-4844 is a very complex improvement to the Ethereum protocol that is coupled to other system upgrades like proposer/builder separation (PBS) and EIP-1559 blob fee adjustment. It is a component of a wider roadmap.

While knowledge of EIP-4844 will help average customers be better prepared for the changes that are coming, it should be noted that the majority of those changes will take the form of lower prices and quicker transactions.

The Ethereum protocol is always changing and getting better. One of the important near-term updates intended to improve the network’s capabilities is EIP-4844. If EIP-4844 is successfully implemented, Ethereum will be a very competitive global transaction network.