About HIPs

    GitHub Logo HIP-1086: Jumbo EthereumTransaction

    Author Nana Essilfie-Conduah, Richard Bair
    Working Group Richard Bair, Atul Mahamuni, Leemon Baird, Joseph Sinclair, Edward Wertz
    Requested By Relay operators
    Discussions-To https://github.com/hashgraph/hedera-improvement-proposal/discussions/1085
    Status Accepted ⓘ
    Needs Council Approval Yes ⓘ
    Needs Hiero Review Yes ⓘ
    Hedera Reviewed Date ⓘ Tue, 18 Mar 2025 00:00:00 +0000
    Hedera Approval Status ⓘ Approved
    Review period ends ⓘ Tue, 08 Apr 2025 07:00:00 +0000
    Type Standards Track ⓘ
    Category Core, Service ⓘ
    Created 2024-11-20
    Updated 2025-04-24
    Requires 1084

    Table of Contents

    Abstract

    This HIP introduces and supports “jumbo” Ethereum transactions by setting a configurable upper limit of the callData field of an RLP encoded Ethereum transaction found in EthereumTransaction.ethereum_data, and increasing the limit on the total size of EthereumTransaction types from 6KB to a configurable upper limit. It also introduces a new throttle bucket that represents the max bytes-per-second for accepting these “jumbo” transactions larger than 6KB on the network, such that each node gets 1/N of the jumbo throttle bucket (using our existing throttle system).

    Motivation

    Ethereum and other EVM networks permit significantly larger amounts of data in a call, up to 7.15 MB of call data, whereas all Hiero transactions are capped at 6KB. Smart contracts that are larger than 6KB have to be uploaded to the Hiero File Service (HFS) through a FileCreate transaction followed by multiple FileAppend transactions. Not only does this lead to a poor developer experience, but it makes operating a JSON-RPC relay difficult and expensive. Allowing callData in excess of 6KB provides parity with most non-rollup use cases.
    Enabling single-transaction parity with most Ethereum smart contracts and calls improves
    compatibility, developer experience, and makes it easier to operate a JSON-RPC relay.

    Rationale

    Hiero limits all transactions to a maximum size of 6KB. By limiting the size of transactions, Hiero makes it easier for clients to get fair access to the network. Ethereum, on the other hand, supports much larger callData sizes. The 6KB limit is highly problematic for developer experience, and unexpectedly, for network efficiency. This is especially true when creating contracts, and for oracles sending large amounts of data to the network.

    When creating a new smart contract, if the smart contract initcode and all other bytes for the transaction (including signatures) together exceed 6KB, then the user cannot simply create a contract the way they would on Ethereum or other networks. They must instead use the Hiero File Service (HFS) to create a file, and then submit an EthereumTransaction with the file id of the call_data. This has several challenges:

    • The workflow for Hiero is different from Ethereum and other EVM networks
    • Uploading a file is expensive, and requires multiple transactions (since the file upload itself is also limited to 6KB per transaction)
    • The file, if not deleted after use, takes up storage space needlessly
    • If the smart contract has already been deployed and the user has a lot of callData (such as an oracle with a large amount of data), then the user likewise must use HFS to upload the callData in chunks to a file on chain, and then issue an EthereumTransaction in such a way as to use that previously uploaded file as the callData.
    • Overall deployment / call latency is increased due to the need to upload files and then reference them in the Ethereum transactions.

    In addition, JSON-RPC relays need to find a business model whereby they can charge users for these HFS transactions. This creates a poor developer experience. This again breaks the business model of many cross chain relay operators and makes access to cheap relays difficult.

    User stories

    1. As an EOA submitting a transaction with large call data I expect the network to accept my transaction and charge me the appropriate amount of gas.
    2. As a relay I want to provide a service for users where they can submit and pay for transactions without increasing my own costs or establishing an out-of-band business model for working with users.

    Specification

    • Permit callData max size to be configurable but not exceed a specified upper limit in KBs
    • The entire EthereumTransaction, including signatures, may exceed 6KB but shall not exceed a configurable upper limit in KBs
    • Institute a network-wide throttle on bytes-per-second for “jumbo” EthereumTransactions larger than 6KB.

    Execution

    A new configurable throttle bucket will be introduced that represents the max bytes-per-second of the network for transactions larger than 6KB, such that each node gets 1/N of that throttle bucket (using our existing throttle system). If any transaction received exceeds 6KB in size, then it is classified as a “jumbo” transaction. In addition to the normal throttle limits, the number of bytes exceeding 6KB will be added to the ‘jumbo’ throttle bucket. If the bucket does not have capacity, then the transaction will be rejected.

    The pricing will be determined by the usual gas price logic in the EVM world.

    This HIP only permits the EthereumTransaction to be “jumbo” transactions. Any other type of transactions exceeding 6KB should be rejected unless specifically allowed by a future HIP.

    This HIP only applies to single transactions. Jumbo Ethereumtransactions will not be allowed to be executed on Batch transactions,
    as the standard transaction size limit still applies to the batching functionality.

    Consensus

    The configured value for the size of an event in gossip should be set greater than one full-sized jumbo transaction plus room for all the needed event meta data. If the max size of events prevent carrying at least 1 jumbo transactions, then any node receiving a single max sized jumbo transaction will have its transaction pool clogged and the node will need to be restarted. This property should be checked at startup. The node should exit if the configured event size is too small.

    SDK

    Today, if a user wants to create a contract with a large amount of callData, they must first upload the callData to a file in the HFS, and then reference that file in Ethereum transactions. The SDK attempts to manage this complexity for the user automatically. With this HIP, SDKs should be updated to automatically use jumbo transactions when the ethereum_data causes the transaction to exceed the default network 6kb limit. The SDK should support an option to use HFS for callData if the user prefers to manage the complexity themselves.

    Mirror Node

    At Mirror Node level with the allowed increase in Ethereum transaction size, the use of HFS for Ethereum data will be lessened. The Mirror Node should be able to handle both jumbo Ethereum transactions and legacy HFS-based Ethereum transactions. Mirror node will need to support the gas estimation of the “new” Jumbo Ethereumtransaction.

    Relay

    The JSON-RPC relay will be updated to use jumbo transactions. It will no longer use files for large callData.

    A JSON-RPC relay should calculate the HBAR cost of the transaction and verify the sender has sufficient funds before sending the transaction to the network to avoid due diligence failure fees. Added to the previous check, the Json RPC Relay, needs to check in case of smart contract creation transaction, that the total contract do not exceed the EIP-170 specified limit, 24,576 bytes.

    Backwards Compatibility

    Behavior for the consensus node is fully backwards compatible. The default behavior for SDKs will change to use jumbo transactions, which may surprise users who are not expecting the change, and the overall cost may be higher than if the user had used HFS. However, the user can still use HFS if they prefer.

    Users of a JSON-RPC relay may see the price in HBAR change as a result of jumbo transactions. They will also see in the Mirror Node Explorer a single large transaction rather than many small transactions (FileCreate and FileAppend) followed by one small EthereumTransaction.

    Security Implications

    The consensus node will need to take care when ingesting data. Today, with a limit of 6KB, the consensus node can maintain very small memory buffers for each connection. The consensus node should now be updated to allow “linking” smaller buffers together when needed for jumbo transactions. This keeps memory usage minimal (vs. if every buffer was “jumbo” sized).

    Fair ordering of transactions requires that transactions are added to gossip events in the order they are received. Since jumbo transactions occupy more space and events are capped to a configured max size, a large number of consecutive jumbo transactions can cause the transaction pool in the receiving node to back up. For this reason a bytes/second throttle is necessary to limit the number of jumbo transactions received by a node per second.

    Let X be the number of events created per second by a node. Let E be the configured max transaction payload per event. Let T be the configured max KB size per jumbo Ethereum transaction. Let N be the number of nodes in the network. Let J be the configured jumbo transaction throttle in bytes per second for the entire network. Then the maximum throttle value allowed for a network should be J < N * (X * Floor(E / T)). Each node will be able to accept J/N bytes per second in jumbo transactions without the possibility of a DOS attack through the event creation rate.

    The configured event size must be large enough to allow at least 1 jumbo transaction per event.

    How to Teach This

    With this HIP, the behavior of Ethereum transactions will better match expectations for Ethereum developers. There should be documentation added to docs.hedera.com to cover this and the documentation for the SDKs should be updated. The main point to be described to users will be how the jumbo transactions are priced and throttled.

    Rejected Ideas

    Expansion to ContractCreate and ContractCall transactions: The notion of applying similar changes in this HIP for ContractCreate and ContractCall transactions was considered but due to the existing logic of hbar payments which align with normal network behaviour it was deemed not essential for inclusion in this HIP. Additionally, the main pain points are felt by users of the EthereumTrasaction. It is still worth consideration and could be brought up in a separate HIP.

    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: