In-depth Interpretation of EIP-4844: How to Reduce Layer 2 Fees by 100 Times?
What ideas and solutions does EIP-4844 use to address the GAS issue?Original Author: Chuan Lin
Original Source: A&T Capital
01. Introduction
Vitalik released an updated Ethereum roadmap on November 5, 2022. Compared to the previous roadmap published on December 2, 2021, the upcoming Surge phase updates are undoubtedly the most noteworthy.
As shown in the figure below, this phase's updates clearly add more details ------ we can see that to achieve "basic Rollup scalability," the Ethereum community proposed EIP-4844: Proto-Danksharding. This proposal is set to be implemented from May to early June 2023, at which point Rollup costs will be reduced by 100 times, significantly optimizing the user experience of Ethereum L2. Such a substantial optimization is bound to become the focus of discussion and attention in the Web3 community.
What were the issues related to Ethereum? How does EIP-4844 address these issues? This article will help you understand EIP-4844 concisely.
If you want to keep up with the underlying architecture updates of Ethereum and stay updated with community discussions, don't miss this article!
02. Main Text
1. Origin of EIP-4844: L2 Cost Bottleneck Caused by Data Availability
1.1 Current Basic Situation of L2 and L1 Data Interaction
Currently, most Ethereum L2s are based on Rollup as the fundamental technical route. Vitalik has described Ethereum's updates as "A Rollup-Centric Roadmap," indicating that Rollup has essentially unified the L2 landscape.
The basic principle of Rollup operation is to execute a bundle of transactions off the Ethereum main chain, and after execution, return the execution results and transaction data itself back to L1 after compression, so that others can verify the correctness of the transaction results. Clearly, if others cannot read the data, they cannot complete the verification. Therefore, it is crucial to allow others to access the original transaction data, which is referred to as "Data Availability."
However, due to the current architecture of Ethereum, the data transmitted from L2 to L1 is stored in the transaction's Calldata. However, Calldata was initially designed as a parameter for smart contract function calls, which is data that all nodes must synchronize and download. If Calldata expands, it will cause a high load on Ethereum network nodes, making Calldata costs relatively expensive. This is also a major factor contributing to the current L2 costs.
1.2 Improvement Ideas for the Problem
Readers might consider, if you were to design an optimization plan for this issue, which direction would you take for improvement?
In fact, we can observe that the upload of compressed transaction data from L2 is merely to allow it to be downloaded and verified by others, and does not need to be executed by L1. The reason Calldata costs are high is that it is a parameter for a function call, which is assumed to potentially be executed by L1, thus requiring synchronization across all nodes.
This creates a mismatch: for example, it's like I only want to upload data to a cloud drive for others in need to download within a certain time; instead, you broadcast my data to the entire network, forcing everyone to complete the download within a limited time, and then charge me a high fee for this service. This is clearly inappropriate and needs improvement.
So how can we improve it? We can design a separate data type for the data transmitted from L2, separating it from L1's Calldata. This data type only needs to be accessible for a certain period by those in need, without requiring full network synchronization. In fact, many members of the Ethereum technical community have thought of this point.
The improvements of EIP-4844 are essentially centered around this idea.
2. Core of EIP-4844: Transactions with Blobs
If we were to summarize what EIP-4844 does in one sentence, it would be: it introduces a new transaction type called "Blob-carrying Transactions." A Blob is the data type specifically designed for L2 data transmission mentioned earlier.
Therefore, understanding the details related to blobs essentially means you have a basic grasp of EIP-4844.
2.1 The Essence of Blob: A "Large Data Block" for Storing L2 Compressed Data, Existing in Consensus Layer Nodes
The term Blob is actually short for Binary Large Object, literally translating to "binary large data block." It is designed to carry the original compressed transaction data from L2, equivalent to placing the previous L2 data into Calldata, now placed into a Blob. Compared to Calldata, the size of Blob data can be very large, up to 125 KB.
Blobs are stored by consensus layer nodes, rather than being directly placed on the main chain like Calldata, which brings two core characteristics of Blobs:
They cannot be read by the EVM like Calldata.
They have a lifecycle and will be deleted after 30 days.
To be more specific, a Blob itself is a vector composed of 4096 elements. Each dimension of this vector can be a very large number, ranging from 0 to 52435875175126190479447740508185965837690552500527637822603658699938581184513 ------ this very large number is a prime number related to elliptic curve cryptography algorithms.
The number in each dimension of this vector can be seen as the coefficients of a finite field polynomial of degree no higher than 4096. For example, the number in the i-th dimension is the coefficient in front of w^i, where w is a constant satisfying w^4096 = 1. This structural design is intended to facilitate the generation of KZG polynomial commitments.
2.2 Architectural Design Related to Blob: Sidecar
Before understanding the Blob architecture, we need to clarify a concept: Execution Payload. After the Ethereum merge, it split into the Consensus Layer and Execution Layer, each responsible for two main functions: the former handles PoS consensus, while the latter executes EVM. The Execution Payload can be simply understood as ordinary L1 transactions within the EL layer.
The integration of Blobs into the current Ethereum architecture can be likened to the relationship between a motorcycle and its sidecar, like this: (the left side is the motorcycle's sidecar)
The Sidecar is an official metaphor. Its meaning is that while the operation of Blobs relies on the main chain, it also runs parallel to the main chain to some extent, possessing considerable independence.
As shown in the figure below, let's go through the execution process related to Blobs to better understand this metaphor:
First, the L2 Sequencer determines the transaction, sending the transaction results and related proofs (yellow part) and data packets (Blob, blue part) to the L1 transaction pool.
The L1 nodes (Beacon Proposer) see the transaction and will execute the related transaction in the new block proposal (Beacon Block) and broadcast it; however, when broadcasting, they will separate the Blob and leave it in the consensus layer CL, not placing it in the new block of the execution layer.
Other L1 nodes (Beacon Peer) will receive the new block proposal and transaction results. If they need to become L2 validators, they can download the relevant data from the Blob's Sidecar.
The following diagram explains the Blob lifecycle from another perspective, clearly showing that blob data will not go onto the L1 main chain but will only exist within consensus layer nodes, and it has a different lifecycle.
Therefore, it is not difficult to understand why Blobs cannot be directly read by the EVM, i.e., L1 smart contracts: what can be read are things transmitted to the execution layer, and since Blobs only remain in the consensus layer, they certainly do not have this capability. In fact, this separation is precisely why Rollup costs can be reduced.
2.3 Storage of Blobs: New Fee Market
As mentioned earlier, Blob data will exist within consensus layer nodes and have a lifecycle. However, this service is not free, so it will create a new fee market independent of L1 gas fees, which is also what Vitalik advocates as a Multi-dimensional Fee Market. The details of this Fee Market are still being iterated and improved, as discussed and updated on GitHub: https://github.com/ethereum/EIPs/pull/5707
Additionally, if nodes can only store this data temporarily, how can long-term storage be achieved? In response, Vitalik stated that there are actually many solutions. Because the security assumptions here are not high, it is a "1 of N trust model," requiring only someone to complete the actual data storage. With large storage hardware costing only $20 per TB nowadays, storing 2.5 TB of data annually is just a small issue for those interested. Moreover, various decentralized storage solutions could also be an option, although 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, marking the first time Ethereum has built a separate data layer for L2, and it is the first step towards the implementation 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 towards a Multi-dimensional Market.
At the user experience level, the most intuitive perception for users is the significant reduction in L2 costs. This important underlying improvement will provide a crucial foundation for the explosion of L2 and its application layers.
4. Outlook After EIP-4844: Fully Danksharding
Currently, EIP-4844 has been clearly included in the Ethereum Shanghai upgrade series, and according to the timeline provided by community members, it is expected to be completed between May and early June next year.
EIP-4844 is just "Proto-Danksharding," meaning it is a prototype of Danksharding. The complete vision of Danksharding is illustrated in the figure below, where each node can directly verify the correctness of L2 data in real-time through Data Availability Sampling. This will further enhance the security and performance of L2.
