Blockchain Consensus Using Erasure Coding to Cut BFT Latency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Byzantine Fault Tolerant (BFT) consensus mechanisms in blockchain networks face inefficiencies, including increased latency and network bottlenecks due to cumbersome communication requirements and inefficient message authentication, particularly in large consensus groups, and struggle with timely selection of non-faulty primary nodes and recovery of faulty nodes.
Innovation Solution
The implementation of improved consensus mechanisms that convert transaction requests into erasure code blocks, reduce data transmission size, and use an epoch change process based on weight sums to select a new primary node, along with a recovery process that minimizes interference with normal consensus operations, thereby reducing network load and latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing BFT consensus mechanisms are used to ensure system reliability and fault tolerance, then consensus agreement can be achieved among distributed nodes, but network latency increases and bandwidth is consumed due to cumbersome communication requirements and inefficient message authentication
Solution Approach 1:
The transaction request is segmented into multiple erasure code blocks that are distributed across different nodes. Instead of transmitting and authenticating the entire transaction request at once, the system divides it into smaller chunks (EC blocks) that can be processed independently, reducing the communication overhead and authentication time for each message exchange round.
Solution Approach 2:
The system creates multiple copies of erasure code blocks and distributes them to different nodes. Each node receives and processes copies of these blocks, allowing parallel verification and consensus building without requiring all nodes to communicate the full transaction data, thereby reducing network latency.
2Reliability
If existing BFT consensus mechanisms are used to maintain system integrity, then fault tolerance is achieved, but network bandwidth is consumed and memory burden increases due to inefficient message authentication and data transmission
Solution Approach 1:
By segmenting the transaction request into erasure code blocks, the system reduces the amount of data that needs to be transmitted and stored at each node. Only the necessary EC blocks are transmitted during consensus, rather than the complete transaction request, conserving bandwidth and reducing memory burden.
Solution Approach 2:
The system changes the parameter of data representation by converting the transaction request into erasure code form. This transformation allows the same information to be encoded in a more efficient format that requires less transmission bandwidth and storage space while maintaining the ability to reconstruct the original transaction for verification.
3Reliability
If existing BFT consensus mechanisms are used to achieve consensus, then agreement can be reached, but the selection of non-faulty primary nodes is delayed and recovery of faulty nodes is slow
Solution Approach 1:
The system performs preliminary actions by pre-encoding transaction requests into erasure code blocks and preparing them for distribution. This preliminary processing allows the primary node to quickly initiate consensus with pre-prepared data, and enables faster identification and recovery of faulty nodes since the EC blocks are already segmented and can be independently verified and reconstructed.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Implementations of the present specification include a computer-implemented method for achieving a consensus among a number of network nodes of a blockchain network. The blockchain network includes a primary node and one or more backup nodes. The method includes receiving a transaction request by the primary node, sending a number of first messages to the backup nodes by the primary node, receiving second messages from the backup nodes by the primary node, reconstructing the transaction request based on data in the second messages by the primary node, sending a third message to the backup nodes by the primary node, and executing the transaction request in response to receiving a predetermined number of third messages.