Ethereum Postponed its Hard Fork, But Some Miners Didn’t Listen

Ethereum’s developers tried to postpone Constantinople at the last minute, but a sizable number of miners didn’t pay attention. | Source: Shutterstock

On January 15, Ethereum’s developers put out a security alert that they were postponing the scheduled Constantinople upgrade. Not everyone made the appropriate changes, however, and there is a currently a parallel universe of Ethereum mining. A “chain split” has occurred, and some miners are mining the unofficial Constantinople chain without consensus from the majority of the network.

Update to Stop The Upgrade

The delay came after potential vulnerabilities were discovered in one of the new upgrades. As the statement delaying the fork says:

We are investigating any potential vulnerabilities and will follow with updates in this blog post and across social media channels.

Out of an abundance of caution, key stakeholders around the Ethereum community have determined that the best course of action will be to delay the planned Constantinople fork that would have occurred at block 7,080,000 on January 16, 2019.

People need to install a new version to avoid violating consensus.

It seems not all of the miners got the message. At least 10TH/s worth of mining power was still mining the unofficial chain at the time of writing, according to a fork monitor owned by Ethdevops.io:

Not everyone got the message. There’s actually more hashpower mining the aborted Constantinople upgrade than there is mining Ethereum Classic. (forkmon.ethdevops.io)

At time of writing, there was actually more hashrate on the forked version of Ethereum than on Ethereum Classic:

Ethereum Classic, which suffered a 51% attack recently, has less hashpower than the failed Constantinople version of Ethereum. (source: etcstats.net)

‘Non-Zero Risk’

The vulnerability in question allows for a peculiar form of scamming which it takes some degree of sophistication to understand. The bottom line is that a change in the way Ethereum charges for storage enabled an attack that could cost a lot of money to various dApps. A “reentrancy attack” is specific to smart contracts. It’s not the same as a replay attack or a double-spend. It’s a unique problem. ChainSecurity, who uncovered the flawed code, explains it this way:

Certain preconditions have to be met to make a contract vulnerable:

1. There must be a function A, in which a transfer/send is followed by a state-changing operation. This can sometimes be non-obvious, e.g. a second transfer or an interaction with another smart contract.

2. There has to be a function B accessible from the attacker which (a) changes state and (b) whose state changes conflict with those of function A.

3. Function B needs to be executable with less than 1600 gas (2300 gas stipend – 700 gas for the CALL).

Although the vulnerability isn’t anywhere on the actual blockchain, it’s better safe than sorry, says Ethereum’s official blog:

Security researchers like ChainSecurity and TrailOfBits ran (and are still running) analysis across the entire blockchain. They did not find any cases of this vulnerability in the wild. However, there is still a non-zero risk that some contracts could be affected.

Understandably, with a large decentralized network, it’s impossible to get a network upgrade through to everyone in a timely manner. Looking at a Bitcoin node map will show you that several different versions are active on the network at a given time. A minority of mining nodes are currently mining the Constantinople fork as if it had happened, regrettably not earning any actual valid Ethereum in the process.

Featured Image from Shutterstock