Recently, Lane Rettig, an independent core developer of Ethereum [ETH] posted a “post-mortem” report and his concerns regarding the Constantinople hard fork on Ropsten Testnet. The report covered the various issues discovered during the hard fork, which was set to be implemented by the end of October 2018.
According to the report, a consensus bug was discovered in Parity implementation of Ethereum. He explained the reasons why the bug was not discovered by the Ethereum testers and why the consensus bug occurred. Rettig added:
“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.”
In addition, there were concerns regarding the absence of miners on Parity, Geth, or Aleth for Ropsten. During that timeframe, Afri Schoedon, a developer posted a Tweet asking for miners to reach out to run mining hashrate on Parity 2.0.7, 2.1.2 or Geth 1.8.17 “configured for Ropsten”.
Rettig opined that there had to be a better understanding and control over mining on a Proof-of-Work [PoW] Testnet. He further stated that Parity had a limit on “how far back nodes could automatically reorganize themselves”. This was because the fork was too long for Parity Ethereum nodes, as stated by Afri Schoedon.
Rettig added that understanding this mechanism was important as Parity has the limit, which is absent in Geth. Furthermore, Geth had a debug.setHead command which allowed users to manually force it onto the right chain whereas Parity did not have any such feature. He added:
“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?”
“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…”
Furthermore, Rettig stated that Ropsten currently has four chains and that it is very difficult for a node to sync from scratch in order to find the right chain. This is due to the peering process occurring on the wrong chain. He 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”
Another concern raised by Rettig was that the AllCoreDevs channel on Gitter served as the primary means of communication throughout the hard fork but this was disorganized and had no threading. It was further difficult to find a canonical source of information.
According to Rettig, it was necessary to create a core developer “War Room” where this information could be managed during an upgrade or any other emergent situation.
He also stated that since the launch of Constantinople hard fork on Ropsten Testnet till press time, Ropsten was effectively unusable or very difficult to use. In addition, they were still expecting to have several active forks. He added:
“This begs the question, what is a testnet? What is its purpose? Do we need stable, ‘production’ testnets and ‘staging’ testnets?”
The post Ethereum [ETH] Ropsten Constantinople hard fork issues unveiled by core developer appeared first on AMBCrypto.