Long story short: The Cancun upgrade is approaching, and this upgrade mainly contains executive level changes proposed by 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, reduce transaction costs and increase transaction speed for L2. The Cancun upgrade has been completed on the Ethereum Goerli, Sepolia, and Holesky testnets on January 17, January 30, and February 7 respectively, and is scheduled to be activated on the Ethereum mainnet on March 13. Before upgrading, Salus has compiled important safety precautions for this upgrade for developers to check on their own.
Officially disclosed security considerations
Risks related to smart contracts
EIP Proposal Review
EIP-1153
EIP-1153 introduced temporary storage opcodes, which are used to manipulate state and behave almost the same as storage, but temporary storage is discarded after each transaction. This means that temporary storage does not deserialize values from or serialize values to storage, so temporary storage is less expensive since no disk access is required. Smart contracts can access temporary storage through two new opcodes, TLOAD and TSTORE (where “T” stands for “temporary”). This proposal aims to provide a dedicated and efficient solution for communication between multiple nested execution frameworks in Ethereums 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 smart contracts. This provides trustless access to consensus layer state, supporting multiple 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 requires only constant space to represent this information.
EIP-4844
EIP-4844 introduces a new transaction format called"Sharded Blob Transaction", designed to extend Ethereum’s data availability in a simple, forward-compatible way. This proposal introduces a large amount of data"blob-carrying transactions", this data cannot be accessed by the EVM execution, but its commitments can be accessed. This format is fully compatible with the format used by full sharding in the future, providing temporary but significant relief for rolling expansion.
EIP-5656
EIP-5656 introduces a new EVM instruction MCOPY for efficient copying of memory regions. This proposal aims to reduce the overhead of performing memory copy operations on the EVM by directly copying data between memories through the MCOPY instruction. MCOPY allows source and destination addresses to overlap, is designed with backward compatibility in mind, and aims to improve execution efficiency in a variety of scenarios including data structure construction, efficient access and copying of memory objects.
EIP-6780
EIP-6780 Modified the functionality of the SELFDESTRUCT opcode. In this proposal, SELFDESTRUCT will only delete the account and transfer all ether in the same transaction as the contract was created. In addition, when executing SELFDESTRUCT, the contract will not be deleted, but all ether will be transferred to the specified destination. This change is to adapt to the future use of Verkle trees, aiming to simplify EVM implementation and reduce the complexity of state changes, while retaining some common scenarios of SELFDESTRUCT.
EIP-7516
EIP-7516 introduces a new EVM instruction BLOBBASEFEE that returns the blob base fee value in the current block execution. This command is similar to the BASEFEE opcode from EIP-3198, except that it returns the blob base fee as defined in EIP-4844. This feature allows contracts to programmatically take into account the gas price of blob data, for example, allowing rollup contracts to trustlessly calculate blob data usage costs, or implement blob gas futures based on this to smooth blob data costs.
Officially disclosed security considerations
EIP-1153
Smart contract developers should understand the life cycle 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 within the same transaction (for example, in the case of reentrant locks) or cause other errors, so smart contract developers should be careful to only reserve non-temporary storage slots when they are reserved. Zero value. Intended for use by future calls within the same transaction. Otherwise, these opcodes behave exactly like SSTORE and SLOAD , so all the usual security considerations apply, especially regarding reentrancy risks.
Smart contract developers may also try using transient storage as an alternative to memory mapping. They should be aware that temporary storage is not discarded like memory when a call returns or resumes, and memory should be preferred in these use cases to avoid unexpected behavior on reentrancy within the same transaction. Transient storage costs on memory are necessarily high, which should have discouraged this usage pattern. Most uses of in-memory mapping are better implemented with a key-ordered list of entries, and in-memory mapping is rarely needed in smart contracts (i.e. the authors are aware of no known use cases in production).
EIP-4844
This EIP increases the bandwidth requirements by up to approximately 0.75 MB per beacon block. This is 40% larger than the theoretical maximum size of todays blocks (30 M Gas / 16 Gas per calldata byte = 1.875 M Bytes), so it does not significantly increase worst-case bandwidth. After the merger, block times are static rather than unpredictable Poisson distribution, providing a guaranteed time period for the propagation of large blocks.
Even with limited call data, the sustained load of this EIP is much lower than alternatives that reduce the cost of call data because the blobs do not need to be stored as long as the load is executed. This makes it possible to implement a policy where these blobs must be retained for at least some time. The specific value chosen is the MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epoch, which is about 18 days, which is a much shorter latency than the recommended (but not yet implemented) one-year rotation for executing payload history.
EIP-5656
Clients should be aware that their implementations do not use intermediate buffers (for example, the C stdlibmemmove function does not use intermediate buffers) because this is a potential denial of service (DoS) vector. Most of the language built-in/standard library functions for moving bytes have the correct performance characteristics here.
Otherwise, the analysis of denial-of-service (DoS) and memory exhaustion attacks is the same as for other opcodes touching memory because memory extensions follow the same pricing rules.
EIP-6780
The following application SELFDESTRUCT will be broken, and applications that use it in this way are no longer safe:
WhereCREATE 2 is used to redeploy the contract in the same location to make the contract upgradeable. This feature is no longer supported and ERC-2535 or another type of proxy contract should be used instead.
If a contract relies on burning ether by having a SELFDESTRUCT contract as the beneficiary, the contract was not created in the same transaction.
Risks related to smart contracts
EIP 1153
Consider two scenarios using the opcodes TLOAD and TSTORE:
The called contract uses this opcode
Use this opcode to initiate a call to the contract
Risk 1:
Compared with traditional SSTORE and SLOAD, the new transient storage mainly changes the storage period of data. The data stored in tstore is read through tload. The data will be released after the execution of a transaction, rather than at the same time. Contracts written to sstore are permanently recorded. Developers should recognize the characteristics of this opcode when using it to avoid incorrect use that may cause data to be incorrectly written into the contract and cause losses. In addition, the data in tstore are private variables and can only be accessed by the contract itself. If you want to use the data externally, you can only pass it in the form of parameters or temporarily store it in a public stroage variable.
Risk 2:
Another potential risk is that if smart contract developers do not properly manage the lifetime of transient storage variables, it could result in data being cleared when it should not be or being retained incorrectly. 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 this data, data may be incorrectly shared or lost between calls, resulting in logic errors or Security vulnerabilities. Considering that the balance or allowance data similar to the Token project cannot be stored correctly, it will lead to errors in the contract logic and cause losses. Or using this opcode when setting the owner address will result in the privileged address not being recorded correctly and 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 cryptocurrency exchange. The contract updates the price when each trade 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 feature that transient storage is automatically cleared at the end of a transaction, then users may get an incorrect or outdated transaction during the period from the end of one transaction to the beginning of the next transaction. price. This may not only lead users to make decisions based on wrong information, but may also be used maliciously, affecting the credibility of the platform and the security of users assets.
EIP-6780
This proposal changes the behavior of the previous selfdestruct opcode, which does not destroy the contract, only transfers the token, and only contracts created in the same transaction as the self-destruct will be destroyed. The impact of this EIP is relatively large.
Use create 2 to redeploy the contract at the same address to upgrade the contract. This feature is no longer supported, ERC-2535 or another type of proxy contract should be used instead. (This may affect the use of create 2 to implement upgradable contracts.On-chain contractsecurity)
The SELFDESTRUCT operation in a smart contract allows the contract to be destroyed and the contract balance sent to the specified destination address. In this case, the contract uses SELFDESTRUCT to destroy the ether and sends the destroyed ether to the contract. But the contract can only be a contract created in the same transaction (a contract created by this contract or other contracts in the same transaction). Otherwise, only ether will be transferred without destroying the contract (for example, if it self-destructs and the beneficiary is the self-destructing contract, this will not produce any changes). This will affect everything that relies on selfdestruct for withdrawals or other operations.contract。
A Gas Token similar to the 1inch CHI Token works by maintaining an offset and always executing CREATE 2 or SELFDESTRUCT at this offset. After this update, if the contract at the current offset has not correctly self-destructed, subsequent CREATE 2 will not be able to successfully deploy the contract.
The implementation of this proposal will not lead to direct attacks on the contract, but will damage the normal logic of the originally deployed contracts that rely on selfdestruct operations (contracts that only rely on self-destruction for fund transfers will not be affected. If subsequent operations must require self-destruction If the contract is deleted, it will be affected), causing the contract to work unexpectedly. Only for the contract and the user, it may cause the strike of the contract, loss of funds and other hazards (for example, originally using create 2 to deploy a new contract at the original address, self-destructing the original contract. The upgraded contract can no longer be deployed successfully). In the long run, modifying the functionality of an opcode may lead to centralization issues.
For example, there is an existing vault contract vault to update:
create 2 temporary storage contract is used to temporarily reserve vault funds.
Self-destruct vault contract, funds are transferred to temporary contract (only funds are transferred without destroying the contract)
Create 2 new vault contracts at the original address (failed because the original vault contract was not destroyed)
The self-destructing temporary contract returns the funds to the vault (funds are lost, the vault contract is not created)
Further reading
The Cancun upgrade will further enhance Ethereum’s competitive advantage. However, this upgrade brings risks to the changes to the core smart contract layer, which will affect the safe operation of existing DApps. During the development of smart contracts, these changes and the risks they may cause also require great attention. You can do this withSalusContact for risk review or audit support, or read further to learn about changes.
IOS
Android