HIP-410 - Wrapping Ethereum Transaction Bytes in a Hedera Transaction

[shemnon]

Entire hip will be at hips.hedera.com. Here is the initial specification section

Specification

Protobuf changes

Ethereum Transaction

A new transaction body EthereumTransaction will be introduced that hold the
ethereum transaction data.

message EthereumTransactionBody {

    // required 
    bytes ethereumData = 1;

    // optional 
    FileID callData = 2; 

}

The ethereum transaction data will be converted into a ByteString. If the
transaction is small enough it will be the entire unadjusted transaction.

To support larger transactions that won’t fit in the Hedera transaction size
limitations (such as contract create transactions) we will allow the data
section of the transaction (also referred to as callData or inputData) to be
stored as a Hedera file. In these instances the transaction body contains an
edited version of the Transaction, replacing a zero length string for the data
field in the RLP set in the ethereumData message field and storing the call
data in a Hedera File ?? as a hex string ?? as a binary blob ??. When the
transaction is executed and before the signatures are extracted

To support this transaction there will also need to be some changes in other
messages that would be customary for a new transaction body.

// basic_types.proto 
enum HederaFunctionality { 
    //... 
    EthereumTransaction = 83; // enum number may be difference once finalized 
}

// smart_contract_service.proto 
service SmartContractService { 
    //... 
    rpc contractCallEthereum (Transaction) returns (TransactionResponse); 
}

// transaction_body.proto 
message TransactionBody { 
    //... 
    oneof data { 
        //...
        EthereumTransactionBody ethereumTransaction = 50; // field number may change
        //... 
    } 
    //... 
}

ContractCreateTransaction

In cases where the created contract is small it may fit in a Hedera Transaction.
Ordinarily contract creates always require the creation of a Hedera file. To
simplify this case a new field initcodeBytes is added to
the ContractCreateTransactionBody as an alternative to fileID.

message ContractCreateTransactionBody {
    oneof initcodeSource {
        FileID fileID =    1; 
        bytes initcodeBytes = 7; // field number may change in final draft 
      } 
      // ... 
}

Value of gas price and value fields

For Ethereum Transactions we introduce the concept of “WeiBars”, which are 1 to
10^18th the value of a hBar. This is to maximize compatibility with third party
tools that expect ether units to be operated on in fractions of 10^18, also
known as a Wei. Thus, 1 tinyBar is 10^10 weiBars or 10 gWei. When calculating
gas prices and transferred value the fractional parts below a tiny bar are
dropped when converted to tinyBars.

Ethereum Requirements

The replay protection specified in EIP-155 will be required for Legacy
transactions. The Type 1 / EIP-2930 and Type 2 / EIP-1559 transactions also
require a chainId field. Non-restricted chainIDs (where chainID is less than or
equal to zero) are not supported.

For all transaction types the chainID specified must match the chainID of the
network as specified in HIP-26 (0x127 for mainnet, 0x128 for testnet, 0x129 for
devnet, and 0x12a for local networks). Future evolution in the Ledger ID may
impact this.

Transaction Signing Requirements

The sender of an ethereum transaction body will be the account with an account
alias that is an ECDSA(secp256K1) public key. To identify the account the public
key will be recovered from the ethereum transaction, and converted to an
ethereum address. The transaction sender will then be set to the account whose
ethereum address of the alias key has the same ethereum address.

For the purposes of authentication signing the ethereum transaction will provide
the same authorization as though the key signed the entire Hedera transaction.

Paying for the Transaction

In addition to the account signing the Ethereum transaction (the sender account)
each Hedera transaction containing the Ethereum transaction will also need to be
signed by a hedera account (the relayer account). These may be the same account
or different accounts.

If the relayer and sender account are the same account there are no limitations
on hbar transfers.

When the relayer and sender account is different the following restrictions
apply to hbar transfers.

• The effective gas cost is either the gasUsed field (if a contract call or
  contract create transaction) or the gas that a system contract would charge
  for the operation
• The gas price is either the gasPrice field for legacy and type 1 (EIP-2930)
  transactions or the max_fee_per_gas field for type 2 (EIP1339 transactions).
  This value is expressed in weibars.
• The sender will be debited hbar equal or less than the gas price multiplied by
  the effective gas cost (the sender portion).
• If the sender portion is greater than the total fees the relayer will receive
  the excess or the sender portion should be reduced. If the sender portion is
  less than the total fees the sender will pay the difference.
