Ethereum Istanbul Hard fork: Developer raises concerns over implementation of EIP 1884

Ethereum’s upcoming hard fork, Istanbul, is all set to go live with six improvement protocols in the coming months. The Testnet launch is scheduled to take place in Septemeber, while the block number is yet to be decided for the Mainnet upgrade.

The hard fork was set to launch in September. However, it was delayed as all clients failed to merge accepted EIPs, and the schedule was pushed to a later date. According to the most recent meeting, all clients are supposed to merge the six EIPs by September 6. Geth and Pantheon are the only clients that have merged all the protocols, while Parity is lacking behind with just 1 EIP merged. This has also resulted in some of the community members throwing tantrums, with claims that their main project at present was Polkadot, instead of Ethereum.

While the date for the upgrade is yet to be decided, a developer has raised concerns over the implementation of an accepted EIP. The EIP in question is EIP-1884, proposed by Martin Holst Swende, a security lead at Ethereum Foundation. The Ethereum EIP blog post states,

“This EIP proposes repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption […] The growth of the Ethereum state has caused certain opcodes to be more resource-intensive at this point than they were previously. This EIP proposes to raise the gasCost for those opcodes.”

Source: Ethereum Org

Wei Tang, Rust Developer at Parity Tech, expressed concerns about the implementation of this particular EIP. Notably, this was previously brought up during the 69th All Core Dev call. Tang stated that the protocol would “break at least a few deployed contracts,” further stating that the blockchain should be backward compatible.

“One of the reasons why Windows gain popularity is because of backward compatibility. Linux has a policy that it will never break user-space programs. You can run ancient operating systems on modern CPUs. #Ethereum shouldn’t be of exception if it wants to have a bright future.”

This issue was previously addressed by Holst Swende in a GitHub post, stating that the protocol “can always break contracts that explicitly rely on assumptions of gas cost being constant.” The post further stated that this could impose problems for default functions as “it might start to fail on 2300 gas.”

Source: GitHub

Source: GitHub

Jameson Hudson, Community Manager at Ethereum Foundation, weighed into Tang’s concerns on Twitter. With regard to the proposed backward compatibility, Hudson said,

“Normally you would think having backwards compatibility is an obvious answer. In this particular situation there are a few potential problems with this: 1) We arguably have a precedent set that OPCODE prices can and will change so your contracts should not rely on the assumption that they will not change.”

He added,

“If we start making exceptions we lose our ability to make needed OPCODE changes in the future. 2) It can be argued that by making this breaking change we are “ripping the band-aid off” in a way so people will be better prepared for even more drastic changes that are needed for state size management, like state rent.”

This was followed by Hudson presenting a different scenario, where the backward compatibility is implemented without completely analyzing the damage caused by this particular EIP. He asserted that once the blockchain is backward compatible, then developers could “intervene in contracts in ways that may appear, or may actually be, outside of our jurisdiction perse.”

The decision regarding this issue was made during the dev call,

Source: GitHub