Jumbo EthereumTransactions

HIP/hip-1086.md

@@ -0,0 +1,144 @@
+---
+hip: 1086
+title: Jumbo EthereumTransaction
+author: Nana Essilfie-Conduah <@Nana-EC>, Richard Bair <@rbair>
+working-group: Richard Bair <@rbair>, Atul Mahamuni <@atul-hedera>, Leemon Baird <leemon@hedera.com>,
+Joseph Sinclair<@jsync-swirlds>
+requested-by: Relay operators
+type: Standards Track
+category: Core, Service
+needs-council-approval: Yes
+status: Draft
+created: 2024-11-20
+discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1085
+updated: 2024-11-20
+requires: 1084
+---
+
+## Abstract
+
+Raises the limit on the size of `EthereumTransaction` callData to 128KB, and the limit on the total size of an
+`EthereumTransaction` from 6KB to 130KB. Introduce a new throttle bucket that represents the max bytes-per-second of
+the network, such that each node gets 1/N of that throttle bucket (using our existing throttle system). Introduce
+non-linear pricing for transactions larger than 6KB to incentivize smaller sized transactions where possible.
+
+## Motivation
+
+Ethereum and other EVM networks permit up to 128KB of data in a call, whereas Hedera transactions can be no larger than
+6KB. Many smart contracts are much larger than 6KB and have to be broken up into multiple `FileAppend` transactions and
+use the Hedera File Service (HFS). Not only does this lead to a poor developer experience, but it makes operating a
+JSON-RPC relay difficult and expensive. By permitting transactions to use all 128KB, we improve Ethereum compatibility,
+developer experience, and make it easier to operate a JSON-RPC relay.
+
+## Rationale
+
+Hedera limits all transactions to a maximum size of 6KB. By limiting the size of transactions, Hedera makes it easier
+for clients to get fair access to the network. Ethereum, on the other hand, supports callData sizes of up to 128KB. 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 bytecode and all other bytes for the EthereumTransaction
+(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 Hedera File Service (HFS) to create a file, and then call ContractCreate
+with that function. This has several challenges:
+
+- The workflow for Hedera 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
+  `EthereumTransaction`
+
+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 `EthereumTransaction` callData (called `ethereum_data` in the protobuf) to be as large as 128KB
+ - The entire transaction, including signatures, shall not exceed 130KB
+ - Increase the price-per-byte non-linearly to encourage smaller transactions
+ - Institute a network-wide throttle on bytes-per-second for "jumbo" `EthereumTransaction`s
+
+### Services
+
+A new throttle bucket will be introduced that represents the max bytes-per-second of the network, such that each node
+gets 1/N of that throttle bucket (using our existing throttle system). If an `EthereumTransaction` is received that
+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.
+
+In addition, the price of the transaction will be increased non-linearly for transactions that exceed 6KB in size. The
+actual pricing will be determined by the Hedera Council and specified as part of the network configuration. The price
+will **not** affect the gas, but **will** affect the exchange rate between gas and USD.
+
+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.
+
+This HIP only designates jumbo `EthereumTransactions`. Any other transactions exceeding 6KB should be rejected.
+
+The configured value for the size of an event should be set to permit at least one full-sized jumbo
+`EthereumTransaction`.
+
+### 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 the `EthereumTransaction`. 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
+callData exceeds 6KB. The SDK should support an option to use HFS for callData if the user prefers to manage the
+complexity themselves.
+
+### Mirror Node
+
+A Mirror Node should not require any changes. While the size of the `EthereumTransaction` will be larger, and therefore
+the reason for using HFS will be lessened, the Mirror Node should be able to handle both jumbo transactions and legacy
+HFS-based `EthereumTransaction`s.
+
+### Relay
+
+The JSON-RPC relay will be updated to use jumbo transactions. It will no longer use files for large callData. 
+
+## 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).
+
+## How to Teach This
+
+With this HIP, the behavior of `EthereumTransaction` will now match expectations for Ethereum developers. There should
+be documentation added to docs.hedera.com to cover `EthereumTransaction` 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.
+
+## 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)
+- [HIP 1084](https://hips.hedera.com/hip/hip-1084)
+
+## 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)