Ethereum Constantinople Hard Fork Issues Unveiled

← back to the list


Ethereum Constantinople Hard Fork Issues Unveiled

Posted on October 18th, 2018 in Blockchain News by Ryan Warner

Lane Rettig, an independent Ethereum core developer, recently posted a "post-mortem" report as well as his concerns with the Constantinople hard-fork on the Ropsten Testnet. The report details the various issues uncovered with the hard-fork which was scheduled to be implemented at the end of October.

As per the report, a consensus bug was discovered the Parity implementation of Ether. The reasons why the bug was not discovered by testers and why the bug occurred was explained. He said:

“Apparently, in this case, there was some confusion over the meaning of terms like ‘transaction’ and ‘execution frame’ that may have contributed to the bug.”

There were additional concerns with the absence of miners in Parity, Aleth, Geth, or Ropsten. During this time, Afri Schoeden, asked for miners to run on Parity 2.0.7, 2.1.2, or Geth 1.8.17 "configured for Ropsten."

Rettig surmised there needed to be a better understanding and control of mining over the Proof-of-Work Testnet. He also stated Parity had a limit on “how far back nodes could automatically reorganize themselves". This is because the hard fork is too long for Parity Ethereum nodes.

Understanding this mechanism is important as Parity has this limit, but Geth does not, he added. Additionally, Geth has a debug.set head command whereas Parity does not, which allows users to force it onto the correct chain. Rettig said:

“Is this supposed to be a limit on ‘on chain governance’ [allowing nodes to automatically come to consensus on the canonical chain] that triggers the need for meatspace/developer intervention? Or is it more about resource constraints? What’s the limit and why is it set as such?”

He added:

“It’s possible for an upgraded node in fast sync mode (geth or parity, I believe) to fast sync over a bad block which caused a fork and keep following the wrong chain. This is clearly the shortcoming for fast sync but we should discuss this in the context of forks and long reorgs…”

Rettig stated Ropsten currently has four chains making it difficult for a node to sync to find the right chain. This is because of the peering process occurring on the wrong chain. Rettig stated:

“In this case, it was necessary for nodes to turn off discovery entirely and manually enter a set of peers to get caught up to the right chain."

Rettig was also concerned that the primary means of communication through Gitter on the AllCoreDevs channel was disorganized and had no threading. This made it difficult to find information in a canonical order. 

He also stated that since the launch of Constantinople on the Ropsten Testnet it has been effective unusable or extremely difficult to use. They are also expecting to have several active forks. Adding:

“This begs the question, what is a testnet? What is its purpose? Do we need stable, ‘production’ testnets and ‘staging’ testnets?”