Ethereum co-founder Vitalik Buterin and Ethereum Foundation researcher Toni Wahrstätter have proposed a ceiling on how much gas a single transaction can use, and aim to tighten security while preserving efficiency as the protocol matures.
The draft proposal, EIP-7983, sets a 16.77 million gas limit per transaction. Interestingly, this is a significant change from the current architecture, where a single transaction can consume an entire block’s gas allowance.
Developers argue this open-ended design exposes Ethereum to denial-of-service (DoS) risks, inconsistent network load, and slower block verification, especially as the chain supports increasingly complex DeFi and zero-knowledge applications.
EIP-7983
By introducing a hard cap, Buterin and Wahrstätter seek to enforce more predictable resource usage without significantly disrupting typical user activity, noting that most transactions currently fall well below the proposed threshold.
Transactions of more than the 16.77 million gas cap would be rejected during validation. Such a move would ensure oversized transactions cannot enter blocks, while the block gas limit itself would remain adjustable by validators under existing consensus rules.
The authors frame the move as part of a broader effort to simplify Ethereum’s base layer and improve network reliability, which essentially echoes Buterin’s recent calls to streamline protocol design inspired by Bitcoin’s minimalist ethos.
Easing zkVM Constraints
Developers working on zkVMs and parallel execution engines have highlighted difficulties in handling transactions with unpredictable gas sizes. They believe a fixed ceiling could ease engineering constraints and allow better subdivision of workloads across threads.
The cap is also expected to reduce the risk of any single transaction monopolizing block resources, thereby improving consistency in execution times and block propagation. While the proposed limit may require some large deployments to split transactions into smaller segments, it aligns with Ethereum’s longer-term goal of supporting modular and provable systems while maintaining user experience.
EIP-7983 builds on the now-stagnant EIP-7825 but with a lower ceiling. The proposal is currently in draft status and is now open for community discussion as developers assess its practical impact on the network.
