Domain-Specific Consensus Engine for Distributed Ledger Validation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional consensus processes in distributed ledgers lack domain and type-specific validation, leading to inconsistencies due to the use of smart contracts, which can result in invalid or improperly formatted transactions being stored on the ledger.
Innovation Solution
Implementing a domain and type-specific consensus process using a chain of responsibility pattern, where a core consensus engine interfaces with a domain-specific engine that identifies and invokes type-specific processing objects to validate events, ensuring consistent validation across all nodes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Extent of automation
If smart contracts are used for validating events in distributed ledgers, then automation of validation processes is improved, but consistency and reliability of validation across different nodes deteriorates due to potential inconsistent versions of smart contracts
Solution Approach 1:
The validation process is segmented into separate components: a core consensus engine that handles general validation logic and domain-specific processing objects that handle domain-specific validation. This segmentation allows the core engine to maintain consistent validation across all nodes while domain-specific objects can be independently updated without affecting other domains, thereby resolving the contradiction between automation and consistency.
Solution Approach 2:
Domain-specific processing objects act as intermediaries between the core consensus engine and the smart contracts. These processing objects serve as a standardized interface that translates domain-specific validation requirements into consistent execution, ensuring that all nodes validate events in the same manner while maintaining automation through the processing object framework.
2Reliability
If domain-specific processing objects are introduced to improve validation consistency, then reliability of event validation is improved, but device complexity increases due to additional processing components
Solution Approach 1:
The core consensus engine serves multiple functions: it manages the consensus process, interfaces with domain-specific processing objects, validates events, and coordinates with the distributed ledger. This multi-functionality reduces the need for separate dedicated components, thereby improving validation consistency without proportionally increasing system complexity.
Solution Approach 2:
Domain-specific processing objects can be implemented as reusable templates or copies that are instantiated as needed. This allows the system to maintain validation consistency across different domains while avoiding the complexity of maintaining entirely separate validation systems for each domain, as the same processing object framework can be copied and adapted as required.
3Device complexity
If traditional smart contract validation is used, then simplicity of the consensus process is maintained, but data quality and validity of stored events deteriorate due to lack of domain-specific validation
Solution Approach 1:
Domain-specific processing objects provide localized validation quality tailored to each domain's specific requirements. Each processing object can enforce domain-specific validation rules and data quality standards, ensuring that events are validated with the appropriate precision for their specific domain while maintaining overall system simplicity through the standardized processing object interface.
Data Source
AI summary
Domain and/or event type-specific consensus processes for distributed ledger are provided. A consensus request is received by a core consensus engine. The consensus request corresponds to an event, the event (i) corresponds to a domain and (ii) has a type, and the consensus request comprises information corresponding to the event. Information corresponding to the event and the type are provided to the processing manager corresponding to the domain. The processing manager identifies a set of processing objects based on the type. The processing manager calls at least one processing object of the set via a corresponding interface and provides information corresponding to the event to the called processing object. The processing object is executed to generate a corresponding object result. The processing manager generates an aggregate result based on the object results. The core consensus engine determines a consensus response based at least in part on the aggregate result.