Blockchain Node Recovery with ECHO Validation for BFT Consensus

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing Byzantine Fault Tolerance (BFT) mechanisms in blockchain networks are inefficient, leading to increased latency and complexity due to cumbersome communication and network bottlenecks, particularly when dealing with large consensus groups and frequent changes of leader nodes.

Innovation Solution

The implementation of improved consensus mechanisms that convert transaction requests into erasure code blocks, assign weights to consensus process phases, and use an epoch change process based on weight sums to select a new primary node, reducing data transmission size and latency, and simplifying the recovery process for faulty nodes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If existing BFT mechanisms are used for consensus in blockchain networks, then reliability is maintained, but network bandwidth consumption increases and latency is increased due to cumbersome communication

Engineering Contradiction:
Improveconsensus reliabilityVSAvoidnetwork bandwidth consumption
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent segments the consensus process into distinct phases (prepare, commit, ready, commit-ready) and structures communication into targeted message types for each phase. This segmentation reduces redundant communication by ensuring each message serves a specific purpose in the consensus protocol, thereby reducing overall network bandwidth consumption while maintaining reliability.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent extracts and optimizes the communication protocol by defining specific message types (PREPARE, COMMIT, READY, COMMIT-READY) that carry only essential information. This extraction of necessary communication elements eliminates redundant data transmission, reducing network bandwidth usage while preserving the reliability guarantees of BFT consensus.

Inventive Principle:
Principle #2Taking out (Extraction)

2Reliability

If existing BFT mechanisms are used for consensus in blockchain networks, then reliability is maintained, but latency increases due to cumbersome communication and network bottlenecks

Engineering Contradiction:
Improveconsensus reliabilityVSAvoidconsensus latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent introduces dynamic phase transitions in the consensus protocol, where nodes can transition between prepare, commit, ready, and commit-ready phases based on received messages and system state. This dynamic structure allows the protocol to adapt to different network conditions and progress through consensus more efficiently, reducing latency while maintaining reliability.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent ensures continuous progress through the consensus process by designing phases that can overlap and progress simultaneously. Nodes continuously process messages and advance through phases without idle waiting periods, maintaining continuous useful action throughout the consensus process, thereby reducing overall latency while preserving reliability.

Inventive Principle:
Principle #20Continuity of useful action

3Adaptability or versatility

If traditional consensus mechanisms are used with frequent changes of leader nodes, then system resilience is improved, but device complexity increases due to cumbersome communication protocols

Engineering Contradiction:
Improvesystem resilienceVSAvoidcommunication protocol complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal communication protocol that handles multiple consensus operations (leader selection, phase transitions, commitment) using the same message types and procedures. This multi-functional protocol reduces complexity by providing a unified approach to various consensus tasks, while the system remains resilient through frequent, manageable leader node changes.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Adaptability or versatility

If large consensus groups are used in blockchain networks, then system resilience and decentralization are improved, but network bandwidth consumption increases due to increased communication overhead

Engineering Contradiction:
Improvesystem decentralizationVSAvoidnetwork bandwidth consumption
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent segments communication in large consensus groups into targeted, phase-specific messages rather than broadcast-all-messages approaches. Each node sends and receives only the specific message types relevant to its current phase and role, reducing communication overhead proportionally with group size while maintaining decentralization and resilience.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP3560142B1Performing a recovery process for a network node in a distributed system
Publication Date: 2020.09.09 ADVANCED NEW TECHNOLOGIES CO LTD
  • EP3560142B1 patent drawingFigure 1
  • EP3560142B1 patent drawingFigure 2
  • EP3560142B1 patent drawingFigure 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.