Event-Driven Ledger Validation Without Full Consensus Latency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing cryptographically-secured architectures face inefficiencies in processing and validating activities on distributed ledgers, particularly in events-based communication protocols, due to the need for a threshold level of consensus among validators, which can lead to increased latency and reduced scalability.

Innovation Solution

A system and method that utilizes a processor to facilitate an events-based communication protocol, allowing validation of activities corresponding to subscribed events without requiring a threshold level of consensus from validators, and enabling independent monitoring and validation of activities based on their content, with activities not matching events requiring consensus validation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a threshold level of consensus is required for validating activities on the distributed ledger, then reliability is improved, but processing time and latency increase

Engineering Contradiction:
Improvevalidation reliabilityVSAvoidprocessing latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies local quality by differentiating validation requirements based on event types. Events representing shared asset transfers require threshold consensus for reliability, while events representing non-shared asset operations proceed without threshold consensus for faster processing. This selective application of validation strictness resolves the contradiction between reliability and speed.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent segments the validation process into two distinct paths: one for shared asset events requiring threshold consensus and another for non-shared asset events that proceed without threshold consensus. This segmentation allows the system to optimize for reliability where needed and for speed where appropriate, resolving the trade-off between these two requirements.

Inventive Principle:
Principle #1Segmentation

2Reliability

If distributed control and decision-making capabilities are implemented, then system reliability is improved, but processing efficiency deteriorates

Engineering Contradiction:
Improvesystem reliabilityVSAvoidprocessing efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent implements local quality by applying distributed control selectively. Instead of requiring distributed consensus for all operations, the system uses distributed validation only for shared asset events, while allowing faster processing for non-shared asset events. This localized distributed control maintains reliability where necessary while improving overall processing efficiency.

Inventive Principle:
Principle #3Local quality

3Speed

If event-based communication protocols are implemented without threshold consensus, then processing speed is improved, but system security may be compromised

Engineering Contradiction:
Improveprocessing speedVSAvoidsystem security
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The patent applies local quality by differentiating security requirements based on event characteristics. Events involving shared assets receive enhanced security validation, while events involving non-shared assets proceed with faster, reduced validation. This localized security approach maintains system security where critical while enabling faster processing where appropriate.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS12608248B2Cryptographically-secured systems configured to execute events-based communication protocols and architectures, and methods of use thereof
Publication Date: 2026.04.21 BMIC LLC
  • US12608248B2 patent drawing
  • US12608248B2 patent drawing
  • US12608248B2 patent drawing

AI summary

A system for providing cryptographically-secured communication is disclosed. The system receives activities from clients including data for inclusion on a distributed ledger of a distributed ledger architecture. The system then processes each activity and determines whether an activity corresponds to an event subscribed to by at least one computing device. The event may correspond to the presence of a communication in an activity received by the system. The system validates the data associated with the activity by utilizing a plurality of validators and without requiring a threshold level of consensus if the activity corresponds to the event. If the activity does not correspond to the event, the system validates using the threshold level of consensus. Once the activity is validated, the system submits the data associated with the activity for inclusion on the distributed ledger so that the communication is made available to the at least one off-chain computing device.