Ethereum drafts two ways to handle Glamsterdam gas changes

Two Ethereum developers filed separate draft proposals on November 8 to address the gas changes planned for Glamsterdam. Leo Glisic’s proposal would keep the existing rules for deployed code and apply repricing through a new set of instructions. Giulio Rebuffo’s proposal would preserve the old rules for the gas a contract can use while charging the transaction sender under a separate schedule. Both pull requests were open when CoinAbout checked them on November 9.

The choice matters to anyone whose contract calls older code, relies on a fixed gas allowance or tries to recover from a failed call. The drafts put the compatibility boundary in different places. Under Glisic’s approach, the type of call and the target’s code version can decide whether the call proceeds. Under Rebuffo’s approach, an inner call can have enough execution gas and still lose its chance to finish because the transaction as a whole has exhausted its billing allowance.

One worked example shows where compatibility ends

Consider a simplified transaction under Rebuffo’s draft. After earlier charges, both counters have 6,000 units remaining. Suppose a repeated operation uses 1,000 execution credits and costs 2,500 billing units each time. The first two operations fit, leaving 4,000 execution credits and 1,000 billing units. The next operation would need 2,500 billing units, so it runs into a 1,500-unit shortfall even though there are enough execution credits. Under the draft’s billing-exhaustion rule, that third operation does not run and the transaction aborts.

The numbers are illustrative. They are neither proposed prices for a particular instruction nor results from executing a transaction. The example isolates a consequence of the design. A caller that has kept enough execution credits for cleanup still cannot continue after a billing abort. The draft calls for rolling back the application effects across the transaction while retaining specified effects such as the sender’s nonce and fee. The unused execution credits do not offset the fee. The draft would bill the full signed gas limit in this case.

Glisic’s versioned-opcode specification creates a different failure boundary. Imagine newly deployed code trying to run an old library in its own context through the proposed versioned delegate call. The library’s version would fail the target check before its code ran. The instruction would report failure to the caller, with the usual return of unused gas. An ordinary call to that same old code would remain allowed and the callee would run its own instructions under the old schedule. That distinction matters because an ordinary call changes the execution context and may be unsuitable for a system designed around delegated code.

Versioned instructions move the change to deployment

In Glisic’s draft, an opcode is an instruction executed by the Ethereum Virtual Machine. The proposal creates V2 counterparts for instructions affected by the repricing. A deployment check would examine the final runtime bytecode and reject new code that contains a replaced legacy instruction or a disallowed instruction for inspecting gas. Accepted code would carry a version marker. Code already deployed would keep the legacy rules for its legacy instructions.

That gives a developer a concrete starting point for a compatibility review. A system making ordinary calls into older contracts has a different dependency from a new system delegating execution to an older implementation. A legacy proxy can remain deployed while a later implementation runs V2 instructions, so the age of the address users interact with would tell only part of the story. Reviewers would need to identify the bytecode that actually runs and the instruction used to reach it.

The draft also removes the ability for V2 code to read certain gas values directly. It sketches alternatives such as standardized out-of-gas signaling and gas-spent receipts, leaving them to companion proposals. Its rationale anticipates that more execution will move to V2 as code is replaced over time. How quickly that happens matters for the proposed path toward higher network capacity, since legacy activity would continue using the earlier schedule. The draft does not demonstrate that migration rate or set a date for it.

Separate counters move the change to transaction billing

Rebuffo starts both counters from the same signed transaction gas limit. Contracts would still read their remaining execution credits through the usual gas interface. Calls would still forward credits using the legacy rules. The separate billing counter would charge for work at the new rates across the transaction, including work inside nested calls. An internal call receives an execution allowance from its caller without receiving a separate billing budget.

An ordinary inner call that runs out of execution credits can still return a failure to its caller under the legacy rules. Billing exhaustion has a wider scope. An inner call can consume enough of the shared allowance that the next billable operation stops the entire transaction, including unrelated work grouped into the same batch. Conversely, a cheaper billing charge cannot increase the credits forwarded to a call. That separation is why the draft’s compatibility claim depends on enough billing capacity remaining.

The submission discussion says the author had checked the document’s consistency but reported neither an execution-client implementation nor consensus tests for the design. The specification still leaves the exact charge and rebate schedule, receipt fields and block accounting open. Those are practical dependencies for wallets and relayers. A gas estimate that predicts the contract can execute under its credit rules would still need a way to account for billing, and an application reimbursing its users would need to distinguish the two measurements.

There is another edge case for a transaction that can exactly afford its next operation. The billing draft would allow that operation to run with zero billing left afterward. An abort happens when a later positive charge cannot be paid. A simulator that treats zero as an immediate failure could therefore disagree with the proposed rules. It would also need to account for any subsequent charge before declaring the transaction complete.

What the new drafts change about the Hoodi decision

The October 22 postponement notice withdrew Hoodi’s planned October 26 activation and the accompanying increase to a 200 million gas limit. The November 6 Foundation notice kept the testnet fork on hold while compatibility issues are resolved and asked projects to check assumptions in their own contracts and off-chain software. Neither new pull request sets a replacement Hoodi date or establishes that its approach has been selected.

The Foundation’s compatibility checklist remains relevant to both drafts. It covers fixed allowances and stipends as well as what applications infer from a failed call, a receipt or the gas left afterward. For example, its pinned Amsterdam reference measured 110,020 gas for a cold write to a new storage slot against 22,100 under the earlier Osaka specification, about 4.98 times as much. That operation comparison illustrates why a fixed budget deserves scrutiny. It does not supply a transaction fee or a final billing rate for either new draft.

The counterargument to assuming either design will protect an application is that compatibility must hold across the full transaction. For versioned instructions, evidence would include tests spanning existing implementations, new deployments and both ordinary and delegated calls. For separate billing, it would include tests of nested calls, batch rollback, the signed fee ceiling and receipt interpretation under concrete charge rules. Agreement on a draft, published client behavior and a new Hoodi activation notice would each answer a different part of the readiness question. Until those decisions are documented, the two drafts show what developers could change and where each approach still needs evidence.