Explore Ethereum’s Dencun Upgrade and Potential Opportunities

The Ethereum network upgrade Dencun testnet version was launched on the Goerli testnet on January 17, 2024, and the Sepolia testnet was successfully launched on January 30. The Dencun upgrade is getting closer and closer.

After the Holesky testnet upgrade on February 7, it will be the mainnet upgrade. The mainnet launch of Cancun upgrade has been officially determined on March 13, 2024.

Almost every Ethereum upgrade is accompanied by significant market trends. Looking back at the last upgrade on April 12, 2023, known as the Shanghai upgrade, projects related to Proof-of-Stake (PoS) experienced increased market demand.

If we follow previous experiences, there will likely be opportunities for strategic positioning ahead of the upcoming Dencun upgrade.

However, due to the technical complexity involved in the Dencun upgrade, it cannot be summarized as succinctly as the Shanghai upgrade with a single phrase like “Ethereum transitioning from PoW to PoS.” This complexity makes it challenging to grasp the focal points for strategic positioning.

Therefore, this article aims to explain the technical details of the Dencun upgrade in simple and understandable language. It will guide readers through the intricacies of this upgrade, highlighting its connections with data availability (DA), Layer 2 solutions, and other relevant aspects.

01. EIP 4484

EIP-4844 stands out as the most crucial proposal in the Dencun upgrade, marking a significant stride for Ethereum in its decentralized scaling journey.

In layman’s terms, the current Ethereum Layer 2 solutions require submitting transactions occurring on Layer 2 to the calldata of the Ethereum mainnet. This calldata is then used by nodes to verify the validity of blocks on the Layer 2 network.

However, this approach presents challenges, as despite efforts to compress transaction data, the substantial transaction volume on Layer 2, multiplied by the high storage costs on the Ethereum mainnet, still imposes significant expenses on Layer 2 nodes and users. This high cost alone can lead to the migration of users to sidechains.

EIP-4844 introduces a cost-effective solution by establishing a new type of storage area called Binary Large Object (BLOB). It introduces a novel transaction type known as “BLOB-Carrying Transaction” to replace the transaction data previously stored in calldata before the upgrade. This innovative approach helps the Ethereum Layer 2 ecosystem achieve gas cost savings.

Why BLOB Storage is Cost-Efficient？

As we all know, cost-efficiency often comes with a trade-off. The reason why BLOB data incurs lower costs compared to similar-sized regular Ethereum calldata is that the Ethereum Execution Layer (EL) cannot directly access the BLOB data itself.

Instead, the EL can only access references to the BLOB data, and the actual data of the BLOB can only be downloaded and stored by the Ethereum Consensus Layer (CL, also known as beacon nodes). The memory and computational requirements for storing BLOB data are significantly lower than regular Ethereum calldata.

Furthermore, BLOB has a distinctive feature – it can only be stored for a limited period (typically around 18 days) and does not infinitely expand like the Ethereum ledger’s size.

Validity Period of BLOB Storage

In contrast to the blockchain’s permanent ledger, BLOBs are temporary storage that is available for 4,096 epochs, or approximately 18 days.

After expiration, most consensus clients will be unable to retrieve specific data in the BLOB. However, proof 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? This is a trade-off between storage cost and effectiveness.

First of all, we must consider the most intuitive beneficiaries of this upgrade, optimistic rollups (such as Arbitrum and Optimism,), because there is a 7-day Fraud Proof time window in Optimistic Rollups. 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 Fraud Proof is accessible. For the sake of simplicity, the Ethereum community chose 2 to the power of 12 (4,096 epochs are derived from 2^12, and one epoch is approximately 6.4 minutes).

BLOB-Carrying Transaction and BLOB

Understanding the relationship between the two is important to understanding the role of BLOBs in data availability (DA).

The former is the overall EIP-4484 proposal and is 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 that most of the data in the former (layer 2 transaction data) is stored in the latter. The remaining data, that is, the BLOB data commitment, will be stored in the calldata of the mainnet. In other words, promises can be read by the EVM.

Commitment can be imagined as constructing all transactions in the BLOB into a Merkle tree, and then only the Merkle root, which is the Commitment, can be accessed by the contract.

This can be achieved cleverly: although the EVM cannot know the specific content of the BLOB, the EVM contract can verify the authenticity of the transaction data by knowing the Commitment.

02. The Relationship Between BLOB and Layer 2

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

The purpose of uploading transaction data to L1 is simply to allow all participants to view the data.

