Ethereum’s hardfork Constantinople is delayed due to a security breach

Ethereum hardfork Constantinople delayed due to security breach

On the 15th of January 2019, the Ethereum Core Developers and the Ethereum Security Community were made aware of the potential issues related to the Constantinople Hardfork that was due to start today.

Major Ethereum clients such as Parity and Go-Ethereum (Geth) have released software updates following an earlier decision to delay the planned Hardfork which would have occurred at block 7,080,000.

Geth released an emergency hotfix designed to delay the fork. However users who do not wish to upgrade to the new version can continue running on the current version 1.8.20 or can as well downgrade their clients to a version 1.8.19. The same applies to parity clients, they can either upgrade to the stable release or the beta release or downgrade to version 2.2.4.

Kirill Pimenov, Head of Security at Parity Technologies spoke in an Ethereum core developers chat on Gitter recommending users not to downgrade to an older version but instead to upgrade to the new release. Kirill says that downgrading Parity to the older version is a bad idea;

“I want to restate — downgrading Parity to pre-Constantinople versions is a bad idea, we don’t recommend that to anyone. Theoretically it should even work, but we don’t want to deal with that mess.”

Constantinople Hardfork that was due to start today

What Led to the Delay?

The long awaited upgrade was postponed after the blockchain audit firm Chain Security discovered a security issue in Ethereum Improvement Proposal (EIP) 1283, one of the upgrades included in the Hardfork. If the Constantinople upgrade goes through, the bug will allow for ‘’re-entrance attacks’’, and therefore malicious actors or fraudsters will be able to withdraw funds from the same source multiple times.

According to the Ethereum Blog Post, Chain Security and TrailOfBits, another security researcher, are still running analysis on the entire blockchain to ensure that no contract s affected. The post also stated that users who do not run a node or anyone who does not participate on the network does not need to do anything at all.

Smart Contract owners do not need to do anything either, though they may decide to examine the potential risks and check their contracts. According to the blog post, no risks have been discovered in live contracts so far but it states quite clearly that there is still a ‘’non-zero’’ risk that some contracts could be affected.