Istanbul hard fork may lead to broken Ethereum contracts

By Jeff Benson

At the August 23 Ethereum Core Devs Meeting, Martin Holst Swende was unapologetic about the ramifications of Ethereum Improvement Proposal (EIP) 1884, one of six changes being made as part of the eighth Ethereum hard fork.

"So, yeah, we know it's going to break things, theoretically," he said, summing up the issue.

After discussing EIP 1884 two weeks ago, the core devs today determined that the testnet hard fork will go ahead around October 2, but they declined to set a block number for the mainnet, in case more things break than expected. 

Specifically, EIP 1884 will raise the gas cost of underpriced opcodes, i.e., the instructions within smart contracts. The argument for doing so is straightforward: As the size of the Ethereum network expands, certain smart contracts used by dapps are using a lot of computing power but paying relatively little in terms of gas costs to compensate. 

According to the EIP, written by Swende, that discrepancy creates vulnerabilities: "It could be used for attacks, by filling blocks with underpriced operations which causes excessive block processing time."

It continues by noting the practicality of the change:

"Underpriced opcodes cause a skewed block gas limit, where sometimes blocks finish quickly but other blocks with similar gas use finish slowly […] If operations are well-balanced, we can maximise the block [gas limit] and have a more stable processing time."

It makes sense, then, to up the gas limit. The problem, however, is that some contracts are coded in a way that relies on the gas cost staying the same. Swende points out that this isn't best practice. After all, the Tangerine Whistle hard fork, which superseded The DAO in late 2016, changed one of the OPCODE gas costs from 50 to 200. It was reasonable for smart-contract developers to assume costs might rise again. 

Swende also notes that, after EIP 1884 is implemented, default functions—one method smart contracts use to transfer Ether—might also fail, disabling wallets or only allowing payments below a certain limit.

One developer present at the August 23 meeting was Parity Technologies' Wei Tang. He's worried. He argued in the meeting, and in subsequent tweets, that the developers should take steps to avoid accidentally freezing contracts before Istanbul. Primarily, he pushed backward compatibility.

To simplify, applying backward compatibility would more or less grandfather current contracts in at their current gas cost, while putting new contracts at the post-hard fork rates. And it's completely doable, Tang told Decrypt:

"Backward compatibility is an implementable feature on Ethereum/EVM. The reason why we're not doing that in Istanbul hard fork is mostly due to time restraints.” Tang said that governance issues have taken long, so meatier changes like EIP 1702, which is backward compatible, have been set aside for a future hard fork.

Hudson Jameson, who organizes the core dev calls, wrote later on Twitter: "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."

But Tang is worried that the band-aid might rip off some skin. While he says the EIPs in Istanbul are "mostly simple ones," he worries about the PR consequences of contracts breaking bad. In the meeting, he raised the specter of the Parity Multisig hack from 2017, which prompted Parity to float the idea of a hard fork to unfreeze 500,000 ETH stuck in a wallets linked to a frozen contract.

And while security concerns have been part of the reason behind the push to get Istanbul running, Tang suggests that not taking the time to pursue backward compatibility has its own risks, which could manifest in a network attack. This can be done by developing smart contracts that don’t seem vulnerable and then proposing gas cost changes that render them dysfunctional. 

“If the effect was hidden, or core devs were convinced that the backward incompatible change is acceptable,” Tang told Decrypt, “then the malicious entity can disrupt the network, or steal user funds."

The issue of EIP 1884 re-emerged in today's meeting, with some small degree of consensus forming around the approach. After Tang reiterated his view, Swende agreed that the devs should be ready to make right any unintended consequences—but not for contracts from developers that have seen this change coming. 

"I definitely think that if we break things, we should fix it afterwards. Yes,” Swende said. “But I do think that in all the cases where it's just, 'Oh, it's hard, we need to upgrade to a new contract and it's a pain in the ass'—I don't think that needs fixing. I think they need to take that pain and go through with it because they need to change the behavior of the contract."

Recommended News