Blockchain Node View Change Exit Protocol
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Practical Byzantine Fault Tolerance (PBFT) systems, nodes may mistakenly enter the view change protocol due to network communication disruptions, leading to delayed recovery and wasted computing power, as the traditional view change protocol requires a majority of nodes to agree on a non-functioning primary node, causing stuck nodes to wait unpredictably for other nodes to join the view change.
Innovation Solution
A node in the view change protocol can efficiently exit by obtaining a quorum of messages from other nodes confirming a consistent current view and sequence number, indicating the primary node and the latest blockchain state, allowing it to synchronize and resume normal operation without relying on traditional view change protocols.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a node waits for a majority of nodes to enter the view change protocol and agree on a non-functioning primary node, then the view change protocol can safely switch to a new primary node, but the node becomes stuck in the view change protocol with unpredictable delay and wasted computing power
Solution Approach 1:
The system performs preliminary actions by having nodes continuously multicast their current view and sequence number information even during normal operation. When a node enters view change protocol, this pre-established communication channel allows it to quickly receive view information from other nodes and determine whether to exit view change, avoiding the need to wait for majority confirmation.
Solution Approach 2:
The system implements feedback mechanisms where nodes multicast their view and sequence number information to the network. A node in view change protocol can receive feedback from other nodes about their current state, and based on this feedback (receiving Q messages with consistent view), it can autonomously determine whether to exit view change protocol, creating a closed-loop control system that resolves the stuck node problem.
2Reliability
If a node enters the view change protocol due to network communication disruption, then it can detect potential primary node failures, but it mistakenly triggers view change and shuts itself out of the consensus process
Solution Approach 1:
The system uses feedback from multiple sources to verify whether view change is truly needed. Instead of relying on a single trigger condition, a node receives feedback from Q other nodes about their current view and sequence number. If the majority of nodes are still in normal operation (which will be reflected in the feedback messages), the node can identify its own false positive trigger and exit view change protocol, thereby reducing false positives while maintaining reliable failure detection.
Solution Approach 2:
The system requires a quorum of Q messages (where Q > F, the fault tolerance threshold) to confirm view change exit conditions. This excessive action beyond the minimum fault tolerance requirement provides a safety margin that filters out false positives caused by network disruptions, ensuring that view change protocol is only exited when truly safe to do so.
3Reliability
If the traditional view change protocol requires at least 2F+1 nodes to enter view change and multicast view change messages, then consensus safety is maintained, but computing power is wasted and network resources are consumed by stuck nodes
Solution Approach 1:
The system enables nodes to serve themselves by autonomously determining when to exit view change protocol. Instead of requiring other nodes to actively pull them out or wait for majority view change participation, a node can independently assess the situation by receiving Q messages with consistent view information and self-correct by exiting view change protocol, thereby eliminating the need for continuous participation in a potentially unnecessary view change process.
Solution Approach 2:
The system introduces dynamic behavior where nodes can flexibly transition between view change protocol and normal operation protocol based on real-time network conditions. The threshold for exiting view change (receiving Q consistent messages) is dynamically adjustable and can be set to balance between safety and productivity, allowing the system to adapt to different operational contexts and minimize wasted computing power while maintaining consensus safety.
Data Source
AI summary
Methods, systems, and apparatus, including computer programs encoded on computer storage media, for performing view change. One of the methods is to be implemented on a blockchain maintained by a number (N) of nodes and performed by a first node of the N nodes that is in a view change protocol. The method includes: obtaining, respectively from at least Q second nodes of the N nodes, at least Q first messages each comprising (1) a consistent current view known to the second node indicating a primary node designated among the N nodes and (2) a consistent current sequence number known to the second node, the current sequence number associated with a latest transaction or a latest block, wherein the current sequence number is larger than a first sequence number known to the first node; and responsive to obtaining the at least Q first messages, ending the view change protocol.