HIP-1084: Zero Cost EthereumTransaction on Success
| Author | Nana Essilfie-Conduah, Richard Bair |
|---|---|
| Working Group | Richard Bair, Atul Mahamuni, Stanimir Stoyanov |
| Requested By | Relay Operators |
| Discussions-To | https://github.com/hashgraph/hedera-improvement-proposal/discussions/1083 |
| Status | Last Call ⓘ |
| Needs Council Approval | Yes ⓘ |
| Review period ends ⓘ | Wed, 29 Jan 2025 07:00:00 +0000 |
| Type | Standards Track ⓘ |
| Category | Service ⓘ |
| Created | 2024-11-20 |
| Updated | 2025-01-15 |
| Requires | 410 |
Table of Contents
Abstract
Updates the rules for charging fees for EthereumTransactions, so that the payer of an EthereumTransaction will only
incur a fee if the transaction fails due diligence checks.
Motivation
Today, relay operators must pay the EthereumTransaction HAPI fee for every transaction they submit on behalf of an
Externally Owned Account (EOA). Currently, for every simple EthereumTransaction, this fee is the hbar equivalent of
$0.0001, based on the exchange rate. Although this fee is very low, it effectively compels relay operators on Hedera
to adopt a non-standard business model to cover these costs, which are then passed on to the users. Users are also
burdened with understanding this more complex business model, which negatively impacts their experience.
This situation acts as a friction point for EOAs looking to access cost-effective relay operators on the Hedera public network.
Rationale
On Ethereum, all execution costs are paid for by the ‘sender’ who created, signed, and submitted the transaction.
Hedera follows a similar approach for ContractCallTransactions. However, Hedera charges an additional fee for
each EthereumTransaction submitted via JSON-RPC relays. This fee serves as a defense against a malicious
JSON-RPC relay that might send malformed transactions to the network, where there would be no one to pay for
the processing of those transactions.
This fee is unnecessary for successful transactions since the intrinsic gas fee covers the base costs (gossip &
consensus). Therefore, this HIP proposes that the fee for submitting EthereumTransactions to the network
should only be charged if the JSON-RPC relay submits a transaction that fails due diligence checks, such that the
EOA cannot be charged for the overhead of gossip and consensus.
User stories
- As a relay operator, I want to submit an
EthereumTransactionon behalf of an EOA without paying additional fees. - As a node operator, I want to charge relays that submit transactions that cannot be charged to the EOA.
- As a user, I want to use the same pricing structure and have the same user experience for Hedera relays as with other networks.
Specification
Definitions:
evm tx: The RLP encoded transaction bytes defined by the Ethereum yellow paper that form a standard Ethereum transactionrelay: A system that, given anevm tx, wraps it in an HAPIEthereumTransactionand submits it to Hedera. This is also thepayerfor theEthereumTransaction. See TransactionBody.transactionIDEOA: The account that created and signed theevm txand submitted it to arelay. This is thefromin the Ethereum Transaction Schema often noted as (tx.from)
Smart Contract Creation and Execution Transactions
The relay will only be charged if handling of the EthereumTransaction fails before any bytecodes are executed.
In other words, the relay is charged when one of the pre-requisite checks for EthereumTransaction fails, regardless of
the execution status of the transaction itself once it begins smart contract creation or execution in the EVM.
Examples:
- The
relayis charged if theevm txcannot be parsed or is otherwise malformed - The
relayis charged if theEOAspecified in theevm txrefers to a non-existent account - The
relayis charged if theevm txwas not properly signed by the keys of theEOA - The
relayis charged if theEOAhas insufficient funds to pay the intrinsic gas fee - The
relayis charged if thenoncecheck fails - The
relayis not charged if the contract is called but concludes with an error code - The
relayis not charged if the contract is called and concludes without error
In summary the relay account is not charged if the EthereumTransaction transaction completes in a
CONTRACT_REVERT_EXECUTED or SUCCESS HAPI response code, all other responses codes will result in a charge to the
relay account.
### Regular Transactions
A “regular transaction” is a simple HBAR crypto transfer between two accounts. The relay will be charged for any
failure of the transaction. This is required to maintain compatibility with the semantics in Ethereum, where a regular
transaction will not be included in a block or executed if it will not succeed.
Example:
- The
relayis charged if theevm txcannot be parsed or is otherwise malformed - The
relayis charged if theEOAspecified in theevm txrefers to a non-existent account - The
relayis charged if theevm txwas not properly signed by the keys of theEOA - The
relayis charged if theEOAhas insufficient funds to pay the intrinsic gas fee and the transfer - The
relayis charged if the receiver hasreceiverSigRequiredenabled - The
relayis charged if the receiver doesn’t exist, must be auto-created, and theEOAhas insufficient funds to pay for the account creation - The
relayis charged if thenoncecheck fails
In summary the relay account is not charged if the EthereumTransaction transaction completes in a SUCCESS
HAPI response code, all other response codes will result in a charge to the relay account.
Backwards Compatibility
No changes to transaction execution or record stream externalization is made in this HIP.
EthereumTransaction will continue to work and will only see a reduction in cost on success or contract revert cases.
Security Implications
No changes in security.
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: