Original Author: Chuan Lin

first level title

01. Introduction

Vitalik released an updated Ethereum roadmap on November 5, 2022. Compared with the previous roadmap released on December 2, 2021, the upcoming update of The Surge phase is undoubtedly the most noteworthy.

As shown in the figure below, the update at this stage obviously adds more details - we can clearly see that in order to achieve "basic Rollup expansion", the Ethereum community proposed EIP-4844: Proto-Danksharding. This proposal will be implemented from May to early June 2023, at which time the cost of Rollup will be reduced by 100 times, which will greatly optimize the user experience of Ethereum L2. Such a large optimization is bound to become the focus of discussion and attention in the Web3 community.

Where is the problem related to Ethereum? What ideas and solutions does EIP-4844 use to solve this problem? This article will help you understand EIP-4844 concisely.

first level title

02. Text

1. Origin of EIP-4844: L2 fee bottleneck caused by data availability

1.1 The current basic situation of data interaction between L2 and L1

At present, most Ethereum L2 uses Rollup as the basic technical route. Vitalik even describes the update of Ethereum with "A Rollup-Centric Roadmap", which shows that Rollup has basically dominated the L2 arena.

The basic principle of Rollup operation is to execute a bundle of transactions outside the Ethereum main chain. After the execution, the execution results and transaction data themselves are compressed and sent back to L1, so that others can verify the correctness of the transaction results.Obviously, if no one else has a way to read the data, then verification cannot be done. So it is very important to make the raw transaction data available to others. It is also called "Data Availability".

However, limited by the current architecture of Ethereum, the data transmitted from L2 to L1 is stored in the Calldata of the transaction.However, Calldata was only a parameter of a smart contract function call when Ethereum was originally designed, and it is the data that all nodes must download synchronously. If Calldata expands, it will cause a high load on the Ethereum network nodes, so the cost of Calldata is relatively expensive. This is also the main factor contributing to the current L2 fee.

1.2 Improvement ideas for the problem

Readers may wish to think about it, if you were asked to design an optimization plan for this problem, in which direction would you make improvements?

In fact, we can observe that the uploading of L2’s transaction compressed data is just to allow it to be downloaded and verified by others, and does not need to be executed by L1. The reason why the Calldata cost is high is that as a parameter of a function call, it may be executed by L1 by default, so it needs to be synchronized by nodes in the entire network.

This creates a mismatch: for example, I just want to transfer the data to a network disk, so that other people who need it can download it for a period of time; in the end, you made my data A network-wide broadcast synchronization that I don't need, forcing everyone to complete the download within a limited time, and then in turn charge me a high fee for this service. This is obviously inappropriate and needs improvement.

So how to improve?We can design a separate data type for the data passed from L2, and separate it from the Calldata of L1. This type of data only needs to be able to be accessed and downloaded by other people who need it within a certain period of time, and there is no need to synchronize the entire network.In fact, this point has also been thought of by many members of the Ethereum technical community.

The improvement of EIP-4844 is actually carried out around this context.

2. The core of EIP-4844: transactions with blobs

If you use one sentence to summarize what EIP-4844 does, it is: introduce"Transactions with blobs"This new transaction type. Blob is a data type specially designed for L2 data transmission mentioned above.

Therefore, if you understand the details about the blob clearly, you can say that you basically understand EIP-4844.

2.1 Blob ontology: a "big data block" used to place L2 compressed data, stored in the nodes of the consensus layer

The name Blob is actually the abbreviation of Binary Large Object, literally translated as "binary large data block". It was designed to carry the compressed data of L2's original transactions, which is equivalent to putting the data of L2 into Calldata before, and now putting it into Blob. Compared to Calldata, the data size of Blob can be very large, up to 125 KB.

Blobs are stored by the nodes of the consensus layer, rather than being directly uploaded to the main chain like Calldata, which also brings two core features of Blobs:

• Cannot be read by EVM like Calldata

• Has a lifetime and will be deleted after 30 days

In more detail, the Blob itself is a vector (Vector) consisting of 4096 elements. Each dimension of this vector is a very large number, with a range range from 0 to 52435875175126190477474050818596525252527637826036999938584513 -this very large number is a quality number, it is oval and oval. Curve -algorithm algorithm related.

