Blockchain Node Recovery Using ECHO-Based State Reconstruction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Byzantine Fault Tolerance (BFT) mechanisms in blockchain networks are inefficient, leading to increased latency and complexity due to network bottlenecks and the inability to promptly recover from faulty nodes, especially when using round robin methods for leader node changes.
Innovation Solution
Implementing improved consensus mechanisms that convert transaction requests into erasure code blocks, assigning weights to consensus process phases, and using an epoch change process based on weight sums to select a new primary node, while also facilitating a recovery process that does not disrupt normal network operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing BFT mechanisms are used for consensus among network nodes, then reliability is maintained, but latency increases and network efficiency deteriorates
Solution Approach 1:
The consensus process is segmented into distinct phases (prepare, commit, revert) with clearly defined transition conditions. Each phase has specific validation rules, allowing nodes to efficiently progress through the consensus steps without redundant verification, thereby reducing overall latency while maintaining reliability.
Solution Approach 2:
The system performs preliminary validation of transactions and pre-processes consensus data during the prepare phase before final commitment. By preparing and validating data in advance, the system reduces the time required for final consensus decisions, addressing the latency issue while preserving reliability through staged verification.
2Device complexity
If round robin method is used for primary node selection, then simplicity is maintained, but system reliability deteriorates due to inability to avoid faulty nodes
Solution Approach 1:
The system implements feedback mechanisms where nodes report their status and transaction processing results. The primary node selection and continuation depend on feedback from the prepare and commit phases - if validation fails or timeouts occur, the system automatically triggers a revert and selects a new primary node, ensuring faulty nodes are avoided while maintaining manageable complexity through rule-based decisions.
3Reliability
If recovery process is initiated for faulty network node, then system reliability is improved, but normal consensus operations are disrupted
Solution Approach 1:
The recovery process is extracted as a separate, isolated procedure that does not interfere with ongoing consensus operations. Faulty nodes are identified and taken out of the active consensus process through the revert mechanism, allowing their recovery to be handled independently through state reconstruction from valid ECHO messages, while healthy nodes continue normal operations without disruption.
4Adaptability or versatility
If traditional consensus mechanisms are used, then compatibility is maintained, but network bandwidth usage increases and memory burden grows
Solution Approach 1:
The system uses cryptographic hashing to create compact representations (copies) of transaction data. Instead of transmitting and storing full transaction details, nodes exchange hash values that serve as verified copies, dramatically reducing network bandwidth consumption and memory requirements while maintaining compatibility with existing blockchain structures through the use of standard hash functions.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method for performing a recovery process of a network node of a blockchain network includes broadcasting a state request message by the network node to the other network nodes of the blockchain network to recover a target transaction of a target sequence number, receiving state reply messages that each includes a sequence number from the other network nodes, identifying the target sequence number based on the sequence numbers in the state reply messages, sending a requesting message to the other network nodes to request an ECHO message from each of the other network nodes, determining a number of valid ECHO messages that are sent by the other network nodes, recovering the target transaction based on the number of valid ECHO messages, and sending a message to the other network nodes indicating that the network node has been recovered.