Difference between Geth POA Clique and Parity POA Aura

Question

I am creating my own private blockchain with a POA consensus. What is the difference between POA networks created by Geth (Clique) and by Parity (Aura), and are there scenarios that favor one over the other?

Answer 1

Since some moderator decided to delete the only answer to this question here it is again:

I do not have time to summarize it.

Good question!

I don't have an answer but I do have a link that might be worth reading

In this paper we derive the functioning of two prominent consensus algorithms for permissioned blockchains based on the PoA paradigm, namely Aura and Clique. We provide a qualitative comparison of them with respect to PBFT in terms of consistency, availability and performance, by considering a deployment over the Internet where the network is realistically modelled as eventually synchronous rather than synchronous. By applying the CAP Theorem, we claim that in this setting PoA algorithms can give up consistency for availability when considering the presence of Byzantine nodes. This can prove to be unacceptable in scenarios where the integrity of the list of transactions has to be absolutely kept (which is likely to be the actual reason why a blockchain-based solution is used). On the other hand, PBFT keeps the blockchain consistent at the cost of availability, even when the network behaves temporarily asynchronously and Byzantine nodes are present; this behaviours is much more desirable when data integrity is a priority. Despite one of the most praised advantages of PoA algorithms is their performance, our qualitative analysis shows that in terms of latency the expected loss of PBFT is bounded, and can be offset by the gain in consistency guarantees. As future work, we plan to deepen the analysis of PoA algorithms by engaging further reverse engineering tasks and thorough experimental evaluations. The final goal is to validate and possible revise our claims on the availability and consistency guarantees of PoA and PBFT, by implementing the adverse scenarios we envisioned in Section 4.1. Furthermore, we want to collect real performance measurements, both transaction latency and throughput, and to test scalability with respect to varying input transaction rates and number of nodes/authorities. Moreover, we are moving towards a formalisation of permissioned blockchains so to define a framework for benchmarking and evaluating these algorithms with a more formal approach.

http://ceur-ws.org/Vol-2058/paper-06.pdf