• If there is a max_priority_fee_per_gas specified then the relayers account
  cannot receive more than the effective gas cost times
  the max_priority_fee_per_gas (in weibars). The sender portion should be
  reduced until the transfers balance out. The relayer may still spend any
  amount needed to balance out the transfers.

Finally, if an ethereum transaction reaches consensus and is invalid and cannot
be processed (for critical failures such as a bad ECDSA signature, an account
not matching the sender, an invalid ethereum transaction, an incorrect nonce, or
any other such error) the relayer is responsible for all fees relating to
bringing the transaction to consensus.

Account Nonce

Ethereum transactions have a different deconfliction and transaction enablement
mechanism than Hedera, but it is an inseparable part of ethereum toolchains. To
that end we will support transaction sequence numbers as an additional
transaction validity check.

Each Hedera account will track a new value ethereumNonce, defaulting to zero.

When an EthereumTransaction is validated at consensus time the transaction
will fail if the account's ethereumNonce is not equal to the nonce in the
ethereum transaction bytes.

If the transaction passes all validations and EVM execution (or equivalent
processing) starts then the ethereumNonce in the user account is incremented
by one. If the transaction fails for any reason prior to EVM execution the nonce
is not incremented.

Executing the Transaction

Ethereum transactions can have a number of possible handling routes. All of them
are driven by the to field in the ethereum transaction.

If the to field is empty, zero length, or all zeros it will be converted into
a ContractCreate transaction. If the transaction has a callData value in the
transaction it will be places din the ContractCreates fileID field,
otherwise the data goes in the initcodeBytes field.

For non-zero non-empty to fields the address will first be decoded as a
standard solidity mapping (bytes 1-4 are shard, bytes 5-12 are realm, bytes
13-20 are id, big endian encoded). If this does not map to an exiting entity
then the to address will be processed as an alias, which currently can map to
Crypto Accounts and Smart Contract Accounts.

If the to field still does not map to an entity the transaction fails with a
hedera error. Intrinsic gas will be charged to the sender account.

If the to address points to a Contract account the body of the ethereum
transaction will be converted into a ContractCall and executed.

If the to address corresponds to a Token ID the call will initially be handled
as an EVM, and converted into a ContractCall. In future updates it will be
handled directly via the HTS Precompile code skipping the EVM step.

If the to address points to a Topic ID or File ID the call will be handled as
an EVM, and converted into a ContractCall. If precompile support for the
consensus and file service is developed then there may be similar handling as
token calls.

[Daniel-K-Ivanov]

In cases where the created contract is small it may fit in a Hedera Transaction.
Ordinarily contract creates always require the creation of a Hedera file. To
simplify this case a new field initcodeBytes is added to
the ContractCreateTransactionBody as an alternative to fileID.

We had similar use-cases where a given property had to be changed to one of and the discussions that we had with the Mirror node team, went in the direction that it is easier (in terms of compatibility) to add another property and implicitly implement the one of feature instead of directly changing the protobuf to one of.

@steven-sheehy what is your take on this?

[shemnon]

I will defer to @steven-sheehy, but using oneof in this way is wire compatible with two separate fields. My desire in addingthe oneof is to have the tools enforce the "one or the other" option for the initcode in the contract create.

[steven-sheehy]

The oneof is fine for us. People who don't update their protobuf can continue to parse the bytes, but people who do update will need to make a code change to be compatible. I don't recall why we would prefer not to use oneof in the past.

[Daniel-K-Ivanov]

I think that the use-case we were discussing was the NON_FUNGIBLE token types, but maybe the situation there was a bit different. If you do not see an issue with the proposed change we can go along and use one of.

[Daniel-K-Ivanov]

Value of gas price and value fields
For Ethereum Transactions we introduce the concept of “WeiBars”, which are 1 to
10^18th the value of a hBar. This is to maximize compatibility with third party
tools that expect ether units to be operated on in fractions of 10^18, also
known as a Wei. Thus, 1 tinyBar is 10^10 weiBars or 10 gWei. When calculating
gas prices and transferred value the fractional parts below a tiny bar are
dropped when converted to tinyBars.

Can you confirm that the stated above means:

If tx.value=1 is sent, it will have 1 weibar of value and after processing through the EVM, the from address will not get 1 reduced from his balance (excluding fee payment) and the to address will not have his balance increased. The following will be true until tx.value reaches more than 10 gwei which is the equivalent of tx.value=10000000000. If that is the case, this would be a breaking change from the current behaviour and we have to explicitly state it.

