The Dencun testnet version of the Ethereum network upgrade was launched on the Goerli testnet on January 17, 2024, and was successfully launched on the Sepolia testnet on January 30. The Dencun upgrade is getting closer and closer to us.
After the Holesky testnet upgrade on February 7, the mainnet will be upgraded. The Cancun upgrade mainnet launch has been officially confirmed on March 13.
Almost every Ethereum upgrade is accompanied by a wave of thematic market conditions. The last time Ethereum was upgraded was in Shanghai on April 12, 2023. POS-related projects have been sought after by the market.
If previous experience is followed, there will also be opportunities to plan ahead for this Dencun upgrade.
However, since the technical content behind the Dencun upgrade is relatively obscure, it cannot be summed up in one sentence like the Shanghai upgrade, "Ethereum switches from PoW to PoS", and it is difficult to grasp the key points of the layout.
Therefore, this article will explain the technical details of the Dencun upgrade in plain language, and sort out the connection between this upgrade and tracks such as data availability DA and Layer 2 for readers. EIP-4844 is the most important proposal in this Dencun upgrade, marking a practical and important step for Ethereum on the road to expansion in a decentralized manner.
In layman's terms, Ethereum Layer 2 currently needs to submit transactions occurring on the Layer 2 to the calldata of the Ethereum mainnet so that nodes can verify the validity of blocks produced by the Layer 2 network.
The problem with this is that although transaction data has been compressed as much as possible, the huge transaction volume of the second layer multiplied by the high storage cost base of the Ethereum main network is still a considerable expense for the second layer nodes and second layer users. The price factor alone will cause the second layer to lose a large number of users and flow to the side chain.
EIP 4484 establishes a new, cheaper storage area called BLOB (Binary Large Object), and uses 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 second layer to save gas costs.
Why BLOB storage is cheap
As we all know, cheapness comes at a price, and the reason BLOB data costs less than normal Ethereum Calldata of similar size is that the Ethereum Execution Layer (EL, EVM) cannot actually access the BLOB data itself.
In contrast, EL can only access references to BLOB data, and the BLOB data itself can only be downloaded and stored by Ethereum’s consensus layer (CL, also known as beacon nodes), which consumes far less memory and computation than ordinary Ethereum Calldata.
Another feature of BLOB is that it can only be stored for a limited period of time (usually about 18 days) and will not expand indefinitely like the size of the Ethereum ledger.
BLOB storage expiration date
In contrast to the blockchain’s permanent ledger, BLOBs are temporary storage that is available for 4096 epochs, or about 18 days.
After expiration, a majority of consensus clients will not be able to retrieve specific data in the BLOB. However, evidence of its previous existence will remain on the mainnet in the form of KZG commitments and will be permanently stored on the Ethereum mainnet.
Why 18 days? It is a compromise between storage cost and availability.
First, we need to consider the most direct beneficiaries of this upgrade, Optimistic Rollups (such as Arbitrum and Optimism), because according to the settings of Optimistic Rollups, there is a 7-day Fault Proof time window.
The transaction data stored in the blob is exactly what Optimistic Rollups needs when launching a challenge.
Therefore, the validity period of the Blob must ensure that the Optimistic Rollups fault proof is accessible. For simplicity, the Ethereum community chose 2 to the power of 12 (4096 epochs are derived from 2^12, and one epoch is approximately 6.4 minutes).
BLOB-Carrying Transaction 与 BLOB
Understanding the relationship between the two is important to understanding the role of BLOBs in data availability (DA).
The former is the whole of the EIP-4484 proposal and is a new type of transaction, while the latter can be understood as a location for temporary storage transactions on layer 2.
The relationship between the two can be understood as follows: most of the data in the former (layer 2 transaction data) is stored in the latter. The remaining data, that is, the commitment of the BLOB data, will be stored in the calldata of the main network. In other words, the commitment can be read by the EVM.
You can think of Commitment as building a Merkle tree of all transactions in the BLOB, and then only the Merkle root, which is the Commitment, can be accessed by the contract.
Doing so can cleverly achieve the following purpose: although EVM cannot know the specific content of BLOB, the EVM contract can verify the authenticity of transaction data by knowing Commitment.
Relationship between BLOB and Layer 2
Rollup technology achieves data availability (DA) by uploading data to the Ethereum mainnet, but this is not intended for L1 smart contracts to directly read or verify the uploaded data.
The purpose of uploading transaction data to L1 is simply to make the data available to all participants.
Before the Dencun upgrade, as mentioned above, Op-rollup will publish transaction data as Calldata to Ethereum. So anyone can use this transaction information to reproduce the status and verify the correctness of the second-layer network.
It is not difficult to see that Rollup transaction data needs to be cheap + open and transparent. Calldata is not a good place to store transaction data specifically for the second layer, and BLOB-Carrying Transaction is tailor-made for Rollup.
After reading this, you may have a question in your mind: this kind of transaction data seems unimportant, what is its use?
In fact, transaction data is only used in a few cases:
For Optimistic Rollup, based on the trust assumption, there is a certain possibility of dishonesty issues. At this time, the transaction records uploaded by Rollup come in handy. Users can use this data to initiate transaction challenges (fraud proof);
For ZK Rollup, zero-knowledge proof has proved that the state update is correct. Uploading data is only to allow users to calculate the complete state by themselves and enable the escape hatch mechanism (Escape Hatch, which requires a complete L2 state tree, which will be discussed in the last section) when the second-layer node cannot operate correctly.
This means that the actual use of transaction data by contracts is very limited. Even in the Optimistic Rollup transaction challenge, only evidence (status) proving that the transaction data "existed" needs to be submitted on the spot, without the need for the transaction details to be stored in the main network in advance.
So if we put the transaction data in a BLOB element, although the contract cannot access it, the mainnet contract can store the Commitment of this BLOB.
In the future, if the challenge mechanism needs a certain transaction, we only need to provide the data of that transaction, as long as it matches. This will convince the contract and provide the transaction data to the challenge mechanism.
This not only takes advantage of the openness and transparency of transaction data, but also avoids the huge gas cost of entering all data into the contract in advance.
By only recording Commitment, transaction data verifiability is achieved while costs are greatly optimized. This is a clever and efficient solution for uploading transaction data using Rollup technology.
It should be noted that in the actual operation of Dencun, the Merkle tree method similar to Celestia is not used to generate commitments, but the clever KZG (Kate-Zaverucha-Goldberg, polynomial commitment) algorithm is used.
Compared with the Merkle tree proof, the process of generating KZG Proof is relatively complicated, but its verification volume is smaller and the verification steps are simpler. However, its disadvantage is that it requires a trusted setup (which is now over) and is not resistant to quantum computing attacks (Dencun uses the Version Hash method, and other verification methods can be replaced if necessary).
For the currently popular DA project Celestia, it uses a Merkle tree variant. Compared with KZG, it relies to a certain extent on the integrity of the nodes, but it helps to lower the threshold requirements for computing resources between nodes and maintain the decentralized characteristics of the network.
Opportunities in Dencun
While Eip 4844 reduces costs and increases efficiency for the second layer, it also raises security risks, which also brings new opportunities.
To understand why, we need to go back to the escape hatch or forced withdrawal mechanism mentioned above.
When the Layer 2 node fails, this mechanism can ensure that the user's funds return to the main network safely. The premise for activating this mechanism is that the user needs to obtain the complete state tree of Layer 2.
Under normal circumstances, users only need to find a Layer 2 full node to request data, generate a merkle proof, and then submit it to the main network contract to prove the legitimacy of their withdrawal.
But don’t forget that the user wants to activate the escape hatch mechanism to exit L2 precisely because the L2 node is doing evil. If all nodes are doing evil, then there is a high probability that the desired data will not be obtained from the node.
This is the data withholding attack that Vitalik often refers to.
Before EIP-4844, permanent Layer 2 records were recorded on the mainnet, and when there was no Layer 2 node to provide complete off-chain status, users could deploy a full node themselves.
This full node can obtain all historical data published by the Layer 2 sorter on the main network through the Ethereum main network. Users can then construct the required Merkle proof and submit the proof to the contract on the main network to safely complete the L2 asset withdrawal.
After EIP-4844, Layer 2 data only exists in the BLOB of the Ethereum full node, and historical data before 18 days will be automatically deleted.
Therefore, the method of obtaining the entire state tree by synchronizing the main network in the previous paragraph is no longer feasible. If you want to obtain the complete state tree of Layer 2, you can only use the main network node of a third party that stores all the data of the Ethereum BLOB (which should be automatically deleted after 18 days) or the Layer 2 native node (very rare).
Therefore, after 4844 goes online, it will become very difficult for users to obtain the complete state tree of Layer 2 in a completely trusted way.
Without a stable way to obtain the Layer 2 state tree, users cannot perform forced withdrawals under extreme conditions. Therefore, 4844 has caused security shortcomings/deficiencies in Layer 2 to a certain extent.
To make up for this security gap, we need to have a trustless storage solution with a positive economic cycle. Storage here mainly refers to retaining data in Ethereum in a trustless way, which is different from the past storage track because there is still the keyword "trustless".
Ethstorage can solve the trustless problem and has received two rounds of funding from the Ethereum Foundation.
It can be said that this concept can truly cater to/make up for Dencun's upgraded track and is well worth paying attention to.
First of all, the most intuitive significance of Ethstorage is that it can extend the availability of DA BLOB in a completely decentralized manner, making up for the shortest security issue of Layer 2 after 4844.
In addition, most existing L2 solutions focus mainly on expanding Ethereum's computing power, that is, increasing TPS. However, the demand for securely storing large amounts of data on the Ethereum mainnet has surged, especially due to the popularity of dApps such as NFT and DeFi.
For example, the storage requirements of on-chain NFTs are very obvious, because users not only own the tokens of the NFT contract, but also the on-chain images. Ethstorage can solve the additional trust issues that come with storing these images in a third party.
Finally, Ethstorage can also solve the need for decentralized dApp front-ends. Existing solutions are mainly hosted by centralized servers (with DNS), which makes the website vulnerable to censorship and other issues such as DNS hijacking, website hacking or server crashes, as evidenced by events such as Tornado Cash.
