In-depth Analysis of the Post-Cancun Upgrade Era: Data and Investment Perspectives

Preface

Since its official launch on July 30, 2015, Ethereum has undergone 12 upgrades, each of which has attracted significant attention.

The main goal of the Ethereum Cancun-Deneb upgrade ( Dencun upgrade ) is to enhance the scalability and modularity of Layer 2 networks, strengthen the security features of the Ethereum network, and improve overall usability.

1. What is the Dencun upgrade?

1.1 Upgrade Introduction

1.1.1 Origin of the Name

The Ethereum underlying structure consists of two parts: the execution layer and the consensus layer, each with different naming conventions.

The naming convention for execution layer upgrades has been based on cities hosting Devcon (Ethereum Developers Conference) since 2021. For example, the Berlin upgrade, the London upgrade, the Shanghai upgrade, etc.

The naming convention for the consensus layer upgrade has been based on celestial names since the launch of the Beacon Chain, following alphabetical order. For example, Altair, Bellatrix, Capella, etc.

Each upgrade of Ethereum is named by combining the different upgrade names of the two, forming an overall upgrade designation. Since this Devcon is held in Cancun, Mexico, and the consensus layer upgrade is called Deneb, this Ethereum upgrade is referred to as the Dencun upgrade.

1.1.2 Upgrade Background

The background of the Dencun upgrade is based on a long-term plan for the development of Ethereum, and another core aspect is to enhance the Ethereum user experience, ultimately achieving a permissionless, decentralized, censorship-resistant, and open-source ecosystem.

On one hand, according to the roadmap released by Ethereum founder Vitalik Buterin on December 31, 2023, the Dencun upgrade corresponds to the part of The Surge, prioritizing user experience (such as improving transaction speed and reducing Gas fees). The goal is to enhance network efficiency, lower transaction costs, and lay a solid foundation for future development.

On the other hand, from the article "Make Ethereum Cypherpunk Again" published by Vitalik Buterin on December 28, 2023, it can be understood that Vitalik believes one of the core reasons currently limiting blockchain to asset speculation is the rise in transaction fees. This has made Degen Gamblers the mainstream group, which is detrimental to realizing the practical value of blockchain applications. Therefore, transaction fees must be reduced.

Upgrade Time 1.1.3

According to the Ethereum plan, the upgrade time and activation information are:

• Execution layer upgrade block height: 18,963,249
• Consensus Layer Epoch: 269,568
• Estimated time: March 13, 2024 (UTC time)

1.1.4 Related Content

The Ethereum Cancun-Deneb upgrade has made a series of improvements to both the execution layer and the consensus layer. Cancun has refined the execution layer (EL), while Deneb has strengthened the consensus layer (CL), incorporating a series of EIPs (Ethereum Improvement Proposals) that are crucial for the development of the Ethereum network. There are a total of 9 EIPs, and we will introduce the key EIPs in the following sections.

Key Points of the Dencun Upgrade 1.2

1.2.1 EIP-4844 Shard Blob Transactions (Proto-Danksharding)

