Cancun Support HIPs

HIP/hip-0000-cancun-1.md

@@ -0,0 +1,115 @@
+---
+hip: <HIP number (this is determined by the HIP editor)>
+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: <comma separated list of dates>
+requires: <HIP number(s)>
+replaces: <HIP number(s)>
+superseded-by: <HIP number(s)>
+---
+
+## 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
+
+// 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)

HIP/hip-0000-cancun-2.md

@@ -0,0 +1,155 @@
+---
+hip: <HIP number (this is determined by the HIP editor)>
+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: <comma separated list of dates>
+requires: <HIP number(s)>
+replaces: <HIP number(s)>
+superseded-by: <HIP number(s)>
+---
+
+## 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](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.
+
+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 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
+
+// none
+
+## References
+
+* [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)

HIP/hip-0000-cancun-3.md

@@ -0,0 +1,126 @@
+---
+hip: <HIP number (this is determined by the HIP editor)>
+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: <comma separated list of dates>
+requires: <HIP number(s)>
+replaces: <HIP number(s)>
+superseded-by: <HIP number(s)>
+---
+
+## 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)