Companion Database for Near-Real-Time Blockchain Transaction Processing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The delay in validating transactions on distributed electronic ledgers like blockchains, such as Bitcoin, can lead to significant delays in asset transfers, which is not suitable for immediate delivery expectations in retail transactions, as users typically wait for multiple blocks to be published before confirming a transaction.

Innovation Solution

A companion database is introduced that stores the status of assets and metadata related to transactions, allowing for quick querying and authorization of transactions without waiting for the blockchain to verify updates, thereby reducing the time required for transaction approval.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If peer processors verify updates before recording them in the distributed electronic ledger, then the reliability of the ledger is improved, but the transaction processing speed deteriorates

Engineering Contradiction:
Improveledger verification reliabilityVSAvoidtransaction processing speed
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The companion database pre-computes and stores asset states and transaction metadata before the distributed ledger completes its verification process. This allows the system to provide immediate transaction information without waiting for the slow peer processor verification to finish, effectively performing the information preparation action in advance.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The companion database acts as an intermediary between the distributed ledger and the transaction processing system. It receives updates from the ledger, pre-processes them into usable state information, and provides this information to requesting systems, thereby mediating between the slow verification process and the need for fast transaction processing.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the system waits for multiple blocks to be published before confirming transactions, then the reliability of transaction confirmation is improved, but the transaction completion time deteriorates

Engineering Contradiction:
Improvetransaction confirmation reliabilityVSAvoidtransaction completion time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The companion database pre-computes asset states based on received updates even before those updates are confirmed in multiple blocks. This preliminary computation allows the system to have transaction confirmation information ready much earlier, reducing the time loss while maintaining reliability through the pre-computed state tracking.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If the companion database processes updates independently without waiting for ledger verification, then the productivity of transaction processing is improved, but the risk of processing unverified data increases

Engineering Contradiction:
Improvetransaction processing throughputVSAvoiddata verification reliability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The companion database implements a feedback mechanism where it continuously monitors the verification status of updates from the distributed ledger. When updates are verified and recorded in the ledger, the companion database receives feedback and adjusts its pre-computed states accordingly, ensuring that processed data remains reliable through continuous verification feedback.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11188884B2Processing network architecture with companion database
Publication Date: 2021.11.30 THE TORONTO DOMINION BANK
  • US11188884B2 patent drawing
  • US11188884B2 patent drawing
  • US11188884B2 patent drawing

AI summary

A system comprises a non-transitory machine readable storage medium storing instructions and a database identifying a plurality of assets and a state of each asset. The instructions configure a processor for receiving updates to a distributed electronic ledger managed by plural peer processors. Each update includes an event or change affecting one of the assets. The peer processors verify portions of the ledger describing each event or change. At least one of the updates has not yet been recorded in the ledger at a time of the receiving. The processor computes a state of each asset, based on the updates, receives a request for a state of one of the assets; and responds to the request, reflecting each event and change affecting that asset. The response is performed without waiting for the peer processors to verify an update that has not yet been recorded in the ledger.