Reconfiguration Service for Distributed Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Byzantine fault-tolerant distributed computing systems face security challenges, particularly in long-lived blockchain systems where clients may reconnect to outdated or malicious configurations, leading to potential long-range attacks and 'I still work here' attacks, especially in Proof-of-Work and Proof-of-Stake systems.

Innovation Solution

A reconfiguration service is implemented as a smart contract using a distinct consensus protocol, allowing nodes to dynamically update and approve changes in system membership, preventing long-range attacks by ensuring accurate configuration updates and secure client reconnections through a proof of work mechanism.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a long-lived blockchain system maintains a fixed set of nodes, then system stability is improved, but the system becomes vulnerable to security attacks when nodes need to be updated or replaced

Engineering Contradiction:
Improvesystem stabilityVSAvoidnode reconfiguration capability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent implements dynamic node reconfiguration by allowing the set of blockchain nodes to change over time through structured reconfiguration events. Nodes can be added, removed, or replaced while maintaining system integrity through consensus-based approval processes and configuration logs that track membership changes across epochs.

Inventive Principle:
Principle #15Dynamics

2Adaptability or versatility

If the system allows dynamic node reconfiguration, then adaptability is improved, but security risks increase due to potential long-range attacks and configuration inconsistencies

Engineering Contradiction:
Improvenode reconfiguration capabilityVSAvoidsecurity vulnerabilities
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The patent applies preliminary action by requiring nodes to vote on and approve reconfiguration requests before actual configuration changes take effect. The system maintains configuration logs that record approved changes, and clients can verify current configurations before connecting, preventing attacks that would otherwise exploit unexpected configuration changes.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback mechanisms where nodes collectively vote on reconfiguration requests, and the outcomes are recorded in configuration logs. This feedback loop ensures that configuration changes are transparent, verifiable, and consensus-based, preventing malicious reconfigurations while enabling legitimate system evolution.

Inventive Principle:
Principle #23Feedback

3Ease of operation

If clients connect without verifying current configuration, then ease of operation is improved, but security is compromised due to connection to outdated or malicious nodes

Engineering Contradiction:
Improveclient connection simplicityVSAvoidconnection security
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent requires clients to perform preliminary configuration verification by querying the reconfiguration service for current system configuration before establishing connections. This preliminary check ensures clients connect to the correct, up-to-date node set without adding significant complexity to the connection process.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11665067B2Managing reconfigurations of distributed computing systems
Publication Date: 2023.05.30 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US11665067B2 patent drawing
  • US11665067B2 patent drawing
  • US11665067B2 patent drawing

AI summary

A computer manages reconfigurations of a Byzantine fault-tolerant, distributed computing system comprising a network of first nodes adhering to a given consensus protocol at a reconfiguration service. The computer services the network by receiving a request of change of status of a second node with respect to the network. The computer informs at least a subset of the first nodes of the received request. The computer obtains an approval of the request, whereby at least a subset of the first nodes collectively approve the change of status as a result of contributions processed according to the given consensus protocol. The computer updates a configuration log according to request approvals obtained by servicing the network. The computer addresses requests of clients about configurations of the network based on the updated configuration log.