EIP4844: An intermediate solution before Ethereum data sharding

In the future, Ethereum will first go through a merger, then the Shanghai hard fork, and then the future shard chain. These are the processes that Ethereum will go through in terms of data availability.

EIP-4844 is a key update in this long process. The proposal is currently in draft form and may be revised.

The technical requirements of EIP-4844 belong to proto-danksharding, which is a method to expand data availability. The main technical change is the introduction of a new transaction type to Ethereum, where beacon nodes accept blob data and can verify blobs.

Sharding in Ethereum is the process of breaking data into two or more smaller chunks. These chunks are then distributed across separate database nodes, known as physical shards.

The sharding strategy currently adopted by Ethereum is a "aggregation-centric" approach. Under this idea, the processing of off-chain data is included, so this idea certainly requires the entire infrastructure to utilize the scalability of Layer 2.

However, the goal of Rollups is long-term. Currently, the main idea that can be achieved is to compress the transaction size. Within a limited block size, more transactions can be compressed to reduce transaction gas costs.

In the long-term goal of data sharding, there is another thing that cannot be ignored, that is, the size of the data availability space of each block after data sharding. Data sharding will increase the dedicated data space of about 16MB per block for the chain using rollups. Once this goal is achieved, the data under the chain or layer2 can be well coordinated with rollups, improving the data transaction processing capabilities.

But before the long data sharding comes, EIP4844 has made an intermediate plan, which can expand the data availability space of each block of the beacon chain to a maximum of 2MB. That is, adding a part of Blob data to the block of the beacon chain may reach the data storage limit, but in theory, the limit of 1 MB per block plus an additional 300 bytes per transaction is a maximum of 1.4 MB. But using gas calculation, it should be 1.8M. So there will be a specification with a target of 1MB and an upper limit of 2MB.

Data in the form of a transaction blob becomes part of the beacon chain and is fully downloaded by all consensus nodes (but can be deleted after a relatively short delay).

It is important to note here that node validation of blobs is to check whether the blob is available, i.e., whether it can be downloaded from the network. The data space in these blobs is expected to be used by layer 2 protocols that support high throughput operations.

In addition, according to the EIP details, this data does not occupy the block header, but enters the block body. So this option is not to create additional space, but to allocate more space for data blocks. Because adding blobs to blocks is not for access, but to represent whether the data exists and can be accessed from the network L2 infrastructure (such as Arbitrum, Optimism, etc.).

The blob will be kept on the beacon chain for a period of time to ensure some transaction needs.

With such a blob of data usage, a 128kb block would ideally cost 1 gas, which is 0.01 cents at today’s gas prices and Ether prices.

In addition, it may be necessary to recognize some differences between EIP-4488 and proto-danksharding. EIP-4488 attempts to minimize the changes required currently, while proto-danksharding requires a lot of changes. After this process, few changes are required to upgrade to full sharding in the future. Implementing full sharding (including data availability sampling, etc.) is a complex task, and this complexity is contained in the consensus layer. Once proto-danksharding is launched, the execution layer client team, rollup developers, and users can complete the transition to full sharding without further work.

The Ethereum Foundation believes that this provides a substantial scaling solution for the Ethereum network until the final sharding upgrade is completed.