About HIPs

    GitHub Logo 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 Final ⓘ
    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-06-24
    Release 0.50.1

    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: