If you are trying to understand more about Proof of Authority consensus, Instanbul Byzantine Fault Tolerance (IBFT) or just blockchain consensus protocols in general, just jump straight into some research papers.
It may seem daunting at first and it actually is but these papers are well written where sufficient background is provided to slowly build up a good understanding of other fundamentals.
Here are key excerpts from the three papers I read.
- IBFT was developed by AMIS technologies in early 2017. [1]
- IBFT consensus protocol falls in the PoA category because only a set of special nodes, called validators, are authorised to propose new blocks. [1]. For more info on IBFT visit: https://github.com/ethereum/EIPs/issues/650 (this was inspired by EIP225 (link below)).
- The set of validators in PBFT is static whereas in IBFT they are dynamic [1]
- A private blockchain is a special permissioned blockchain operated by one entity. ie within one single trust domain. [3]
- Aura and Clique are two popular PoA algorithms. [2]
- Aura and Clique are two popular PoA implementations. [2] For more information on Clique, visit: https://github.com/ethereum/EIPs/issues/225
- A blockchain is a linked data structure replicated over a peer-to-peer network, where transactions are issued to form new blocks. Peers achieve distributed consensus on transaction ordering by placing them into new blocks; each block is linked to the previous via its hash.[2]
- PBFT is one of the most well-established BFT algorithms. Specifically, it rests on three rounds of message exchange before reaching agreement. This ensures that 3f + 1 nodes can achieve consensus also in presence of f Byzantine nodes. [2]
- Many other BFT algorithms have been proposed, mainly for improving PBFT performance. eg Q/U, HQ, Zyzzyva, Aardvark. [2]
- PoW does not enjoy consensus finality (as forks can happen), while all BFT-like approaches does (all parties reach agreement before consensus). [2]
- Consensus in PoA algorithms relies on a mining rotation schema, a widely used approach to fairly distribute the responsibility of block creation among authorities [2]
- PBFT is one of the most well-established BFT algorithms and requires three rounds of message exchange before reaching agreement. This ensures that 3f + 1 nodes can achieve consensus also in presence of f Byzantine nodes; this is proved to be optimal [2]
- In Aura, each block proposal requires two message rounds. [2]
- In Clique, a block proposal consists of a single round [2]
References:
- Correctness Analysis of IBFT
- PBFT vs Proof-of-Authority: Applying the CAP Theorem to Permissioned Blockchain
- Blockchain Consensus Protocols in the Wild
This article is also worth a read: https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95
It talks about failure being classified into three categories. Crashing, omitting, and being byzantine.
It then talks about simple fault tolerant and Byzantine fault tolerant, which is split into 2 (BAR tolerant). Several papers actually call simple fault tolerant Crash Fault Tolerant or CFT.
Another concept highlighted is synchronous v asynchronous. In a synchronous system, it is assumed that messages will be delivered within some fixed, known amount of time. In other words, there is a fixed upper bound.
“In an asynchronous message-passing system, it is assumed that a network may delay messages infinitely, duplicate them, or deliver them out of order. In other words, there is no fixed upper bound on how long a message will take to be received.”
Algorithms designed for asynchronicity more accurately reflects real life. ie In reality, most environments don’t allow us to make the synchronous assumption. So we must design for asynchronous environments.
The lack of a global clock needs to be considered because ordering of transactions needs to be determined. This is another factor to consider in a distributed system.
Safety and liveness are also two interesting concepts. In a Pegasys blog, they are defined as:
Safety means that nothing bad will ever happen. When applied to a consensus algorithm such as IBFT with immediate finality this means that no two valid but different blocks for the same height can be produced. Finality is a type of safety property.
Liveness means that something good will eventually happen. When applied to any consensus algorithm, IBFT included, this means that any transaction submitted to the network is eventually added to the blockchain of all participating nodes.
In Prethi’s blog, she explains it in another way: “Safety is another term for the “agreement” property we discussed earlier, where all non-faulty processes agree on the same output. If we can guarantee safety, we can guarantee that the system as a whole will stay in sync. We want all nodes to agree on the total order of the transaction log, despite failures and malicious actors. A violation of safety means that we end up with two or more valid transaction logs.”
Liveness is another term for the “termination” property we discussed earlier, where every non-faulty node eventually decides on some output value. In a blockchain setting, “liveness” means the blockchain keeps growing by adding valid new blocks. Liveness is important because it’s the only way that the network can continue to be useful — otherwise, it will stall.