[shemnon]

We either need to consistently round up or down, so if there is a case for up we can do that.

There are some fields where the math needs to be done before the rounding, for example gas fees, multiplying the gasPrice by the gas used should be done in weibars and then rounded up or down as appropriate.

Note that while the tx will be in weibars the EVM will see the values in tinybars. So the TX may authorize 2 weibars the EVM will see the rounded values.

[Daniel-K-Ivanov]

If the to address points to a Contract account the body of the ethereum
transaction will be converted into a ContractCall and executed.

I think that we should explicitly state that if to is Account (not only Contract), the transaction will be converted into a ContractCall

[shemnon]

That is easier to code and cuts out a lot of complex logic.

[Nana-EC]

My understanding is an EthereumTransactionBody with a non-null ethereumData will produce a ContractCreateTransactionBody with initCode set. Is there also a FileCreate transaction added to the record file? Or will the contract bytes only ever be recorded in the EthereumTransactionBody.ethereumData and ContractCreateTransactionBody.initCode?

[steven-sheehy]

No, a EthereumTransaction will not produce a child synthetic transaction in the record like ContractCreateTransactionBody. Also, if they use a file to hold call data the file should've been previously created via HAPI.

[steven-sheehy]

Note a synthetic ContractCreateTransactionBody will be used internally within services code to be able to leverage the existing TransactionLogic that requires it, but not written to the record. Perhaps that's a source of some confusion.

[Nana-EC]

Thanks for confirming

[Nana-EC]

Is ethereum_nonce exposed in the record file somewhere? It currently seems to only be exposed in a cryptoGetInfo() but not in a CryptoAccount or Contract related transactionBody or transactionRecord.

[steven-sheehy]

No, it is in the EthereumTransactionBody in the RLP bytes so the mirror node will parse it out of there.

[Nana-EC]

Sounds good, thanks

[spalladino]

If the to field is empty, zero length, or all zeros it will be converted into
a ContractCreate transaction.

Heads up that, in Ethereum, a tx to the null address is different to a tx to the zero address: the former is a contract create, but the latter is just a transfer to the zero address. If the goal of the HIP is to simplify compatibility with Ethereum, it may be best to follow its behaviour - even if it's not the most intuitive one.

[shemnon]

Will update.

[spalladino]

When an EthereumTransaction is validated at consensus time the transaction
will fail if the account's ethereumNonce is not equal to the nonce in the
ethereum transaction bytes.

Does this mean that if a client submits a tx with nonce 11 when the expected one was 10, the tx will be accepted by the node but will be failed on execution? If so, this means that it is risky for a client to submit a tx without having confirmation that the previous one has been processed. As an example, if the txs with nonces 10 and 11 were sent one right after the other, but nonce 11 ends up ordered before 10, then both txs would fail execution.

[shemnon]

The risk profile is the same as Ethereum, if you don't submit a TX with nonce 10 to the memory pool but submit 11, 12, etc. and never submit nonce=10 then those transactions will never get a block.

If you are going to "shotgun" transactions from a single account then the relayer should ensure that only one node receives the events, which will then properly order them. This is also the case with hedera transactions, if order strictly matters (a credit before a debit) then the client should only send those transactions to one node.

[spalladino]

The risk profile is the same as Ethereum, if you don't submit a TX with nonce 10 to the memory pool but submit 11, 12, etc. and never submit nonce=10 then those transactions will never get a block.

Agree, but that's not the scenario I have in mind: in Ethereum, if you submit two txs with consecutive nonces simultaneously, they get ordered and executed. Here, you can get any ordering, where one would cause the wrapping Hedera txs to fail execution.

This is also the case with hedera transactions, if order strictly matters (a credit before a debit) then the client should only send those transactions to one node.

Is this enough to guarantee ordering? I understood that ordering is determined by consensus timestamp (the median timestamp when the super majority of the stake sees the tx), which may not be the same as the order in which the first node received the txs. Or do nodes wait for a tx to be added to consensus before gossipping the next one?

[shemnon]

The nodes should keep their own TXes in order. So other nodes may weave into a set of transactions the node gossiping should preserve the order. It would be best to wait for the first TX to finish the RPC call to the specific node to submit first, parallel RPC calls may not guarantee ordering.