Before the Dencun upgrade, as mentioned above, Optimistic Rollups will publish transaction data to Ethereum as calldata. Therefore, 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 to store transaction data specifically for the Layer 2, and BLOB-Carrying Transaction is tailor-made for Rollup.

At this point, you may wonder about the significance of transaction data.

In reality, transaction data is only used in specific scenarios:

• For Optimistic Rollup, based on a trust assumption, there is a possibility of dishonesty. In such cases, the transaction records uploaded by rollup become useful, enabling users to initiate fraud proofs.
• For ZK Rollup, zero-knowledge proof has proven that the state update is correct. Uploading data is only to allow users to calculate the complete state by themselves. When the Layer 2 node cannot operate correctly, the escape hatch mechanism, which requires a complete L2 state tree, is enabled. This will be discussed in the last section of this article.

This implies that the actual usage of transaction data by contracts is very limited. Even in Optimistic Rollup’s fraud proofs, only proof that transaction data “existed” at a particular moment is required, and there is no need to store the details of each transaction on the mainnet in advance.

By placing transaction data in the BLOB, although inaccessible to contracts, the mainnet contract can store the BLOB’s commitment.

If the fraud proof mechanism needs a specific transaction in the future, providing the data for that transaction, as long as it matches, can convince the contract and supply the transaction data for the fraud proof 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 is verifiable while greatly optimizing costs. 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 similar to Celestia is not used to generate commitment, but the KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment) algorithm is used.

Compared with Merkle tree proof, the process of generating KZG Proof is relatively complex, but its verification volume is smaller and the verification steps are simpler. However, the disadvantage is that it requires trustworthy settings (ceremony.ethereum.org, which has now ended) and does not have ability to prevent quantum computing attacks (Dencun uses the Version Hash method, and other verification methods can be replaced if necessary).

For the now popular DA project Celestia, it uses a variant of the Merkle tree. Unlike KZG, it relies to some extent on the integrity of nodes but helps lower the computational resource threshold between nodes, maintaining the decentralized nature of the network.

03. Opportunities in Dencun

While EIP-4844 reduces costs and increases efficiency for Layer 2, it also raises security risks, which also brings new opportunities.

To understand why, we need to go back to the escape hatch mechanism or forced withdrawal mechanism mentioned above.

When the Layer 2 node is disabled, this mechanism can ensure that user funds are safely returned to the mainnet. The prerequisite 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 merkle proof, and then submit it to the mainnet 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 nodes have acted maliciously. If this happens, there is a high probability that they will not get the data they want from the nodes.

This is what Vitalik often refers to as a data withholding attack.

Before EIP-4844, permanent Layer 2 records were recorded on the mainnet. When no Layer 2 node could provide complete off-chain status, users could deploy a full node themselves.

This full node can obtain all historical data released by the Layer 2 sequencer on the mainnet through the Ethereum mainnet. Users can construct the required Merkle proof and submit the proof to the contract on the mainnet to safely complete L2 asset withdrawal.

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

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

After EIP-4844 goes live, it will be very difficult for users to obtain the complete status tree of Layer 2 in a completely trustworthy way.

Without a stable way for users to obtain the Layer 2 state tree, they cannot perform forced withdrawal operations under extreme conditions. Therefore, EIP-4844 has become a security shortcoming for Layer 2 to a certain extent.

To make up for this lack of security, 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 manner, which is different from the storage space in the past because there is a keyword “trustless” in this case.

Ethstorage can solve the problem of trustlessness and has received two rounds of funding from the Ethereum Foundation.

Actually, this concept can truly cater to the potential brought by the Dencun upgrade, and it is worthy of our attention.

The most intuitive significance of Ethstorage is that it can extend the available time of DA BLOB in a completely decentralized manner, making up for the shortcomings of Layer 2 security after EIP-4844.

Additionally, most existing L2 solutions mainly focus 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 NFTs and DeFi.

For example, the demand for storing on-chain NFTs is huge, because users not only own tokens of NFT contracts, but also the on-chain image. Ethstorage can solve the additional trust issues that come with storing these images in a third party.

Finally, Ethstorage can also solve the front-end needs of decentralized dApps. Currently existing solutions are primarily hosted by centralized servers (with DNS). This setup makes websites vulnerable to censorship and other issues such as DNS hijacking, website hacking, or server crashes, as evidenced by incidents such as Tornado Cash.

Ethstorage is still in the initial testing stage, and users who are optimistic about the prospects of this track can give it a try.

Disclaimer：

1. This article is reprinted from [Biteye], All copyrights belong to the original author [Biteye]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.