Author: Biteye, Core Contributor: Fishery Isla
The Ethereum network upgrade Dencun testnet version went live on the Goerli testnet on January 17, 2024, and successfully launched on the Sepolia testnet on January 30. The Dencun upgrade is getting closer to us.
After the Holesky testnet upgrade on February 7, the mainnet upgrade will follow. It has been officially confirmed that the Dencun upgrade mainnet will go live on March 13.
Almost every Ethereum upgrade is accompanied by a wave of market trends. Looking back at Ethereum's last upgrade on April 12, 2023, POS-related projects were sought after by the market.
Based on previous experience, there will likely be opportunities for early positioning in this Dencun upgrade.
Due to the technical complexity behind the Dencun upgrade, it is not as straightforward as the Shanghai upgrade, which transitioned Ethereum from PoW to PoS in a single sentence. It is difficult to grasp the key points of positioning.
Therefore, this article will explain the technical details of the Dencun upgrade in simple language, outlining the connection between this upgrade and data availability (DA) and Layer 2.
1. EIP 4484
EIP-4844 is the most important proposal in the Dencun upgrade, marking a significant step for Ethereum in its decentralized scaling efforts.
In simple terms, the current Ethereum Layer 2 needs to submit the transactions occurring in Layer 2 to the calldata of the Ethereum mainnet for nodes to verify the validity of Layer 2 network block production.
The problem with this approach is that, despite compressing the transaction data as much as possible, the large volume of Layer 2 transactions multiplied by the high storage cost base of the Ethereum mainnet still represents a significant expense for Layer 2 nodes and users. Due to the price factor alone, many Layer 2 users may move to side chains.
EIP 4484 establishes a cheaper new storage area called BLOB (Binary Large Object) and introduces a new transaction type called "BLOB-Carrying Transaction" that can point to the BLOB storage space to replace the transaction data that needed to be stored in calldata before the upgrade, helping the Ethereum ecosystem's Layer 2 achieve gas cost savings.
Reasons for the low cost of BLOB storage
It is well known that cheapness comes at a cost. The reason why BLOB data costs less than similar-sized regular Ethereum calldata is that the Ethereum Execution Layer (EL, EVM) cannot actually access the BLOB data itself.
Instead, the EL can only access references to the BLOB data, and the storage and memory consumption of the BLOB itself by the Ethereum consensus layer (CL, also known as beacon nodes) is far less than that of regular Ethereum calldata.
Additionally, BLOB has a unique feature in that it can only store data for a limited period (usually about 18 days) and will not expand indefinitely like the Ethereum ledger size.
BLOB storage expiration
Unlike the permanent ledger of the blockchain, BLOB is temporary storage with a lifespan of 4096 epochs, approximately 18 days.
After expiration, most consensus clients will be unable to retrieve specific data from the BLOB. However, evidence of its previous existence will be retained in the form of KZG commitments on the mainnet and permanently stored on the Ethereum mainnet.
Why choose 18 days? This is a compromise between storage cost and effectiveness.
First and foremost, the most immediate beneficiaries of this upgrade are Optimistic Rollups (such as Arbitrum and Optimism) because, according to the settings of Optimistic Rollups, there is a 7-day window for fraud proof.
The transaction data stored in the BLOB is precisely the information needed when initiating a challenge in Optimistic Rollups.
Therefore, the expiration period of BLOB must ensure that the fraud proof of Optimistic Rollups can be accessed. For simplicity, the Ethereum community chose a power of 2 to the 12th (4096 epochs derived from 2^12, approximately 6.4 minutes per epoch).
Relationship between BLOB-Carrying Transaction and BLOB
Understanding the relationship between these two is crucial for understanding the role of BLOB in data availability (DA).
The former is the overall proposal of EIP-4484, a new type of transaction, while the latter can be understood as a temporary storage location for layer 2 transactions.
The relationship between the two can be understood as follows: most of the data (layer 2 transaction data) in the former is stored in the latter. The remaining data, which is the commitment of the BLOB data, will exist in the calldata of the mainnet. In other words, the commitment can be read by the EVM.
The commitment can be imagined as constructing a Merkle tree from all the transactions in the BLOB, and only the Merkle root, i.e., the commitment, can be accessed by the contract.
This cleverly achieves the purpose of allowing EVM contracts to verify the authenticity of transaction data, even though the EVM cannot know the specific content of the BLOB.
2. Relationship between BLOB and Layer 2
Rollup technology achieves data availability (DA) by uploading data to the Ethereum mainnet, but not for the purpose of allowing L1 smart contracts to directly read or verify this uploaded data.
The purpose of uploading transaction data to L1 is solely to allow all participants to view this data.
As mentioned earlier, before the Dencun upgrade, Op-rollup would publish transaction data as Calldata to Ethereum. Therefore, anyone could use this transaction information to reproduce the state and verify the correctness of the Layer 2 network.
It is clear that Rollup transaction data needs to be cheap and publicly transparent. Calldata is not a good place to specifically store transaction data for Layer 2, and the BLOB-Carrying Transaction is tailored for Rollup.
At this point, you may wonder, what is the use of this transaction data?
In fact, transaction data is only used in a few scenarios:
For Optimistic Rollup, based on the trust assumption, there is a possibility of dishonesty. In this case, the transaction records uploaded by Rollup become useful, and users can use this data to initiate transaction challenges (fraud proof);
For ZK Rollup, zero-knowledge proofs have already proven that the state update is correct, and the uploaded data is only used for users to calculate the complete state and activate the escape hatch mechanism when the Layer 2 node fails to operate correctly (the last section will cover this).
This means that the scenarios in which the contract actually uses transaction data are very limited. Even in the transaction challenge of Optimistic Rollup, only evidence that the transaction data "existed" needs to be submitted on the spot, rather than having the details of that transaction data stored on the mainnet in advance.
Therefore, if we place the transaction data in the BLOB, although the contract cannot access it, the mainnet contract can store the commitment of this BLOB.
In the future, if the challenge mechanism requires a certain transaction, we only need to provide the data for that transaction, as long as it corresponds. This can convince the contract and provide the transaction data for the challenge mechanism.
This approach utilizes the transparency of transaction data and avoids the huge gas cost of pre-recording all data into the contract.
By only recording the Commitment, the transaction data's verifiability is achieved while greatly optimizing costs. This is a clever and efficient solution for Rollup technology to upload transaction data.
It should be noted that in the actual operation of Dencun, a clever KZG (Kate-Zaverucha-Goldberg, polynomial commitment) algorithm is used to generate Commitment, rather than a Merkle tree similar to Celestia.
Compared to Merkle tree proofs, the generation process of KZG Proof is relatively complex, but its verification volume is smaller, and the verification steps are simpler. However, the drawback is that it requires a trusted setup (ceremony.ethereum.org has now ended) and does not have resistance to quantum computing attacks (Dencun uses the Version Hash method, and other verification methods can be replaced if necessary).
For the popular DA project Celestia, it uses a variant of the Merkle tree, which, compared to KZG, relies to some extent on the honesty of nodes, but helps to lower the threshold of computational resources between nodes, maintaining the decentralized nature of the network.
3. Opportunities for Dencun
While EIP-4844 reduces costs and improves efficiency for Layer 2, it also introduces security risks, which in turn bring new opportunities.
To understand the reasons, we need to discuss the escape hatch mechanism or forced withdrawal mechanism mentioned earlier.
When a Layer 2 node becomes incapacitated, this mechanism ensures the safe return of user funds to the mainnet. The premise for activating this mechanism is that users need to obtain the complete state tree of Layer 2.
Under normal circumstances, users only need to request data from a Layer 2 full node, generate a Merkle Proof, and submit it to the mainnet contract to prove the legitimacy of their withdrawal.
But don't forget that users want to activate the escape hatch mechanism to exit L2 precisely because the L2 node is acting maliciously. If all nodes are acting maliciously, it is highly likely that users will not obtain the data they need from the nodes.
This is what Vitalik often refers to as data withholding attacks.
Before EIP-4844, the mainnet recorded permanent Layer 2 records. When there were no Layer 2 nodes able to provide the complete off-chain state, users could deploy a full node themselves.
This full node could obtain all historical data published by the Layer 2 sequencer on the mainnet by interacting with the Ethereum mainnet, allowing users to construct the required Merkle proof and submit it to the mainnet contract to safely withdraw L2 assets.
After EIP-4844, however, Layer 2 data only exists in the BLOB of Ethereum full nodes, and historical data from before 18 days ago will be automatically deleted.
Therefore, the method of synchronizing the mainnet to obtain the entire state tree as mentioned in the previous paragraph is no longer feasible. To obtain the complete state tree of Layer 2, users can only rely on a mainnet node that has stored all Ethereum BLOB data (which should have been automatically deleted after 18 days) in a trustworthy manner, or Layer 2 native nodes (which are rare).
After the launch of EIP-4844, it will become very difficult for users to obtain the complete state tree of Layer 2 in a completely trustworthy manner.
Without a stable way to obtain the Layer 2 state tree, users cannot perform forced withdrawals under extreme conditions. Therefore, EIP-4844 has to some extent created a security vulnerability/deficiency in Layer 2.
To address this security deficiency, we need a trustless storage solution with a positive economic cycle. Here, storage mainly refers to retaining data in Ethereum in a trustless manner, which is different from the past storage solutions because it includes the keyword "trustless."
Ethstorage can solve the trustless issue and has received funding from two rounds of the Ethereum Foundation.
It can be said that this concept truly caters to/mitigates the track of the Dencun upgrade and is very worthy of attention.
Firstly, Ethstorage's most immediate significance lies in its ability to extend the availability of DA BLOB in a completely decentralized manner, addressing the security vulnerability of Layer 2 after 4844.
In addition, most existing L2 solutions mainly focus on expanding Ethereum's computational capabilities, i.e., increasing TPS. However, there is a significant increase in the demand for secure storage of large amounts of data on the Ethereum mainnet, especially due to the popularity of dApps such as NFTs and DeFi.
For example, the storage demand for on-chain NFTs is very apparent because users not only own tokens from NFT contracts but also own on-chain images. Ethstorage can solve the issue of storing these images in a third-party manner without additional trust issues.
Finally, Ethstorage can also address the needs of the front end of decentralized dApps. Currently, existing solutions are mainly hosted by centralized servers (with DNS), making websites susceptible to censorship and other issues such as DNS hijacking, website hacking attacks, or server crashes, among others.
Ethstorage is still in the early network testing phase, and users who are optimistic about the prospects of this track can experience it.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
