HIP-865: Add EVM Support for transient storage and memory copy Cancun opcodes
| Author | Danno Ferrin |
|---|---|
| Working Group | Nana Essilfie-Conduah |
| Requested By | EVM Developers |
| Discussions-To | https://github.com/hashgraph/hedera-improvement-proposal/discussions/872 |
| Status | Final ⓘ |
| Needs Council Approval | Yes ⓘ |
| Review period ends ⓘ | Wed, 06 Mar 2024 07:00:00 +0000 |
| Type | Standards Track ⓘ |
| Category | Core ⓘ |
| Created | 2024-01-24 |
| Updated | 2024-06-24 |
| Release | 0.50.1 |
Table of Contents
Abstract
Update the Hedera network to add support for new Opcodes found in the Cancun fork of Ethereum Mainnet unrelated to EIP-4844 support, namely TSTORE, TLOAD, and MCOPY
Motivation
Hedera’s goal of EVM Equivalence also includes the requirement to stay up-to-date with the current state of Ethereum Mainnet. This HIP addresses new opcodes added to the EVM that do not address any features relating to Blobs, or the Consensus Layer, or changes to existing opcodes.
Rationale
The opcodes discussed in this HIP only exist within the EVM and do not interact with any novel features of ethereum mainnet (such as blobs and CL beacon root). The current version of Solidity may generate these opcodes with non-standard CLI options. It is expected in the near future those options will be defaults. Other languages are expected to follow a similar path with eventual implicit and explicit use of these opcodes. Because of that we need to support them as specified.
User stories
- As a smart contract author, I want to be able to use transient storage features of solidity in my hedera smart contracts.
- As a smart contract author, I want to be able to use future versions of Solidity, Vyper, Fe, et al. that may use memory copying implicitly.
- As a smart contract author, I want to be able to explicitly use the memory copy features solidity may expose in future releases.
Specification
EVM Implementation
Two EIPs define the operational semantics of the added opcodes. For the
transient storage opcodes TSTORE and TLOAD they are defined
in EIP-1153. For the MCOPY
operation they are defined
in EIP-5656.
The specified opcodes are to be implemented identically to Ethereum Mainnet and as specified in their respective EIPs. This includes opcode numbers, gas schedules, stack semantics, and new facilities such as transient storage added to the execution frame.
Backwards Compatibility
The core EVM library shipping with Hedera as of version 0.46 already contains the needed EVM support. The activation will add a new Hedera EVM version that will activate all the Cancun support in one release.
Security Implications
Because the operations are being brought in with identical semantics there are no security risks above those already present from existing Ethereum Equivalence changes.
How to Teach This
Any smart contract tutorials will want to examine the possibility of adding sample contracts showcasing the use of transient storage and easy memory copying. Ideally these could be sourced from existing Ethereum Tutorials as the features are fairly well anticipated in the Ethereum community.
Reference Implementation
// TBD
Rejected Ideas
No ideas were rejected around these three opcodes, aside from not supporting Cancun features.
The idea of supporting EIP-4788: Beacon block root in the EVM was rejected because there is no EL/CL separation in Hedera. If we wanted to support similar hash storage ideas we would want to mine a different address.
Open Issues
// none
References
Copyright/license
This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)
Citation
Please cite this document as: