Ethereum’s Upgrades: Why Constantinople Fork Is So ‘Hard’ to Implement

More than a year ago software developer and member of the Ethereum Foundation, Hudson Jameson, announced plans to launch Metropolis, the third stage on the way to moving the platform to Proof-of-Stake (PoS). All this time, the developers have been keeping secret the date of its final phase, called Constantinople, which is to be held in the form of a hard fork on the network.

On September 14, during one of the team’s bi-weekly video calls, it finally became known that the planned hard fork was on track for its mainnet release in November. However, due to “a consensus issue”, which happened during the testing of a new update on October 13, the developers decided to delay Constantinople until January 2019.

On the way to Proof-of-Stake

Ethereum was designed as a platform for decentralized applications (DApps), and four main upgrades have been laid down in its development in order to make the network’s functional better suit this purpose. With the ultimate goal of the Ethereum Foundation to follow Vitalik Buterin’s vision and move from a Proof-of-Work (PoW) to a Proof-of-Stake protocol, the network is supposed to solve the mining and scalability related problems.

While this transition is planned to be made during the system’s final upgrade called Serenity, the preparation began almost immediately after the launch of the Ethereum network. The roadmap was divided into five main parts, with Byzantium and Constantinople being part of one phase called Metropolis.

What is Constantinople

The upcoming Constantinople hard fork includes five different Ethereum Improvement Proposals (EIPs) to smooth the transition from PoW to PoS. Once released, they would fundamentally change the Ethereum blockchain via a host of new upgrades, which prevent any backwards compatibility, meaning that nodes must either update synchronically with the entire system or carry on running as a separate blockchain entity.

Essential role of Constantinople in delaying the “Difficulty Bomb”

Furthermore, the Constantinople hard fork includes changes to Ethereum’s underlying mining economic policy and the delay of the “Difficulty Bomb”, aimed at making the production of new blocks more complex and unfavourable. This is a set of code programmed to trigger the so-called “Ethereum Ice Age”, the main purpose of which is to make mining unprofitable and promote transition to PoS.

The Ethereum Ice Age is designed to ensure that all participants switch to the new network after a hard fork is implemented. The bomb gradually complicates ETH mining, increasing the mining block time. With the introduction of the Casper update as part of the Serenity milestone, the complexity is supposed to grow higher. Miners will not be able to match the increase in complexity: the purchase of new equipment and its configuration will simply be economically unprofitable. Thus, the network will be left without miners and will “freeze” – the Ice Age will come. The bomb was introduced in September 2015, soon after the launch of the Ethereum network.

The “Difficulty Bomb” delay will be included in Constantinople to maintain the stability of the system, by leaving the network in the same state as before. Reducing the block reward also decreases the likelihood of a miner driven chain split as Ethereum approaches Proof-of-Stake.

Five elements of Constantinople

Code optimization and network stabilization, the main purposes of Constantinople as part of the scaling roadmap, will be reached through the implementation of five EIPs. These are the standards, developed by the Ethereum foundation members at different times, which include core protocol specifications, client APIs, and contract standards.

EIP 145

Feb. 13, 2017

An improvement proposal written by Alex Beregszaszi and Pawel Bylica to introduce native bitwise shifting as a more efficient method of information processing on Ethereum blockchain.

EIP 1014

April 20, 2018

Created by Vitalik Buterin, the upgrade is aimed at providing a better scaling solution based on "off-chain" transactions. It allows interactions to be made with addresses that do not exist on-chain yet but can be relied on.

EIP 1052

May 2, 2018

A proposal by core developer Nick Johnson, allows the optimization of large-scale code executions on Ethereum.

EIP 1234

July 19, 2018

Written by Parity release manager Afri Schoedon, EIP 1234 is supposed to reduce block mining rewards from 3 ETH to 2 ETH, and delay the “Difficulty Bomb” for 12 months. The changes are mainly directed towards network stabilization and smoother preparation for the implementation of the next upgrades, to gradually move away from PoW.

EIP 1283

Aug. 1, 2018

Based on EIP 1087, this upgrade mainly benefits smart contract developers by reducing excessive gas costs where it doesn’t match how most implementation works.

In a nutshell, all five EIPS have impacts to Ethereum that affect a number of the wider goals and initiatives still to be managed after the final release of Constantinople. Péter Szilágyi, lead developer of a popular Ethereum client, Geth, said that “the EIPs are mostly done.”

Timeline of the hard fork failure

The upgrade was originally scheduled to be launched on the Ropsten test network on October 14, but unexpectedly happened 24 hours ahead of schedule.

First, the hard fork stalled at block 4,299,999 for two hours, indicating that Constantinople hadn’t been properly activated by miners. Even after testnet block processing resumed after an extended break, zero transactions were seen in the post-hard fork blocks.

Zero transactions records on Etherscan, October 21, 2018. Image source: Etherscan

Afri Schoedon, a developer at Parity, was the first to provide a solid update on his Twitter. He elaborated that a consensus issue had unfortunately occurred, catalyzing a three-way fork between Geth, Parity, and other Ethereum clients responsible for maintaining and upgrading the network. The thing is that ten developers groups are involved in the development of EIPs and the implementation of tests, and not all of them managed to get prepared for the release on time.

Image source: Github

Six days after the failed attempt, on October 19, the developers held a video call, where Schoedon provided a more in-depth analysis on what happened.

Image source: Jacek Sieka @jcksie

He pointed out that the deviation from the scheduled go-live time left many Ethereum community members and miners unprepared to support it, leading to a desynchronization of chains.

Even after block 4,300,000 was mined, which was previously set as a starting point of the Constantinople launch, Schoedon explained that clients were “using the wrong config” and were following the Byzantium protocol, which is what the Ethereum mainnet is built on today.

In a post-mortem of the Ropsten hard fork, the Parity developer touched on a few more points, writing:

  • Recently added hashpower caused reduced block times and caused this hard fork to happen much earlier than expected on Saturday which is, by all means, the worst time for a hard fork.
  • Hard fork happened only 6 days after Geth release and 1 day after Parity Ethereum release, users had not enough time to upgrade.
  • There is no fork monitor available, only http://ropsten-stats.parity.io which does not reveal details about the different chains.

However, delaying Constantinople may be a reasonable decision, according to Schoeden, as the arrival of it in the middle of the above inefficiencies would create more problems than it would solve:

“I keep getting the feeling that we’re trying to rush this and I would second that we should breathe and see what happens… I’m not comfortable talking about the hard fork date until we have the tests for Constantinople ready.”

During the meeting, the Ethereum Foundation team further discussed the Constantinople hard fork, which was announced on the official GitHub account of Ethereum. The next call will be on November 9, due to DevCon, which will be held from October 30 to November 2.

Concluding the meeting, the Parity tech developer, Afri Schoedon, has informed the community that the mainnet hard fork wouldn’t happen before the end of January, at the earliest. He also