Ethereum's Constantinople Hard Fork Upgrade Delayed Until Early 2019

  • Ethereum's hard fork upgrade, Constantinople, has been postponed until at least end of January 2019.
  • Issues related to Ethereum community members not using the latest versions of Ethereum's clients (Parity and Geth) have been cited as being partly responsible for delay.

Ethereum’s (ETH) core developers have all agreed to postpone the planned hard fork of the blockchain-based smart contract platform until January of 2019. The developers made this decision on Friday, October 19.

As CryptoGlobe covered in mid-September, Ethereum’s hard fork (backwards incompatible upgrade), referred to as Constantinople, had been tentatively scheduled for November of 2019.

Hard Fork Transition Fails On Testnet

After testing the hard fork on Ethereum’s public testnet, Ropsten, on October 13, which allows developers to check whether smart contracts and other upgrades are bug-free before launching on mainnet, the platform’s developers have agreed not to do the upgrade until early next year.

The meeting, which has been recorded and published on YouTube, involved Ethereum’s developers openly discussing the current challenges the platform is facing - with one developer noting that it might be more “politically” correct to refer to Constantinople as an update, instead of a hard fork.

The decision to delay the upgrade came after a number of issues were encountered when testing its codebase on Ropsten. According to Ethereum’s development team, the fork experienced problems at block number 4,299,999 - right before its planned activation at block number 4,230,000.

After stalling at 4,299,999 for about 2 hours, miners participating on the testnet failed to activate the transition. Alfri Schoeden, an Ethereum client developer, revealed the failed activation may be attributed to “a consensus issue” - which led to what he described as a “three-way fork” between two Ethereum clients: Parity and Geth.

Not Enough Time To Upgrade

Schoeden, who had prepared the agenda for the virtual meeting, noted that “recently added hashpower caused reduced blocktimes and caused this hardfork to happen much earlier than expected on a Saturday.” He added that this was “by all means the worst time for a hardfork.” 

According to Schoeden, the timing of certain events - which occurred in close proximity to each other - might have caused the hard fork to fail on he testnet. He explained that the fork attempt had been initiated only six days after the launch of the latest version of the Geth client, and only 1 day after Parity’s.

This, he suggested users weren't given enough time to install the required upgrades, while there was also a “consensus” issue found in Parity’s latest version - based on results from the “post-mortem” report which may be accessed from the “Fellowship of Ethereum Magicians” website.

"Not A Single" Miner On Constantinople Chain

Furthermore, Schoeden pointed out that “not a single” miner had been mining on the Constantinople chain, which led to the two-hour delay before block 4,230,000 could be processed. Other issues noted during the meeting were that the Ethereum community does not have a reliable tool yet to effectively monitor hard forks launched on testnets. Ethereum client Parity has a website that tracks stats, however, Schoeden said it “does not reveal details about the different chains.”

Meanwhile, Ethereum developer, Hudson Jameson, liked an idea suggested by another developer - which is to “regularly spawn and mine temporary testnets to test transition into Constantinople.” This, Jameson thinks would allow for issues to be detected on a “baby’ testnet so that “if something goes wrong we’ll know it pretty quickly.”

As covered, the following interdependent ethereum improvement proposals (EIPs) have been planned to go into effect with Constantinople:

  • EIP 145 - more cost-effective and efficient approaching to processing information
  • EIP 1014: better approach to accommodating network scaling solutions such as off-chain transactions
  • EIP 1052 - an improvement on how contracts are processed
  • EIP1234 - 12-month delay of difficulty bomb; reduce mining rewards from 3 ETH to 2 ETH
  • EIP 1283 - a better way to monetize data storage changes (made by smart contract programmers)

Also as covered, Ethereum co-founder Vitalik Buterin delivered an Ethereum history lesson and recapped the details related to its ongoing development in mid-August through 75 different tweets.

Vitalik Buterin Calls Ethereum’s Scalability a ‘Big Bottleneck’

Michael LaVere
  • Vitalik Buterin calls Ethereum's scalability a "big bottleneck" issue. 
  • Proposes a network system that does not require each computer to verify transactions. 

Ethereum co-founder Vitalik Buterin had some interesting words on the state of scalability for ETH, calling it a pressing issue facing the cryptocurrency. 

Ethereum Scalability

In an interview with The Star published on Aug. 19, Buterin said that scalability has become the primary hurdle for organizations interested in using Ethereum’s blockchain, and that the issue has become a “big bottleneck.”

He said, 

Scalability is a big bottleneck because the Ethereum blockchain is almost full. If you’re a bigger organization, the calculus is that if we join, it will not only be more full but we will be competing with everyone for transaction space. It’s already expensive and it will be even five times more expensive because of us. There is pressure keeping people from joining.

Buterin proposed an alternative to the vice grip of scale that has plagued most blockchain-based projects, including cryptocurrency. He speculated that the Ethereum’s network should evolve beyond the need to have every computer verify each transaction.

Instead, he believes that a blockchain can remain secure while utilizing a model that has connected computers only verifying a small portion of the transactions on average. 

When asked whether this would compromise the existing security of blockchains, Buterin said, 

There would be a sacrifice but it would be fairly modest.

However, he also said that implementing such a system would reduce scalability costs by “a factor over 100,” for every transaction. 

In addition to scalability, Ethereum’s co-founder also highlighted challenges in usability, posing the rhetorical question, “how do you turn it into something people will use?”