Parity Finds Consensus Bug, Urges Upgrade to New Client – Trustnodes

Parity Finds Consensus Bug, Urges Upgrade to New Client


Parity abstract

One of ethereum’s most popular client, run by around 25% of the network, has found and fixed a bug which can lead to consensus failure, thus urges all Parity node operators to quickly upgrade.

The bug in question was apparently found on Ropsten testnet earlier today, with Parity quickly fixing it and releasing a new client version.

It has not, therefore, been exploited on mainnet as far as we are aware, with ethereum’s network operating without disruption.

Any miner running the old client however might think some transactions are valid, while Geth, ethereum’s most popular client, will reject it, which can cause a split.

As such we’d think all mining pools have been notified and hopefully have upgraded. In bitcoin they had a messaging alert system which directly alerts nodes in these sort of situations, but it’s unclear whether Parity has a likewise system and, if it does, whether any such alert was sent.

That would be important when moving to Proof of Stake as while currently mining is somewhat centralized in a handful of pools, stakers will require almost no hardware resources, therefore may be a lot more decentralized.

That’s especially the case as in Hybrid Casper there are in-built incentives to choose a small pool or to not do what the majority is doing, so potentially making it difficult to quickly respond to similar situation as reaching all validators may well be effectively impossible unless the node itself alerts them.

Such alerting system is however a bit controversial because it could potentially be an attack vector itself, just as some argue having more than one implementation is itself a cause of vulnerabilities.

But two different implementations can not technically be avoided unless the network never upgrades. In bitcoin, for example, every soft-fork has a transitionary period when two implementations are operating.

That has, in the past, led to temporary consensus failures and network splits for some hours which have resulted in known losses of up to $50,000, and in one case even a roll-back of the blockchain or a going back in history.

We’re not aware of any likewise split in ethereum. That may be because they do not use soft-forks and it may be because the different implementations act as sort of back-up.

In late 2016, for example, when a DDoS bug was exploited in Geth, Parity kept the network running, with end-users seeing little to no disruption.

Parity, moreover, from general commentary, seems to sync a lot better and faster than Geth, while Geth in turn has had its own cases where it “rescued” the network so to speak.

This multiple implementations approach, therefore, finds a very high level of support in ethereum where while you’d think it would lead to consensus failures, it has actually managed to keep ethereum’s network running to the point it can claim 100% uptime, while for bitcoin it would have to be 99.something percent.



Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>