Ethereum’s Constantinople Hard Fork Delayed Due to Discovery of Critical Bug

/latest/2019/01/ethereums-constantinople-hard-fork-delayed-due-to-discovery-of-critical-bug/

On Tuesday (January 15th), Zurich-based blockchain security firm ChainSecurity announced that it had discovered a critical bug in Ethereum’s code changes for the Constantinople upgrade that could leave some smart contracts vulnerable to attacks that could lead to loss of user funds. This means that the Constantinople hard fork, which was expected to be activated around 20:00 PT on January 16th (i.e. 04:00 UTC on January 17th) at block number 7,080,000, has had to be delayed.

ChainSecurity offers three types of services:

  • smart contract audits (based on its “proprietary audit platform”);
  • a secuity audit platform (a set of “automated tools for developers and auditors” — this takes a smart contract and its formal specification as inputs and produces a security report as the output; and
  • security monitoring (“ideal for exchanges and response teams”) — this type of monitoring “inspects smart contracts on-chain to ensure compliance and absence of security exploits”.

ChainSecurity’s Medium blog post, which was published earlier today, was titled “Constantinople enables new Reentrancy Attack.” Here was the summary of the critical vulnerability that they had discovered:

“The upcoming Constantinople Upgrade for the ethereum network introduces cheaper gas cost for certain SSTORE operations. As an unwanted side effect, this enables reentrancy attacks when using address.transfer(…) or address.send(…) in Solidity smart contracts. Previously these functions were considered reentrancy-safe, which they aren’t any longer.”

So, basically, ChainSecurity was saying that the implementation of one of the Constantinople’s five main changes, EIP 1283, contained a critical bug. This discovery led to Ethereum’s core developers, as well as other stakeholders such as Ethereum creator Vitalik Buterin, meeting virtually and agreeing to delay the hard fork while they studied this issue, with a further meeting scheduled for this Friday to decide on a new fork date.

This is how the Ethereum Foundation announced (at 21:45 on January 15th) the news about the postponement of the Constantinople hard fork:

Ethereum Foundation’s blog post had this avice for anyone running a node:

“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.

This will require anyone running a node (node operators, exchanges, miners, wallet services, etc…) to update to a new version of Geth or Parity before block 7,080,000. Block 7,080,000 will occur in approximately 32 hours from the time of this publishing or at approximately January 16, 8:00pm PT / January 16, 11:00pm ET / January 17, 4:00am GMT.”

This blog post pointed out that “if you are a person who simply interacts with Ethereum (you do not run a node), you do not need to do anything.” This includes smart contract owners (since “the change that would introduce this potential vulnerability will not be enabled”).

As for those running an Ethereum node, it advised them to update their “Geth and/or Parity instances when they are released.”

Featured Image Credit: Photo via Pexels.com

Leave a Reply