Great work. I think it would be useful to coordinate the resource and fee fields of EIP-8141 with the direction explored in EIP-7999, particularly given the ambition for frame transactions to provide an enduring transaction format. This could make the transition to a multidimensional fee market more seamless. Some preparation is already in place in EIP-8141, e.g., in the form of the explicit per-frame state dimension with limits and fees carried as nested lists, and some can still be developed further. Two adjustments are described below, followed by a question/discussion about how the frame design relates to multidimensional EVM gas accounting.
Use byte limits instead of gas limits
The transaction should ideally specify its state limit in bytes. The same would go for a future data limit: more generally, capacity is best specified in native resource units.
The first benefit is that we can protect users across fork boundaries when the gas cost of a resource is adjusted. If the limit is denominated in gas and the gas cost rises, a previously sufficient limit may become insufficient, causing the transaction to fail. This kind of failure is already quantified for the Glamsterdam repricing candidates in the repricing analysis, which distinguishes transactions that fail at their original gas limit but succeed with a higher one.
It is not necessary to maintain the denomination in state bytes within the EVM. For simplicity, we can convert a specified state_bytes_limit to state_gas_limit immediately when processing the transaction:
state_gas_limit = CPSB * state_bytes_limit
The existing accounting can then proceed unchanged. The transaction would still need to satisfy its fee limit, but a change in CPSB would no longer reduce the amount of state creation permitted by its state limit. Wallets would also no longer need to read the current CPSB merely to express that limit correctly.
A second benefit is that byte limits can have a smaller encoding, taking up less space in the transaction. A third is that bytes are a more intuitive unit for state creation, both for users and developers. Looking further ahead, state creation may eventually interact with execution only through the transaction’s total fee. At that point, expressing state limits in gas would only be confusing.
Use a unified max fee
The transaction should ideally specify one unified max_fee, denominated in wei, as in EIP-7999. As explained in its economic rationale, separate max fees per resource can prevent inclusion when relative resource prices change, even though the user’s total budget is sufficient. Spare max fees assigned to one resource cannot compensate for an insufficient max fee on another.
A unified max_fee lets the transaction remain eligible for inclusion as long as its total budget covers the required costs. It also more directly expresses what users generally care about: how much they are willing to pay for the transaction. These benefits grow as the number of separately priced resources increases, but already apply to the separate max fees for regular gas and blob gas. A single transaction-wide max fee is also compatible with keeping each frame’s resource limits separate.
A unified max_fee would also be a convenient anchor for the mempool to reserve against the payer: the worst-case cost is then a signed transaction field rather than a quantity derived from limits and per-unit fees (and, for blob-carrying transactions, from the current blob base fee).
Further note that if state becomes separately priced, a max_fee_per_state_byte would match a state_bytes_limit more naturally than a max_fee_per_state_gas. Separate max fees would however retain the economic inefficiency described above, so I would favor a unified max_fee.
Implications for multidimensional EVM gas accounting
Finally, I think it would be useful to discuss how EIP-8141 gas accounting relates to the EVM gas-accounting designs discussed for EIP-7999.
As I understand the current design, each transaction frame has its own execution and state budgets. Within a frame, CALL(g) controls execution gas, while all nested calls share the frame’s state budget. Execution gas cannot cover state charges when that budget runs out, unlike under the EIP-8037 reservoir mechanism. Thus, a paymaster could for example reserve resources for its post-operation work in a later frame, without the user’s earlier frame being able to consume them.
Within an ordinary contract call, the situation is different. As Jochem noted, a successful subcall can consume the enclosing frame’s remaining state budget, leaving its caller unable to create state afterward even if it retained sufficient execution gas. This matters for existing contracts that reserve gas for that purpose, and it also gives an untrusted callee a way to block state creation by its caller. Moving the later work into another transaction frame can provide the necessary reservation where the application supports that structure.
I would be interested in hearing how these considerations were weighed when developing EIP-8141. It would be useful to discuss which resource-reservation needs are met by separate transaction frames, which remain within ordinary calls, and what this suggests for the accounting model we ultimately choose for Ethereum.
These choices have implications for several of the models being considered for EIP-7999, including S and M+O_S. Applying subfee accounting (S) would mean that each transaction frame executes against a scalar gas budget usable for execution, state, and data (data here referring to data metered during execution, rather than calldata, which EIP-8141 prices at the intrinsic level outside the frame budgets).
Multidimensional accounting with subfee overflow (M+O_S) would instead retain dedicated resource budgets and add an overflow accounted for using subfee conversions. In that design, the legacy scalar gas interface would control the overflow. Both approaches would therefore require changes to EIP-8141’s currently specified accounting, including what GAS reports and what CALL(g) controls.