Discussion topic for EIP-7825
Update Log
Creation
External Reviews
Outstanding Issues
None as of 2024-11-25.
5 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.
Yes it is potentially problematic for ULTRA TX. I have proposed EIP-7814 that exposes the transaction trie to the EVM so that the latest state can be calculated at any place in the block efficiently, so top of block is not required and the ULTRA TX can be split over multiple transactions if needed.
1 Like
Hi all, I am a bit late to this discussion, but I do not think that this is the right way to go about doing this. This pathway prevents the utility of certain decentralized projects that are projected to hit this limit in the next few years. By applying a single transaction gas spend limit, optimizations such as accessing warmed SLOADs become harder to achieve when performing group actions.
Imagine a contract that uses 10m in gas, mostly during SLOADs. After that 10m spend, only ~6m is left for warm accessing, which is much less than the current 20m. I could be for this EIP if the warm SLOAD costs were also reduced substantially, like from 100->20 or something similar or if using EIP2930 were re-jigged to not price the user out up front and pack in risk of not using the loads (main reason why people do not use it imo)
Do we not want people to burn the native token?
Addendum:
If EIP2929 applies across a block, I could be more for this, but that still leaves a lot of risk with the executor of multiple batched transactions.
@bennypoloven-netizen check this bro
Hello all,
I don’t understand the rationale behind this change. From the EIP itself (which is very short):
- DoS Attacks: A single transaction consuming most or all of the block gas can result in uneven load distribution and impact network stability.
Why couldn’t an attacker just DoS with multiple transactions? Just for the 21,000 initial gas of each transactions?
- State Bloat Risks: High-gas transactions often result in larger state changes, increasing the burden on nodes and exacerbating the Ethereum state growth problem.
Why? Again for the 21,000 gas?
- Validation Overhead: High-gas transactions can lead to longer block verification times, negatively impacting user experience and network decentralization.
Why 1 transaction of 10M gas is harder to verify than 10 transactions of 1M gas (actually my intuition is that it’s the opposite)?
edit: (from a chat with @Giulio2002) different transactions are (more likely) executable in parallel. Which explains 3.
Also, as stated earlier in the thread, putting a value lower than the current block gas limit is technically a breaking change. How can we know that there aren’t some critical actions in some smart-contracts that take more than 16M gas?
Thanks for the answers.
edit: this thread contains a lot of info about the rationale behind this EIP and the breaking change.
Hey @MathisGD , I would not claim to know what the original poster believes, but how I would answer your question is as follows:
Why couldn’t an attacker just DoS with multiple transactions? Just for the 21,000 initial gas of each transactions?
I don’t know about all clients, but for erigon there is a spam limit where the node will start dropping transactions intentionally if you get above 16 (check me on that number) transactions in the mempool. I am sure there are other spam reduction measurements in other clients.
Why? Again for the 21,000 gas?
Usually this is achieved via sstore’s since it is an easy gas operation to create. Just increment a number and write it to a mapping.
How can we know that there aren’t some critical actions in some smart-contracts that take more than 16M gas?
I agree. There are / will be more often. Check out: EIP-7825: Transaction Gas Limit Cap - #17 by 3commascapital
1 Like