Paper Overview
"SoK: A Taxonomy for Critical Analysis of Consensus Mechanisms in Consortium Blockchain" is a comprehensive survey published in IEEE Access, 2023. The paper provides a systematic taxonomy and critical analysis of consensus mechanisms used in consortium blockchains, focusing on three key dimensions: reliability, performance, and security.
Key Insight: Consensus algorithms are central to blockchain technology and determine network reliability, enhance performance efficiency, and ensure system security. This paper fills a gap by providing a systematic taxonomy of enterprise-level blockchain consensus protocols and a detailed analysis of each protocol.
Key Data Points
Key Insights Summary
Comprehensive Taxonomy
The paper proposes a taxonomy that classifies consensus algorithms into four main categories: Paxos and derivatives, PBFT and derivatives, Federated Byzantine Agreement, and Randomized consensus mechanisms.
Three-Dimensional Assessment
Consensus algorithms are evaluated along three dimensions: reliability (communication complexity, scalability, decentralization), performance (latency, throughput, resource consumption), and security (fault tolerance).
Byzantine Fault Tolerance
Most BFT-based algorithms can tolerate up to f Byzantine faults when the total number of nodes n ≥ 3f+1, providing robust security for consortium blockchains.
Performance Trade-offs
There are inherent trade-offs between decentralization, security, and performance. Algorithms with higher fault tolerance often have higher communication complexity and lower throughput.
Network Model Impact
The network model (synchronous, partially synchronous, or asynchronous) significantly impacts algorithm reliability and performance, with asynchronous protocols providing the highest reliability.
Future Research Challenges
Key challenges include scalability enhancement, algorithmic melding, privacy-preservation, performance improvement, and searching/storing optimization in consortium blockchains.
Content Overview
Document Contents
I. Introduction
Blockchain, a decentralized, immutable, and transparent distributed ledger, maintains a continuously growing list of transaction records ordered into blocks. At its core lies the consensus algorithm, an agreement to validate the correctness of blockchain transactions.
Consortium blockchain is a hybrid architecture comprising features from public and private blockchains in which participation is limited to a consortium of participating members. Each node may refer to a single organization or institution in the consortium.
This paper provides a systematic taxonomy of enterprise-level blockchain consensus protocols and a detailed analysis of each protocol, considering aspects such as reliability, performance, and security.
II. Building Blocks
Blockchain Architecture
The framework of blockchain comprises the following layers from bottom up:
- Infrastructure Layer: Contains hardware, architecture equipment, and deployment environment
- Network Layer: Includes node organization method, communication mechanisms, and transmit protocol
- Consensus Layer: Forms the core of the consensus protocol used to ensure trust and security
- Data Layer: To realize traceability and non-tampering through blockchain structure
- Application Layer: Encapsulates script codes, smart contracts, DApps and APIs
Types of Blockchain Networks
Blockchain networks can be categorized as:
- Public Blockchain: Permissionless, completely decentralized, any node can participate anonymously
- Private Blockchain: Permissioned, not open to the outside world, used by specific organizations
- Consortium Blockchain: Hybrid architecture with limited participation to a consortium of members
Consensus Algorithm Classification
Consensus algorithms can be classified by:
- Approach to decision-making: Proof-based (PoW, PoS, PoET) vs Voting-based (Paxos, PBFT, Raft)
- Fault tolerance design: Crash Fault Tolerance (CFT) vs Byzantine Fault Tolerance (BFT)
III. Taxonomy of Consensus Mechanisms
Paxos and Derivatives
Paxos: A classical fault-tolerant consensus algorithm that relies on message passing in a distributed system. It divides nodes into three roles: proposer, acceptor, and learner.
Paxos Execution Phases:
- Prepare Phase: Proposer sends Prepare request to determine if majority is prepared to accept proposal
- Accept Phase: Proposer broadcasts Accept request if it receives enough Promise messages
Raft: Designed for ease of understandability and implementability. It divides nodes into leader, follower, and candidate roles.
PBFT and Derivatives
PBFT (Practical Byzantine Fault Tolerance): A consensus algorithm based on state machine replication where services are replicated on different nodes.
PBFT Consensus Process:
- Pre-prepare: Primary node receives request and generates Pre-prepare message
- Prepare: Replicas verify message and broadcast Prepare message
- Commit: Replicas broadcast Commit message after receiving enough Prepare messages
- Reply: Node sends committed certificate to client
RBFT (Redundant BFT): Improves robustness by using multi-core architecture with multiple PBFT instances.
BFT-SMART: A state machine replication library written in Java with enhanced error recovery.
HotStuff: Uses threshold signatures and pipelining to achieve O(n) message complexity.
LibraBFT: A variant of HotStuff with epochs for consensus node replacement and incentive mechanisms.
Federated Byzantine Agreement
RPCA (Ripple Protocol Consensus Algorithm): Uses pre-configured validators to vote on transactions. Validators maintain Unique Node List (UNL).
SCP (Stellar Consensus Protocol): Based on Federated Byzantine Agreement (FBA) with quorum slices. Does not require miners but a distributed server network.
Randomized Consensus Mechanisms
PoET (Proof of Elapsed Time): Utilizes Trusted Execution Environment (TEE) to randomly select validator node based on waiting time.
Ouroboros: Based on Proof of Stake, randomly chooses stakeholders to generate blocks in epochs divided into slots.
HoneyBadgerBFT (HB-BFT): Achieves consensus in asynchronous networks using threshold encryption and random transaction selection.
Dumbo: Practical asynchronous BFT protocol that reduces number of ABA instances for improved efficiency.
IV. Reliability
This section analyses the network reliability of consensus algorithms along the metrics of communication complexity, scalability, decentralization degree, and network models.
Communication Complexity
Refers to the number of messages required to reach a round of consensus. Lower complexity indicates more efficient algorithms.
- PBFT: O(n²) in normal case, O(n³) when leader fails
- HotStuff: O(n) in both normal and failure cases
- FBA: O(nK) where K is federation size
Scalability
Refers to the number of peering nodes that the algorithm can process:
- High: Supports over 100 participants
- Medium: 20 to 100 participants
- Low: Less than 20 participants
Decentralization
Degree of decentralization depends on selection rules and number of recording nodes:
- High: All nodes competitive with equal probability of becoming primary
- Medium: Multiple primary nodes or some nodes with higher priority
- Low: Primary nodes pre-selected
Network Models
- Synchronous: Known upper bound on message latency
- Asynchronous: No upper bound on message latency
- Partially Synchronous: System becomes synchronous after Global Stabilization Time
V. Performance
This section provides assessment of selected consensus algorithms regarding performance efficiency.
Latency
Time from transaction submission to confirmation:
- High: Minutes
- Medium: Seconds
- Low: Milliseconds
Throughput
Transactions Per Second (TPS):
- High: > 2,000 TPS
- Medium: 1,500-2,000 TPS
- Low: < 1,500 TPS
Resource Consumption
Computing power, memory, I/O, and energy resources:
- High: Extensive computation for leader competition
- Medium: High communication complexity but minimal computation
- Low: Bounded communication complexity, no extensive computation
VI. Security
This section provides assessment of consensus algorithms regarding system security elaborated by fault tolerance.
Fault Tolerance
Capacity of distributed network to minimize severity and frequency of network incidents:
- Paxos and Raft: 50% crash fault tolerance, no Byzantine fault tolerance
- PBFT and derivatives: 33% Byzantine fault tolerance (n ≥ 3f+1)
- FBA: Varies by algorithm, SCP similar to PBFT, RPCA lower due to pre-configured nodes
- Randomized: PoET and Ouroboros: 50% crash fault tolerance; HB-BFT and Dumbo: 33% Byzantine fault tolerance
VII. Concluding Remarks
The choice of a consensus algorithm has an enormous impact on the performance of a blockchain application. Ongoing research into the design and implementation of consensus algorithms will advance and facilitate the adoption of blockchain for diverse applications.
Primary research challenges in the consensus mechanism domain for consortium blockchain include:
- Scalability enhancement: Adapting to changing business and platform expansion needs
- Algorithmic melding: Integrating different types of consensus mechanism algorithms
- Privacy-preservation: Ensuring security and privacy of data while maintaining decentralization
- Performance improvement: Increasing throughput, reducing latency and computational requirements
- Searching and storing optimization: Optimizing data storage and retrieval in immutable ledgers
Algorithm Comparison
| Protocol | Category | Complexity (Normal) | Byzantine Fault Tolerance | Scalability | Network Model |
|---|---|---|---|---|---|
| Paxos | Paxos Derivatives | O(n²) | - | Medium | Partially Synchronous |
| Raft | Paxos Derivatives | O(n) | - | High | Partially Synchronous |
| PBFT | PBFT Derivatives | O(n²) | 33% | Low | Partially Synchronous |
| HotStuff | PBFT Derivatives | O(n) | 33% | High | Partially Synchronous |
| RPCA | FBA | O(nK) | 20% | Medium | Partially Synchronous |
| PoET | Randomized | O(n) | - | Medium | Synchronous |
| Ouroboros | Randomized | O(n) | - | High | Synchronous |
Note: The above is a summary of the paper content. The complete document contains extensive analysis, comparison tables, and detailed evaluation of consensus algorithms. We recommend downloading the full PDF for in-depth reading.