And the number of each dimension of this vector can be regarded as each coefficient of a finite field polynomial not higher than 4096 order. For example, the number of the i-th dimension is the coefficient in front of w^i, where w is a constant and satisfies w^4096 = 1. This structure is designed to facilitate the generation of KZG polynomial commitments.

2.2 Architecture design related to Blob: Sidecar

Before understanding the Blob architecture, a concept needs to be explained: Execution Payload. After the merger of Ethereum, the Consensys Layer and Execution Layer were separated, which are responsible for two main functions: the former is responsible for PoS consensus, and the latter executes EVM. The Execution Payload can be simply considered as an ordinary L1 transaction in the EL layer.

The integration of Blob and the current Ethereum architecture can be compared to the relationship between the motorcycle body and the motorcycle sidecar (Sidecar), like this: (the one on the left is the sidecar of the motorcycle)

Sidecar (motorcycle sidecar) is an official metaphor. Its meaning is actually that although the operation of Blob depends on the main chain, it is also parallel to the main chain to some extent and has considerable independence.

As shown in the figure below, let us go through the execution process related to Blob to better understand this metaphor:

• First, the L2 Sequencer determines the transaction, and transmits the result of the transaction and related proofs (yellow part) and data packets (Blob, blue part) to the transaction pool of L1

• The L1 node (Beacon Proposer) sees the transaction, it will execute the relevant transaction in the new block proposal (Beacon Block) and broadcast it; but when broadcasting, it will separate the Blob and leave it in the consensus layer CL, does not put it into a new block in the execution layer

• Other L1 nodes (Beacon Peer) will receive new block proposals and transaction results. If they need to become L2 validators, they can go to Blobs Sidecar to download relevant data.

The figure below is an illustration of the Blob life cycle from another perspective. We can clearly see that the blob data will not be uploaded to the L1 main chain, but will only exist in the consensus layer nodes, and it has a different life cycle.

therefore,It is not difficult to understand why the Blob cannot be directly read by the EVM, that is, the L1 smart contract: what can be read is what is passed to the execution layer. Since the Blob only stays in the consensus layer, there must be no such function now.In fact, this separation is why Rollup costs can be reduced.

2.3 Blob Storage: New Fee Market

As mentioned earlier, Blob data will be stored in consensus layer nodes and have a life cycle. But obviously this service is not free, so it will bring a new fee market independent of the L1 Gas fee, which is also the Multi-dimensional Fee Market advocated by Vitalik. The relevant details of this Fee Market are still being improved iteratively. For details, please refer to the relevant discussions and updates on Github: https://github.com/ethereum/EIPs/pull/5707

In addition, if the node level can only store these data for a short time, how to achieve long-term storage? In this regard, Vitalik said that there are actually many solutions. Because the security assumption here is not very demanding, it is a "1 of N trust model", as long as someone can complete the storage of real data. At a time when large storage hardware only costs $20 per TB, 2.5 TB of data storage per year is a small problem for those who want to. In addition, various other decentralized storage solutions will also be an option, but Vitalik did not mention specific projects here.

3. Impact of EIP-4844

At the architectural level, EIP-4844 introduces a new transaction type, Blob-carrying Transaction, which is the first time that Ethereum has built a separate data layer for L2, and it is also the first step in the realization of Full Danksharding.

At the economic model level, EIP-4844 will introduce a new Fee Market for blobs, which will also be the first step for Ethereum to move towards a Multi-dimensional Market.

At the user experience level, the most intuitive perception of users is the substantial reduction of L2 fees. This important improvement at the bottom layer will provide an important foundation for the explosion of L2 and its application layer.

4. Outlook after EIP-4844: Fully Danksharding

at present,EIP-4844 has been clearly included in the Ethereum Shanghai upgrade series. According to the timetable given by current community members, it is expected to be completed from May to early June next year.

And EIP-4844 is just "Proto-Danksharding", meaning the prototype of Danksharding. The idea of ​​the full version of Danksharing is shown in the figure below. Each node can directly verify the correctness of L2 data through Data Availability Sampling. This will further improve the security and performance of L2.