Zero Cost EthereumTransaction on Success (#1084)

Signed-off-by: Nana Essilfie-Conduah <nana@swirldslabs.com>
Co-authored-by: Richard Bair <rbair23@users.noreply.github.com>
Co-authored-by: Michael Garber <michael.garber@swirldslabs.com>

HIP/hip-1084.md

@@ -0,0 +1,120 @@
+---
+hip: 1084
+title: Zero Cost EthereumTransaction on Success
+author: Nana Essilfie-Conduah <@Nana-EC>, Richard Bair <@rbair>
+working-group: Richard Bair <@rbair>, Atul Mahamuni <@atul-hedera>, Stanimir Stoyanov <stanimir.stoyanov@limechain.tech>
+requested-by: Relay Operators
+type: Standards Track
+category: Service
+needs-council-approval: Yes
+status: Last Call
+last-call-date-time: 2025-01-29T07:00:00Z
+created: 2024-11-20
+discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1083
+updated: 2025-01-15
+requires: 410
+---
+
+## 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
+
+1. As a relay operator, I want to submit an `EthereumTransaction` on behalf of an EOA without paying additional fees.
+2. As a node operator, I want to charge relays that submit transactions that cannot be charged to the EOA.
+3. 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 transaction
+ - `relay`: A system that, given an `evm tx`, wraps it in an HAPI `EthereumTransaction` and submits it to Hedera.
+            This is also the `payer` for the `EthereumTransaction`. See
+            [TransactionBody.transactionID](https://github.com/hashgraph/hedera-protobufs/blob/main/services/transaction_body.proto#L104)
+ - `EOA`: The account that created and signed the `evm tx` and submitted it to a `relay`. This is the `from` in the
+          [Ethereum Transaction Schema](https://github.com/ethereum/execution-apis/blob/main/src/eth/transaction.yaml)
+          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 the `evm tx` cannot be parsed or is otherwise malformed
+ - The `relay` is charged if the `EOA` specified in the `evm tx` refers to a non-existent account
+ - The `relay` is charged if the `evm tx` was not properly signed by the keys of the `EOA`
+ - The `relay` is charged if the `EOA` has insufficient funds to pay the intrinsic gas fee
+ - The `relay` is charged if the `nonce` 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 the `evm tx` cannot be parsed or is otherwise malformed
+- The `relay` is charged if the `EOA` specified in the `evm tx` refers to a non-existent account
+- The `relay` is charged if the `evm tx` was not properly signed by the keys of the `EOA`
+- The `relay` is charged if the `EOA` has insufficient funds to pay the intrinsic gas fee **and** the transfer
+- The `relay` is charged if the receiver has `receiverSigRequired` enabled
+- The `relay` is charged if the receiver doesn't exist, must be auto-created, and the `EOA` has insufficient funds to
+    pay for the account creation
+- The `relay` is charged if the `nonce` 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
+
+- [EthereumTransaction protobuf specification](https://github.com/hashgraph/hedera-protobufs/blob/main/services/ethereum_transaction.proto)
+- [Hedera JSON RPC Relay](https://docs.hedera.com/hedera/core-concepts/smart-contracts/json-rpc-relay)
+- [HIP 410](https://hips.hedera.com/hip/hip-410)
+
+## 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)