Private blockchain consensus mechanisms
Private blockchains have different requirements compared to public blockchain system and therefore need alternative consensus algorithm and technical trade-offs.
Me and my colleague Max (@tw7613781) have studied 8 different approaches and sharing small summaries on each one of them. These approaches doesn’t require mining and are used in private blockchain platforms.
1. Proof of Authority
The term PoA has been first coined by ethereum co-founder Gavin Wood. PoA uses identity as the sole verification of the authority to validate, meaning there is no need to use mining. And no validator is allowed to approve consecutive blocks.
Pros:
- It can be used for both private and public blockchains.
- High TPS — no requirement of excessive communications between nodes to reach consensus
- Low requirement of computational power
- Every validator has equal power
- Malicious validator can’t do too much harm to the network
Cons:
- All validators should be known to each other — no anonymous
- Validator’s identity should be more important than destroying the network
Examples:
- POA.network — Public blockchain — mainnet
- Ethereum Kovan and Rinkeby — Public blockchain — testnet
2. Proof of Elapsed Time
Each participating node in the network is required to wait for a randomly chosen time period, and the first one to complete the designated waiting time wins the new block. This mechanism needs to ensure two important factors. First, that the participating nodes genuinely select a time that is indeed random and not a shorter duration chosen purposely by the participants in order to win, and two, the winner has indeed completed the waiting time.
Pros:
- Low requirement of computational power
- No requirement of excessive communications between nodes to reach consensus.
Cons:
- Relies on Trusted Execution Environment (specific hardware)
- Block time is random and is limited by sleep time
- Can only be used in private blockchain
- Small subset of compromised nodes can harm the system
Examples:
- Hyperledger Sawtooth — Private — mainnet
3. Proof of Importance
It is an algorithm that was first introduced by NEM. Accounts with a higher importance score will have a higher probability of being chosen to create a block. This system not only rewards those with a large account balance, but also takes into account how much they transact to others and who they transact with.
Pros:
- It can be used for both private and public blockchains
- High TPS
- Low requirement of computational power.
Cons:
- All nodes/accounts are not equal
- Most important node/account may harm the network
Examples:
- NEM — Public — mainnet
4. Practical Byzantine Fault Tolerance
All of the nodes in the pBFT model are ordered in a sequence with one node being the primary node (leader) and the others referred to as the backup nodes. The assumption is that the amount of malicious nodes in the network cannot simultaneously equal or exceed 1/3 of the overall nodes in the system.
Pros:
- It can be used for both private and public blockchains
- Instant transaction finality
Cons:
- Nodes communicate with each other heavily
- Works only in small consensus group size
- Susceptible to sybil attacks
Examples:
- Zilliqa — Public — mainnet
- Hyperledger Fabric — Private — testnet
5. Federated Byzantine Agreement
The Ripple blockchain pioneered the Federated Byzantine Agreement (FBA) consensus mechanism. In FBA systems, each node does not have to be known and verified ahead of time, membership is open, and control is decentralized. Nodes can choose whom they trust. System-wide quorums emerge from decisions made by individual nodes.
Pros:
- Open membership and decentralized control
- It can be used for both private and public blockchains
- Each node chooses its own trusted nodes set
- High TPS even in public
Cons:
- Trust is not automated, choosing wrong node set will result in loss
- Works only in small consensus group size
- Susceptible to sybil attacks
Examples:
6. Raft
In Raft, there are three roles, leader (only 1), follower (others) and a candidate (intermediate status). Time is divided into terms of arbitrary length. Terms are numbered with consecutive integers starting from 0. Each term begins with an election, the winner becomes a leader and will make block and send to followers. In order to avoid split vote (No one gets majority vote), election timeouts are chosen randomly from a fixed interval (e.g., 150–300ms).
Pros:
- Solid theory support
- High TPS
- Fault tolerance
- Instant transaction finality
Cons:
- Only for private blockchain
- Relies on Trusted Execution Environment (specific hardware)
- Leader — follower mode might make system vulnerable
Example:
- Miyabi — Private — testnet
7. Istanbul BFT
There are two entities in IBFT, proposer and validators. Proposer can be selected by either round robin scheduling or sticky proposer. Proposer collects transactions from transaction pool and generates a block and broadcasts it to validators. The system can tolerate at most F faulty nodes in a N validator nodes network, where N = 3F + 1, as validator need to receive 2F + 1 validation messages from other validators.
Pros:
- High TPS
Cons:
- Massive communication between nodes
- Works only in small consensus group size
- Susceptible to sybil attacks
Example:
8. Tangle
Tangle is a data structure be used in IOTA, which is a DAG with vertices represent transactions and edges represent approvals. Nodes sync transactions with each other and a special node called coordinator which is controlled by IOTA Foundation issues zero-valued transaction every two minutes, called a milestone. Any transactions referenced by a milestone is confirmed.
Pros:
- High TPS
- It can be used for both private and public blockchains.
Cons:
- Existence of coordinator violates decentralization of blockchain system
- Conflicts are detected later (late finality)
Example:
- IOTA — Public — mainnet
Summary
Each consensus mechanisms are suitable for different use cases and trying to find a winner amongst them is not a good idea. So we have decided to find the most suitable algorithm based on our specific use case. Our requirements are:
- Scalable — starts with smaller participants and later should be able to add hundreds of new nodes
- Supports most platform — not restricted by any specific hardware
- Minimal governance — system should require minimal human interference
╔════════╦══════════╦════════════════════════╦════════════════════╗
║ ║ scalable ║ supports most platform ║ minimal governance ║
╠════════╬══════════╬════════════════════════╬════════════════════╣
║ PoA ║ yes ║ yes ║ yes ║
║ PoET ║ yes ║ no ║ yes ║
║ PoI ║ yes ║ yes ║ no ║
║ pBFT ║ no ║ yes ║ yes ║
║ FBA ║ no ║ yes ║ no ║
║ Raft ║ yes ║ no ║ yes ║
║ IBFT ║ no ║ yes ║ yes ║
║ Tangle ║ yes ║ yes ║ no ║
╚════════╩══════════╩════════════════════════╩════════════════════╝Finally, we have chosen Proof of Authority for our private blockchain platform development. We will share our detailed report on our implementation of Proof of Authority consensus mechanism soon!
