HIP-866: Add EVM compatibility for non-supported Cancun blob features.
| Author | Danno Ferrin |
|---|---|
| Working Group | Nana Essilfie-Conduah, Jasper Potts, Richard Bair |
| Requested By | EVM Developers |
| Discussions-To | https://github.com/hashgraph/hedera-improvement-proposal/discussions/872 |
| Status | Accepted ⓘ |
| Needs Council Approval | Yes ⓘ |
| Review period ends ⓘ | Wed, 28 Feb 2024 07:00:00 +0000 |
| Type | Standards Track ⓘ |
| Category | Core ⓘ |
| Created | 2024-01-24 |
| Updated | 2024-03-08 |
Table of Contents
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 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. 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
Copyright/license
This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)
Citation
Please cite this document as: