FBA (Federated Byzantine Agreement)
Ripple Consensus Protocol
Ripple is a blockchain-based platform and payment protocol that targets financial use cases and the payments domain. The Ripple Consensus Protocol can support open-ended node participation.
Each node is required to define a Unique Node List (UNL) comprising other Ripple nodes that are trusted by that node not to collude against it. At least 40% of the nodes in its UNL must appear also in the UNL of other nodes. Consensus is achieved by each node broadcasting candidate sets of transactions, and then consulting the votes of the nodes in its UNL, and then refining the candidate set. When a candidate set receives at least an 80% vote from the nodes in a UNL, the candidate becomes a valid block on the Ripple blockchain. Consensus in the entire network is reached when each individual sub-network reaches consensus.
Stellar Consensus Protocol
Stellar, like Ripple, is a blockchain-based platform and payment protocol that targets financial use cases and the payments domain. Stellar Consensus protocol uses the concept of quorums (a set of nodes sufficient to reach agreement) and quorum slices (a subset of a quorum that can convince one node about agreement). Quorum slices and quorums are based on real life business relationships between the entities thereby leveraging trust that already exists in business models.
To reach global consensus, quorums must intersect. Each node first performs initial voting on transactions. Each node performs its selection of transactions, and will never vote for another transaction contradicting its selection. It can however accept a different transaction if its quorum slice has accepted a different one. A node accepts a transaction if it has never accepted a transaction contradicting the current transaction and each node in its quorum slice has accepted that transaction. Quorum slices influence one another leading to quorums that agree on a certain transaction. Confirmation is the last step of the voting process and signifies system level agreement. This step ensures that nodes send each other confirmation messages so that all agree upon the final value of the state in the system.
PBFT (Practical Byzantine Fault Tolerance)
One node is elected as leader, which orders transactions to include in the block and broadcasts this list to all other validation peers. Each validation peer executes this list of transactions and then calculates the hash code for the newly created block. Each validation broadcasts this hash code to the network, and takes note of the hash codes broadcast by all other validating nodes. If it sees that 2/3 of all validation nodes have the same hash code, it will commit the new block to its local copy of the ledger.
Weaknesses
PBFT has only ever been scaled and tested to 20 validating nodes and its messaging overhead increases significantly as the number of validating nodes is increased.