BFT SMR Execution Engine Integration Without Custom Request Handlers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing BFT SMR systems require custom request handling code and proprietary communication interfaces for each service/execution engine, complicating integration and extension of new services.
Innovation Solution
An execution engine integration (EEI) framework with a generic set of APIs and a standard communication interface, along with a request orchestrator, allows seamless integration of new execution engines without custom handlers, supporting both standalone and dynamically linked implementations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If custom request handling code and proprietary communication interfaces are used for each service/execution engine, then the system can maintain reliability and control over service-specific operations, but the device complexity and difficulty of integrating new services increase significantly
Solution Approach 1:
The patent implements a universal request handler that can process requests for multiple different execution engines through a standardized interface. This single component performs the function of what would otherwise require multiple custom handlers, reducing system complexity while maintaining the ability to handle service-specific operations reliably through the standardized protocol
Solution Approach 2:
The patent introduces a standardized communication interface as an intermediary layer between the consensus layer and execution engines. This mediator translates service-specific request formats into a universal format that the request handler can process, maintaining reliability for service-specific operations while reducing overall system complexity by eliminating the need for custom handlers for each service
2Manufacturing precision
If custom request handling code is implemented for each execution engine, then precise control over service-specific request processing is achieved, but the ease of manufacture and integration of new services deteriorates
Solution Approach 1:
The universal request handler is designed to maintain precise control over request processing for different services through the standardized interface. It can interpret and route requests appropriately while using the same code base, eliminating the need to manufacture new custom handlers for each service and significantly improving integration ease
Solution Approach 2:
The patent uses parameter-based configuration to maintain precise control over service-specific request processing. By changing parameters and configuration data rather than code, the system can adapt to different services while maintaining the same request handling infrastructure, making integration as easy as configuring parameters rather than developing custom code
3Reliability
If proprietary communication interfaces are used for each service, then communication reliability and service-specific requirements are met, but the adaptability and versatility of the system for new services decreases
Solution Approach 1:
The standardized communication interface is designed to be universally applicable across different services while maintaining communication reliability. It handles service-specific communication requirements through a unified protocol that can be configured for different services, providing both reliability and adaptability without requiring proprietary interfaces for each service
Solution Approach 2:
The patent implements a dynamic configuration system that allows the standardized communication interface to adapt its behavior based on service-specific requirements. The interface can dynamically adjust its processing based on configuration parameters, maintaining communication reliability for established services while easily adapting to new services through configuration changes rather than interface redesign
Data Source
AI summary
The present invention, in various embodiments, provides a novel execution engine integration framework for a BFT SMR system. With this framework, execution engines for services can be integrated into the BFT SMR system in a generic manner, thereby avoiding the need to implement a custom request handling code for each individual service/execution engine.