Blockchain Node View Change Exit Protocol
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In Practical Byzantine Fault Tolerance (PBFT) systems, nodes may incorrectly enter the view change protocol due to network communication disruptions, leading to wasted computing power and unpredictable delays in returning to normal operation.
Innovation Solution
A method where a node in the view change protocol multicasts a view change message and obtains echo messages from other nodes confirming the current view and sequence number, allowing it to exit the view change protocol when a quorum of consistent responses is received, ensuring the majority of nodes are still in normal operation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a node enters the view change protocol due to network communication disruption, then the node can detect potential primary node failures, but the node's computing power is wasted and it experiences unpredictable delays in returning to normal operation
Solution Approach 1:
The system performs preliminary actions by having nodes continuously monitor for view change messages and prepare to respond with echo messages. When a node is in view change mode, other nodes proactively send echo messages with their current view and sequence number information, so that the monitoring node can quickly determine whether to exit view change mode without waiting for an extended period or for multiple conditions to be met.
2Reliability
If a node waits for a majority of nodes to enter the view change protocol before exiting, then consensus safety is maintained, but network resources are wasted and productivity decreases
Solution Approach 1:
The system implements feedback mechanisms where nodes in view change mode receive echo messages from other nodes containing information about their current views and sequence numbers. By analyzing this feedback, a node can determine that if it receives echo messages indicating a consistent current view from a quorum of nodes, then the majority of nodes are still in normal operation mode, and it can safely exit view change mode. This feedback loop maintains consensus safety while enabling timely exit from view change protocol.
3Reliability
If the traditional view change protocol requires 2F+1 nodes to agree on a new view before exiting, then Byzantine fault tolerance is ensured, but the system experiences unpredictable delays and lost computing power
Solution Approach 1:
The system enables self-service by allowing a node in view change mode to independently determine when to exit by monitoring echo messages from other nodes. Instead of requiring the node to wait for a formal view change consensus involving 2F+1 nodes, the node can autonomously assess the situation by receiving quorum echo messages indicating that the majority of nodes remain in normal operation, and then self-correct by exiting view change mode and resuming normal consensus participation.
Data Source
Figure 1
Figure 2A~2C
Figure 3A~3B
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 and performed by a first node of N nodes in a view change protocol. The method includes: multicasting a view change message to at least some of the N nodes; obtaining, respectively from at least Q second nodes of the N nodes, at least Q echo messages each comprising: a consistent current view known to the second node indicating a primary node designated among the N nodes, and a consistent current sequence number known to the second node, the current sequence number associated with a latest transaction or a latest block, the current sequence number is larger than a first sequence number known to the first node; and responsive to obtaining the at least Q echo messages, ending the view change protocol.