Ethereum Dencun Upgrade and Potential Opportunities

Author: Biteye Core Contributor Fishery IsIa

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 experiencing another upgrade of the Holesky testnet on February 7, the mainnet upgrade will follow, with the Cancun upgrade on the mainnet officially confirmed to launch on March 13. Each Ethereum upgrade is almost always accompanied by a wave of thematic market trends. The last upgrade for Ethereum was the Shanghai upgrade on April 12, 2023, which saw POS-related projects being highly sought after by the market.

Based on previous experiences, this Dencun upgrade will also present opportunities for early positioning.

However, due to the technical content involved in the Dencun upgrade being relatively obscure, it cannot be summarized in a single sentence like the Shanghai upgrade's "Ethereum transitions from PoW to PoS," making it difficult to grasp the key points for positioning.

Therefore, this article will explain the technical details of the Dencun upgrade in simple and understandable language, helping readers clarify the connections between this upgrade and data availability (DA), Layer 2, and other related fields.

1. EIP 4484

EIP-4844 is the most important proposal in this Dencun upgrade, marking a significant and practical step for Ethereum in its path to decentralized scaling.

In simple terms, currently, Ethereum Layer 2 needs to submit transactions occurring on Layer 2 into the calldata of the Ethereum mainnet for nodes to verify the validity of block production on the Layer 2 network.

The problem with this approach is that although transaction data has been compressed as much as possible, the enormous transaction volume of Layer 2 multiplied by the high storage costs of the Ethereum mainnet still represents a significant expense for Layer 2 nodes and users. Just the price factor alone can cause Layer 2 to lose a large number of users to sidechains.

EIP 4484 establishes a cheaper new storage area called BLOB (Binary Large Object) and replaces the transaction data that needed to be stored in calldata before the upgrade with a new transaction type called "BLOB-Carrying Transaction," helping Ethereum's Layer 2 ecosystem save on gas costs. Reasons for the low cost of BLOB storage

It is well known that cheap comes at a cost. The reason BLOB data is cheaper than regular Ethereum calldata of similar size 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, while the data itself can only be downloaded and stored by Ethereum's consensus layer (CL, also known as the beacon node), which consumes far less memory and computational resources than regular Ethereum calldata.

Moreover, BLOBs have a characteristic of being stored for a limited period (usually about 18 days), and will not expand indefinitely like the size of the Ethereum ledger. BLOB's storage validity period

In contrast to the permanent ledger of the blockchain, BLOBs are temporary storage, with a usable time of 4096 epochs, which is approximately 18 days.

After expiration, most consensus clients will be unable to retrieve specific data from the BLOB. However, the evidence of its prior existence will be retained on the mainnet in the form of KZG commitments and will be permanently stored on the Ethereum mainnet.

Why choose 18 days? This is a compromise between storage costs and effectiveness.

First, 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 fraud proof time window.

The transaction data stored in the BLOB is precisely the information needed when Optimistic Rollups initiate a challenge.

Therefore, the validity period of the BLOB must ensure that the fraud proof of Optimistic Rollups can be accessed. For simplicity, the Ethereum community chose 2 raised to the power of 12 (4096 epochs derived from 2^12, with one epoch being approximately 6.4 minutes). BLOB-Carrying Transaction and BLOB

Understanding the relationship between these two is crucial for grasping 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 transaction data.

The relationship can be understood as most of the data in the former (Layer 2 transaction data) being 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.

One can imagine the commitment as constructing a Merkle tree from all transactions in the BLOB, where only the Merkle root, i.e., the commitment, can be accessed by contracts.

This clever approach allows for the EVM to not know the specific contents of the BLOB, but EVM contracts can verify the authenticity of transaction data by knowing the commitment.

2. The relationship between BLOB and Layer 2

Rollup technology achieves data availability (DA) by uploading data to the Ethereum mainnet, but this is not for L1 smart contracts to directly read or verify the uploaded data.

The purpose of uploading transaction data to L1 is merely to allow all participants to view this data.

Before the Dencun upgrade, as mentioned above, Op-rollups 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 for storing transaction data specifically for Layer 2, while BLOB-Carrying Transaction is tailor-made for Rollups.

At this point, you might have a question: this transaction data doesn't seem important; what is its use?

In fact, transaction data is only used in a few situations:

• For Optimistic Rollup, based on trust assumptions, there is a possibility of dishonesty issues, at which point the transaction records uploaded by Rollup come into play, allowing users to initiate transaction challenges (fraud proofs);