EIP-4844 is the highlight of this upgrade, aimed at reducing transaction fees, increasing transaction throughput (TPS), and enhancing scalability. Essentially, it is a transitional upgrade to prepare for the future, to achieve full Danksharding (the final part of Ethereum's "Serenity" phase upgrade), while Proto-Danksharding lays the groundwork for Danksharding.

The data availability provided on the Ethereum main chain is called Calldata (which can be understood as the data generated during contract transaction calls). The data sent back from Layer 2 to Layer 1 is stored in Calldata. Additionally, for security reasons, each step of executing Calldata requires Gas, leading to higher Gas costs. However, after the transaction data in Calldata is verified, it actually has little use; long-term data can also be downloaded and verified, and it may not even need to be sent to the execution layer. Taking the average historical transaction fees of the Layer2-OP chain as an example, it can be seen that nearly 80% of the fees come from L1 data fees.

EIP-4844 introduces a new data storage structure—Blob, specifically designed for storing transaction data submitted from L2 to L1. After its introduction, L2 transaction data is directly submitted to the Blob for storage, allowing consensus nodes to fully download it and delete it after a brief delay, reducing unnecessary storage burden. This means that the introduction of Blob will significantly lower L2 transaction fees. Additionally, Blob effectively expands the block space for L2, while the transaction throughput of L2 will also see a notable increase.

1.2.2 EIP-1153 Transient Storage Opcode

The main purpose of EIP-1153 is to save storage space and storage costs. Transient storage is discarded after each transaction, so temporary storage is cheaper as it does not require disk access.

EIP-1153 is more friendly to Dapp developers, introducing new opcodes TSTORE and TLOAD in the EVM, with a Gas cost of about 100 Gas per call, which is 95% cheaper than traditional storage calls (SLOAD and SSTORE). Additionally, once the complete transaction execution is finished, this portion of storage will be cleared, thereby reducing storage costs and Gas consumption, potentially allowing new DeFi contracts to save more Gas in the future.

1.2.3 EIP-4788 Beacon Block Root in EVM

EIP-4788 will enable communication between the EVM (Ethereum Virtual Machine) and the Beacon Chain. This feature supports various use cases and can improve staking pools, restaking constructions, smart contract bridges, MEV, and more.

Previously, the EVM could not directly access the data and state of the Beacon and could only capture the state through external trusted oracles. Therefore, it was proposed to place a parent beacon block root (parent_beacon_block_root) in each EVM block, so that when the Beacon is updated, accurate information can be immediately obtained on the EVM.

The parent beacon block root will be stored in a circular buffer, retained for about 1 day. Once a new parent beacon block root enters, and the buffer capacity reaches the critical value, the oldest parent beacon block root will be overwritten, thus achieving efficient and limited consensus storage. In this way, communication is realized in a trust-minimized manner, eliminating external oracle failures and malicious risks, thereby enhancing security.

1.2.4 EIP-5656 MCOPY - Memory Copy Instruction

EIP-5656 optimizes the cost of the memory area copy process by introducing a new EVM instruction, MCOPY, thereby improving the efficiency of data movement within the EVM.

Memory copying is a fundamental operation, but implementing it on the EVM comes with overhead. Taking the example of copying 256 bytes of memory data, developers can significantly reduce the cost from the previous 96 Gas (using MLOAD and MSTORE) to 27 Gas through the MCOPY opcode. It is expected that in the future, most developers will use MCOPY instead of MSTORE/MLOAD, and more efficient Gas contracts will ultimately benefit end users.

At the same time, MCOPY fills the gap in the current methods of copying memory in EVM.

1.2.5 EIP-6780 SELFDESTRUCT only within the same transaction

EIP-6780 restricts the functionality of the SELFDESTRUCT opcode, where the new feature simply sends all funds in the account to the target, but does not affect the code, storage, and other information, while also preparing for the subsequent Verkle tree upgrade.

Before EIP-6780, if the SELFDESTRUCT opcode was referenced during contract creation, funds could be sent to the target, but the code, storage, and other information would be deleted. However, this functionality posed certain dangers and unexpected consequences. After EIP-6780, all of this will not be affected, allowing developers to better manage projects, thus achieving a more stable and predictable blockchain.

2. Impact on the data layer after the upgrade

2.1 Impact of Gas Fees

The most core aspect of this upgrade, and the one that everyone is most concerned about, is the change in Gas fees. With the introduction of EIP-4844, the most significant beneficiaries are Layer 2 solutions, where the decrease in Gas costs is very noticeable, leading to an improved user experience. It basically meets the expectation of a 90% reduction in Layer 2 transaction fees that was anticipated prior to the upgrade.

As for Layer 1 (Ethereum itself), after the upgrade, the Gas fees have decreased, but not significantly, and users do not experience any changes in actual usage.

2.2 Impact of Trading Volume

In addition to reducing Gas, the upgrade also aims to improve throughput, which is a key focus in Ethereum's scaling development plan.

After the upgrade was completed, the trading volume of Base surged first and broke through the previous bottleneck, increasing from 500,000 to 2 million, indicating that EIP-4844 had a direct impact, with the benefits being most apparent.

2.3 TPS Impact

The optimization of TPS (transactions per second) means that developers have greater flexibility when building and deploying dApps, which is expected to give rise to more complex, data-intensive applications, thereby attracting a broader user base.

After the upgrade is complete, the TPS of each Layer 2 has generally increased, but it does not exceed 30 transactions per second.

Low TPS is a common phenomenon in the current Web3 industry, which is different from the high TPS characteristics of the traditional Web2 industry. The highest TPS of Layer 2 has not exceeded 500, but from the perspective of industry development, this upgrade is also laying the foundation for the future, while echoing the expectations for Ethereum's development—reaching 100,000+ TPS.

2.4 Blob Usage

The overall decrease in Layer 2 transaction fees is mainly due to the introduction of Blob types. The more Blobs are attached to a transaction, the greater the overall throughput, which also lays the groundwork for future Ethereum upgrades.

Initially, it was estimated that if an average target of 3 Blobs per block is achieved, the throughput of L2 would see an almost 2-fold increase. If the ultimate goal of having 64 Blobs per block is realized, the throughput of L2 would see an almost 40-fold increase. The maximum limit for this upgrade is set to 6 Blobs.

As of now, Blob has started to be used in transactions, but the overall usage rate is not high. The peak occurred right after the upgrade was completed, and it has gradually declined since then, not yet reaching the estimated average target of 3 Blobs.

However, the introduction of Blob types has significantly improved the data costs of Layer 2 on Layer 1. From the example of the OP chain mentioned above, it can be intuitively felt that the data costs of using L1 in the average transaction fees of Layer 2 have significantly decreased, almost eliminated. This also suggests from another perspective that the profit margins of Layer 2 may have the potential to increase.

The profit model of L2 is relatively simple and clear, which can basically be summarized as: on-chain profit = L2 transaction fees - L1 payment costs; taking the OP chain as an example, although the upgrade simultaneously reduced L2 transaction fees and L1 payment costs, due to the increase in trading volume and user base, the reduction in both is not on the same order of magnitude. Transaction fees decreased from hundreds of thousands to tens of thousands, while payment costs dropped from hundreds of thousands to less than 1k, and on-chain profits have also increased after the upgrade.

Price Impact of 2.5

For this upgrade,