Blockchain Node Pull Orchestration for Scalable Updates

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Centralized push-based orchestration systems in blockchain networks face scalability challenges, network congestion, and inconsistency due to bottlenecks at the central server, especially in large-scale environments, leading to difficulties in ensuring timely updates and managing resources efficiently.

Innovation Solution

A decentralized pull-based orchestration system using cluster-level operators that independently manage and upgrade blockchain nodes, leveraging multiple orchestrators and decentralized storage solutions like git, IPFS, or S3 to maintain a source of truth, allowing nodes to self-upgrade and reduce latency and network traffic.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If a centralized push-based orchestration model is used, then control and coordination of blockchain nodes is simplified, but scalability and network performance deteriorate due to server bottlenecks

Engineering Contradiction:

Improveorchestration control complexityVSAvoidnetwork scalability

Core Design Contradiction:

Device complexityVSProductivity

Solution Approach 1:

The patent divides the centralized orchestrator into multiple distributed operators, each responsible for specific clusters of blockchain nodes. This segmentation eliminates the single point of bottleneck while maintaining coordinated control through the operator network that communicates with the source of truth.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

Blockchain nodes automatically pull configuration updates from the source of truth and apply changes independently without requiring manual intervention or centralized push commands. The operators monitor for changes and trigger updates autonomously, reducing reliance on centralized control.

Inventive Principle:

Principle #25Self-service

2Ease of operation

If a centralized push-based update mechanism is used, then update coordination is simplified, but network traffic and latency increase due to continuous communication requirements

Engineering Contradiction:

Improveupdate coordinationVSAvoidupdate latency

Core Design Contradiction:

Ease of operationVSLoss of time

Solution Approach 1:

Instead of continuous push updates, the system uses periodic pull requests where operators check for changes in the source of truth at scheduled intervals. This reduces network traffic during idle periods while ensuring timely updates when changes occur.

Inventive Principle:

Principle #19Periodic action

Solution Approach 2:

The system implements event-driven architecture where changes in the source of truth automatically trigger feedback loops that notify operators of updates. This ensures timely propagation of changes without requiring continuous polling, reducing latency when updates are needed.

Inventive Principle:

Principle #23Feedback

3Stability of the object's composition

If a centralized orchestrator is used, then system consistency is easier to maintain, but reliability decreases when nodes miss updates due to network issues

Engineering Contradiction:

Improvesystem consistencyVSAvoidupdate reliability

Core Design Contradiction:

Stability of the object's compositionVSReliability

Solution Approach 1:

The system maintains local copies of configuration data in the source of truth and operators cache recent configurations locally. This beforehand cushioning allows nodes to continue operating with cached configurations during network outages and automatically sync when connectivity is restored, ensuring reliability.

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

Solution Approach 2:

Each operator maintains an independent copy of the configuration state from the source of truth. When updates occur, operators pull new configurations and apply them locally. This copying mechanism ensures that even if some nodes miss updates temporarily, the system can maintain consistency through independent recovery.

Inventive Principle:

Principle #26Copying

4Device complexity

If a centralized push model is used, then deployment control is simplified, but error handling and rolling back become complex in large-scale environments

Engineering Contradiction:

Improvedeployment controlVSAvoiderror handling complexity

Core Design Contradiction:

Device complexityVSEase of repair

Solution Approach 1:

The patent segments the deployment control into independent operator units, each managing specific clusters. This segmentation isolates errors to local clusters rather than propagating system-wide, simplifying error handling and enabling independent rollback operations for each cluster.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system implements comprehensive feedback mechanisms where operators report deployment status and errors back to the source of truth and to each other. This feedback enables automatic detection of failures and triggers coordinated rollback procedures across the distributed system.

Inventive Principle:

Principle #23Feedback

Data Source

PatentUS20250335207A1Systems and methods of pull-based orchestration of nodes in a blockchain network

Publication Date: 2025.10.30 CHAINSTACK PTE LTD

AI summary

Computer systems and methods with decentralized blockchain orchestration architecture use multiple orchestrators embedded at the cluster level. A push architecture is provided for manipulating and verifying workload configurations, including the ability to determine differences between stored configurations and actual configurations.