Essential Security Checks for Developers Before the Cancun Upgrade

*Forward the Original Title：坎昆升级前，项目开发者必看的几项安全检查

TL;DR: With the Cancun upgrade approaching, it includes six EIP-proposed changes, mainly EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, and EIP-7516. EIP-4844 focuses on enhancing Ethereum’s scalability, reducing transaction costs, and speeding up transactions for Layer 2 solutions. The upgrade has been tested on Ethereum testnets and is scheduled for activation on the mainnet on March 13th. Salus has compiled important security considerations for developers to check before the upgrade.

Review of EIP Proposals

Official Security Considerations

Smart contracts related risks

Further reading

Review of EIP Proposals

EIP-1153

EIP-1153 introduces temporary storage opcodes, which are used to manipulate state in a way similar to storage, but with the temporary storage being discarded after each transaction. This means that temporary storage does not deserialize values from storage, nor serialize values to storage, resulting in lower costs due to avoiding disk access. With the introduction of two new opcodes, TLOAD and TSTORE (where “T” stands for “temporary”), smart contracts can access temporary storage. This proposal aims to provide a dedicated and efficient solution for communication between multiple nested execution frames during transaction execution in Ethereum.

EIP-4788

EIP-4788 aims to expose the hash tree roots of beacon chain blocks to the EVM, allowing these roots to be accessed within smart contracts. This enables access to the consensus layer state without trust, supporting various use cases such as staking pools, restaking structures, smart contract bridges, and MEV mitigation. The proposal achieves this by storing these roots in a smart contract and 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 “Shard Blob Transactions” designed to expand Ethereum’s data availability in a simple and backward-compatible manner. This proposal achieves its goal by introducing “blob-carrying transactions” containing large amounts of data that cannot be accessed by the EVM but can be accessed by their commitments. This format is fully compatible with the format used by future full-sharding, providing a temporary but significant relief for rollup scalability.

EIP-5656

EIP-5656 introduces a new EVM instruction, MCOPY, for efficient copying of memory regions. This proposal aims to reduce the overhead of memory copy operations on the EVM by directly copying data between memories using the MCOPY instruction. MCOPY allows for overlapping of source and destination addresses, designed with backward compatibility in mind, and aims to improve execution efficiency in various scenarios, including data structure construction, efficient access, and copying of memory objects.

EIP-6780

EIP-6780 modifies the functionality of the SELFDESTRUCT opcode. In this proposal, SELFDESTRUCT only deletes accounts and transfers all ether in the same transaction as contract creation. Additionally, when executing SELFDESTRUCT, the contract will not be deleted but will transfer all ether to a specified target. This change accommodates the future use of Verkle trees, aiming to simplify EVM implementation, reduce the complexity of state changes, while retaining some common use cases of SELFDESTRUCT.

EIP-7516

EIP-7516 introduces a new EVM instruction, BLOBBASEFEE, to return the base fee value for blobs in the current block execution. This instruction is similar to the BASEFEE opcode introduced in EIP-3198, with the difference being that it returns the blob base fee defined according to EIP-4844. This functionality allows contracts to programmatically consider the gas price of blob data, enabling rollup contracts to calculate blob data usage costs without trust or implement blob gas futures to smooth blob data costs.

Official Security Considerations

EIP-1153

Smart contract developers should understand the lifecycle of transient storage variables before using them. Since temporary storage is automatically cleared at the end of a transaction, smart contract developers might attempt to avoid clearing slots during a call to save gas. However, this could prevent further interaction with the contract in the same transaction (e.g., in the case of reentrant locks) or lead to other errors. Therefore, smart contract developers should be cautious and only retain non-zero values when the temporary storage slot is reserved for future calls within the same transaction. Otherwise, the behavior of these opcodes is identical to SLOAD and SSTORE, so all common security considerations apply, especially regarding reentrancy risks.

Smart contract developers may also attempt to use transient storage as an alternative to memory mapping. They should be aware that transient storage is not discarded like memory when a call returns or is reverted and should prioritize memory in such use cases to avoid unexpected behavior during reentry in the same transaction. The high cost of transient storage in memory should already discourage this usage pattern. Most use cases for mappings in memory can be better implemented through a sorted list of entries by key, and transient storage in memory mappings is rarely needed in smart contracts (i.e., no known use cases in production).

EIP-4844

This EIP increases the bandwidth requirements for each beacon block by up to approximately 0.75 MB. This is a 40% increase over the theoretical maximum size of today’s blocks (30M Gas / 16 Gas per calldata byte = 1.875M bytes), so it does not significantly increase bandwidth in worst-case scenarios. After merging, block times are static rather than unpredictably Poisson distributed, providing a guaranteed timeframe for the propagation of large blocks.

Even with limited call data, the sustained load of this EIP is significantly lower than alternative solutions that could reduce the cost of call data because Blob storage does not need to be retained for the same duration as execution load. This makes it possible to implement strategies that require these blobs to be retained for at least a period of time. The specific value chosen is the MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, which is approximately 18 days, much shorter than the proposed (but not yet implemented) one-year rotation time for executing valid payload histories.

EIP-5656

Clients should be mindful that their implementations do not use intermediate buffers (e.g., C stdlib memmove function not using intermediate buffers) as this is a potential denial of service (DoS) vector. Most language built-in functions/standard library functions used for moving bytes have the correct performance characteristics here.

