The mainnet will be activated on March 13. What potential risks and security issues will the Cancun upgrade bring?

Mar 4, 10:52

Original source: salus security

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

1.EIP-1153

EIP-1153 introduced 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 "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.

2.EIP-4788

EIP-4788 aims to convert the beacon chain block The hash tree roots are exposed to the EVM to allow access to 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.

3.EIP-4844

EIP-4844 introduces a new transaction format , called "Sharded Blob Transactions," are 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.

4.EIP-5656

EIP-5656 introduces a new EVM instruction MCOPY for Efficiently copy 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.

5.EIP-6780

EIP-6780 Modifies 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.

6.EIP-7516

EIP-7516 introduces a new EVM instruction BLOBBASEFEE , used to return 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 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 per beacon block by up to About 0.75 MB. 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 there is no need to combine blob storage with execution load Just as long. 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 note that their implementations do not use intermediate buffers (e.g. 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 that touch memory, because memory expansion follows the same Pricing rules.

EIP-6780

The following application SELFDESTRUCT will be broken, and in this way Applications using it are no longer safe:

WhereCREATE2 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

EIP1153

Imagine 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, and the data will be released after the execution of a transaction. The written contract is not permanently recorded 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, If smart contract developers do not properly manage the lifecycle of transient storage variables, it can 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, not destroying the contract, only transferring Token, only contracts created in the same transaction as 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 using create2 to implement upgradable contracts)

The SELFDESTRUCT operation in the smart contract allows the contract to be destroyed and the contract The balance is 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 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 contract that relies on the selfdestruct operation (only relying on self-destruction) The contract for fund transfer will not be affected. If the subsequent operation must require the self-destructing contract to be deleted, 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, a contract that originally used create2 to deploy a new contract at the original address and self-destructed 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 to update:

● ; create2 temporary storage contract is used to temporarily reserve vault funds

● Self-destruct the vault contract, and the funds are transferred to the temporary contract (only funds are transferred but No contract destroyed)

● Create2 new vault contract at the original address (failed because the original vault contract has not been destroyed)

● ;The self-destructing temporary contract returns the funds to the vault (funds are lost, the vault contract is not created)

Extended 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 contact Salus for risk review or audit support, or read further to learn about changes.

Cancun Network Upgrade Specification