
2024 Meet "Cancun": Ethereum's Next Upgrade, Reducing Costs and Boosting Efficiency, Benefiting Layer2
TechFlow Selected TechFlow Selected

2024 Meet "Cancun": Ethereum's Next Upgrade, Reducing Costs and Boosting Efficiency, Benefiting Layer2
This upgrade is key to further scaling of Ethereum, enabling an increase in the number of transactions per second the Ethereum network can handle.
Author: Bulu
Ethereum's "Cancun Upgrade" has made new progress: On December 8, 2023, during the 176th Ethereum Foundation meeting, developers unanimously agreed that if everything proceeds smoothly, they will set a Goerli fork date in early 2024, aiming to activate the Goerli Dencun testnet by January 2024.
As for the specific timeline for the final completion of Ethereum’s “Cancun Upgrade,” based on industry experts’ assessments of current protocol development and testing progress, the upgrade is expected to be officially implemented between March and April 2024.
The significance of Ethereum’s "Cancun Upgrade" is no less than that of the "Shapella Upgrade"—because this upgrade is key to further scaling Ethereum, increasing the number of transactions per second the network can handle, and ushering in a new phase of development for Ethereum's data storage and retrieval capabilities.
For blockchain users holding digital assets, the most direct change brought by Ethereum’s "Cancun Upgrade" to digital asset transactions will be: Gas fees required for digital asset transactions on Ethereum Layer 2 networks will significantly decrease, potentially by up to 14 times.
imToken already supports all Layer 2 networks and EVM-compatible chains on Ethereum. After the "Cancun Upgrade" is completed, users holding digital assets can use imToken to experience higher cost-effectiveness and cheaper Gas fee transactions on Ethereum Layer 2 networks. Additionally, imToken supports OP and Polygon; directly using imToken’s Swap function can also enjoy relatively lower network operation fees.
For blockchain developers, it is important to note: once the Ethereum "Cancun Upgrade" is officially implemented in 2024, the Goerli testnet will no longer be used, and developers are advised to migrate to the Sepolia testnet as soon as possible.
imToken now fully supports the Sepolia testnet and allows claiming test assets via the "Faucet" entry point.
Understanding the "Cancun Upgrade"
Cancun is a famous tourist city in Mexico and was also the host city of Devcon 3. According to Ethereum’s upgrade naming convention, upgrades named after locations refer to upgrades at the execution layer of Ethereum.
The concurrent consensus layer upgrade associated with this "Cancun Upgrade" is codenamed Deneb. Therefore, the official full name of this dual-layer Ethereum upgrade—execution and consensus—is now confirmed as the "Dencun Upgrade," a portmanteau of Cancun and Deneb.
Below are the key improvement protocols (EIPs) from the "Cancun Upgrade" worth paying attention to. Let's take a closer look.
01 The Star of the "Cancun Upgrade": EIP-4844 — A Prototype for Ethereum Sharding
▶ Goal: Address Ethereum's scalability (i.e., expansion needs), helping reduce transaction costs for Ethereum Layer 2 (Layer 2) Rollup solutions and improving Rollup speed.
▶ Background: Fees on Ethereum’s Layer 1 mainnet have remained persistently high, necessitating improvements to reduce overall operational costs.
Currently, Ethereum’s primary scaling solutions are Layer 2 Rollups.
In practice, Rollup solutions have helped users save significant operational costs (hereinafter referred to as Gas Fee). For example, representative project Optimism typically incurs only 0.001 gwei in Gas Fees, far below regular Layer 1 mainnet expenses. ZK Rollup solutions offer even better data compression performance and do not require signature data inclusion, resulting in lower fees—sometimes as low as one percent of those on the Ethereum Layer 1 mainnet.
However, for a broader user base, even with Rollup solutions, Gas Fees remain relatively expensive. Furthermore, Ethereum’s efficiency in processing parallel transactions remains low, handling at most double-digit transactions per second. These limitations call for new improvements to enhance scalability.
Sharding is a powerful method to solve these issues, but full sharding cannot yet be implemented on Ethereum. The timely proposal of improvement EIP-4844 offers a pragmatic compromise between immediate needs and future sharding implementation, laying the technical groundwork for Ethereum’s eventual full data sharding.
Thus, EIP-4844 was initially called “Proto-danksharding,” meaning “prototype of danksharding.” The term “dank” comes from Ethereum researcher Dankrad Feist, who stated: “EIP-4844 will become an accelerator for Rollups.”
To better illustrate the technical enhancements of EIP-4844, the title of the EIP-4844 improvement proposal has been standardized as “Shard Blob Transactions,” i.e., “Blob Transactions.”
▶ Technical Improvements (Completed):
-
Introduce Blob transactions: Blob stands for Binary Large Object. Blob transactions are a new type of transaction designed for future use in sharded environments.
-
Implement all execution-layer logic required for future full sharding.
-
Implement all cross-validation logic between execution and consensus layers required for future full sharding.
-
Achieve separation between beacon block validation (i.e., Ethereum Layer 2 data) and Blob data availability sampling.
-
Introduce most of the logic within beacon blocks needed for future full sharding.

△ Full sharding conceptual diagram (by Vitalik Buterin)
Image source: foresightnews
▶ Notes: Blobs were originally designed to carry data for Ethereum Layer 2. Meanwhile, this vector of data is stored by nodes at Ethereum’s consensus layer and thus cannot be read by the Ethereum Virtual Machine (EVM) at the execution layer. This data separation is precisely what enables reduced costs for Ethereum Layer 2 Rollup solutions.
Additionally, Blob data will be deleted after 18 days.
To minimize pressure on the mainnet, compared to future full sharding implementations, EIP-4844 sets an upper limit on additional storage per beacon block—approximately 0.5 MB (about 4 Blobs). However, this cap is expected to increase in the future.

