- The scheduled October 26 testnet rehearsal for Ethereum’s Glamsterdam upgrade was postponed following serious warnings from security researchers.
- Critics warn that planned gas increases could break high-profile protocols, with over 200,000 smart contracts already identified as potentially impacted.
- Core developers and researchers are drafting alternative solutions, including Glisic’s EIP-8488 dual-instruction set and Rebuffo’s dual-metering gas framework.
The rollout of Ethereum’s Glamsterdam upgrade has hit a critical roadblock as community developers and blockchain security researchers urge core teams to rethink planned changes to network execution costs. While Glamsterdam is currently running on one of Ethereum’s practice networks—the testing environments where developers trial core modifications prior to real-world deployment—a key secondary rehearsal slated for October 26 was abruptly postponed in response to severe technical concerns.
Security Researchers Raise Alarms Over Gas Schedule Changes
The primary concern stems from proposed gas repricing, which critics argue could disrupt the functionality of thousands of deployed decentralized applications. Prominent security figures have taken to public forums to demand that client teams halt the current deployment pipeline until these vulnerabilities are addressed.
Voicing deep concern regarding the current trajectory of the network fork, security researcher pcaversaccio highlighted prior notifications delivered to development teams. imho Glamsterdam should not be shipped in its current form, period,
security researcher pcaversaccio wrote on X, referring to the gas increases, which he said he had flagged to Ethereum’s core developers two weeks earlier.
Echoing these findings, pseudonymous developer banteg warned that the current blast radius of the proposed changes is significantly wider than initially estimated by network teams. besides the already huge list of 200,000 affected contracts in ethereum/repricing-impact, i found multiple methodological issues that make it miss many more,
he wrote on X. it affects deployment and operation of several high profile protocols, not just some random devs misusing opcodes that were given to them.
Competing Proposals Emerge to Avert Breaking Changes
In response to the risk of widespread operational failures across existing smart contracts, developers are drafting competing Ethereum Improvement Proposals (EIPs) to mitigate the damage while still achieving the upgrade’s underlying optimization goals.
One primary pathway under review is EIP-8488, authored by developer Glisic, which proposes bifurcating Ethereum’s execution environment to shield legacy applications from the changes. Glisic’s draft, EIP-8488, splits Ethereum’s instruction set in two. Existing contracts keep the legacy schedule,
it says, while new contracts must use V2 opcodes that carry the EIP-8037/8038 gas schedule.
An alternative architectural model has been proposed by developer Rebuffo. Rebuffo’s draft runs two gas meters per transaction instead, one that tracks execution under the old rules and one where billing uses the new schedule and determines the transaction fee.
However, this approach carries its own developmental hurdles; the proposal also admits no execution-client implementation or consensus tests have been run for this design.
Why This Matters
Ethereum smart contracts are designed to be immutable, meaning live protocols cannot simply be updated if changes to underlying execution costs (opcodes) exceed fixed gas assumptions embedded in their original code. The delay of the October 26 rehearsal underscores the delicate balance Ethereum core developers must strike between long-term protocol scalability and backwards compatibility.
Because the potential fallout extends beyond minor projects to several high-profile decentralized finance protocols, client teams must reach a consensus on whether to proceed with dual-instruction models like EIP-8488, novel multi-metering structures, or further testnet delays to ensure network stability before any mainnet deployment.
Frequently Asked Questions
Why was the Glamsterdam testnet rehearsal postponed?
The rehearsal scheduled for October 26 was paused after security researchers and developers warned that proposed gas schedule increases would break thousands of existing smart contracts, including those powering high-profile decentralized protocols.
What is EIP-8488 proposed by Glisic?
EIP-8488 is a draft proposal that seeks to prevent contract failures by splitting Ethereum’s instruction set. Under this design, existing contracts retain the legacy gas schedule, while newly deployed contracts are required to use updated V2 opcodes that implement the newer gas schedules.
How does Rebuffo’s alternative proposal work?
Rebuffo’s draft outlines a system that tracks transactions using two simultaneous gas meters—one that monitors execution under historical rules and a second that handles fee billing under the updated schedule. However, the proposal notes that no execution-client implementations or consensus tests have been conducted yet for this model.
