diff --git a/HIP/hip-1086.md b/HIP/hip-1086.md new file mode 100644 index 000000000..8e659e790 --- /dev/null +++ b/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 , +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)