From fc74ecc75f1a1a542ac920a498d9d3669d0f784f Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Tue, 26 Dec 2023 23:48:16 -0700 Subject: [PATCH 1/4] rough draft of first 2 Cancun HIPs --- HIP/hip-0000-cancun-1.md | 81 +++++++++++++++++++++++++++++++++ HIP/hip-0000-cancun-2.md | 96 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 177 insertions(+) create mode 100644 HIP/hip-0000-cancun-1.md create mode 100644 HIP/hip-0000-cancun-2.md diff --git a/HIP/hip-0000-cancun-1.md b/HIP/hip-0000-cancun-1.md new file mode 100644 index 000000000..b137a1545 --- /dev/null +++ b/HIP/hip-0000-cancun-1.md @@ -0,0 +1,81 @@ +--- +hip: +title: Add EVM Support for new non-blob Cancun opcodes +author: Danno Ferrin (@shemnon) +working-group: // TBD +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 Ethereum 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. It is expected that future versions of solidity 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. + +### Hedera Activation + +The operations will be added into a new EVM version of Hedera (notionally version 0.50, but subject to change), like the versions added for Shanghai support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled into this EVM version. + +## 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 + +While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. + +## 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) diff --git a/HIP/hip-0000-cancun-2.md b/HIP/hip-0000-cancun-2.md new file mode 100644 index 000000000..b546566b9 --- /dev/null +++ b/HIP/hip-0000-cancun-2.md @@ -0,0 +1,96 @@ +--- +hip: +title: Add EVM compatibility for non-supported Cancun blob features. +author: Danno Ferrin (@shemnon) +working-group: // TBD +type: Standards Track +category: Core +needs-council-approval: Yes +status: Draft +created: // TBD +discussions-to: // TBD +updated: +requires: +replaces: +superseded-by: +--- + +## Abstract + +Add compatibility for Ethereum Mainnet Cancun features relating to Hedera's non-support of EIP-4844 blobs. + +## Motivation + +In order to maintain maximum compatibility with Ethereum Mainnet there will need to be support for some Blob opcodes in the EVM that behave appropriately in the absence of Blobs support in Hedera. At the same time, space needs to be preserved in the event Hedera provides similar Blob functionality that needs to be mapped to the EIP-4844 facilities. + +## Rationale + +In order to both preserve compatibility and future design space we need to act as if blobs are not being added to Hedera. This allows existing contracts that may depend on blob behavior to continue to function in the absence of blobs. + +First we will prevent blobs from entering the system. There are complex EL/CL interactions in Ethereum Mainnet, but as far as Hedera's consensus is similar to Ethereum Mainnet's, the main entry point is a "Type 3" transaction that allows blobs to be attached. Furthermore, Type 3 transactions require a blob to be attached. Prohibiting Type 3 transactions will thus be sufficient to keep blobs form entering the EVM's realm of concern and similarly will not prohibit other interactions that are desirable to Hedera. + +Second, we need to support the new opcodes but ensure they operate as they would in the absence of any Blobs. + +## User stories + +* As a smart contract deployer, I want my smart contract that expects blob support to not fail in unexpected ways. +* As a smart contract user, I will not be able to successfully use contracts that depend on the presence of blobs. +* As a future Hedera Core developer, I want the option to provide blob like behavior using EIP-4844 semantics and existing opcodes. + +## Specification + +### EVM Implementation + +Two opcodes need to be supported. The `VERSIONEDHASH` opcode defined in [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) and the `BLOBBASEFEE` operation in [EIP-7516](https://eips.ethereum.org/EIPS/eip-7516). These opcodes should behave in the same way as though there are no blobs and that there never have been blobs. + +For `VERSIONEDHASH` this will result in returning all zeros whenever called, as there are no versioned hashes in the current transaction. This is the behavior if called from a legacy, Type 1, or Type 2 operation. + +For `BLOBBASEFEE` this will result in returning `1` at all times, as the blob gas cost cannot adjust below 1. This will require updating the `TxValues` object with a blob fee of `1`. + +### Hedera Services Implementation + +The `EthereumTransaction` transaction type in Hedera will need to reject all type 3 transactions as invalid. The services should not need to parse the transactions at this time as all Type 3 transactions will be rejected. + +This behavior should be automatic in current implementation, as all unrecognized types are rejected. To verify this system tests should be updated to add a valid Type 3 transaction and an invalid transaction starting with the bytes `0x03`. + +### JSON-RPC Relay Implementation + +The JSON-RPC relay will need to be updated to reject type 3 transactions. There are two main locations this could be seen. The `eth_sendRawTransaction` call may receive fully formed Type 3 transactions. Those should be detected and rejected with a specific error message. We could parse the transaction and ensure it is a well-formed Type 3 transaction and provide different rejection messages. For now this will be a distinction without a difference as both valid and invalid Type 3 transactions will be rejected. + +Second, we will begin to see calls to the simulation and estimation APIs (`eth_estimateGas`, `eth_call`) that may include fields indicating it is a blob transaction. In those cases we should similarly detect that a blob transaction is being simulated and reject the transaction before sending it to the simulation and estimation engines. + +### Hedera Activation + +The operations will be added into a new EVM version of Hedera (notionally version 0.50, but subject to change), like the versions added for Shanghai support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled into this EVM version. + +## 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. The generation of the call frame will need to be updated to set the BlobGasFee to 1. In prior EVM versions this change will not be accessible. + +## Security Implications + +It is expected that disabling blobs in this fashion will not result in any new or novel attacks against Hedera or the EVM subsystem. + +## How to Teach This + +User documentation will need a section discussing Ethereum Mainnet Blobs. It needs to be made clear that blobs are not supported and that the support of the two opcodes is meant as an affordance to systems that may introduce them in contracts that do not actually require blobs to function correctly, such as Layer 2 contracts. No tutorials should need to be updated as no useful features are exposed. + +## Reference Implementation + +//TODO + +## Rejected Ideas + +The idea of supporting blobs via the Hedera Consensus Service was briefly considered. Two major blockers made this inviable: (a) HCS messages are limited to the Hedera transaction size (6 Kib total) and (b) there is no way currently to sync consensus messages to the EVM, which may be necessary to ensure the versioned hash matches data submitted to the consensus system. Future research efforts may result in support of blobs. + +## Open Issues + +While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. + +## References + +A collections of URLs used as references through the HIP. + +## 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) From 6648a1126c35c04828dd09bdf6838d19746ecd24 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Mon, 8 Jan 2024 15:48:15 -0700 Subject: [PATCH 2/4] KZG precompile hip --- HIP/hip-0000-cancun-1.md | 76 ++++++++++++++++------- HIP/hip-0000-cancun-2.md | 105 +++++++++++++++++++++++++------- HIP/hip-0000-cancun-3.md | 126 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 263 insertions(+), 44 deletions(-) create mode 100644 HIP/hip-0000-cancun-3.md diff --git a/HIP/hip-0000-cancun-1.md b/HIP/hip-0000-cancun-1.md index b137a1545..9402adffc 100644 --- a/HIP/hip-0000-cancun-1.md +++ b/HIP/hip-0000-cancun-1.md @@ -3,10 +3,10 @@ hip: title: Add EVM Support for new non-blob Cancun opcodes author: Danno Ferrin (@shemnon) working-group: // TBD -type: Standards Track -category: Core +type: Standards Track +category: Core needs-council-approval: Yes -status: Draft +status: Draft created: // TBD discussions-to: // TBD updated: @@ -17,45 +17,73 @@ 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 +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 Ethereum 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. +Hedera's goal of Ethereum 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. It is expected that future versions of solidity will support both implicit and explicit use of these opcodes. Because of that we need to support them as specified. +The opcodes discussed in this HIP only exist within the EVM and do not interact +with any novel features of ethereum mainnet. It is expected that future versions +of solidity 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. - +* 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). +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. +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. ### Hedera Activation -The operations will be added into a new EVM version of Hedera (notionally version 0.50, but subject to change), like the versions added for Shanghai support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled into this EVM version. +The operations will be added into a new EVM version of Hedera (notionally +version 0.50, but subject to change), like the versions added for Shanghai +support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled +into this EVM version. ## 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. +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. +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. +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 @@ -63,19 +91,25 @@ Any smart contract tutorials will want to examine the possibility of adding samp ## Rejected Ideas -No ideas were rejected around these three opcodes, aside from not supporting Cancun features. +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. +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 -While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. +// 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 +* [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) +This document is licensed under the Apache License, Version 2.0 -- +see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) diff --git a/HIP/hip-0000-cancun-2.md b/HIP/hip-0000-cancun-2.md index b546566b9..29aa9ccef 100644 --- a/HIP/hip-0000-cancun-2.md +++ b/HIP/hip-0000-cancun-2.md @@ -17,63 +17,115 @@ superseded-by: ## Abstract -Add compatibility for Ethereum Mainnet Cancun features relating to Hedera's non-support of EIP-4844 blobs. +Add compatibility for Ethereum Mainnet Cancun features relating to Hedera's +non-support of EIP-4844 blobs. ## Motivation -In order to maintain maximum compatibility with Ethereum Mainnet there will need to be support for some Blob opcodes in the EVM that behave appropriately in the absence of Blobs support in Hedera. At the same time, space needs to be preserved in the event Hedera provides similar Blob functionality that needs to be mapped to the EIP-4844 facilities. +In order to maintain maximum compatibility with Ethereum Mainnet there will need +to be support for some Blob opcodes in the EVM that behave appropriately in the +absence of Blobs support in Hedera. At the same time, space needs to be +preserved in the event Hedera provides similar Blob functionality that needs to +be mapped to the [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) facilities. ## Rationale -In order to both preserve compatibility and future design space we need to act as if blobs are not being added to Hedera. This allows existing contracts that may depend on blob behavior to continue to function in the absence of blobs. +In order to both preserve compatibility and future design space we need to act +as if blobs are not being added to Hedera. This allows existing contracts that +may depend on blob behavior to continue to function in the absence of blobs. -First we will prevent blobs from entering the system. There are complex EL/CL interactions in Ethereum Mainnet, but as far as Hedera's consensus is similar to Ethereum Mainnet's, the main entry point is a "Type 3" transaction that allows blobs to be attached. Furthermore, Type 3 transactions require a blob to be attached. Prohibiting Type 3 transactions will thus be sufficient to keep blobs form entering the EVM's realm of concern and similarly will not prohibit other interactions that are desirable to Hedera. +First we will prevent blobs from entering the system. There are complex EL/CL +interactions in Ethereum Mainnet, but as far as Hedera's consensus is similar to +Ethereum Mainnet's, the main entry point is a "Type 3" transaction that allows +blobs to be attached. Furthermore, Type 3 transactions require a blob to be +attached. Prohibiting Type 3 transactions will thus be sufficient to keep blobs +form entering the EVM's realm of concern and similarly will not prohibit other +interactions that are desirable to Hedera. -Second, we need to support the new opcodes but ensure they operate as they would in the absence of any Blobs. +Second, we need to support the new opcodes but ensure they operate as they would +in the absence of any Blobs. ## User stories -* As a smart contract deployer, I want my smart contract that expects blob support to not fail in unexpected ways. -* As a smart contract user, I will not be able to successfully use contracts that depend on the presence of blobs. -* As a future Hedera Core developer, I want the option to provide blob like behavior using EIP-4844 semantics and existing opcodes. +* As a smart contract deployer, I want my smart contract that expects blob + support to not fail in unexpected ways. +* As a smart contract user, I will not be able to successfully use contracts + that depend on the presence of blobs. +* As a future Hedera Core developer, I want the option to provide blob like + behavior using EIP-4844 semantics and existing opcodes. ## Specification ### EVM Implementation -Two opcodes need to be supported. The `VERSIONEDHASH` opcode defined in [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) and the `BLOBBASEFEE` operation in [EIP-7516](https://eips.ethereum.org/EIPS/eip-7516). These opcodes should behave in the same way as though there are no blobs and that there never have been blobs. +Two opcodes need to be supported. The `VERSIONEDHASH` opcode defined +in EIP-4844 and the `BLOBBASEFEE` +operation in [EIP-7516](https://eips.ethereum.org/EIPS/eip-7516). These opcodes +should behave in the same way as though there are no blobs and that there never +have been blobs. -For `VERSIONEDHASH` this will result in returning all zeros whenever called, as there are no versioned hashes in the current transaction. This is the behavior if called from a legacy, Type 1, or Type 2 operation. +For `VERSIONEDHASH` this will result in returning all zeros whenever called, as +there are no versioned hashes in the current transaction. This is the behavior +if called from a legacy, Type 1, or Type 2 operation. -For `BLOBBASEFEE` this will result in returning `1` at all times, as the blob gas cost cannot adjust below 1. This will require updating the `TxValues` object with a blob fee of `1`. +For `BLOBBASEFEE` this will result in returning `1` at all times, as the blob +gas cost cannot adjust below 1. This will require updating the `TxValues` object +with a blob fee of `1`. ### Hedera Services Implementation -The `EthereumTransaction` transaction type in Hedera will need to reject all type 3 transactions as invalid. The services should not need to parse the transactions at this time as all Type 3 transactions will be rejected. +The `EthereumTransaction` transaction type in Hedera will need to reject all +type 3 transactions as invalid. The services should not need to parse the +transactions at this time as all Type 3 transactions will be rejected. -This behavior should be automatic in current implementation, as all unrecognized types are rejected. To verify this system tests should be updated to add a valid Type 3 transaction and an invalid transaction starting with the bytes `0x03`. +This behavior should be automatic in current implementation, as all unrecognized +types are rejected. To verify this system tests should be updated to add a valid +Type 3 transaction and an invalid transaction starting with the bytes `0x03`. ### JSON-RPC Relay Implementation -The JSON-RPC relay will need to be updated to reject type 3 transactions. There are two main locations this could be seen. The `eth_sendRawTransaction` call may receive fully formed Type 3 transactions. Those should be detected and rejected with a specific error message. We could parse the transaction and ensure it is a well-formed Type 3 transaction and provide different rejection messages. For now this will be a distinction without a difference as both valid and invalid Type 3 transactions will be rejected. +The JSON-RPC relay will need to be updated to reject type 3 transactions. There +are two main locations this could be seen. The `eth_sendRawTransaction` call may +receive fully formed Type 3 transactions. Those should be detected and rejected +with a specific error message. We could parse the transaction and ensure it is a +well-formed Type 3 transaction and provide different rejection messages. For now +this will be a distinction without a difference as both valid and invalid Type 3 +transactions will be rejected. -Second, we will begin to see calls to the simulation and estimation APIs (`eth_estimateGas`, `eth_call`) that may include fields indicating it is a blob transaction. In those cases we should similarly detect that a blob transaction is being simulated and reject the transaction before sending it to the simulation and estimation engines. +Second, we will begin to see calls to the simulation and estimation +APIs (`eth_estimateGas`, `eth_call`) that may include fields indicating it is a +blob transaction. In those cases we should similarly detect that a blob +transaction is being simulated and reject the transaction before sending it to +the simulation and estimation engines. ### Hedera Activation -The operations will be added into a new EVM version of Hedera (notionally version 0.50, but subject to change), like the versions added for Shanghai support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled into this EVM version. +The operations will be added into a new EVM version of Hedera (notionally +version 0.50, but subject to change), like the versions added for Shanghai +support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled +into this EVM version. ## 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. The generation of the call frame will need to be updated to set the BlobGasFee to 1. In prior EVM versions this change will not be accessible. +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. The generation of the call +frame will need to be updated to set the BlobGasFee to 1. In prior EVM versions +this change will not be accessible. ## Security Implications -It is expected that disabling blobs in this fashion will not result in any new or novel attacks against Hedera or the EVM subsystem. +It is expected that disabling blobs in this fashion will not result in any new +or novel attacks against Hedera or the EVM subsystem. ## How to Teach This -User documentation will need a section discussing Ethereum Mainnet Blobs. It needs to be made clear that blobs are not supported and that the support of the two opcodes is meant as an affordance to systems that may introduce them in contracts that do not actually require blobs to function correctly, such as Layer 2 contracts. No tutorials should need to be updated as no useful features are exposed. +User documentation will need a section discussing Ethereum Mainnet Blobs. It +needs to be made clear that blobs are not supported and that the support of the +two opcodes is meant as an affordance to systems that may introduce them in +contracts that do not actually require blobs to function correctly, such as +Layer 2 contracts. No tutorials should need to be updated as no useful features +are exposed. ## Reference Implementation @@ -81,16 +133,23 @@ User documentation will need a section discussing Ethereum Mainnet Blobs. It ne ## Rejected Ideas -The idea of supporting blobs via the Hedera Consensus Service was briefly considered. Two major blockers made this inviable: (a) HCS messages are limited to the Hedera transaction size (6 Kib total) and (b) there is no way currently to sync consensus messages to the EVM, which may be necessary to ensure the versioned hash matches data submitted to the consensus system. Future research efforts may result in support of blobs. +The idea of supporting blobs via the Hedera Consensus Service was briefly +considered. Two major blockers made this inviable: (a) HCS messages are limited +to the Hedera transaction size (6 Kib total) and (b) there is no way currently +to sync consensus messages to the EVM, which may be necessary to ensure the +versioned hash matches data submitted to the consensus system. Future research +efforts may result in support of blobs. ## Open Issues -While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. +// none ## References -A collections of URLs used as references through the HIP. +* [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844): Shard Blob Transactions +* [EIP-7516](https://eips.ethereum.org/EIPS/eip-7516): BLOBBASEFEE opcode ## 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) +This document is licensed under the Apache License, Version 2.0 -- +see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) diff --git a/HIP/hip-0000-cancun-3.md b/HIP/hip-0000-cancun-3.md new file mode 100644 index 000000000..80c8767c7 --- /dev/null +++ b/HIP/hip-0000-cancun-3.md @@ -0,0 +1,126 @@ +--- +hip: +title: Add Smart Contract Services Support for KZG Point Evaluation Precompiled Function +author: Danno Ferrin (@shemnon) +working-group: // TBD +type: Standards Track +category: Core +needs-council-approval: Yes +status: Draft +created: // TBD +discussions-to: // TBD +updated: +requires: +replaces: +superseded-by: +--- + +## Abstract + +Add the Ethereum KZG Point Evaluation Precompile from EIP-4844: Shard Blob +Transactions. + +## Motivation + +One part of [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) is the KZG Point +Evaluation function, a cryptographic precompile that can be used un zero +knowledge proofs as well as proving that certain subsections of a blob are +present without introducing the entire blob. This precompile adds value to the +other parts of EIP-4844, but it does not require them. Hedera will expose +support for this precompile without introducing other parts of the EIP. + +## Rationale + +While Hedera will not be supporting most EIP-4844 features the KZG Point +Evaluation Precompile is cleanly severable from the other integrated features. +This precompile, when accompanied by the associated trusted setup, can be viewed +as a cryptographic primitive similar to ECDSA. The ability to proved subsets of +hashed data provides unique functionality not found in other cryptographic +precompiles. Ethereum apps may use the KZG features without any interation with +blob varying transactions, and it makes sense to allow Hedera Smart Contract +apps the same latitude. + +This precompile will be brought in with the same semantics and calling +conventions as Ethereum Mainnet. The trusted setup from Ethereum Mainnet will +also be used. + +## User stories + +* As a smart contract developer I want to use the EIP-4844 Point Evaluation + Precompile in my smart contract applications. + +## Specification + +There are no changes needed to Hedera Services and the JSON-RPC relay. + +### EVM Implementation + +The [KZG Point Evaluation precompile](https://eips.ethereum.org/EIPS/eip-4844#point-evaluation-precompile) +will be implemented as it is in EIP-4844. + +The address for the precompile will be the same as Ethereum +Mainnet (`0x000000000000000000000000000000000000000A`). + +The point evaluation will use teh +same [trusted setup](https://github.com/ethereum/c-kzg-4844/blob/main/src/trusted_setup.txt) +as Ethereum Mainnet. + +### Hedera Activation + +The precompile will be added into a new EVM version of Hedera (notionally +version 0.50, but subject to change), like the versions added for Shanghai +support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled +into this EVM version. + +## 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. The precompile should +automatically be part of the Besu EVM Library implementation. + +## Security Implications + +It is expected the gas cost of the precompile will fall in line with compute +usage during the execution. Performance tests will need to be executed to +validate that heavy use of the precompile matches this expectation. + +## How to Teach This + +User documentation that discusses available precompiled contracts will need to +be updated to reflect the presence of this precompile. Because this is a feature +using cutting edge cryptography there should be no need for tutorials. +References to Ethereum specifications may be useful, but it is expected users +using this feature will already be familiar with the function. + +## Reference Implementation + +The Besu EVM Library uses +the [Java bindings for c-kzg-4844](https://github.com/ethereum/c-kzg-4844/blob/main/bindings/java/README.md). + +## Rejected Ideas + +The only two ideas granted serious consideration were either full inclusion of +the feature or full exclusion of the feature. The idea of doing our own trusted +setup would (a) provide incompatibilities with developer tools, (b) be +time-consuming or (c) lack credible neutrality. + +The decision to include the precompile over exclusion is predicated on the +anticipation that some zero knowledge systems will be able to use the +precompile. + +## Open Issues + +// none + +## References + +* [c-kgz-4844](https://github.com/ethereum/c-kzg-4844) reference implementation +* [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844): Shard Blob Transactions + +A collections of URLs used as references through the HIP. + +## 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) From cf3723fd4f4e06bdc39e17053648e6076544931a Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Fri, 12 Jan 2024 11:25:38 -0700 Subject: [PATCH 3/4] transient selfdestruct hip --- HIP/hip-0000-cancun-4.md | 163 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 163 insertions(+) create mode 100644 HIP/hip-0000-cancun-4.md diff --git a/HIP/hip-0000-cancun-4.md b/HIP/hip-0000-cancun-4.md new file mode 100644 index 000000000..00c49fd9c --- /dev/null +++ b/HIP/hip-0000-cancun-4.md @@ -0,0 +1,163 @@ +--- +hip: +title: Support Cancun Self-Destruct Semantics in Smart Contract Services +author: Danno Ferrin (@shemnon) +working-group: // TBD +type: Standards Track +category: Core +needs-council-approval: Yes +status: Draft +created: // TBD +discussions-to: // TBD +updated: +requires: +replaces: +superseded-by: +--- + +## Abstract + +Add support for EIP-6780 SELFDESTRUCT semantics while supporting the Hedera +account model. + +## Motivation + +Ethereum Equivalence requires that Hedera add features supported by Ethereum +Mainnet (mapped to Hedera semantics). This effort also spans to the rare +occasion that Ethereum removes features from the EVM. + +In this case Ethereum is wanting to remove the SELFDESTRUCT opcode in order to +make future upgrades achievable. The removal of all contract state as part of +self-destruction would make future data model changes prohibitively expensive. +However, there were a number of contracts that depended on side effects of +SELFDESTRUCT not related to the contract storage and contract code removal, +namely the transfer of Ether to a beneficiary address. Similarly, some DeFi +usage patterns used "transient" contracts to store data between calls within the +same transaction, and self-destruction was key to being a good citizen and not +leaving garbage around. + +To reduce the damage that would occur from simply disabling the opcode Ethereum +decided to change the behavior of SELFDESTRUCT depending on the age of the +contract. If the contract existed prior to the start of the transaction the +operation would change so that neither the code nor the storage was deleted, but +the ether balance would be sent to the beneficiary. This moved the operation +into a "sweep" operation that allowed contracts to clean up all balance without +having to query it. For contracts that did not exist prior to the transaction +SELFDESTRUCT would continue to operate normally. Balance would be sent to the +beneficiary, and code and storage would be deleted. Since none of this data had +been part of the committed data the deletion did not impact any plans for +changes to their storage model. + +Within the EVM Hedera should support a similar model, as contracts will now +expect SELFDESTRUCT to operate as a sweep in some cases. Outside the EVM, +however, there is no need to change any semantics. HAPI calls can still be used +to delete a contract and state expiry can still delete an account. + +## Rationale + +Hedera will support the [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780) +change to the SELFDESTRUCT operation. If the contract existed prior to the +transaction the contract will not be destroyed and the contents will instead be +swept to the beneficiary. Contracts within the same transaction will be +destroyed as per prior behavior. + +However, since Hedera places "ownership" of token balances with the account +holding the balance we will need to extend the behavior of the sweep mode to +also transfer all HTS tokens to the beneficiary. This is consistent with current +self-destruct behavior and consistent with the spirit of the Ethereum change in +that code and the account are no longer deleted. + +When the self-destruct is invoked on a contract within a transaction the +behavior of Hedere will remain as it currently is in all respects. + +## User stories + +* As a smart contract developer I want to use the "sweep" semantics of EIP-6780 + in my contracts to sweep out hbar while not destroying the contract. +* As a smart contract developer I want to be able to continue to use the + transient contract pattern and have it behave the same way prior to this HIP. +* As a HAPI user I want to be able to control my contract account in the same + ways I did prior to this HIP. + +## Specification + +There are no changes needed to the JSON-RPC relay. + +### EVM Implementation + +The SelfDestructOperation will be re-implemented with hedera semantics. An +existing hedera version of self-destruct exists that may be manipulated in a way +similar to how the Besu EVM's implementation was altered. + +The existing transient self-destruct behaviors will be retained, and the new +sweep mode changes will be added. All hBar and HTS tokens will be swept as part +of the self-destruct to the beneficiary address, what will change is that the +contract will not be marked for removal. + +### Hedera Services + +Hedera services may need to be changed to ensure that the transaction processing +does not leave a "shadow" account number for transient self-destructs. Such +transient self-destructs will also need to be tested to ensure all HTS tokens +are properly swept during the sweep as well as the transient contract modes. + +### Hedera Activation + +The operation will be added into a new EVM version of Hedera (notionally +version 0.50, but subject to change), like the versions added for Shanghai +support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled +into this EVM version. + +## Backwards Compatibility + +This change could break contracts that depend on selfdestruct destroying old +contracts. Relying on such behaviors has been discouraged for years and formally +deprecated for at least a year on Ethereum Mainnet, so it is expected that such +use cases have never found their way onto Hedera's Mainnet. + +In the event such a pattern is discovered, the ability to use HAPI calls to +delete the contract can be used as a shim to restore proper functionality +between transactions. + +## Security Implications + +The substantial changes of this HIP are the removal of some functionality in +some circumstances. There are no known security impacts of this removal and +furthermore there are no known security mitigations that require the presence of +the removed functionality. It is expected the security implications will be +minimal to none. + +## How to Teach This + +When discussing fork compatibility it should be called out that HTS token +balances will be included in sweep operations. Such documentation should already +exist for the existing self-destruct behavior. Because the SELFDESTRUCT +operation is still formally deprecated for remove it is not recommended that any +tutorials be written to demonstrate sweep mode or transient contract deletions. +Tutorials should only be written for features that have been signaled as long +term stable. + +## Reference Implementation + +//TODO + +## Rejected Ideas + +One alternative is to simply not implement EIP-6780 and to continue to allow +contracts to use SELFDESTRUCT. This was rejected because we do not want to +encourage smart contracts to use deprecated design patterns and rely on +out-of-date features within Hedera. + +## Open Issues + +// NONE + +## References + +* [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780): SELFDESTRUCT only in same + transaction + +## 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) From 97bebf1b6be6d8d33ea9128d29956e7464f40050 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Mon, 22 Jan 2024 15:22:30 -0700 Subject: [PATCH 4/4] review comments Signed-off-by: Danno Ferrin --- HIP/hip-0000-cancun-1.md | 18 ++++++------------ HIP/hip-0000-cancun-2.md | 14 ++++++-------- HIP/hip-0000-cancun-3.md | 19 ++++++++----------- HIP/hip-0000-cancun-4.md | 24 ++++++++++-------------- 4 files changed, 30 insertions(+), 45 deletions(-) diff --git a/HIP/hip-0000-cancun-1.md b/HIP/hip-0000-cancun-1.md index 9402adffc..c1eea237a 100644 --- a/HIP/hip-0000-cancun-1.md +++ b/HIP/hip-0000-cancun-1.md @@ -1,8 +1,8 @@ --- hip: -title: Add EVM Support for new non-blob Cancun opcodes +title: Add EVM Support for transient storage and memory copy Cancun opcodes author: Danno Ferrin (@shemnon) -working-group: // TBD +working-group: Nana Essilfie-Conduah <@nana-ec> type: Standards Track category: Core needs-council-approval: Yes @@ -22,7 +22,7 @@ Ethereum Mainnet, namely TSTORE, TLOAD, and MCOPY ## Motivation -Hedera's goal of Ethereum Equivalence also includes the requirement to stay +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. @@ -30,8 +30,9 @@ 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. It is expected that future versions -of solidity will support both implicit and explicit use of these opcodes. +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 @@ -59,13 +60,6 @@ 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. -### Hedera Activation - -The operations will be added into a new EVM version of Hedera (notionally -version 0.50, but subject to change), like the versions added for Shanghai -support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled -into this EVM version. - ## Backwards Compatibility The core EVM library shipping with Hedera as of version 0.46 already contains diff --git a/HIP/hip-0000-cancun-2.md b/HIP/hip-0000-cancun-2.md index 29aa9ccef..dcbbff65b 100644 --- a/HIP/hip-0000-cancun-2.md +++ b/HIP/hip-0000-cancun-2.md @@ -2,7 +2,7 @@ hip: title: Add EVM compatibility for non-supported Cancun blob features. author: Danno Ferrin (@shemnon) -working-group: // TBD +working-group: Nana Essilfie-Conduah <@nana-ec>, Jasper Potts <@jasperpotts>, Richard Bair <@rbair23> type: Standards Track category: Core needs-council-approval: Yes @@ -72,6 +72,11 @@ For `BLOBBASEFEE` this will result in returning `1` at all times, as the blob gas cost cannot adjust below 1. This will require updating the `TxValues` object with a blob fee of `1`. +Proper handling of the `TxValues` object in EVM transaction execution should +allow us to use the Besu opcodes without modification. This would consist of +always setting the `versionedHashes` to an empty list and setting +the `blobGasPrice` to 1 Gwei. + ### Hedera Services Implementation The `EthereumTransaction` transaction type in Hedera will need to reject all @@ -98,13 +103,6 @@ blob transaction. In those cases we should similarly detect that a blob transaction is being simulated and reject the transaction before sending it to the simulation and estimation engines. -### Hedera Activation - -The operations will be added into a new EVM version of Hedera (notionally -version 0.50, but subject to change), like the versions added for Shanghai -support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled -into this EVM version. - ## Backwards Compatibility The core EVM library shipping with Hedera as of version 0.46 already contains diff --git a/HIP/hip-0000-cancun-3.md b/HIP/hip-0000-cancun-3.md index 80c8767c7..b15e54020 100644 --- a/HIP/hip-0000-cancun-3.md +++ b/HIP/hip-0000-cancun-3.md @@ -2,7 +2,7 @@ hip: title: Add Smart Contract Services Support for KZG Point Evaluation Precompiled Function author: Danno Ferrin (@shemnon) -working-group: // TBD +working-group: Nana Essilfie-Conduah <@nana-ec>. David Bakin <@david-bakin-sl> type: Standards Track category: Core needs-council-approval: Yes @@ -23,7 +23,7 @@ Transactions. ## Motivation One part of [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) is the KZG Point -Evaluation function, a cryptographic precompile that can be used un zero +Evaluation function, a cryptographic precompile that can be used with zero knowledge proofs as well as proving that certain subsections of a blob are present without introducing the entire blob. This precompile adds value to the other parts of EIP-4844, but it does not require them. Hedera will expose @@ -41,8 +41,9 @@ blob varying transactions, and it makes sense to allow Hedera Smart Contract apps the same latitude. This precompile will be brought in with the same semantics and calling -conventions as Ethereum Mainnet. The trusted setup from Ethereum Mainnet will -also be used. +conventions as Ethereum Mainnet. It also requires a customizable data file known +as the trusted setup. For maximum compatibility the same trusted setup from +Ethereum Mainnet will be used. ## User stories @@ -61,16 +62,12 @@ will be implemented as it is in EIP-4844. The address for the precompile will be the same as Ethereum Mainnet (`0x000000000000000000000000000000000000000A`). -The point evaluation will use teh +The point evaluation will use the same [trusted setup](https://github.com/ethereum/c-kzg-4844/blob/main/src/trusted_setup.txt) as Ethereum Mainnet. -### Hedera Activation - -The precompile will be added into a new EVM version of Hedera (notionally -version 0.50, but subject to change), like the versions added for Shanghai -support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled -into this EVM version. +This is the same out-of-the-box setup provided by the Besu EVM library, there +should be little to zero Hedera code needed to enable this. ## Backwards Compatibility diff --git a/HIP/hip-0000-cancun-4.md b/HIP/hip-0000-cancun-4.md index 00c49fd9c..0ee775fff 100644 --- a/HIP/hip-0000-cancun-4.md +++ b/HIP/hip-0000-cancun-4.md @@ -2,7 +2,7 @@ hip: title: Support Cancun Self-Destruct Semantics in Smart Contract Services author: Danno Ferrin (@shemnon) -working-group: // TBD +working-group: Nana Essilfie-Conduah <@nana-ec>, Jasper Potts <@jasperpotts>, Richard Bair <@rbair23>, Stoyan Panayotov type: Standards Track category: Core needs-council-approval: Yes @@ -22,7 +22,7 @@ account model. ## Motivation -Ethereum Equivalence requires that Hedera add features supported by Ethereum +EVM Equivalence requires that Hedera add features supported by Ethereum Mainnet (mapped to Hedera semantics). This effort also spans to the rare occasion that Ethereum removes features from the EVM. @@ -63,17 +63,20 @@ destroyed as per prior behavior. However, since Hedera places "ownership" of token balances with the account holding the balance we will need to extend the behavior of the sweep mode to -also transfer all HTS tokens to the beneficiary. This is consistent with current -self-destruct behavior and consistent with the spirit of the Ethereum change in -that code and the account are no longer deleted. +also transfer all HTS tokens to the beneficiary. Notably, for a successful +transaction beneficiary accounts must support the receiving of HTS tokens via +association configuration. This is consistent with current self-destruct +behavior and consistent with the spirit of the Ethereum change in that code and +the account are no longer deleted. When the self-destruct is invoked on a contract within a transaction the -behavior of Hedere will remain as it currently is in all respects. +behavior of Hedera will remain as it currently is in all respects. ## User stories * As a smart contract developer I want to use the "sweep" semantics of EIP-6780 - in my contracts to sweep out hbar while not destroying the contract. + in my contracts to sweep out value (HBAR and HTS token balance) while not + destroying the contract. * As a smart contract developer I want to be able to continue to use the transient contract pattern and have it behave the same way prior to this HIP. * As a HAPI user I want to be able to control my contract account in the same @@ -101,13 +104,6 @@ does not leave a "shadow" account number for transient self-destructs. Such transient self-destructs will also need to be tested to ensure all HTS tokens are properly swept during the sweep as well as the transient contract modes. -### Hedera Activation - -The operation will be added into a new EVM version of Hedera (notionally -version 0.50, but subject to change), like the versions added for Shanghai -support (v 0.38) and Paris support (v 0.34). There will be multiple HIPs rolled -into this EVM version. - ## Backwards Compatibility This change could break contracts that depend on selfdestruct destroying old