Two Ethereum developers submitted competing proposals on Sunday to prevent Glamsterdam, Ethereum's next major software upgrade, from breaking existing apps that hold users' funds. Both proposals remain drafts, and neither has a target date.
Glamsterdam proposals EIP-8037 and EIP-8038 would increase gas charges for creating and accessing stored data. Gas measures the cost of each operation performed by a smart contract, the program underlying an Ethereum app. EIP-8037 would increase the base cost of creating a contract from 32,000 gas to 183,600 gas, excluding code storage and execution costs. Many Ethereum apps were designed around the assumption that those costs would remain unchanged. Some apps allocate a fixed amount of gas when calling another app, so higher costs would cause those calls to fail. Many deployed apps cannot be modified.
The risk has already delayed upgrade testing. Glamsterdam is running on one Ethereum test network, where developers can check changes without putting real funds at risk. A second rehearsal scheduled for October 26 was postponed after security researchers raised concerns. Security researcher pcaversaccio argued that Glamsterdam must not launch in its current form because of the gas increases. The researcher said Ethereum's core developers had been alerted to those concerns two weeks earlier. Pseudonymous developer banteg said the ethereum/repricing-impact list already contained 200,000 affected contracts. Banteg said methodological problems caused the assessment to miss many additional contracts. Banteg said the changes affect the deployment and operation of several prominent protocols, rather than only developers misusing available opcodes.
Leo Glisic's proposal, EIP-8488, would divide Ethereum's instruction set into two versions. Existing contracts would retain the current gas schedule. Newly deployed contracts would have to use V2 opcodes with the gas schedule specified by EIP-8037 and EIP-8038.
Giulio Rebuffo's proposal would apply the new gas prices to all contracts while allowing existing apps to continue executing under the old rules. Rebuffo's draft proposes a pair of gas meters for each transaction. One meter would measure execution according to the old rules. The other meter would apply the new gas schedule to calculate the transaction fee. Rebuffo's draft acknowledges that the design has not undergone an execution-client implementation or consensus testing.