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 ContractCallTransaction
s. 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
EthereumTransaction
on 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 HAPIEthereumTransaction
and submits it to Hedera. This is also thepayer
for theEthereumTransaction
. See TransactionBody.transactionIDEOA
: The account that created and signed theevm tx
and submitted it to arelay
. This is thefrom
in 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
relay
is charged if theevm tx
cannot be parsed or is otherwise malformed - The
relay
is charged if theEOA
specified in theevm tx
refers to a non-existent account - The
relay
is charged if theevm tx
was not properly signed by the keys of theEOA
- The
relay
is charged if theEOA
has insufficient funds to pay the intrinsic gas fee - The
relay
is charged if thenonce
check fails - The
relay
is not charged if the contract is called but concludes with an error code - The
relay
is 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
relay
is charged if theevm tx
cannot be parsed or is otherwise malformed - The
relay
is charged if theEOA
specified in theevm tx
refers to a non-existent account - The
relay
is charged if theevm tx
was not properly signed by the keys of theEOA
- The
relay
is charged if theEOA
has insufficient funds to pay the intrinsic gas fee and the transfer - The
relay
is charged if the receiver hasreceiverSigRequired
enabled - The
relay
is charged if the receiver doesn’t exist, must be auto-created, and theEOA
has insufficient funds to pay for the account creation - The
relay
is charged if thenonce
check 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: