BFT Consensus Topology Switching With Vote Aggregation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Byzantine Fault-Tolerant (BFT) consensus protocols in distributed ledger technologies face high computational and communication overhead, and complex mechanisms for handling non-leader node faults, which increase implementation complexity and hinder verification of correctness.
Innovation Solution
A method for establishing consensus among distributed nodes using a leader node that constructs an initial communication topology as a tree structure, switches to updated topologies if faults are suspected, and falls back to a pessimistic topology if necessary, eliminating the need for complicated fallback protocols and allowing for simpler verification.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Byzantine fault-tolerant consensus protocols use complex mechanisms to handle non-leader node faults (such as fallback protocols and transition mechanisms), then fault tolerance is improved, but implementation complexity increases
Solution Approach 1:
The patent extracts and removes the complex fallback protocol and transition mechanism from the consensus system. By using a leaderless architecture where any node can become leader, the patent eliminates the need for separate fallback protocols that were required in leader-based systems to handle non-leader faults. This extraction of unnecessary components directly reduces implementation complexity while maintaining fault tolerance through the underlying BFT voting mechanism.
Solution Approach 2:
The patent implements a universal consensus mechanism where the same BFT voting protocol handles all fault scenarios regardless of which node fails. Any node can serve as leader, and the same view-change mechanism handles both leader and non-leader faults uniformly. This multi-functionality eliminates the need for separate fallback protocols, reducing implementation complexity while maintaining comprehensive fault tolerance.
2Reliability
If Byzantine fault-tolerant consensus protocols use multiple protocols (main protocol and fallback protocol) to handle different fault scenarios, then reliability is improved, but device complexity increases
Solution Approach 1:
The patent employs a single universal BFT consensus protocol that handles all fault scenarios including leader failures, non-leader failures, and network partitions. The view-change mechanism serves multiple functions: it elects new leaders, handles faulty nodes, and maintains consensus continuity. This eliminates the need for separate fallback protocols and transition mechanisms, reducing protocol complexity from multiple protocols to one unified protocol while maintaining comprehensive reliability.
3Productivity
If optimized consensus protocols use passive replication and advanced communication topologies, then productivity is improved, but device complexity increases
Solution Approach 1:
The patent segments the consensus protocol into distinct optimization layers: passive replication handles read operations separately from write operations, while advanced communication topologies optimize the voting and view-change mechanisms. This segmentation allows each layer to be optimized independently for throughput without requiring complex integration logic, thereby improving productivity while managing implementation complexity through modular design.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Disclosed is a method for establishing consensus between a plurality of distributed nodes connected via a data communication network (1), the plurality of distributed nodes including a plurality of active nodes (2), the plurality of active nodes (2) including a leader node (3), each of the plurality of distributed nodes including a processor and computer readable media. The method comprises executing, by the leader node (3), the steps of preparing a proposal; constructing a first communication topology; and propagating the proposal to active nodes (2) according to the first communication topology. The method further includes, by the leader node (3), in case of receiving any sufficient set of vote aggregations from the active nodes (2), creating a proposal commitment using the vote aggregations and accepting the proposal, or, in case of suspecting that the first communication topology is not reliable to reach consensus on the proposal due to active node (2) faults, creating an updated communication topology different from the first communication topology and continuing with propagating the same proposal down to active nodes (2) according to the updated communication topology.