Create HIP: Add no-op compatibility for cancun blobs

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)