Ethereum [ETH] Constantinople delay post-mortem: Vulnerability could have been discovered earlier

Earlier this week, Charles St. Louis, a member of Ethereum Cat Herders, published the post mortem report of the Constantinople hard fork postponement, on his official Medium page. The report outlines the process of the decision taken by the community during the timeframe, and the measure that could have been taken to prevent the postponement.

Constantinople hard fork is part of the third stage of Ethereum, Metropolis. Apart from the upcoming hard fork, Byzantium hard fork, which occurred in October 2017, is also a part of the third phase. Prior to Metropolis, the two phases of Ethereum were Frontier and Homestead. The next and the final phase ‘Serenity’ introduces major updates to the network, with Proof-of-Stake – Beacon and Casper, Plasma, Zero-knowledge proofs being the key-upgrades.

The hard fork that was supposed to take place earlier this month proposed five Ethereum Improvement Protocols [EIP]’s, with the main light on EIP 1234, written by Afri Schoedon. This EIP proposed the delay of the difficulty bomb for another 12 months and the thirdening – reduction of the block reward from 3 ETH to 2 ETH.

Among the five improvement proposals, the one that led to the delay of the hard fork is EIP 1283: Net gas metering for SSTORE without dirty map. On the eve of the hard fork, ChainSecurity, an audit platform for smart contracts, announced that their team has discovered a potential vulnerability in the implementation of the protocol. The team discovered that the implementation would result in smart contracts being vulnerable to a Reentrancy attack, which would have been enabled while using address.transfer[…] or address.send[…], after the hard fork.

According to the post-mortem report, there were five major factors that were involved in the hard fork postponement decision. This included: deciding whether the issue could be fixed or not, the potential risk of delaying the hard fork and not delaying the hard fork, emergency call with Ethereum stakeholders/developers, the community’s sentiment and discussion of trading security for efficiency. Furthermore, the report states that the issue could have been discovered earlier.

“ChainSecurity utilizes Truffle/Ganache for security analysis however the first Constantinople-ready Ganache version came out only six days before the hard fork […] There are reports that other security researchers in the ecosystem suspected this vulnerability but did not prepare an official bug bounty or report it because they assumed it was already known.”

Here, it has been concluded that developer tools in the ecosystem should be incentivized more and that developer tool readiness should be taken into account during the hard fork schedule discussion. It also states that there should either be new documentation or an update of the existing documentation on how to disclose vulnerabilities or suspected vulnerabilities.

“Include extensive resources for reporting or discussing potential issues — not just official bug bounties. These should include key bug bounties across the ecosystem (not just the official EF bug bounty program), relevant chat rooms, encouraging people to comment on EIPs, pointing people to Github issues, security, bugs, PGP, support email, forums, security Telegram channels, etc.”

According to the recent decision, the hard fork is scheduled to occur on block #7,280,000, which would take place around February 27, 2019. This time, there will be two hard forks that will occur on the same block. The first hard fork will include all the proposed EIPs except for EIP 1283 and the second hard fork will allow test networks and private networks an option to undo the Constantinople changes, especially the networks that are already forked. The post-mortem stated:

“Individual testnets and private networks that already implemented the original Constantinople will trigger the two forks on different blocks at their discretion”