Designing a transaction fee market for Ethereum that accommodates parallel execution by charging transactions based on resource utilization and demand.
Ethereum’s current fee market does not differentiate between transactions that access a single resource and those that access multiple resources, as long as they require the same amount of computation. This is well-aligned with the current implementation executing transactions on a single thread. However, one often-proposed Ethereum scaling approach involves parallelizing execution across multiple threads, which fits well with the abundance of multi-core consumer hardware. Achieving this efficiently requires redesigning the incentives structure: transactions that normally cost the same might impact parallelization differently, like by accessing multiple high-demand resources, which introduces scheduling contention.
We aim to explore the fee market design in light of parallel execution, focusing specifically on the fee component related to computation. Specifically, we will investigate ways to compute a transaction’s gas usage that reflect its “parallelizability.” For example, transactions that utilize many resources should be charged more than those that use a single resource, as the latter requires locking fewer resources for the duration of execution. Similarly, transactions that utilize resources in high demand should incur higher fees than those using low-demand resources, as the latter are easier to schedule efficiently.
Moving towards parallel execution appears to be the most straightforward approach to scaling Ethereum L1 without overburdening solo stakers. Consequently, exploring fee markets for this potential transition is highly relevant for the Ethereum ecosystem. Such markets would make the workload more parallelizable by incentivizing users to submit “simpler” transactions, leading to better throughput than just parallelizing with the current incentives structure.
While our method focuses on the execution component, in practice, gas accounts for multiple other aspects, such as data bandwidth and storage. Moving toward real-world deployment could follow two paths. On the one hand, we could integrate the new execution gas measure into Ethereum’s existing framework by adjusting the current gas weights. On the other hand, a more principled approach would be incorporating the new execution gas measure into a multi-dimensional fee market, with one component being execution and others related to storage, data bandwidth, etc. In addition to the benefits from a multi-dimensional fee market this would also allow for a more straightforward implementation of an effective method for computing execution gas in the respective component. Regardless of the chosen path, the new method of computing execution gas usage needs to be integrated with existing transaction fee mechanisms (e.g., EIP1559) to create a fee market capable of handling parallel execution. Identifying an effective method for computing execution gas usage in a parallel execution environment could be the foundation for the real-world deployment of parallel execution-aware transaction fee mechanisms on Ethereum L1.
The following deliverables were made available in support of this ROP:
We will follow the “axiomatic approach,” prevalent in the social choice theory, mechanism design, and game theory literature. To do this, we will begin with identifying a set of desirable properties (”axioms”) that the market should attain to set up the right incentives for parallelization. Afterward, we will propose alternative gas computation schemes and evaluate the resulting markets against the axioms, aiming to weigh the strengths and weaknesses of each scheme and ultimately put forward alternative market proposals that should achieve the desired effect.
The axiomatic approach has been successfully applied in the Transaction Fee Mechanism Design literature (see relevant references below). In contrast to us, these works keep the gas component of the market fixed and vary the mechanism for determining the base fee per gas unit, striving to achieve axioms like user incentive compatibility (UIC) and miner incentive compatibility (MIC). Notably, none of these efforts consider parallelizability, which will be the main focus of our normative treatment.
Transaction Fee Mechanism Design and Analysis: