Ethereum Constantinople Postponed Out of an Abundance of Caution

Corey Petty -

Despite Status nodes bearing no impact from these hardfork changes, we will continue to support and monitor for the greater security of the Ethereum Network.  

The Ethereum Core Developers and the Ethereum Security Community were made aware of the potential Constantinople-related issues identified by ChainSecurity on January 15, 2019. 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.

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.

What You Need To Do

If you are a person who simply interacts with Ethereum (you do not run a node), you do not need to do anything.

Miners, Exchanges, Node Operators:

  • Update your Geth and/or Parity instances when they are released.
  • These releases are not released yet. We will update this post when they are available.
  • Links and version numbers and instructions will be provided here when they are available.
  • We expect to have updated releases in 3–4 hours from the time this blog is published.

Geth

  • Upgrade to 1.8.21 , OR
  • Downgrade to Geth 1.8.19, OR
  • Remain on 1.8.20, but use the switch ‘–override.constantinople=9999999’ to postpone the Constantinople fork indefinitely.

Parity

Everyone Else:

Ledger, Trezor, Safe-T, Parity Signer, WallEth, Paper Wallets, MyCrypto, MyEtherWallet and other users or token holders that do not participate in the network by syncing and running a node.

  • You do not have to do anything.

Contract owners

  • You do not have to do anything.
  • You may choose to examine the analysis of the potential vulnerability and check your contracts.
  • However, you do not have to do anything as the change that would introduce this potential vulnerability will not be enabled.

How was the decision to postpone the Constantinople fork was made

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.

Because the risk is non-zero and the amount of time required to determine the risk with confidence is longer the amount of time available before the planned Constantinople upgrade, a decision was reached to postpone the fork out of an abundance of caution.

Parties involved in the discussions included, but were not limited to:

  • Security researchers.
  • Ethereum stakeholders.
  • Ethereum client developers.
  • Smart contract owners / developers.
  • Wallet providers.
  • Node operators.
  • Dapp developers.
  • Media.

Response Time

  • 3:09am PT
    • ChainSecurity responsibly discloses potentially vulnerability via Ethereum Foundation's bug bounty program
  • 8:09am PT
    • Ethereum Foundation’s asks ChainSecurity to publicly disclose.
  • 8:11am PT
    • Original article by ChainSecurity is published.
  • 8:52am PT
  • 8:52am PT - 10:15am PT
    • Discussion occurs across various channels regarding potential risks, on-chain analysis, and what steps need to be taken
  • 10:15am PT - 12:40pm PT
    • Discussion via Zoom audio call with key stakeholders. Discussion continues in gitter and other channels as well
  • 12:08pm PT
    • Decision made to delay Constantinople upgrade
  • 1:30pm PT
    • Public blog post released across various channels and social media

Background

The article by ChainSecurity dives deep into the potential vulnerability and how smart contracts can be checked for the vulnerability. Very briefly:

  • EIP-1283 introduces cheaper gas cost for SSTORE operations
  • Some smart contracts (that are already on chain) may utilize code patterns that would make them vulnerable to a re-entrancy attack after the Constantinople upgrade takes place
  • These smart contracts would not have been vulnerable before the Constantinople upgrade

ChainSecurity’s article goes into details about the attack and what can be done to check if your smart contract code is vulnerable.

Contracts that increase their probability to being vulnerable are contracts that utilize a transfer() or send() function followed by a state-changing operation. An example of such a contract would be one where two parties jointly receive funds, decide on how to split said funds, and initiate a payout of those funds.

Status smart contracts are at extremely low risk of any impact of this vulnerability. However, we are still monitoring and testing rigorously. It is important to note that Status nodes only use Geth nodes for Whisper, therefore, these hardfork changes do not impact Status.

In support of the Ethereum Foundation, we will continue to monitor and test rigorously as needed.

For specific questions or concerns, please feel free to contact us in the Status public channel #status-security

This article was put together in a collaborative effort by EvanVanNess, Infura, MyCrypto, Parity, Status, The Ethereum Foundation, and the Ethereum Cat Herders.

For the full text and latest Geth/Parity versions, please read the Ethereum Foundation’s blog post here: https://blog.ethereum.org/2019/01/15/security-alert-ethereum-constantinople-postponement/