Additionally, analysis of denial of service (DoS) and memory exhaustion attacks is the same as for other memory-touching opcodes since memory expansion follows the same pricing rules.

EIP-6780

The following applications of SELFDESTRUCT will be broken, and applications using it in this way are no longer secure:

Where CREATE2 is used to redeploy a contract at the same location to make contracts upgradeable. This functionality is no longer supported and should be replaced with ERC-2535 or other types of proxy contracts.

If a contract relies on burning ether to a contract via SELFDESTRUCT as the beneficiary, the contract is not created in the same transaction.

Smart Contract Related Risks

EIP1153

Consider two scenarios using opcodes TLOAD and TSTORE:

1. Called contracts use these opcodes.
2. Calling contracts use these opcodes.

Risk 1:

Compared to traditional SSTORE and SLOAD, the introduction of transient storage mainly changes the storage duration of data. Data stored by TSTORE is read through TLOAD and will be released after the execution of a transaction, rather than being permanently recorded in the contract like SSTORE. Developers should understand the characteristics of these opcodes when using them to avoid incorrectly using them, which may result in data not being correctly written to the contract, causing losses. Additionally, data stored by TSTORE is private and can only be accessed by the contract itself. If external access to this data is required, it must be passed through parameters or temporarily stored in a public storage variable.

Risk 2:

Another potential risk is that if smart contract developers do not manage the lifecycle of transient storage variables correctly, it may lead to data being cleared at inappropriate times or incorrectly retained. If a contract expects to use data stored in transient storage in subsequent calls of a transaction but fails to properly manage the lifecycle of this data, it may erroneously share or lose data between different calls, resulting in logical errors or security vulnerabilities. Failure to store data correctly, such as balance or allowance data in token projects, can lead to logic errors in contracts, causing losses. Similarly, using these opcodes to set the owner address may result in the privileged address not being correctly recorded, leading to the loss of modifications to important parameters of the contract.

Consider a smart contract that uses transient storage to temporarily record the transaction price on a cryptocurrency trading platform. The contract updates the price after each transaction and allows users to query the latest price within a short period. However, if the contract design does not consider the automatic clearing of transient storage at the end of a transaction, there may be a period between the end of one transaction and the beginning of the next where users may receive an incorrect or outdated price. This could not only lead to users making decisions based on incorrect information but also be exploited maliciously, affecting the platform’s reputation and the security of users’ assets.

EIP-6780

This proposal changes the behavior of the previous selfdestruct opcode, where the contract is not burned but only token transfer occurs, and only contracts created in the same transaction as the selfdestruct contract will be burned. The impact of this EIP is relatively significant.

Using create2 to redeploy contracts at the same address for contract upgrades is no longer supported. This functionality should be replaced with ERC-2535 or other types of proxy contracts. (This may affect the security of on-chain contracts implementing upgradable contracts using create2).

The SELFDESTRUCT operation in smart contracts allows contracts to be burned, and the contract balance to be sent to a specified target address. In this case, the contract uses SELFDESTRUCT to burn Ether and sends the burned Ether to the contract. However, this contract must only be created in the same transaction as other contracts (contracts created by this contract or other contracts in the same transaction). Otherwise, Ether will only be transferred without burning the contract (for example, selfdestruct with the beneficiary being the selfdestruct contract, which will not produce any changes). This will affect all contracts that rely on selfdestruct function for withdrawals or other operations.

A Gas Token similar to the 1inch CHI Token works as follows: maintaining an offset, always deploying CREATE2 or SELFDESTRUCT at this offset. After this update, if the contract at the current offset has not been correctly self-destructed, subsequent CREATE2 will not be able to successfully deploy contracts.

This proposal implementation cannot directly attack contracts, but it will damage the normal logic of existing contracts that rely on selfdestruct operations (contracts that only rely on selfdestruct for fund transfers are not affected, but contracts that require subsequent operations to delete selfdestruct contracts are affected), causing contracts to work unexpectedly, and may lead to contract strikes, loss of funds, etc. (for example, contracts that originally used create2 to deploy new contracts at the original address and self-destructed the original contract for upgrade, can no longer be successfully deployed). In the long run, modifying the functionality of an opcode may bring about centralization issues.

For example, there is an existing vault contract for updates:

• Temporary storage contracts, create2, are used to temporarily reserve funds for the vault.
• Self-destruct the vault contract, transferring funds to the temporary contract (only funds are transferred without burning the contract).
• Create a new vault contract at the original address using create2 (fails because the original vault contract has not been burned).
• Self-destruct the temporary contract to return funds to the vault (funds lost, the vault contract has not been created).

Extended Reading:

The Cancun upgrade will further enhance Ethereum’s competitive advantage. However, the changes to the core smart contract layer in this upgrade bring risks that will affect the secure operation of existing DApps. During smart contract development, these changes and the potential risks they may bring need to be closely monitored. You can contact Salus for risk checks or audit support, or further reading to understand the changes.

Cancun Network Upgrade Specification

EIP-1153

EIP-4788

EIP-4844

EIP-5656

EIP-6780

EIP-7516

Metapod contract

GasToken2 contract

Disclaimer：

1. This article is reprinted from [Aicoin], Forward the Original Title‘Salus Insights：坎昆升级前，项目开发者必看的几项安全检查’. All copyrights belong to the original author [*Odaily Planet Daily]. 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.