△ Data updated as of 2023/12/11

△ Data source: I2fees.info, statistics as of 2023/12/8
02 List of Confirmed Improvement Proposals for the "Cancun Upgrade":
-
EIP-4844
-
EIP-1153
-
EIP-6780
-
EIP-4788
-
EIP-5656
-
EIP-7516
In addition to the widely discussed EIP-4844 mentioned above, as of December 8, 2023, other confirmed improvement proposals being implemented for this "Cancun Upgrade" include:
▶ EIP-1153 "Transient Storage Opcodes": Adds opcodes for transient storage. Transient storage is specifically designed to address intra-block communication.
Transient storage does not alter the semantics of existing operations. Data stored transiently is discarded after each transaction, does not access server disks, requires no cleanup of storage slots afterward, and clients don’t need to load original data.
Therefore, the advantage of using transient storage for intra-block communication lies in its lower Gas Fee, and future Ethereum data storage designs won't need to account for gas refunds caused by temporary storage usage. However, EIP-1153 is not suitable for solving the use of temporary data storage in existing smart contracts.
▶ EIP-6780 "SELFDESTRUCT only in same transaction": Modifies the functionality of the SELFDESTRUCT opcode, preparing for Ethereum’s future adoption of the Verkle Tree architecture (commonly abbreviated as “Verkle Tree”).
Currently, Ethereum uses the Merkle Tree architecture (commonly known as “Merkle Tree”), where the SELFDESTRUCT opcode can make extensive changes to account states—for instance, deleting code and storage. However, when Ethereum adopts the Verkle Tree architecture in the future, accounts cannot be easily modified or deleted because each account will be stored under separate account keys that are not linked to the root account.
Therefore, EIP-6780 proposes modifying the functionality of the SELFDESTRUCT opcode. Under EIP-6780, the revised SELFDESTRUCT opcode will no longer have the ability to modify or delete accounts and will only be used to transfer ETH to the caller, except in cases where SELFDESTRUCT is invoked within the same transaction that created a smart contract.

△ Implementation progress of related improvement proposals for the Ethereum Cancun Upgrade across clients (as of 2023/12/8)
Image source: github@Cancun Network Upgrade Specification
▶ EIP-4788 "Beacon block root in the EVM": Exposes the beacon chain block root inside the Ethereum Virtual Machine. The beacon chain block root is a cryptographic accumulator used to prove arbitrary consensus states.
Exposing the beacon chain block root within the EVM enables minimal-trust access to Ethereum’s consensus layer. This is also an improvement beneficial for use case development, supporting enhanced trust assumptions (Trust Assumptions) for applications like Staking Pools and smart contract bridges.
▶ EIP-5656 "MCOPY - Memory copying instruction": Introduces a new, efficient EVM instruction for copying memory regions. Memory copying is a fundamental operation useful for various compute-intensive tasks, though it will incur operational costs once implemented on the Ethereum Virtual Machine.
The instruction introduced by EIP-5656 is entirely new. Existing smart contracts using this new instruction must consider compatibility and may require adjustments.
▶ EIP-7516 "BLOBBASEFEE opcode": Introduces the BLOBBASEFEE opcode. This opcode functions similarly to the BASEFEE opcode defined in EIP-3198, except BLOBBASEFEE returns the blob base fee according to EIP-4844 introduced in the Cancun Upgrade.
During the initial planning phase of the "Cancun Upgrade" schedule (around April–May 2023), there was considerable discussion about potentially including execution-layer protocols such as EIP-2537 (precompiles for BLS12-381 curve operations) and EIP-5920 (introducing a new PAY opcode). As of December 8, 2023, however, neither has appeared on the official upgrade roadmap.

△ Client integration test progress, Devnet-12 activated (as of 2023/12/8)
Image source: github@Cancun Network Upgrade Specification
03 Improvement Proposals Confirmed for the Consensus Layer "Deneb Upgrade," Synchronized with the "Cancun Upgrade":
-
EIP-7400
-
EIP-7045
-
EIP-7514
▶ EIP-7400 "Perpetually Valid Signed Voluntary Exits": Enables perpetually valid signed voluntary exits. This technical protocol primarily locks validator exit signature domains on the current Capella consensus layer so they retain validity post-"Cancun Upgrade," thereby reducing complexity for staking operations on Ethereum.
▶ EIP-7045 "Increase max attestation inclusion slot": Increases the maximum attestation inclusion slot. This technical protocol is crucial for current LMD-GHOST security analysis and rule confirmation. Currently, validators on-chain have 32 slots available to submit attestations; after implementing EIP-7045, validators could have up to 64 slots available for attestation submissions.
▶ EIP-7514 "Add Max Epoch Churn Limit": Adds a Max Epoch Churn limit. The purpose of this technical protocol is to mitigate negative externalities arising from the growth of total staked ETH. EIP-7514 is a transitional solution, with dedicated technical solutions expected in the future for these issues.
With the growing total amount of staked ETH, unrestricted validators lead to increased noise data and mounting data pressure on Ethereum’s consensus layer. To address these issues, the EIP-7514 improvement suggests setting the Max Churn limit to 8. This reduces the number of active validators added to the set while preventing unbounded growth of the validator set.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














