Blockchains are ideal for shared databases in which every user is able to read everything, but no single user controls who can write what. By contrast, in traditional databases, a single entity exerts control over all read and write operations. However, issues relating to scalability, enforcement of business constraints, and aggregation may arise when using shared ledger structures for multi-party or distributed transaction models. Augmentation of the blockchain protocol using a collector or aggregator mechanism is necessary to overcome the issues.

Interorganizational Record Keeping

The chain acts as a mechanism for collectively recording and notarizing any type of data, whose meaning can be financial or otherwise. An example is an audit trail of critical communications between two or more organizations, say in the healthcare or legal sectors. No individual organization in the group can be trusted with maintaining this archive of records, because falsified or deleted information would significantly damage the others. Nonetheless it is vital that all agree on the archive’s contents, in order to prevent disputes.

Multiparty Aggregation

This use case is similar to the previous one, in that multiple parties are writing data to a collectively managed record. However, in this case the motivation is different – to overcome the infrastructural difficulty of combining information from a large number of separate sources.

Imagine two banks with internal databases of customer identity verifications. At some point they notice that they share a lot of customers, so they enter a reciprocal sharing arrangement in which they exchange verification data to avoid duplicated work. Technically, the agreement is implemented using standard master–slave data replication, in which each bank maintains a live read-only copy of the other’s database, and runs queries in parallel against its own database and the replica.

Now imagine these two banks invite three others to participate in this circle of sharing. Each of the 5 banks runs its own master database, along with 4 read-only replicas of the others. With 5 masters and 20 replicas, we have 25 database instances in total. While doable, this consumes noticeable time and resources in each bank’s IT department.

Fast forward to the point where 20 banks are sharing information in this way, and we’re looking at 400 database instances in total. For 100 banks, we reach 10,000 instances. In general, if every party is sharing information with every other, the total number of database instances grows with the square of the number of participants. At some point in this process, the system is bound to break down.

Multi-party and Distributed Transaction Challenges

In either a multi-party record keeping or distributed transaction model, a party may want to find and reorder related blocks in chronological order to support a decision or they may want to enforce constraints before taking action. Using patient care as a specific example, a doctor may want to pull all of the medical records for a patient before deciding whether to perform a medical procedure. These records may include hospital records, test results, medical history, insurance authorizations, etc. Proceeding with the patient care may be dependent upon factors such as a primary care doctor referral, appropriate insurance authorizations, and blood test results within 72 hours of the planned medical procedure.

By automating the retrieval and sequencing of events through an aggregator mechanism, we can deliver the necessary information in correct sequence at the right time—without cumbersome manual manipulation of chains or custom coding.

Shared-Ledger Algorithm

We have developed a mathematical algorithm that collects and dispatches the right sequence of events and time sensitive priorities to aggregate multiple domain specific blockchains to form a purpose-oriented blockchain. Tested under a variety of cases to determine its wide applicability, the patented algorithm complements the blockchain protocol to provide necessary aggregation solution for multi-party transaction processes that characterize industries and services of multiple shared blockchains such as:

• Healthcare: Patient treatment and admission, preventive medicine, research, etc.
• Government-citizen services
• Regulations
• Supply chain management
• Corporate actions
• Multiple-suppliers to right time processing
• Food production
• Research and development
• Banking and capital markets