From 85637d9cab7dd23c89c1020c200c7ab568cf6962 Mon Sep 17 00:00:00 2001 From: Danno Ferrin Date: Fri, 16 Feb 2024 11:11:09 -0700 Subject: [PATCH] Create HIP: Add no-op compatibility for cancun blobs (#866) Signed-off-by: Danno Ferrin Signed-off-by: Danno Ferrin Co-authored-by: Nana Essilfie-Conduah <56320167+Nana-EC@users.noreply.github.com> Co-authored-by: Michael Garber --- HIP/hip-866.md | 161 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 HIP/hip-866.md diff --git a/HIP/hip-866.md b/HIP/hip-866.md new file mode 100644 index 000000000..7485c4194 --- /dev/null +++ b/HIP/hip-866.md @@ -0,0 +1,161 @@ +--- +hip: 866 +title: Add EVM compatibility for non-supported Cancun blob features. +author: Danno Ferrin (@shemnon) +working-group: Nana Essilfie-Conduah <@nana-ec>, Jasper Potts <@jasperpotts>, Richard Bair <@rbair23> +requested-by: Swirlds Labs +type: Standards Track +category: Core +needs-council-approval: Yes +status: Last Call +last-call-date-time: 2024-02-28T07:00:00Z +created: 2024-01-24 +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/872 +updated: 2024-02-14 +--- + +## 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 +from 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 receive appropriate errors when I attempt to + introduce blobs via Ethereum transactions. +* As a future Hedera Core developer, I want the option to provide blob like + behavior using EIP-4844 semantics and the related 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`. + +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 +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. + +### Mirror Node web3 Module Implementation + +When parsing and displaying the transaction bodies of `EthereumTransactions` the +mirror node and web3 module will need to detect type 3 transactions and display +that they are rejected or reject them as part of their API. The error message +should contain a message about how Hedera does not support "Type 3 (Blob)" +transactions. All Type 3 transactions start with `0x03` and that can be used as +a rubric to detect them without parsing them. + +## 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)