Blockchain Micro-Service Framework for Distributed Consensus

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing blockchain technologies face challenges in managing and scaling blockchain services effectively due to rapid changes in underlying cryptography and processing demands, leading to inefficiencies and reliability issues across different micro-services.

Innovation Solution

A framework for providing blockchain-based micro-services that allows for focused development and risk management through a micro-service architecture, enabling the use of shared ledgers in a distributed consensus network, where API calls initiate specific framework modules for consensus validation, and responses are generated to provide reliable services.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If blockchain technology relies on an ever-growing proof-of-work chain to validate information blocks, then security and validation are improved, but system complexity and processing demands increase significantly

Engineering Contradiction:
Improvevalidation securityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the monolithic blockchain validation system into modular micro-services, where different validation functions (proof-of-work, proof-of-stake, smart contract execution) are separated into independent, interchangeable components. This allows the system to maintain security while reducing overall complexity by enabling selective implementation of validation mechanisms.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The framework enables dynamic selection and switching between different consensus algorithms and validation methods at runtime. The system can adaptively choose appropriate validation approaches based on specific service requirements, transitioning from static proof-of-work to more efficient methods when applicable, thereby reducing processing demands while maintaining security.

Inventive Principle:
Principle #15Dynamics

2Ease of operation

If blockchain services are managed through centralized control points, then service delivery is simplified, but scalability and reliability are limited

Engineering Contradiction:
Improveservice managementVSAvoidservice reliability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent creates a universal framework that can manage multiple blockchain services across different distributed networks through standardized interfaces. The framework provides multi-functional capabilities to handle various consensus algorithms, node types, and service requirements uniformly, enabling simplified management while maintaining the reliability benefits of distributed architecture.

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

Solution Approach 2:

The framework acts as an intermediary layer between control points and the distributed blockchain network. It provides abstraction and standardization, allowing simplified service management at the control point level while ensuring reliable distributed execution through the intermediary framework that coordinates between centralized management and decentralized validation.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If new blockchain technologies and cryptography are rapidly introduced, then adaptability and security are improved, but system stability and compatibility are compromised

Engineering Contradiction:
Improvetechnology adaptabilityVSAvoidsystem stability
Core Design Contradiction:
Adaptability or versatilityVSStability of the object's composition

Solution Approach 1:

The framework is designed to be dynamic and configurable, allowing new cryptographic methods and blockchain technologies to be integrated without restructuring the entire system. Services can dynamically adopt new algorithms while the framework maintains stable core functionalities, enabling continuous adaptation to emerging technologies while preserving system stability.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

By segmenting the system into modular micro-services with well-defined interfaces, the framework isolates stability-critical components from rapidly evolving technology components. This allows new cryptography and blockchain methods to be introduced in isolated modules without affecting the stability of the core framework, maintaining compatibility while enabling adaptability.

Inventive Principle:
Principle #1Segmentation

4Productivity

If micro-services are designed to scale independently, then productivity and efficiency are improved, but system complexity and coordination overhead increase

Engineering Contradiction:
Improveservice efficiencyVSAvoidarchitecture complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements a universal framework with standardized interfaces and common infrastructure that all micro-services share. This universality enables independent scaling of individual services while avoiding the complexity of custom integration for each service, as the framework provides built-in coordination mechanisms and standardized communication protocols.

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

Data Source

PatentUS10447770B2Blockchain micro-services framework
Publication Date: 2019.10.15 VERIZON PATENT & LICENSING INC
  • US10447770B2 patent drawing
  • US10447770B2 patent drawing
  • US10447770B2 patent drawing

AI summary

A network device receives a first application programming interface (API) call from an application. The first API call requests a micro-service of a blockchain-based technology. The blockchain-based technology includes use of a shared ledger among participating nodes in a distributed consensus network. The micro-service provides a function for the application. The network device sends, in response to the first API call, a second API call to one of the participating nodes. The second API call initiates a framework module of a multiple of framework modules in the participating nodes. The network device receives, from the one of the participating nodes, a response to the second API call, the response indicating consensus of the participating nodes. The network device generates, based on the response to the second API call, a reply to the first API call.