Create HIP: Add Cancun Opcodes (TSTORE, TLOAD, MCOPY)

HIP/hip-865.md

@@ -0,0 +1,107 @@
+---
+hip: 865
+title: Add EVM Support for transient storage and memory copy Cancun opcodes
+author: Danno Ferrin (@shemnon)
+working-group: Nana Essilfie-Conduah <@nana-ec>
+type: Standards Track
+category: Core
+needs-council-approval: Yes
+status: Draft
+created: 2024-01-24
+discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/872
+---
+
+## 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](https://eips.ethereum.org/EIPS/eip-1153). For the `MCOPY`
+operation they are defined
+in [EIP-5656](https://eips.ethereum.org/EIPS/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](https://eips.ethereum.org/EIPS/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
+
+* [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153): Transient storage opcodes
+* [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656): MCOPY - Memory copying
+  instruction
+
+## Copyright/license
+
+This document is licensed under the Apache License, Version 2.0 --
+see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)