Discussion topic for EIP-7825
Update Log
Creation
External Reviews
Outstanding Issues
None as of 2024-11-25.
4 Likes
Ideally the value would be lower
This EIP is great and I fully support it.
However, I think the EIP itself could use some clarifcations.
Transactions specifying gas limits higher than 30 million gas will be rejected with an appropriate error code (e.g.,
MAX_GAS_LIMIT_EXCEEDED)
This is likely meant in the context of JSON-RPC, where the client would respond with this error code. However this could be confused with other places, like the EVM or block validation.
@benaadams wants the value to be lower. Also for txpool performance to quickly invalidate transactions, what about a limit of 2^(3*8) - 1? So the gas limit should be <= 2^(3*8)-1. This means that the value (16_777_215) fits into a bytes3. So we can quickly check when decoding the RLP to figure out if the transaction is valid or not regarding this rule: if it is 4 or more bytes it is invalid.
This will need analysis on-chain what transactions use more gas limit than this to ensure we don’t break anything.
Would also need an error for block validation? As a block builder could include an invalid size transaction regardless of what the tx pool accepts
Am ok with this limit 
Though some analysis of larger txs and why they are larger might be needed
Yes the block should definitely be rejected! This was meant in the scope of the EIP, in that specific section it should be made clear that it is about JSON-RPC. Then later on in the EIP it should be made explicit that any block with such transaction is invalid. This thus also implies (but it’s fine to note this in the EIP) that these should be directly thrown out of mempool (we don’t want invalid txs in our mempool)
One of many potential futures for Ethereum is one where apps and users do not produce traditional L1 transactions but instead ERC-4337 ops. If so, we might end up in a situation that looks like ULTRA-TX, where it is most efficient for the block builder to make one big transaction that takes up 50 to 90% of the block with all of the meta-transactions in it, and fill the rest of the block with traditional transactions. Suppose the gas limit is 300M+: if the per transaction limit is 30M, we are forcing the builder to split up their big transaction into up to ten pieces, forcing them to perform the knapsack algorithm and pay intrinsic gas multiple times. It might still be beneficial to put this limit and remove it later if needed, but this should be considered. We might even hamper the emergence of ULTRA-TX by including this EIP.
1 Like
Shipping a transaction cap feels premature to me atm, but if we were to ship it I think it should be updatable without a full hard fork for future flexibility (same as the gas block limit is, iiuc)
1 Like
Another example of expensive transactions are big contract deployments because they pay a lot for the stored code (200 gas per byte). So this limit also puts limit on the code size (~70k by my very quick estimation).
In other words, this EIPs goes against the EIP-7903: Remove Initcode Size Limit, discussed in EIP-7903: Remove Initcode Size Limit.
2 Likes
I posted this over at the EIP-7987 discussion, but it’s really important not to make breaking/backwards-incompatible changes. Why set this limit lower than the “conventional” block gas limit of 30M? We already have examples of dApps that this lower limit will break. Don’t squander the goodwill that Ethereum’s stability has engendered. The EVM is such a vibrant developer ecosystem precisely because of Ethereum’s stability. I see this entirely too often in EIPs that affect the execution layer. Linus wouldn’t tolerate this and neither should we.
1 Like
Splitting the huge tx into multiple pieces means the tx can be parallelized which means the validators can support the higher gaslimit throughput
Intrinsic gas is 21k; if they had to submit 10x for a 300M fill; that’s 0.07% of their tx gas. Isn’t particularlly a feature?
I agree that intrinsic gas is negligible in this case. There could however also be issues with transient storage, blob aggregation, and top-of-block guarantees when knapsacking the tx, at least based on my reading of ULTRA-TX. But it’s hard to know since we haven’t seen any implementations. I would also like to invite @Brechtpd to opine on this, given what was said in Cannes during the Gwyneth talk.