The Nov. 6 appeal says the delay continues pending resolution, while the notices leave mainnet activation unset.
The consequences extend from relayers recovering too little of their transaction costs to wallet authorizations becoming reusable after a particular kind of failure. That makes application repairability part of the evidence developers need when weighing changes to the upgrade.
Glamsterdam’s EIP-8037 would raise the cost of creating persistent blockchain data and meter that state growth separately from execution, and EIP-8038 would reprice access and writes to existing state.
The aim is to support higher throughput while controlling the data Ethereum nodes must retain.
The eight-invariant framework separates three price assumptions, covering fixed budgets and reserves, from five accounting assumptions involving gas returns, failure handling, billing and delegation.
Gas accounting changes payments and wallet safety
A relayer pays to execute a transaction for someone else and may recover that expense by measuring gas before and after the work. The framework’s INV-5 entry explains how the proposed accounting can disrupt that calculation.
Under EIP-8037, a transaction initially funds a separate state-gas reservoir when its gas limit exceeds 16,777,216. State creation draws from that pool first, then execution gas. Solidity’s gasleft() reading excludes the reservoir, so subtracting two readings can miss costs that the relayer actually pays.
If the later reading exceeds the earlier one, checked subtraction reverts, blocking the operation. Unchecked subtraction can wrap into a large number and potentially produce excessive reimbursement, depending on the surrounding arithmetic and payment checks.
Meanwhile, invisible reservoir spending can leave users undercharged and operators covering the shortfall.
The billing guidance suggests agreeing on a user-signed fee using an estimate under the new rules. Where metering remains necessary, clamping the subtraction and capping payment at a signed maximum limits the charge, while reservoir-funded costs remain outside the measurement.
An open specification proposal, PR #12581, would prevent gas readings from increasing. That would address the subtraction problem, but the reservoir’s billing blind spot would remain.
INV-8 examines EIP-7702 delegation, where an account authorizes delegated contract code. Under the proposed rules, insufficient gas during pre-execution can leave a transaction included in a block while rolling back its delegation and authorization-related update to the account’s sequence number, or nonce.
An exposed authorization that still satisfies its validity checks, including the authorizing account’s nonce, can then be reused. If the delegated contract also has an initializer that lets the first caller choose the owner, an attacker could apply the authorization and initialize ownership in one transaction.
Authorization front-running already existed in public mempools, but here a failed mined transaction can expose a reusable authorization even after private submission.
Delegations already applied before the top-level execution frame remain in place when that later frame fails. A failed receipt requires further checking of the account’s resulting code and nonce.
Suggested wallet safeguards include binding initialization to the account’s signature or self-calls and invalidating exposed authorizations. Charging the worst-case authorization cost upfront has also been suggested as a protocol change and remains unadopted.
Repair options enter the upgrade decision
Under the proposed schedule, creating a cold storage slot costs 110,020 total gas, versus 22,100 under Osaka. Of that proposed total, 12,100 is execution gas, and 97,920 is state gas, with the reservoir determining which balance funds the latter.
ChainSecurity’s Oct. 13 research shows how changed costs and returned gas can let a contract finish recording an underfunded operation as permanently unsuccessful. If that record removes the retry path, a valid operation can become impossible to repeat.
Revalidated budgets, propagating failures, and preserving retries address different parts of that risk.
The repository asks affected projects whether a setting, upgrade, or migration can fix their problem, and roughly when. Those answers help developers assess how much compatibility work applications can absorb and where specification changes could prevent damage.
Concrete reports of what breaks and how to repair it will inform the next specification discussions.
Leave a Reply