As the Cancun upgrade approaches, what should you pay attention to and what potential risks might arise?
TechFlow Selected TechFlow Selected
As the Cancun upgrade approaches, what should you pay attention to and what potential risks might arise?
The Cancun upgrade has already been successfully implemented on the Ethereum Goerli, Sepolia, and Holesky testnets on January 17, January 30, and February 7, respectively, and is scheduled to activate on the Ethereum mainnet on March 13.
Navigating Web3 tides with focused insightsAuthor: Salus Insights
In short: The upcoming Cancun upgrade includes six execution-layer EIPs—EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, and EIP-7516. EIP-4844 is the centerpiece of this upgrade, aiming to enhance Ethereum's scalability by reducing transaction costs and accelerating transaction speeds for Layer 2 (L2) solutions. The Cancun upgrade has already been successfully implemented on the Goerli, Sepolia, and Holesky testnets on January 17, January 30, and February 7 respectively, and is scheduled to activate on the Ethereum mainnet on March 13. Ahead of the upgrade, Salus has compiled key security considerations for developers to review.
EIP Proposal Overview
EIP-1153
EIP-1153 introduces transient storage opcodes, which operate similarly to regular storage but are discarded at the end of each transaction. This means transient storage does not deserialize values from or serialize values into persistent storage, eliminating disk access and resulting in lower operational costs. Two new opcodes, TLOAD and TSTORE (where "T" stands for "transient"), allow smart contracts to access transient storage. This proposal aims to provide a dedicated and efficient solution for communication between multiple nested execution contexts during Ethereum transaction processing.
EIP-4788
EIP-4788 exposes the Merkle root of beacon chain blocks within the EVM, enabling trustless access to consensus layer state data directly inside smart contracts. This supports various use cases such as staking pools, restaking protocols, smart contract bridges, and MEV mitigation mechanisms. The proposal stores these roots via a smart contract using a circular buffer to limit storage consumption, ensuring that each execution block requires only constant space to represent this information.
EIP-4844
EIP-4844 introduces a new transaction format called "blob-carrying transactions," designed to expand Ethereum’s data availability in a simple and forward-compatible manner. These transactions carry large volumes of data known as blobs, which cannot be accessed directly by the EVM but whose commitments can be verified. This format is fully compatible with future full sharding designs and provides immediate, significant relief for rollup-based scaling.
EIP-5656
EIP-5656 introduces a new EVM instruction, MCOPY, for efficiently copying memory regions. This proposal reduces the overhead of memory copy operations on the EVM by allowing direct data transfer between memory areas. MCOPY supports overlapping source and destination addresses and was designed with backward compatibility in mind, aiming to improve execution efficiency in scenarios involving data structure construction, object duplication, and efficient memory access.
EIP-6780
EIP-6780 modifies the behavior of the SELFDESTRUCT opcode. Under this proposal, SELFDESTRUCT will delete an account and transfer all Ether only if the contract is destroyed within the same transaction in which it was created. Otherwise, executing SELFDESTRUCT will not delete the contract but will still transfer all Ether to the designated recipient. This change prepares the network for future adoption of Verkle trees, simplifies EVM implementation, reduces complexity in state transitions, while preserving common use cases of SELFDESTRUCT.
EIP-7516
EIP-7516 introduces a new EVM opcode, BLOBBASEFEE, which returns the current blob base fee value for the executing block. Similar to the BASEFEE opcode introduced in EIP-3198, BLOBBASEFEE differs in that it returns the blob-specific base fee defined under EIP-4844. This enables contracts to programmatically assess blob gas pricing—for example, allowing rollup contracts to compute blob usage costs trustlessly or implement blob gas futures to smooth out cost fluctuations.
Officially Disclosed Security Considerations
EIP-1153
Smart contract developers should understand the lifecycle of transient storage variables before using them. Since transient storage is automatically cleared at the end of a transaction, developers might attempt to avoid clearing slots during calls to save gas. However, this could prevent further interactions with the contract within the same transaction (e.g., in reentrancy lock patterns) or lead to other errors. Developers should carefully ensure non-zero values are stored only when intended for use in subsequent calls within the same transaction. Otherwise, the behavior of these opcodes is identical to SSTORE and SLOAD, so all standard security best practices apply—especially regarding reentrancy risks.
Developers may also consider using transient storage as an alternative to memory mapping. They should be aware that unlike memory, transient storage is not discarded upon call return or revert, and memory should be preferred in such cases to avoid unexpected behaviors during reentrancy within the same transaction. The high cost of transient storage relative to memory likely discourages such misuse. Most use cases for in-memory mappings can be better implemented using sorted lists of entries, and true in-memory mappings are rarely needed in practice (to the author's knowledge, there are no known production use cases).
EIP-4844
This EIP increases bandwidth requirements per beacon block by up to approximately 0.75 MB. This is 40% larger than the theoretical maximum size of today's blocks (30M gas / 16 gas per calldata byte = 1.875M bytes), so it does not significantly increase worst-case bandwidth demands. After the merge, block times are fixed rather than unpredictable Poisson-distributed intervals, providing guaranteed time windows for propagating large blocks.
Even with limited call data, the sustained load from this EIP is much lower compared to alternatives that reduce call data costs, because blobs do not need to be stored as long as execution payloads. This makes it feasible to enforce policies requiring blobs to be retained for at least a minimum duration. The chosen value, MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS (~18 days), is significantly shorter than the proposed (but not yet implemented) one-year rotation period for execution payload history.
EIP-5656
Clients should ensure their implementations do not use intermediate buffers (for example, C stdlib memmove functions typically avoid intermediate buffers), as doing so could introduce potential denial-of-service (DoS) vectors. Most built-in or standard library functions across programming languages for moving bytes exhibit correct performance characteristics here.
Beyond this, analysis of DoS and memory exhaustion attacks remains consistent with other opcodes that interact with memory, since memory expansion follows the same gas pricing rules.
EIP-6780
The following applications of SELFDESTRUCT will be broken, and any application relying on this behavior will no longer be secure:
Using CREATE2 to redeploy a contract at the same address for upgradability. This functionality is no longer supported and should be replaced with ERC-2535 or other proxy contract patterns.
Contracts that rely on burning Ether via SELFDESTRUCT where the beneficiary is a contract not created within the same transaction.
Smart Contract-Related Risks
EIP-1153
Consider two scenarios involving the use of TLOAD and TSTORE opcodes:
-
Called contract uses these opcodes
-
Calling contract uses these opcodes
Risk 1:
Compared to traditional SSTORE and SLOAD, the newly introduced transient storage primarily changes data persistence duration—data stored via tstore is readable via tload but is released after transaction execution, rather than being permanently recorded like sstore. Developers must fully understand the characteristics of these opcodes to avoid incorrect usage that results in data failing to persist properly, potentially leading to losses. Additionally, tstore data constitutes private variables accessible only by the contract itself. To expose this data externally, it must either be passed as parameters or temporarily stored in a public storage variable.
Risk 2:
Another potential risk arises when developers fail to properly manage the lifecycle of transient storage variables, possibly causing data to be cleared prematurely or incorrectly retained. If a contract expects to use data stored in transient storage during later function calls within the same transaction but fails to manage its lifecycle correctly, it may inadvertently share or lose data across invocations, leading to logic errors or security vulnerabilities. For instance, incorrect handling of critical data such as token balances or allowances could result in flawed contract logic and financial loss. Similarly, setting privileged addresses like owner using this opcode may result in failure to record the correct authority, compromising control over critical contract parameters.
Consider a smart contract that uses transient storage to temporarily record trading prices on a cryptocurrency exchange platform. The contract updates the price upon completion of each trade and allows users to query the latest price briefly afterward. However, if the design fails to account for the fact that transient storage is automatically cleared at the end of each transaction, users may receive incorrect or outdated pricing information between the end of one transaction and the start of the next. This could lead users to make decisions based on inaccurate data and may even be exploited maliciously, affecting the platform’s reputation and user asset security.
EIP-6780
This proposal alters the previous behavior of the selfdestruct opcode: contracts are no longer destroyed unless they were created within the same transaction as the selfdestruct call. Instead, Ether is transferred without contract destruction. The impact of this EIP is relatively significant.
Using CREATE2 to redeploy a contract at the same address for upgrades is no longer supported. Alternatives such as ERC-2535 or other proxy patterns should be used instead. (This may affect the security of on-chain contracts that use CREATE2 for upgradable contract implementations.)
The SELFDESTRUCT operation in smart contracts allows a contract to destroy itself and send its balance to a specified target address. Under this update, such destruction only occurs if the contract being destroyed was created within the same transaction (either by itself or another contract). Otherwise, Ether is transferred without destroying the contract (e.g., self-destructing with the beneficiary being the contract itself results in no change). This affects all contracts that depend on SELFDESTRUCT for withdrawals or other operations (contracts).
A mechanism similar to the 1inch CHI Token Gas Token works by maintaining an offset and consistently performing CREATE2 or SELFDESTRUCT at that offset. After this update, if the contract at the current offset hasn't been properly self-destructed, subsequent CREATE2 deployments at that address will fail.
While the implementation of this proposal does not enable direct attacks on contracts, it disrupts the normal logic of existing deployed contracts that rely on the original SELFDESTRUCT behavior (contracts relying solely on selfdestruct for fund transfers remain unaffected; those requiring actual contract deletion for subsequent operations are impacted), potentially causing unintended behavior. For both contracts and users, this could result in operational failures or financial losses (e.g., contracts that previously upgraded by deploying a new version at the same address via CREATE2 and self-destructing the old one can no longer succeed). In the long term, modifying opcode semantics may raise concerns about centralization.
For example, consider an upgrade process for a vault contract:
-
CREATE2 a temporary contract to hold the vault’s funds
-
SELFDESTRUCT the vault contract, transferring funds to the temporary contract (funds transferred but vault not destroyed)
-
CREATE2 a new vault contract at the original address (fails because the original vault still exists)
-
SELFDESTRUCT the temporary contract to return funds to the vault (loss of funds—the vault contract was never recreated)
Further Reading
The Cancun upgrade will further strengthen Ethereum’s competitive edge. However, changes to the core smart contract layer introduce new risks that may affect the secure operation of existing DApps. During smart contract development, these changes and their associated risks must be closely monitored.
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
@salus_sec
