-
Notifications
You must be signed in to change notification settings - Fork 143
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create HIP: Add no-op compatibility for cancun blobs (#866)
Signed-off-by: Danno Ferrin <[email protected]> Signed-off-by: Danno Ferrin <[email protected]> Co-authored-by: Nana Essilfie-Conduah <[email protected]> Co-authored-by: Michael Garber <[email protected]>
- Loading branch information
3 people
authored
Feb 16, 2024
1 parent
b93fd2a
commit 85637d9
Showing
1 changed file
with
161 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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) |