Some of the Parity and OpenEthereum users are currently stuck between a months-long resync and a bugged client. It all started after an update in the OpenEthereum client made the nodes running on the new version virtually useless. OpenEthereum client is the community successor of the Parity client for Ethereum.
The bug seems to have come up in the 2.7.2 version of OpenEthereum. It was the same platform on which the subsequent 3.0 update was based as well. Although the 2.7 release was marked as entirely stable, the community started reporting since June about the client occasionally freezing. These incidents required a manual hard restart for the node.
This issue seems random “one or three times a month,” and interestingly the software does not notify of its malfunction. Some of its users have now decreed the release as “useless” and “broken for node operators.”
Developers appear to have focused on the issue blaming it on a subtle bug in thread concurrency. The thread is used to process various tasks in parallel. In this particular case, the software appears to be entering a deadlock. This is a condition where two threads are mostly left waiting for their turn to access some of the shared data.
OpenEthereum decided to shun the 2.7 release due to this bug and other “heisenbugs” that are majorly challenging to reproduce and thus fix. Notably, the new 3.0 iteration which is entirely based on the last truly stable 2.5 version. It is set for release in mid-September right before the Berlin hard fork.
OpenEthereum Nodes Greatly Affected
Until all that happens, nonetheless, all of the operators who downloaded the new version are left with the extensively disruptive task of downgrading. A developer at infrastructure developer BlockNative, Liam Aharon, highlighted on Twitter that downgrading needs a whole resync of the blockchain. The process may take months for some node configurations.
The bug affects around 50% of the current Parity nodes and all nodes that come under the OpenEthereum brand. Hence, it sums up to a cumulative 12% of the whole network as documented by Ethernodes data.
Currently, the OpenEthereum team is working on a conversion process to help all the affected nodes to avoid the expensive process of re-synchronization. Some criticism came up against the team for marking a deeply bugged release as ‘stable’. That error had propagated into all of the subsequent releases.
Others questioned the soundness of the multi-client approach. The critics cited Satoshi’s view that many implementations of the same blockchain node would inevitably result in several issues.
The supporters of the multi-client approach think that it prevents the bugs in one implementation from bringing down the entire network with them. For now, the OpenEthereum bug seems to be that exact type of scenario. But developers are striving relentlessly to ensure that they come up with viable solutions as soon as possible.