• For ZK Rollup, zero-knowledge proofs have already proven that state updates are correct, and uploaded data is merely for users to compute the complete state themselves, enabling the escape hatch mechanism when Layer 2 nodes cannot operate correctly (Escape Hatch, which requires a complete L2 state tree, will be discussed in the last section).

This means that the scenarios in which transaction data is actually used by contracts are very limited. Even in the case of transaction challenges in Optimistic Rollup, it only requires submitting evidence that the transaction data "existed" at the time (state), without needing the details of that transaction to be stored on the mainnet in advance.

Therefore, if we place transaction data in the BLOB element, although contracts cannot access it, the mainnet contract can store the commitment of this BLOB.

In the future, if the challenge mechanism requires a specific 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 while avoiding the enormous gas costs of pre-recording all data in contracts.

By only recording the commitment, we achieve verifiability of transaction data 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 method similar to the Merkle tree used in Celestia was not adopted to generate commitments, but rather a clever KZG (Kate-Zaverucha-Goldberg, polynomial commitment) algorithm was used.

Compared to Merkle tree proofs, the process of generating KZG proofs is relatively complex, but its verification size is smaller, and the verification steps are simpler. However, the downside is that it requires a trusted setup (ceremony.ethereum.org has now concluded) and does not have resistance against quantum computing attacks (Dencun uses the Version Hash method, which can be replaced with other verification methods if needed).

For the currently popular DA project Celestia, it adopts a variant of the Merkle tree, which, compared to KZG, relies to some extent on the honesty of nodes while helping to lower the threshold requirements for computational resources between nodes, maintaining the decentralized characteristics of the network.

3. Opportunities in Dencun

EIP-4844 reduces costs and increases efficiency for Layer 2, but it also introduces security vulnerabilities, which brings new opportunities.

To understand the reason, we need to revisit the escape hatch mechanism or forced withdrawal mechanism mentioned earlier.

When Layer 2 nodes become incapacitated, this mechanism can ensure that user funds safely return to the mainnet. The prerequisite for activating this mechanism is that users need to obtain the complete state tree of Layer 2.

Under normal circumstances, users can 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 let’s not forget that users want to activate the escape hatch mechanism to exit L2 precisely because the L2 nodes are acting maliciously; if the nodes are malicious, it is highly likely that they will not provide the desired data.

This is the data withholding attack that Vitalik often mentions.

Before EIP-4844, the mainnet recorded permanent Layer 2 records. When no Layer 2 nodes can 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, allowing users to construct the necessary Merkle proof and submit it to the mainnet contract to safely complete the withdrawal of L2 assets.

However, after EIP-4844, Layer 2 data only exists in the BLOB of Ethereum full nodes, and historical data older than 18 days will be automatically deleted.

Therefore, the method mentioned in the previous paragraph of synchronizing with the mainnet to obtain the complete state tree is no longer feasible. To obtain the complete state tree of Layer 2, one can only rely on third parties that have stored all Ethereum BLOB data (which should have been automatically deleted after 18 days) or native Layer 2 nodes (which are rare).

As a result, after the launch of 4844, it will become very difficult for users to obtain the complete state tree of Layer 2 in a fully trustworthy manner.

Without a stable way to obtain the Layer 2 state tree, users cannot perform forced withdrawal operations under extreme conditions. Therefore, 4844 has created a certain degree of security shortfall/loss for Layer 2.

To fill this security gap, we need a trustless storage solution with a positive economic cycle. The storage here mainly refers to retaining data in Ethereum in a trustless manner, which is quite different from past storage tracks because it still involves the key term "trustless."

Ethstorage can solve the trustless issue and has received funding from the Ethereum Foundation in two rounds.

This concept can truly meet and compensate for the shortcomings of the Dencun upgrade, making it very worthy of attention.

First, Ethstorage's most intuitive significance lies in its ability to extend the availability of DA BLOBs in a completely decentralized manner, filling the security shortfall of Layer 2 after 4844.

In addition, most existing L2 solutions primarily focus on expanding Ethereum's computational capacity, i.e., increasing TPS. However, there is a surge in demand for securely storing 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 evident because users not only own the tokens of the NFT contract but also the on-chain images. Ethstorage can solve the issue of storing these images with third parties, which would bring additional trust problems.

Finally, Ethstorage can also address the needs of decentralized dApp frontends. Currently, existing solutions are mainly hosted by centralized servers (with DNS), which makes websites vulnerable to censorship and other issues, such as DNS hijacking, website hacking, or server crashes, as evidenced by events like Tornado Cash.

Currently, Ethstorage is still in the early testnet phase, and users who are optimistic about this track can experience it.