Two Ethereum developers, Leo Glisic and Giulio Rebuffo, submitted rival proposals on Sunday that outline separate strategies for protecting applications already deployed on the network. Both address the potential consequences of Ethereum Improvement Proposals EIP-8037 and EIP-8038, which would increase the gas required for certain smart contract operations. The dispute has become a significant issue for Glamsterdam, as developers assess whether the proposed pricing changes can be introduced without interfering with contracts that were engineered around Ethereum's existing gas schedule.

Glamsterdam Gas Changes Draw Compatibility Concerns

At the center of the controversy are EIP-8037 and EIP-8038, two proposals included in the planned Glamsterdam upgrade that would modify the cost of creating contracts and accessing stored blockchain data. Gas is the unit Ethereum uses to measure the computational resources required to execute transactions and smart contract instructions, and changes to gas pricing can alter how applications behave, particularly when developers have programmed contracts around specific execution limits.

Ethereum upgrades such as Glamsterdam bundle multiple EIPs into a single coordinated change to the network's rules, and proposals typically move through core developer review, client implementation, and testnet testing before an activation decision is made. The current dispute is playing out inside that process: the objections are surfacing while Glamsterdam is still in testnet evaluation, before anything reaches the main blockchain.

Under EIP-8037, the base gas charge for creating a smart contract would rise from 32,000 to 183,600 gas, with additional costs tied to code storage and execution applied separately. The increase has raised concerns because some existing Ethereum applications were developed with the expectation that certain operations would continue to consume the same amount of gas.

Some contracts allocate a fixed gas allowance when interacting with other applications. If the cost of those interactions climbs beyond the allocated amount, the operations could fail. The stakes are particularly high for smart contracts that cannot be modified after deployment, since such applications may have no straightforward mechanism for adapting to a revised gas schedule.

Security Researchers Warn of Widespread Contract Disruptions

The concerns have already affected Glamsterdam's testing timeline. Although the upgrade has been deployed on an Ethereum test network, a second testing exercise scheduled for October 26 was postponed following warnings from security researchers. Ethereum test networks allow developers to evaluate protocol changes before they reach the main blockchain, where applications and transactions involve real assets. Gas schedules have been revised in previous Ethereum upgrades as well, which is why repricing proposals are routinely checked against contracts written to older cost assumptions.

Security researcher pcaversaccio publicly criticized the proposed gas adjustments, arguing that Glamsterdam should not proceed in its existing form.

"imho Glamsterdam should not be shipped in its current form, period," pcaversaccio wrote on X.

The researcher said the concerns had been raised with Ethereum core developers two weeks earlier.

Pseudonymous developer banteg also questioned the scope of existing compatibility assessments, pointing to a list of approximately 200,000 potentially affected contracts in the ethereum/repricing-impact repository. According to banteg, methodological limitations in the assessment could mean that substantially more contracts are affected than the existing list indicates. The developer further warned that the proposed changes could interfere with the deployment and operation of several prominent Ethereum protocols, rather than affecting only less widely used applications.

The warnings have intensified scrutiny of how Ethereum developers intend to implement the gas repricing while preserving the functionality of contracts already operating on the network.

EIP-8488 Proposes Separate Gas Rules for Existing and New Contracts

Glisic's proposal, identified as EIP-8488, introduces a compatibility mechanism that would distinguish between smart contracts deployed before the upgrade and those created afterward. Existing contracts would continue operating under Ethereum's current gas pricing rules, while newly deployed contracts would use a revised set of instructions reflecting the higher gas costs introduced by EIP-8037 and EIP-8038.

The proposal would effectively divide Ethereum's instruction set into two versions, allowing older applications to retain their established execution costs while requiring new applications to follow the updated pricing structure.

"Existing contracts keep the legacy schedule," the EIP-8488 draft states.

New contracts would be required to use V2 opcodes associated with the revised gas schedule. The approach is intended to reduce compatibility risks for applications that cannot be upgraded, while allowing Ethereum to introduce its planned gas pricing changes for future deployments.

Alternative Proposal Introduces Dual Gas Accounting

Rebuffo has put forward a different mechanism that would apply the new gas pricing schedule to transaction billing while preserving existing execution behavior for older smart contracts. Rather than maintaining separate instruction sets for old and new applications, the design would introduce two gas accounting mechanisms within each transaction. One meter would track contract execution according to the existing gas rules, while a second would calculate transaction charges using the updated pricing schedule.

Under this structure, the new schedule would determine the transaction fee, but older applications would continue executing under the assumptions established by the previous gas rules. The proposal aims to separate the calculation of transaction costs from the execution conditions that existing smart contracts depend upon.

The draft acknowledges, however, that the design remains untested at the implementation level.

"no execution-client implementation or consensus tests have been run for this design," the proposal states.

Developers Face Decisions Over Glamsterdam Gas Changes

The competing proposals highlight different approaches to addressing the same compatibility problem. Glisic's EIP-8488 would preserve existing gas pricing for previously deployed contracts while introducing the revised schedule through new instructions. Rebuffo's alternative would apply updated transaction billing while retaining legacy execution behavior. Both approaches seek to prevent the planned gas repricing from disrupting applications that rely on Ethereum's existing execution costs.

The issue has attracted attention because the affected contracts may include established protocols that cannot easily modify their deployed code. With testing already delayed following security warnings, the proposals introduce potential technical solutions for developers evaluating Glamsterdam's compatibility risks.

The milestones that would move the debate forward are concrete: a rescheduled testnet round run with a compatibility mechanism in place, and, if either draft is to advance, execution-client implementations and consensus test results to evaluate it. Until those steps occur, the compatibility question remains open as Glamsterdam moves through its development cycle.

The available information does not establish whether either proposal will be adopted. Rebuffo's design also remains without execution-client implementation or consensus test results, leaving its technical feasibility subject to further evaluation.

Source: CoinDesk

First published by: Hokanews