Weight-Based Primary Node Selection in Blockchain Consensus
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing consensus mechanisms in distributed blockchain systems, such as Byzantine Fault Tolerance (BFT) and Practical Byzantine Fault Tolerance (PBFT), face inefficiencies including increased latency and network bottlenecks due to cumbersome communication requirements and the inability to efficiently select a non-faulty primary node, especially in large consensus groups.
Innovation Solution
The implementation of a method that assigns weights to phases of the consensus process, determines a weight sum, and selects a new primary node based on this sum instead of a round robin method, reducing latency and improving network efficiency by using erasure code blocks and efficient message verification processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional consensus mechanisms like PBFT are used, then reliability is maintained through comprehensive node verification, but latency increases and network efficiency decreases due to cumbersome communication requirements
Solution Approach 1:
The consensus process is segmented into distinct phases (prepare, commit, ready, committed) with specific verification requirements for each phase. Nodes only need to verify relevant messages for their current phase rather than all messages, reducing communication overhead and latency while maintaining reliability through phase-specific validation.
Solution Approach 2:
The system performs preliminary verification of primary node candidacy before full consensus execution. Backup nodes pre-verify the weight sum and eligibility of potential primary nodes during the prepare phase, allowing faster consensus progression without compromising reliability. This preliminary action prevents unnecessary full verification cycles.
2Adaptability or versatility
If traditional primary node selection methods are used, then all nodes can participate in consensus, but network bottlenecks occur and efficiency decreases in large consensus groups
Solution Approach 1:
The system changes the selection parameter from simple round-robin or random selection to weight-sum-based selection. The primary node is chosen based on the sum of weights from backup nodes, where weights reflect node reliability, performance metrics, and phase completion status. This parameter change enables efficient selection of optimal primary nodes while maintaining adaptability to different network conditions and node capabilities.
3Reliability
If comprehensive message verification is performed, then consensus reliability is ensured, but network bandwidth consumption and memory burden increase
Solution Approach 1:
The system performs partial verification appropriate to each consensus phase rather than exhaustive verification of all messages. In the prepare phase, nodes verify weight sum and primary node eligibility; in the commit phase, nodes verify specific commit messages; in the ready phase, nodes verify readiness conditions. This partial action approach ensures reliability for each phase while significantly reducing network bandwidth consumption and memory burden compared to comprehensive verification of all historical messages.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method of performing a change of a primary node in a blockchain network includes a backup node of the blockchain network determining that an epoch change needs to be performed, determining a respective weight of the backup node associated with each of three phases of a consensus process in a current epoch, determining a weight sum for the backup node based on the respective weights, sending an EPOCH_CHANGE message to the other network nodes to apply for a new primary node in a new epoch, receiving NEW_EPOCH messages from the other network nodes, determining whether a number of valid NEW_EPOCH messages exceeds a second predetermined threshold, and determining the backup node to be the new primary node in the new epoch in response to determining that the number of valid NEW_EPOCH messages exceeds the second predetermined threshold.