From 9674d6934712b571796a90fde6c29f6a4ccd1ce3 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Wed, 24 Jan 2024 11:55:29 -0700 Subject: [PATCH 1/4] Add cancun opcodes HIP to add three Cancun opcodes to the EVM: TSTORE, TLOAD, and MCOPY.. Signed-off-by: Danno Ferrin --- HIP/hip-0000.md | 109 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) create mode 100644 HIP/hip-0000.md diff --git a/HIP/hip-0000.md b/HIP/hip-0000.md new file mode 100644 index 000000000..e443dc4c8 --- /dev/null +++ b/HIP/hip-0000.md @@ -0,0 +1,109 @@ +--- +hip: +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: // TBD +discussions-to: // TBD +updated: +requires: +replaces: +superseded-by: +--- + +## Abstract + +Update the Hedera EVM to add support for new Opcodes found in the Cancun fork of +Ethereum Mainnet, 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). +It is expected that future versions of solidity, Vyper, and other languages +targeting the EVM will support both 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 that may use memory copying implicitly, like what happened with + the `PUSH0` operation. +* 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) \ No newline at end of file From f6d4b2e46ec80c0123c90485ae04cb9c9073b557 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Tue, 30 Jan 2024 12:38:44 -0700 Subject: [PATCH 2/4] Front matter update Signed-off-by: Danno Ferrin --- HIP/{hip-0000.md => hip-865.md} | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) rename HIP/{hip-0000.md => hip-865.md} (94%) diff --git a/HIP/hip-0000.md b/HIP/hip-865.md similarity index 94% rename from HIP/hip-0000.md rename to HIP/hip-865.md index e443dc4c8..deb892493 100644 --- a/HIP/hip-0000.md +++ b/HIP/hip-865.md @@ -1,5 +1,5 @@ --- -hip: +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> @@ -7,12 +7,8 @@ type: Standards Track category: Core needs-council-approval: Yes status: Draft -created: // TBD -discussions-to: // TBD -updated: -requires: -replaces: -superseded-by: +created: 2024-01-24 +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/872 --- ## Abstract From feeeed8321b10e115f1e12a768e05080cf5d2d06 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Fri, 2 Feb 2024 10:06:47 -0700 Subject: [PATCH 3/4] Review comments. Signed-off-by: Danno Ferrin --- HIP/hip-865.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/HIP/hip-865.md b/HIP/hip-865.md index deb892493..89a10e90c 100644 --- a/HIP/hip-865.md +++ b/HIP/hip-865.md @@ -13,7 +13,7 @@ discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discuss ## Abstract -Update the Hedera EVM to add support for new Opcodes found in the Cancun fork of +Update the Hedera network to add support for new Opcodes found in the Cancun fork of Ethereum Mainnet, namely TSTORE, TLOAD, and MCOPY ## Motivation @@ -36,8 +36,7 @@ Because of that we need to support them as specified. * 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 that may use memory copying implicitly, like what happened with - the `PUSH0` operation. + solidity 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. From a14793529374e983a6697d91db38e2bf9dbc51bf Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Tue, 6 Feb 2024 12:37:20 -0700 Subject: [PATCH 4/4] Review comments Signed-off-by: Danno Ferrin --- HIP/hip-865.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/HIP/hip-865.md b/HIP/hip-865.md index 89a10e90c..0fdf4a18d 100644 --- a/HIP/hip-865.md +++ b/HIP/hip-865.md @@ -13,8 +13,9 @@ discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discuss ## Abstract -Update the Hedera network to add support for new Opcodes found in the Cancun fork of -Ethereum Mainnet, namely TSTORE, TLOAD, and MCOPY +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 @@ -27,16 +28,18 @@ the Consensus Layer, or changes to existing opcodes. 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). -It is expected that future versions of solidity, Vyper, and other languages -targeting the EVM will support both implicit and explicit use of these opcodes. -Because of that we need to support them as specified. +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 that may use memory copying implicitly. + 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.