Ethereum New Proposal EIP-7983: Exploring Transaction Gas Limit

Recently, the Ethereum community is discussing a new proposal called EIP-7983. This proposal was put forward by Vitalik Buterin and Toni Wahrstaetter, aiming to set a hard gas limit for each transaction, specifically 16,777,216 gas (i.e., 2²⁴). The purpose of this initiative is to enhance the stability and execution efficiency of the network.

In the current Ethereum mainnet, a single transaction can theoretically use the entire block's gas. This design, while flexible, may lead to issues such as resource concentration and uneven node load, thereby affecting overall performance. The core idea of EIP-7983 is to enforce a limit that forces some oversized transactions to be split, preventing a single transaction from consuming too much network resources.

It is worth noting that this limitation will not change the total gas capacity of the block and does not involve modifications to the consensus rules. It simply introduces a new restriction during the transaction execution process. If a transaction exceeds the set limit before entering the block, it will be rejected during the validation stage.

For execution environments that rely on parallel computing, such as zero-knowledge virtual machines (zkVM) and potential future multithreaded execution models, this limitation helps prevent extreme transactions from slowing down the entire block processing flow. In the execution layer logic, this limitation resembles a "resource usage specification," allowing each transaction to be more evenly divided while keeping the total amount unchanged, which is beneficial for the overall scheduling and execution of the network.

The proposer of EIP-7983 aims to reduce the risk of denial of service (DoS) caused by extreme trading through this measure, while improving the overall predictability of the execution process. For the operating environment, this limitation helps simplify the validator's execution logic and alleviates the pressure caused by concentrated resource consumption.

However, this proposal has also sparked some discussions and concerns. Some advanced applications, such as contract deployment and complex DeFi operations, may require additional transaction splitting, which could increase the complexity of user interactions. Moreover, the differences in how gas is displayed and handled across different platforms may initially lead to understanding costs and inconsistencies in usage.

It should be noted that EIP-7983 primarily targets denial of service attacks during the transaction execution phase, and does not directly address the attack behavior of manipulating transaction sorting in the memory pool by using high gas transactions. Therefore, it focuses more on limiting resource overload on the node side, rather than addressing all forms of network attacks.

Overall, EIP-7983 has practical significance in enhancing node execution stability and supporting future parallel architectures. However, its scope of constraints is limited, and it may need to be combined with other mechanisms to comprehensively address network security issues.

The community has mixed opinions on this proposal. Supporters believe that setting a gas limit for transactions aligns with Ethereum's direction of simplicity, security, and modular development, and helps improve network performance and user experience, especially in an environment where zkVM and Layer 2 solutions are gradually maturing. Opponents are concerned about the complexity and compatibility risks that might arise from transaction splitting, and point out that network issues stem more from smart contract design rather than transaction gas limits.

EIP-7983 reflects the community's concerns regarding network stability and execution efficiency. Despite the challenges and disagreements, it provides a potential solution for the execution and scalability of the Ethereum base layer. Considering Ethereum's current multi-layered scaling and modular development direction, EIP-7983 has certain practical value. However, its final impact needs to be evaluated based on community adoption and actual implementation results.