Designs for EVM gas accounting in EIP-7999

Дата публикации: 08-09-2026 10:48:50

Yeah, so to summarize where I think our discussion lands, the overflow can in essence be organized according to any of the three main gas budget models. To recap, these are:
A: Aggregate EVM gas, with one shared gas budget under a fixed relative gas schedule, funded conservatively at the highest relevant base fee.
S: Subfee accounting, with one shared gas budget under a floating relative gas schedule. The user specifies separate resource limits, which are converted into an aggregate gas budget at inclusion (to protect against gas cost drift), with resources charged using their relative base fees.
M: Multidimensional accounting, with separate resource budgets and fixed gas costs in their respective (separate) units.
We can consider each model alone, or use it as overflow behind dedicated multidimensional budgets. The main six configurations are thus:
X \quad\text{or}\quad M+O_X,\qquad X\in\{A,S,M\}.
M+O_A is Universal overflow with fixed gas costs; M+O_S applies the subfee model to overflow; and M+O_M uses an overflow vector as previously outlined. The vector’s separate forwarding rules let the caller retain a different resource mix from what it forwards to the callee.
So I do believe that in the M+O_S design, the user should still specify individual resource limits for the overflow in a vector, even though the overflow is collapsed into a single gas budget at inclusion. These individual resource limits are inputs to the conversion. They need not remain separately enforced during execution, but there can be benefits to such enforcement from a CR perspective.
Concerning the two accounting options you mention, yes, both fit this framework. The subfee market described in the post uses Option 1, where state is assigned a gas cost via the equation:
C_s= c_s\frac{b_s}{b_e},
where c_s is the baseline state gas per byte, b_e is the execution base fee and b_s is the state base fee.
Two further notes:
Could you expand on a rationale for setting a block-level target and limit for the overflow (besides perhaps leveling the block-building competitive landscape)? The way I see it, overflow primarily provides a scalar for legacy calls, as well as flexibility in resource use. The resources that the overflow turns out to consume should still count toward their respective targets and limits.
Vectorized gas limits and base fees like EIP-7706: I am fully on board. That is where we want to take it. But I still think we have it right with the max_fee set by the user being unified (as in EIP-7999).

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999	0	13.47	22-09-2026
2	When Data Binds Execution: Dynamic Simulation of EIP-7999’s Multidimensional Fee Market	0	10.98	16-09-2026
3	Letting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559	0	6.38	10-09-2026
4	Mempool Account Transaction Capacity from Historical Activity (MATCHA)	0	9.38	22-09-2026
5	Public-mempool gas sponsorship needs escrow, a bond, or trust	0	6.46	14-09-2026
6	Preserving censorship resistance for BAL data in EIP-7999	0	6.62	14-08-2026
7	EIP-0000 Preferential Gas Costs for Native ETH Operations – Draft for feedback	0	13.65	05-08-2026
8	Bloom Filters And Keyed Nonces	0	8.23	08-09-2026
9	EIP-8372: Normalized state gas limit	0	10.94	06-08-2026
10	Proprietary AMMs and Ethereum	0	10.18	08-09-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 4.9. Источник: ethresear.ch.