In short: The KanKun upgrade is approaching, and this upgrade mainly includes six EIP-proposed changes at the execution layer, EIP-1153, EIP-4788, EIP-4844, EIP-5656, EIP-6780, and EIP-7516. EIP-4844 is the highlight of this upgrade, aiming to improve Ethereum's scalability, reduce transaction costs, and increase transaction speed for Layer 2. The KanKun upgrade has been completed on the Ethereum Goerli, Sepolia, and Holesky testnets on January 17th, January 30th, and February 7th, respectively, and is scheduled to be activated on the Ethereum mainnet on March 13th. Prior to the upgrade, Salus has compiled important security considerations for this upgrade for developers to check on their own.
Official Disclosure of Security Considerations
EIP Proposal Review
EIP-1153
EIP-1153 introduces temporary storage opcodes, which are used to manipulate state and behave almost identically to storage, but temporary storage is discarded after each transaction, meaning it does not deserialize values from storage or serialize values to storage, resulting in lower costs due to no disk access. With two new opcodes, TLOAD and TSTORE (where "T" stands for "temporary"), smart contracts can access temporary storage. This proposal aims to provide a dedicated and efficient solution for communication between multiple nested execution frames in Ethereum's transaction execution.
EIP-4788
EIP-4788 aims to expose the hash tree root of beacon chain blocks to the EVM, allowing these roots to be accessed within smart contracts without trust. This supports various use cases such as staking pools, restaking structures, smart contract bridges, and MEV mitigation. The proposal involves a smart contract storing these roots and using a circular buffer to limit storage consumption, ensuring that each execution block only requires constant space to represent this information.
EIP-4844
EIP-4844 introduces a new transaction format called "shard Blob transactions" to extend Ethereum's data availability in a simple, forward-compatible manner. This proposal introduces "blob-carrying transactions" containing a large amount of data that cannot be accessed by EVM execution but can access its commitment. This format is fully compatible with the format used by future full shards, providing a temporary but significant relief for rollup scaling.
EIP-5656
EIP-5656 introduces a new EVM instruction, MCOPY, for efficient copying of memory areas. This proposal aims to reduce the cost of memory copy operations on the EVM by directly copying data between memories. MCOPY allows overlapping source and destination addresses, designed with backward compatibility in mind, and aims to improve the efficiency of various scenarios including data structure construction, efficient access to memory objects, and copying.
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 creation, without deleting the contract. This change is to accommodate the future use of Verkle trees, simplify EVM implementation, reduce the complexity of state changes, while retaining some common use cases of SELFDESTRUCT.
EIP-7516
EIP-7516 introduces a new EVM instruction, BLOBBASEFEE, to return the current block's blob base fee value during execution. This instruction is similar to the BASEFEE opcode defined by EIP-3198, but it returns the blob base fee defined by EIP-4844. This feature allows contracts to programmatically consider the gas price of blob data, enabling rollup contracts to calculate the cost of blob data usage without trust, or implement blob gas futures based on this to smooth out blob data costs.
Official Disclosure of Security Considerations
EIP-1153
Smart contract developers should understand the lifecycle of transient storage variables before use. Since temporary storage is automatically cleared at the end of a transaction, developers may attempt 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 reentrancy locks) or lead to other errors. Developers should be cautious and only retain non-zero values when slots are preserved for future calls within the same transaction. Otherwise, the behavior of these opcodes is identical to SLOAD and SSTORE, so all common security considerations apply, especially regarding reentrancy risks.
Smart contract developers may also attempt to use transient storage as an alternative to memory mapping. They should be aware that transient storage is not discarded like memory upon return or restoration, and memory should be prioritized in these use cases to avoid unexpected behavior during reentrancy in the same transaction. The cost of transient storage in memory is inevitably high, which should have already prevented this usage pattern. Most uses of memory mapping can be better implemented by sorting entries in a list and there are few known use cases for memory mapping in smart contracts.
EIP-4844
This EIP increases the bandwidth requirement for each beacon block by up to approximately 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 will not significantly increase bandwidth in worst-case scenarios. After merging, block time is static rather than unpredictably Poisson distributed, providing a guaranteed time window for the propagation of large blocks.
Even with limited call data, the sustained load of this EIP is much lower than alternative solutions that could reduce the cost of call data, as blob storage does not need to be retained for as long as execution load. This makes it possible to implement strategies that must retain these blobs for at least a period of time. The specific value chosen is MINEPOCHSFORBLOBSIDECARS_REQUESTS, approximately 18 days, much shorter than the proposed (but not yet implemented) one-year rotation time for executing payload history.
EIP-5656
Clients should ensure that their implementations do not use intermediate buffers (e.g., C stdlib memmove function does not use intermediate buffers), as this is a potential denial of service (DoS) vector. Most language built-in functions/standard library functions for moving bytes have the correct performance characteristics here.
In addition, analysis of denial of service (DoS) and memory exhaustion attacks is the same as for other memory-touching opcodes, as memory expansion follows the same pricing rules.
EIP-6780
Applications using SELFDESTRUCT will be disrupted, and applications using it in this way are no longer secure:
WhereCREATE2 is used to redeploy contracts at the same address to make the contract upgradeable. This feature is no longer supported and should be replaced with ERC-2535 or other types of proxy contracts.
If a contract relies on burning ether by using a SELFDESTRUCT contract as the beneficiary, the contract is not created in the same transaction.
Smart Contract Related Risks
EIP1153
Consider two scenarios for using the TLOAD and TSTORE opcodes:
The called contract uses these opcodes.
The calling contract uses these opcodes.
Risk 1:
Compared to traditional SSTORE and SLOAD, the newly added transient storage mainly changes the storage duration of data. Data stored with TSTORE is read using TLOAD and will be released after the transaction execution, instead of being permanently recorded in the contract like SSTORE. Developers should be aware of the characteristics of these opcodes to avoid incorrect usage that could result in data not being correctly written to the contract, leading to losses. Additionally, data stored with TSTORE is private and can only be accessed by the contract itself. If external access to this data is required, it can only be done through parameter passing or temporary storage in a public storage variable.
Risk 2:
Another potential risk is if smart contract developers do not manage the lifecycle of transient storage variables correctly, it may lead to data being cleared at the wrong time or retained incorrectly. If a contract expects to use data stored in transient storage in subsequent calls but fails to manage the lifecycle of this data properly, it may inadvertently share or lose data between different calls, leading to logic errors or security vulnerabilities. For example, failure to correctly store data such as balances or allowances in a token project could lead to contract logic errors and losses. Similarly, using this opcode to set the owner address could result in the privileged address not being correctly recorded, leading to the loss of important contract parameters.
Consider a smart contract that uses transient storage to temporarily record the transaction price on a cryptocurrency trading platform. The contract updates the price after each transaction and allows users to query the latest price within a short period. However, if the contract design does not consider the automatic clearing of transient storage after a transaction, users may receive an incorrect or outdated price during the time between the end of one transaction and the beginning of the next. This could not only lead to users making decisions based on incorrect information but could also be exploited maliciously, affecting the platform's reputation and user asset security.
EIP-6780
This proposal changes the behavior of the previous selfdestruct opcode, where the contract is not destroyed, only tokens are transferred, and the contract is only destroyed in the same transaction as its creation. The impact of this EIP is relatively significant.
Using create2 to redeploy contracts at the same address for upgradability is no longer supported and should be replaced with ERC-2535 or other types of proxy contracts. (This may affect the security of on-chain contracts that implement upgradable contracts using create2, such as this contract).
The SELFDESTRUCT operation in smart contracts allows the contract to be destroyed and the contract balance to be sent to a specified target address. In this case, the contract uses SELFDESTRUCT to destroy ether and transfer the destroyed ether to the contract. However, this contract can only be created in the same transaction as the self-destructing contract (a contract created in the same transaction by this contract or another contract). Otherwise, only ether will be transferred without destroying the contract (e.g., self-destruct with the beneficiary being the self-destructing contract, which will not produce any changes). This will affect any contracts that rely on selfdestruct for withdrawals or other operations, such as this contract.
The operation of a Gas Token similar to 1inch CHI Token: maintaining an offset that always executes CREATE2 or SELFDESTRUCT at this offset. After this update, if the contract at the current offset has not been correctly self-destructed, subsequent CREATE2 operations will not be able to deploy contracts successfully.
The implementation of this proposal does not directly lead to attacks on contracts, but it will disrupt the normal logic of existing contracts that rely on the selfdestruct operation (contracts that rely solely on self-destruction for fund transfers are not affected, but if subsequent operations require the self-destructed contract to be deleted, they will be affected), leading to unexpected behavior of contracts. This could potentially lead to contract downtime, fund loss, and other risks for contracts and users (e.g., contracts that originally used create2 to deploy new contracts at the original address and self-destruct the original contract for upgrades will no longer be able to deploy successfully). In the long run, modifying the functionality of an opcode may lead to centralization issues.
For example, consider an existing vault contract that is being updated:
Temporary storage contracts are used to temporarily reserve funds for the vault.
The vault contract is self-destructed, and funds are transferred to the temporary contract (only funds are transferred without destroying the contract).
A new vault contract is created using create2 at the original address (fails because the original vault contract has not been destroyed).
The temporary contract is self-destructed to return the funds to the vault (funds are lost, and the vault contract is not created).
Further Reading
The Cancun upgrade will further enhance Ethereum's competitive advantage. However, the changes to the core smart contract layer in this upgrade bring risks that will affect the secure operation of existing DApps. These changes and the potential risks they may bring need to be closely monitored during the process of smart contract development. You can contact Salus for risk checks or audit support, and further reading on related content to understand the changes.
Cancun Network Upgrade Specification
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
