Long story short: The Cancun upgrade is approaching. This upgrade mainly includes execution layer 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.
EIP proposal review
Officially disclosed security considerations
Smart contract-related risks
Extended reading
EIP-1153 introduces temporary storage opcodes, which are used to manipulate state and behave almost the same as storage, but Temporary storage will be 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 the "T" stands for "temporary"). This proposal aims to provide a dedicated and efficient solution for communication between multiple nested execution frameworks in Ethereum’s transaction execution.
EIP-4788 is designed to expose the hash tree root of the beacon chain block to the EVM to allow Access these roots inside the smart contract. 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 introduces a new transaction format called "Sharded Blob Transactions" designed to Extend Ethereum’s data availability in a simple, forward-compatible way. This proposal works by introducing "blob-carrying transactions" that contain large amounts of data that cannot be accessed by the EVM execution, but can access its commitments. 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 introduces a new EVM instruction MCOPY for efficient copying of memory areas. This proposal aims to reduce the overhead of performing memory copy operations on the EVM and directly copy data between memories through the MCOPY instruction. MCOPY allows source and destination addresses to overlap. It 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 Modifies the functionality of the SELFDESTRUCT opcode. In this proposal, SELFDESTRUCT will only delete the account and transfer all ether coins in the same transaction as the contract creation. In addition, when executing SELFDESTRUCT, the contract will not be deleted, but all ether coins 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 introduces a new EVM instruction BLOBBASEFEE to return the blob base in the current block execution cost value. This instruction is similar to the BASEFEE opcode in EIP-3198, except that it returns the blob base fee as defined in EIP-4844. This feature allows contracts to programmatically consider 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.
Smart contract developers should understand the life cycle of transient storage variables before use. 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. SSTORE Otherwise, these opcodes behave exactly like SLOAD and SLOAD , so all the usual security considerations apply, especially regarding reentrancy risks.
Smart contract developers may also try to use 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).
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 today's blocks (30M Gas / 16 Gas per calldata byte = 1.875M 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 approximately 18 days, a much shorter delay compared to the recommended (but not yet implemented) one-year rotation for executing payload history.
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. Most of the language built-in/standard library functions for moving bytes have the right performance characteristics here.
Otherwise, the analysis of denial of service (DoS) and memory exhaustion attacks is the same as for other opcodes that touch memory because memory extensions follow the same pricing rules.
The following application SELFDESTRUCT will be broken, and applications using it in this way are no longer safe:
WhereCREATE2 is used to re- Deploy the contract so that it is 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 the SELFDESTRUCT contract as the beneficiary, the contract was not created in the same transaction.
Imagine two scenarios using the operation codes TLOAD and TSTORE:
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, instead of being written to the contract and recorded permanently like sstore. 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 life cycle of transient storage variables, it may result in data being cleared at shouldn’t be or incorrectly reserve. 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.
This proposal changes the behavior of the previous selfdestruct opcode. The contract is not destroyed, only the token is transferred, and only contracts created in the same transaction as the self-destruct will be destroyed. The impact of this EIP is relatively large.
Use create2 to redeploy the contract at the same address 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 create2 to implement upgradable contracts)
The SELFDESTRUCT operation in the smart contract allows the contract to be destroyed and the contract balance sent to the specified target 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 all contracts that rely on selfdestruct for withdrawals or other operations.
A Gas Token similar to the 1inch CHI Token works by maintaining an offset and always executing CREATE2 or SELFDESTRUCT at this offset. After this update, if the contract at the current offset has not correctly self-destructed, subsequent CREATE2 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 The operation must require the self-destructing contract to be deleted, otherwise it will be affected), causing the contract to work unexpectedly. Only for the contract and the user, it may cause the contract to strike, lose funds and other hazards (for example, originally using create2 to deploy a new contract at the original address, A contract that self-destructs the original contract for upgrade can no longer be deployed successfully). In the long run, modifying the functionality of an opcode may lead to centralization issues.
For example, if an existing vault contract vault is updated:
create2 temporary storage contract is used to temporarily reserve vault funds
Self-destruct vault contract, funds are transferred to the temporary contract (only funds are transferred without destroying the contract)
Create2 new vault contract at the original address (failed because the original vault contract has not been Destroy)
Self-destruct temporary contract to return funds to the vault (loss of funds, vault contract not created)
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 contact Salus for risk review or audit support, or read further to learn about changes.
The above is the detailed content of Important safety checks before upgrading in Cancun. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
