Discussion topic for EIP-7987
Update Log
- 2025-07-06: initial draft
External Reviews
None as of 2025-07-06
Outstanding Issues
None as of 2025-07-06
consider the following scenario: the gas limit is 45M, and there are three 16.7M transactions in the mempool and nothing else that pays the base fee. Then the block builder can only include two of those and we lose almost 33% of the block. That’s an unlikely edge case, but that’s a peculiarity of this cap compared to 30M or 15M. What we could do though is agree that the block gas limit should be n*2**24 so that we can guarantee that the block builder can include at least n transactions if the mempool has at least n.
The concerns expressed in the EIP-7825 thread of course still apply to this EIP, as much if not more so.
(also the github link is to the wrong EIP)
This isn’t how the fee market works, and what you’re describing is block packing (in-)efficiency. If the only transactions that can make it in are two 16.7M gas ones, then either the basefee is high and those senders are willing to burn a lot of ETH. With the exponential pricing from EIP-1559 in place, it definitely is a edge case.
Also, gas must be paid for: it’s not enough to just set a high gas limit but use little gas. So this kind of spamming “attack” isn’t actually an attack, the cost is simply too high.
1 Like
The best motivation here is parallelization. Singular transactions are purely sequential. While unbatching transactions doesn’t improve the worst case, it can improve the best case.
A fixed cap reduces the risk of DoS attacks caused by excessively high-gas transactions.
I’m not convinced of this. Gas is fungible. If a malicious user is outbidding everyone else with one transaction, they can also outbid with two transactions at the same price. Can you elaborate what you mean?
By capping individual transactions, the validation of blocks becomes more predictable and uniform.
If fewer transactions are more burdensome than more transactions, that just means that the base transaction gas (21000) should be recalibrated. It is possible that the gas advantage of batching is too large, if the transaction overhead (nonce, signature, value) isn’t properly calibrated.
I don’t think this is the correct solution to facilitate parallelization. I can DoS your parallelization by creating a bunch of transactions reading and modifying the same slot. In the same block, this would be worse than a singular transaction. Perhaps a better solution would consider this possibility. I know you’ve also been doing work on the block access list proposals. Perhaps hot slots should cost more, not less. An alternative solution might be for the block producer to specify the before and after values per transaction, which would allow the contentious transactions to be validated in parallel.
Yeah agree, it’s mostly about enabling parallelization, assuming we eventually have the tools for parallel validation.
On DoS risks, I’m more worried about unknown unknowns, e.g., quadratic attacks where some resource doesn’t scale linearly. If an attacker fills a block with max calldata or SLOADs, splitting into 2–3 txs only adds ~21k gas each, so the mitigation is weak. This is true and I wouldn’t even call it a mitigation for such attacks at all.
With block-level access lists, we might want to revisit pricing, possibly deprecate warm access discounts or add caps on storage.
Declaring touched accounts/slots could lead to block bloat if a tx intentionally hits random addresses or storage. You’d get to a worst-case block larger than the worst-case calldata block if you don’t reprice storage at the same time.
I explored some sizing impacts here:
1 Like
Some projects do have use cases for transactions exceeding this limit, for example “Emergency Shutdown” (re: global settlement and the ilk). Convex has systemShutdown that exceeds 16M in one, giant, transaction.
1 Like
Thanks for this resource. Reaching out to matt with more questions.
Do you know more such examples?
How old do you want?
if we set the txn gas limit cap ~at the current block limit and then keep it fixed as the block size expands, we don’t have to ship something that isn’t backwards compatible (but hopefully get the ~same long term benefits?). Just an idea I wanted to throw out there, anyway
That’s true but it also means intentionally choosing to allow a few large transactions at the cost of limiting scaling potential that many others could benefit from.
Backward compatibility is, of course, very important. Changes like the one being proposed must be made carefully, with full consideration of the trade-offs and the parties affected.
Still, after weighing everything, I’ve come to the conclusion that the change is worth it.