jakiro
Ethereum network upgrade Dencun test network version was launched on the Goerli test network on January 17, 2024, and successfully launched the Sepolia test network on January 30. The Dencun upgrade is getting closer and closer to us.
After another upgrade of the Holesky test network on February 7, the main network will be upgraded.Currently, Cancun’s upgraded main network has been officially confirmed on March 13.
Every Ethereum upgrade will almost be accompanied by a wave of theme market. Tracing back to the last Ethereum upgrade was the Shanghai upgrade on April 12, 2023, POS-related projects have been sought after by the market.
If you follow previous experience, this Dencun upgrade will also have the opportunity to make an advance layout.
However, because the technical content involved in the Dencun upgrade is relatively obscure, it cannot be confused with a sentence like Shanghai upgrade, “Ethereum has shifted from PoW to PoS” and it is difficult to grasp the key points of the layout.
Therefore, this article will use easy-to-understand language to explain the technical details of the Dencun upgrade, and sort out the context between this upgrade and the data availability DA and Layer 2 for readers.
EIP 4484
EIP-4844 is the most important proposal in this Dencun upgrade, marking a tangible and important step forward in Ethereum’s expansion in a decentralized way.
In layman’s terms, at present, Ethereum layer 2 needs to submit transactions occurring in layer 2 to the calldata of the Ethereum main network for nodes to verify the effectiveness of the block production of the layer 2 network.
The problem brought about by doing this is that although the transaction data has been compressed as much as possible, the huge transaction volume of the second layer is multiplied by the high storage cost base of the Ethereum main network, which is still the same for the second layer node and second layer users.Not small expenses.The price factor alone will cause the second layer to lose a large number of users and flow to the side chain.
EIP 4484 creates a cheaper new storage area BLOB (Binary Large Object) and replaces the upgraded new transaction type called “BLOB-Carrying Transaction” that can point to the BLOB storage space.The transaction data of calldata is required to help the second layer of the Ethereum ecosystem save Gas costs.
Reasons for cheap BLOB storage
As we all know, cheaper comes at a price. The reason why BLOB data is cheaper than ordinary Ethereum Calldata of similar size is that the Ethereum execution layer (EL, EVM) actually cannot access the BLOB data itself.
On the contrary, EL can only access references to BLOB data, and the data of BLOB itself can only be downloaded and stored by Ethereum’s consensus layer (CL, also known as beacon node), and the memory and calculation amount consumed to be stored is much smaller than that of ordinary Ethereum.Calldata .
Moreover, BLOB has a feature that can only be stored for a limited period of time (usually about 18 days) and will not expand infinitely like the size of the Ethereum ledger.
The storage validity period of BLOB
In contrast to the permanent ledger of blockchain, BLOB is temporary storage with a time of 4096 epochs, or about 18 days.
After expiration, most consensus clients will not be able to retrieve specific data in the BLOB.However, the evidence of its preexisting existence will remain on the mainnet in the form of KZG promises and will be permanently stored on the Ethereum mainnet.
Why choose 18 days?This is a tradeoff between measuring storage costs and effectiveness.
First of all, we need to consider the most intuitive beneficiaries of this upgrade, Optimistic Rollups (such as Arbitrum and Optimism,), because according to the settings of Optimistic Rollups, there is a 7-day time window for Fruad Proof.
The transaction data stored in the blob is exactly the information needed when Optimistic Rollups launches a challenge.
Therefore, the validity period of the Blob must be ensured that the Optimistic Rollups fault proof can be accessed. For simplicity, the Ethereum community chose the power of 2 (4096 epochs are derived from 2^12, and one epoch is about 6.4 minutes).
BLOB-Carrying Transaction and BLOB
Understanding the relationship between these two is important in understanding the role of BLOB in data availability (DA).
The former is the whole of the EIP-4484 proposal, a new type of transaction, while the latter can be understood as a location for temporary storage of transactions for layer 2.
The relationship between the two can be understood as that most of the data in the former (layer2 transaction data) is stored in the latter.The remaining data, BLOB data, will be in the calldata of the main network.That is, the promise can be read by the EVM.
You can imagine a Commitment as building all transactions in a BLOB into a Merkle tree, and then only the Merkle root, the Commitment, can be accessed by the contract.
This can be done cleverly: Although EVM cannot know the specific content of BLOB, EVM contracts can verify the authenticity of transaction data by knowing the Commitment.
The relationship between BLOB and Layer2
Rollup technology enables data availability (DA) by uploading data to the Ethereum mainnet, but this is not to allow L1’s smart contracts to read or verify these uploaded data directly.
The purpose of uploading transaction data to L1 is simply to allow all participants to view this data.
Before the Dencun upgrade, as mentioned above, Op-rollup publishes transaction data to Ethereum as Calldata.So anyone can use these transaction information to reproduce the state and verify the correctness of the layer 2 network.
It is not difficult to see that Rollup transaction data needs to be cheap + open and transparent. Calldata is not a good place for the second floor to store transaction data, 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 does not seem important, what is its use?
In fact, transaction data is only used in a few situations:
-
For Optimistic Rollup, based on the trust assumption, there may be dishonesty problems. Only then can the transaction records uploaded by Rollup come in handy, and users can use this data to initiate transaction challenges (Fraud proof);
-
For ZK Rollup, zero-knowledge proof has proved that the status update is correct. Uploading data is just to allow the user to calculate the complete state by himself. Escape Hatch is enabled when the second-layer node cannot operate correctly (Escape Hatch is required, a complete L2 state tree is required.This will be discussed in the last section).
This means that the actual use of transaction data by contracts is very limited.Even in Optimistic Rollup’s trading challenge, you only need to submit evidence (status) that proves that the transaction data “existence” is on the spot, and the details of that transaction are not required to be stored on the main network in advance.
So if we put transaction data in the BLOB element, although the contract cannot be accessed, the main network 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 of the transaction, as long as it can correspond to it.This can convince the contract and provide transaction data to the challenge mechanism for use.
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 recording only Commitments, the transaction data 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 Dencun’s actual operation, the Commitment is not generated in a Merkle tree similar to Celestia, but the clever KZG (Kate-Zaverucha-Goldberg, polynomial commitment) algorithm is used.
Compared with Merkle tree proof, the process of generating the KZG Proof is relatively complex, but its verification volume is smaller and the verification steps are simpler. However, the disadvantage is that it requires trusted settings (ceremony.ethereum.org is now over) and does not haveAnti-quantum computing attack capability (Dencun uses Version Hash method, and other verification methods can be replaced if necessary).
For the popular DA project Celestia, it uses the Merkle tree variant. Compared with KZG, it depends on the integrity of nodes to a certain extent, but it helps to lower the threshold requirements for computing resources between nodes and maintain the network.Decentralized features.
Dencun’s Opportunity
While Eip4844 reduces costs and increases efficiency for the second layer, it also raises safety risks, which also brings new opportunities.
To understand the reasons, we need to talk about the escape capsule mechanism or the mandatory withdrawal mechanism mentioned above.
When the Layer 2 node is disabled, this mechanism can ensure that the user funds return to the main network safely.The prerequisite for activate this mechanism is that the user needs to obtain the complete state tree of Layer 2.
According to normal circumstances, users only need to find a full Layer2 node to request data, generate a merkle proof, and submit the contract to the main network to prove the legitimacy of their withdrawals.
But don’t forget that the user wants to start the escape capsule mechanism to exit L2 precisely because the L2 node does evil and the node does 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 mentions.
Before EIP-4844, permanent Layer2 records were recorded on the main network. When no Layer2 node can provide a complete off-chain state, the user can deploy a full node by himself.
This full node can obtain all the historical data published by the Layer 2 sorter on the main network with the Ethereum main network. Users can construct the required Merkle proof and submit the proof to the contract on the main network to safely complete the L2 assets.Evacuate.
After EIP-4844, Layer 2 data only exists in the BLOB of the full node of Ethereum, and historical data 18 days ago will be automatically deleted.
Therefore, the method of obtaining the entire state tree through the synchronous 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 store all the Ethereum BLOB data for Ai Generator through a third party (it should have been used to store all the data of Ethereum BLOB for Ai Generator) (it should have been used to obtain the complete state tree of Layer 2).18 days automatically deleted) the mainnet node, or Layer 2 native node (very rarely).
Therefore, after 4844 is launched, it will become very difficult for users to obtain the Layer 2 full status tree in a fully trustworthy manner.
If users do not have a stable way to obtain the Layer 2 status tree, they cannot perform forced withdrawal operations under extreme conditions.Therefore, 4844 has caused Layer 2’s safety shortcomings/loss to a certain extent.
To make up for this security lack, 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 storage track in the past, because the keyword “no trust” still exists.
Ethstorage can solve the problem of no trust 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 the Dencun upgraded track, which is very worthy of attention.
First of all, the most intuitive significance of Ethstorage is that it can extend the available time of DA BLOB in a completely decentralized way, making up for the safety shortest board of Layer 2 after 4844.
In addition, most existing L2 solutions focus primarily on scaling Ethereum’s computing power, i.e., 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 for on-chain NFTs are very obvious because users not only own tokens for NFT contracts, but also on-chain images.Ethstorage can solve the additional trust issue that storing these images on third parties.
Finally, Ethstorage can also solve the front-end needs of decentralized dApps.The current 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, tornado cash, etc., as evidenced by events such as incidents such as DNS hijacking, incidents such as website hacking or server crashes, tornado cash, etc..
Ethstorage is still in the early stage of testing, so users who are optimistic about the prospects of this track can experience it.
