Jumbo EthereumTransactions

[Nana-EC]

Context:
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.

Issue:
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:

1. The workflow for Hedera is different from Ethereum and other EVM networks
2. Uploading a file is expensive, and requires multiple transactions (since the file upload itself is also limited to 6KB per transaction)
3. 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.

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.

Affected Users:
All relay operators and all EVM transaction submitters of callData over 5kb

Solution:

• 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" EthereumTransactions

Since events also have a maximum size, it is slightly more difficult for an artbitrary user's transaction to be included in an event in the presence of jumbo transactions. To mitigate this and encourage maximal fairness on the network, we will encourage smaller transactions by applying non-linear pricing to transactions with greater than 6KB total size, and by limiting their count through a new bytes-per-second throttle.

Acceptance Criteria
A user can submit an ETH tx with a callData > 6kb and will pay all the associated gas. A relay operator will no longer require HFS usage or pay for any fees in the valid case.

[Neurone]

Link to the PR

[rbair23]

I had previously used the word "congestion pricing", but this was wrong. What was meant was "non-linear pricing". I updated the description accordingly. This proposal uses fixed fees, but the more bytes you send, the higher your fixed fee. This is similar to normal transactions where the crypto transfer may be $0.0001, but the more signatures you add, or the more bytes you add to the memo, the higher the price.