Long story short: The Cancun upgrade is approaching, and this upgrade mainly includes the executive layer changes proposed by the six EIPs, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, and EIP-7516. EIP-4844 is the protagonist of this upgrade, which aims to improve the scalability of Ethereum, drop Transaction Cost L2, and increase transaction speed. The Cancun upgrade was completed on January 17, January 30, February 7 in Ethereum Goerli, Sepolia, and Holesky Testnet, and is scheduled to be activated on March 13 in Ethereum Mainnet. Before the upgrade, Salus has compiled important security considerations for this upgrade for developers to check on their own.
EIP Proposal Review
Officially disclosed security considerations
Smart Contract Associated Risks
Read more
EIP Proposal Review
EIP-1153
EIP-1153 introduces ephemeral storage Operation Code, which are Operation Code used for operational state and behave almost identically to storage, but are discarded after each transaction is completed. This means that temporary storage does not deserialize values from storage and does not serialize values to storage, so temporary storage is less expensive because it does not require disk access. With two new Operation Codes, TLOAD and TSTORE (where “T” stands for “temporary”), Smart Contract can access temporary storage. This proposal aims to provide a dedicated and efficient solution for communication between Long nested execution frameworks in Ethereum’s transaction execution.
EIP-4788
EIP-4788 aims to expose the hash tree roots of Beacon Chain Blocks to the EVM to allow access to these roots inside the Smart Contract. Doing so provides trustless access to Consensus layer state, supporting Long use cases such as staking pools, restaking structures, Smart Contract bridges, MEV mitigation, and more. The proposal stores these roots through a Smart Contract and uses a ring buffer to limit storage consumption, ensuring that each execution Block only needs a constant Short to represent this information.
EIP-4844
EIP-4844 introduces a new transaction format called “Sharding Blob Transactions” designed to scale Ethereum’s data availability in a simple, forward-compatible way. This proposal does this by introducing “blob-carrying transactions” that contain a large amount of data that cannot be accessed by the EVM execution, but can access its promises. This format is fully compatible with the format used by full Sharding in the future, providing a temporary but significant relief for rolling scaling.
EIP-5656
EIP-5656 introduces a new EVM instruction, MCOPY, for efficient replication of memory regions. This proposal aims to drop the overhead of performing memory copy operations on the EVM by directly enabling data replication between memory via the MCOPY instruction. MCOPY ALLOWS THE SOURCE AND TARGET Address Address TO OVERLAP, IS DESIGNED WITH BACKWARD COMPATIBILITY IN MIND, AND IS DESIGNED TO IMPROVE EXECUTION EFFICIENCY IN Long SCENARIOS, INCLUDING DATA STRUCTURE CONSTRUCTION, EFFICIENT ACCESS TO IN-MEMORY OBJECTS, AND REPLICATION.
EIP-6780
EIP-6780 modifies the functionality of the SELFDESTRUCT Operation Code. In this proposal, SELFDESTRUCT would only delete the account and transfer all Ether in the same transaction as the contract was created, except that when SELFDESTRUCT was executed, the contract would not be deleted, but would simply transfer all Ether to the specified destination. This change is intended to accommodate the use of Verkle trees in the future, and is intended to simplify EVM implementations and reduce the complexity of state changes, while retaining some of the common scenarios used by SELFDESTRUCT.
EIP-7516
EIP-7516 introduces a new EVM instruction, BLOBBASEFEE, which returns the blob base fee value in the current block execution. This directive is similar to the BASEFEE Operation Code in EIP-3198, except that it returns the blob base fee as defined by EIP-4844. This feature allows the contract to programmatically consider the gas price of blob data, for example, by allowing rollup contracts to trustlessly calculate the cost of using blob data, or to implement blob gas futures based on this to smooth out blob data costs.
Officially disclosed 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 may try to avoid clearing slots during calls to save gas. However, this may prevent further interaction with the contract in the same transaction (e.g., in the case of a reentrant lock) or cause other errors, so Smart Contract developers should be careful to preserve non-zero values only when the temporary slot is reserved. Intended to be used by future calls in the same transaction. SSTORE Otherwise, these Operation Codes behave exactly the same as and SLOAD, so all common security considerations apply, especially when it comes to re-entrancy risks.
Smart Contract developers may also try to use transient storage as an alternative to memory mapping. They should be aware that ephemeral storage is not discarded like memory when the call returns or resumes, and memory should be prioritized in these use cases to avoid unexpected behavior when re-entrancy in the same transaction. Transient storage on memory is necessarily costly, which should have prevented this usage pattern. The large Long use of in-memory mapping can be better achieved with key-sorted entry lists, and in-memory mapping is rarely required in Smart Contract (i.e. the author knows that there are no known use cases in production).
EIP-4844
This EIP increases the bandwidth requirement by about 0.75 MB at a maximum Long per beacon block. This is 40% larger than today’s theoretical maximum Block size (30 M Gas / 16 Gas per calldata byte = 1.875 M bytes), so it doesn’t significantly increase worst-case bandwidth. After the merger, the Block time is static rather than an unpredictable Poisson distribution, providing a guaranteed time period for the propagation of large Block.
Even with limited call data, the sustained load of this EIP is Long lower than alternatives that can drop the cost of call data because you don’t need to store blobs for as long as the execution load. This makes it possible to implement a policy that these blobs must be retained for at least a certain period of time. The specific value selected is the MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, which is approximately 18 days, with a latency of Long compared to the recommended (but not yet implemented) one-year rotation of the execution payload history.
EIP-5656
Clients should be aware that their implementations do not use intermediate buffers (e.g., the C stdlibmemmove function does not use intermediate buffers), as this is a potential denial-of-service (DoS) vector. Long of the language’s built-in/standard library functions for moving bytes have the correct performance characteristics here.
Other than that, analysis of denial-of-service (DoS) and memory exhaustion attacks is the same as other Operation Code for touching memory, because memory expansion follows the same pricing rules.
EIP-6780
THE FOLLOWING APPLICATIONS OF SELFDESTRUCT WILL BE COMPROMISED, AND APPLICATIONS THAT USE IT IN THIS WAY ARE NO LONGER SAFE:
WhereCREATE 2 is used to redeploy the contract in the same location so that the contract is upgradeable. This feature is no longer supported and ERC-2535 or another type of proxy contract should be used instead.
If the contract relies on burning Ether by taking the SELFDESTRUCT contract as a beneficiary, the contract is not created in the same transaction.
Risks associated with Smart Contracts
EIP 1153
Consider two scenarios using the Operation Code TLOAD and TSTORE:
- The called contract uses the Operation Code
- The Operation Code is used to initiate the call contract
Risk 1 :
Compared with the traditional SSTORE and SLOAD, the new transient storage mainly changes the storage period of the data, the data stored by the tstore is read through the tload, and the data will be released after the execution of a transaction, instead of being written into the contract as the sstore is permanently recorded. Developers should recognize the features of the Operation Code when using the Operation Code, so as to avoid losses caused by incorrect use of data that cannot be written into the contract correctly. In addition, the data of the tstore is a private variable and can only be accessed by the contract itself. If you want to use the data externally, you can only pass it as a parameter or stage it in a public stroage variable.
Risk 2 :
Another potential risk is that if Smart Contract developers do not properly manage the lifecycle of transient storage variables, it could lead to data being purged or incorrectly retained at undue times. If a contract expects to use data stored in transient storage in subsequent calls to a transaction, but fails to properly manage the lifecycle of that data, data may be mistakenly shared or lost between different calls, resulting in logical errors or security breaches. Considering that the balance or allowance data of a similar Token project is not stored correctly, it will lead to errors in the contract logic and cause losses. Or the use of this Operation Code when setting the owner Address will cause the privileged Address to not be recorded correctly, thus losing the modification of important parameters of the contract.
Consider a Smart Contract that uses transient storage to temporarily record transaction prices on a Crypto Assets trading platform. The contract updates the price as each transaction is completed and allows users to query the latest price for a short period of time. However, if the contract design does not take into account the fact that transient storage is automatically cleared at the end of the trade, then the user may get an erroneous or outdated price in the period between the end of one trade and the start of the next. This may not only lead users to make decisions based on misinformation, but it can also be maliciously exploited, affecting the reputation of the platform and the security of users’ assets.
EIP-6780
The proposal changes the previous behavior of the selfdestruct Operation Code, not destroying the contract, only transferring the token, and only the contract created in the same transaction as the self-destruct will be destroyed. The impact of this EIP is relatively large.
Redeploy the contract at the same Address with create 2 to upgrade the contract. This feature is no longer supported and ERC-2535 or another type of proxy contract should be used instead. (This may affect the security of on-chain contracts that use create 2 to implement scalable contracts)
The SELFDESTRUCT operation in the Smart Contract allows the contract to be destroyed and the contract balance is sent to the specified destination Address. In this case, the contract uses SELFDESTRUCT to burn Ether and sends the burned Ether to the contract. However, the contract can only be a contract created in the same transaction (a contract created by this contract or another contract in the same transaction). Otherwise, only the Ether will be transferred without destroying the contract (e.g. self-destructing and the beneficiary is a self-destructing contract, which will not change anything). This will affect any contracts that rely on selfdestruct for withdrawals or other operations.
A gas token similar to the 1inch CHI Token works: keep an offset, always execute CREATE 2 or SELFDESTRUCT at that offset. After this update, if the contract with the current offset has not already self-destructed correctly, the subsequent CREATE 2 will not be able to successfully deploy the contract.
The implementation of this proposal will not lead to a direct attack on the contract, but it will damage the normal logic of the original deployed contract that relies on the selfdestruct operation (the contract that only relies on self-destruct for fund transfer will not be affected, and if the subsequent operation must require the self-destruct contract to be deleted, it will be affected), resulting in the contract not working as intended, and only for the contract and users, it may lead to the contract’s strike, loss of funds and other harms (such as the original use of create 2). Deploy a new contract at the original Address, and the contract that self-destructs the original contract for upgrade can no longer be successfully deployed). In the long run, the ability to modify an Operation Code can lead to centralization problems.
For example, there is an existing vault contract vault to update:
- Create 2 Temporary Storage Contract is used to temporarily reserve funds for the vault
- Self-destruct vault contract, transfer of funds to temporary contract (only funds are transferred, no contract is burned)
- New vault contract at the original Address create 2 (failed because the original vault contract was not destroyed)
- Self-destruct temporary contract to return funds to vault (loss of funds, vault contract was not created)
Read more
The Cancun upgrade will further enhance Ethereum’s competitive advantage. However, this upgrade poses a risk to changes to the core Smart Contract layer, which will affect the secure operation of existing DApps. In the process of Smart Contract development, these changes and the risks that may arise also need to be paid close attention. You can contact Salus for risk checks or audit support, or you can read further to understand the changes.
Cancun Network Upgrade Specification
EIP-1153
EIP-4788
EIP-4844
EIP-5656
EIP-6780
EIP-7516
Metapod contract
GasToken 2 contract
