If the goal here is to improve worst-case parallelism (and consequently avoid DoS attacks on validators/zk provers), then this EIP does not help. Assuming that state contention is the limit for parallelism, a transaction with 30M gas limit can be broken into 2 ~15M gas-limit transactions that have storage/account read/write behavior that requires sequential composability. Only reducing the block gas limit or adding some additional state contention validity rules (like Solana does) would help with that.
Re: quadratic attacks: clearly the present 30M transaction gas limit does not pose a DoS threat to the L1 from quadratic attacks. I am not suggesting to increase the transaction gas limit beyond its present value. EIP-7825 is a good idea and is necessary. I am arguing that the ~16.8M limit is too low from an ecosystem perspective AND MOST IMPORTANTLY setting the limit below 30M is a breaking change, which is a major sin and should be avoided.
Now speaking specifically about the challenges that the ~16.8M have on my corner of the ecosystem: to put it simply, it causes an exponential increase in the complexity of the problem of exchange of tokenized value. And I do mean literally exponential. I represent 0x, a leading EVM DEX aggregation platform. We recently ported our DEX aggregation technology to Solana. Solana prioritizes throughput and parallelism over developer experience. The problem of DEX aggregation in an ecosystem that constrains state contention is NP-hard. This increase in complexity makes it more difficult for new entrants to the ecosystem to operate searcher/solver/aggregator stacks (which all require the ability to efficiently solve value flow/exchange problems). Additionally, the desire/requirement for “big” transactions that contend for more state than is allowed in-protocol causes developers to seek out-of-protocol solutions. This causes more flow through private mempools/builders (Jito) to achieve multi-transaction atomicity, compromising decentralization. Tying this back directly to the present EIP: on L2s where gas is cheap, 0x’s APIs routinely return transactions that exceed the proposed cap. This will cause users (or 0x API) to seek multi-transaction atomicity through Ethereum block builder networks or the adoption of more complex, costly routing/MEV technology. If gas throughput is the primary desire, to the detriment of decentralization, then Ethereum would not offer enough differentiated value compared to other L1s. Solana would be the superior choice.
Additionally, a ~16.8M transaction gas limit makes it difficult to deploy “big” contracts. 0x’s router contracts are quite large, pushing the 24KiB Spurious Dragon limit. Deploying a full complement of router contracts already exceeds the proposed limit. See transaction 0xadc4e06a7a4c9442c14d1cf90c384d175e7e39f49f713924461c368253cb2697
. Of course, this can be broken up into multiple transactions, with attendant increase in orchestration complexity, but now you’re giving up on atomicity. But more importantly, if we were to adopt an enhanced version of EIP-7907, it would constrain deployed contract bytecode sizes. Monad L1 testnet has already demonstrated that very large contracts (128Kib) are possible/practical, and this limit curtails that kind of innovation/enhancement.
TL;DR: a ~16.8M gas limit is a breaking change, which should be avoided as to not squander developer goodwill, create a reputation for Ethereum as an unstable platform upon which to build, and to avoid breaking existing dApps. This EIP has second-order ecosystem-wide impacts on application competition that are not fully explored in the discourse around this EIP. We already have examples of broken dApps and degraded developer experience, which should on its own be sufficient reason not to adopt this change. But on top of that, we do not know what we do not know about ecosystem impact.
This EIP should not be adopted as is.