Honey Badger BFT Consensus Vote Migration for Efficiency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Honey Badger BFT consensus mechanism, which uses a binary agreement protocol, faces inefficiencies due to its random and indeterministic nature, leading to increased rounds of message exchange and decreased consensus efficiency, especially in uncontrollable network environments.
Innovation Solution
A blockchain consensus method that iteratively counts and updates consensus votes, migrating proposals based on identical votes into different sets, using an erasure coding algorithm to expedite consensus, until all proposals receive greater than or equal to 2f+1 identical votes, thereby reducing the number of rounds required for message exchange and improving efficiency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If the Honey Badger BFT consensus mechanism uses a binary agreement protocol with random and indeterministic algorithms, then the consensus process can be simplified, but the number of message exchange rounds increases and consensus efficiency decreases
Solution Approach 1:
The patent applies preliminary action by pre-defining the classification criteria for consensus proposals into three distinct sets based on vote thresholds (>=2f+1, >=f+1 and <2f+1, and <f+1 votes). This pre-established classification framework enables systematic processing of proposals in subsequent rounds, reducing the need for random decision-making and accelerating convergence to consensus.
Solution Approach 2:
The patent changes the parameter of decision-making from random coin tossing to deterministic vote threshold comparison. By establishing specific vote thresholds (2f+1 for confirmation, f+1 for potential agreement), the system transforms the indeterministic BA protocol into a more predictable and efficient process that reduces message exchange rounds.
2Device complexity
If the binary agreement protocol continues to use random coin tossing for decision-making, then the protocol remains simple, but multiple rounds of coin tossing are required and consensus efficiency is reduced
Solution Approach 1:
The patent implements feedback by continuously monitoring and counting consensus votes for each proposal across multiple rounds. Based on the accumulated vote counts, the system dynamically classifies proposals into different sets and updates consensus opinions, creating a feedback loop that accelerates convergence and reduces the time required to reach consensus compared to repeated coin tossing.
Solution Approach 2:
The system performs preliminary classification of proposals into three sets based on vote thresholds before final decision-making. This pre-sorting of proposals according to their support levels enables more efficient processing in subsequent rounds, reducing the number of iterations needed to reach consensus.
3Adaptability or versatility
If consensus nodes continuously exchange opinions without systematic classification, then the process remains flexible, but the number of message exchange rounds increases
Solution Approach 1:
The patent segments the consensus proposals into three distinct sets based on their vote counts: Set 1 (>=2f+1 votes), Set 2 (>=f+1 and <2f+1 votes), and Set 3 (<f+1 votes). This segmentation allows each set to be processed differently, with Set 1 proposals confirmed and Set 3 proposals updated to opposition opinions, thereby accelerating the overall consensus process while maintaining flexibility.
Solution Approach 2:
The patent applies local quality by treating different proposal sets differently based on their specific characteristics (vote counts). Each set receives targeted processing: Set 1 proposals are confirmed, Set 2 proposals are evaluated for traceability, and Set 3 proposals are updated to opposition. This differentiated approach optimizes consensus speed for each local group while preserving overall system flexibility.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
This document provides a blockchain consensus method, node, and system based on a Honey Badger Byzantine fault tolerance (BFT) consensus mechanism. The method is applicable to a consensus node and includes the following steps: counting consensus votes of N consensus proposals in a current round of consensus; traversing a first set to: migrate consensus proposals that each receive greater than or equal to f+1 and less than 2f+1 identical consensus votes into a second set; and migrate consensus proposals that each receive less than f+1 identical consensus votes into a third set to update to opposition opinions, where f is a number of fault tolerant consensus nodes; traversing a fourth set to: migrate consensus proposals that each receive greater than or equal to 2f+1 identical consensus votes into the second set; for consensus proposals that receive greater than or equal to f+1 and less than 2f+1 identical consensus votes, migrate consensus opinions that cannot be traced into the third set to update to opposition opinions, and migrate consensus opinions that can be traced into the second set to update to agreement opinions; merging the second set into the first set, and merging the third set into the fourth set, to perform a next round of consensus until the first set includes N consensus proposals on which consensus may be reached; and determining a consensus result based on counted consensus votes in the last round of consensus.