Cancun upgrade is coming soon, what are the things to pay attention to and potential risks?

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

EIP-1153

EIP-1153 introduces temporary storage opcodes, which are used to operate on 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 "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

EIP-4788 is designed 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 transactions", designed to extend Ethereum in a simple, forward-compatible way Data availability. 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

EIP-5656 introduces a new EVM instruction MCOPY, designed to improve efficient copying of memory areas. This proposal aims to reduce the cost of memory copy operations on the EVM and directly copy data between memories through the MCOPY instruction. MCOPY allows source and target addresses to overlap while taking into account backward compatibility, and aims to optimize execution efficiency in various scenarios such as data structure construction and 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 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. 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 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).

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 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 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 (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.

EIP-6780

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 the contract 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 a SELFDESTRUCT contract as the beneficiary, the contract was not created in the same transaction.

Risks related to smart contracts

EIP1153

Imagine two scenarios using the operation codes TLOAD and TSTORE:

1. The called contract uses this operation Code
2. Use this opcode to initiate a call contract

Risk 1:

Compared with the 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 permanently recorded by the contract 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 cause data to be stored when it should not be Time was cleared or incorrectly retained. 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. 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 upgradeable contracts)

The SELFDESTRUCT operation in a 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 the selfdestruct operation (contracts that only rely on self-destruction for fund transfer 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 there is an existing vault contract vault to update:

• create2 temporary storage contract is used to temporarily reserve the funds of the vault.
• Self-destruct the vault contract and transfer the funds to Temporary contract (only funds were transferred without destroying the contract)
• Create2 new vault contract at the original address (failed because the original vault contract was not destroyed)
• Self-destruct temporary contract to return the funds To vault (loss of funds, vault contract was not created)

The above is the detailed content of Cancun upgrade is coming soon, what are the things to pay attention to and potential risks?. For more information, please follow other related articles on the PHP Chinese website!