Posts

Solving Blockchain Distributed Transaction Challenges

/in , /by

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

Blockchain: Navigating the Disruption

/in , /by

After years of theoretical debates and abstract use cases, it is no longer a question of if blockchain will cause market disruption, but rather when and how widely the impact will be felt. Now is the time to remove any outstanding doubts about blockchain applicability and strategically manage the business and operational risks that inevitably come with innovation. The main barrier being how to best plan for and manage the disruption. In all cases, correctly quantifying the threats and opportunities is a requirement for success.

Using a range of specific cases across various markets and industries, including financial services, supply chain and healthcare, we are actively conducting research and collaborating with other industry leaders to verify how to best apply a scientific method of predictive emulation to reveal where the capabilities of blockchain are best suited to solve business problems, quantify the expected improvements and manage the risks in delivering the solution.

Blockchain technology is best known for being the magic behind Bitcoin, but there are scores of other industries that can benefit from this revolutionary technology. The benefits include driving costs savings by reducing labor-intensive processes and eliminating duplicate efforts, as well as creating new markets by exposing previously untapped sources of supply.

Funded by eager venture capitalists, start-ups can easily pursue blockchain initiatives, but convincing stakeholders of global corporations and financial institutions to go all-in on a new technology that could overturn the very fundamentals of the business and the organization’s biggest profit drivers is not easy. Alternatively, taking a wait and see approach may place laggards at a significant competitive disadvantage as the move to blockchain requires a well devised plan and sufficient time for its execution.

Given the dynamic complexity of modern systems, it can be difficult to identify across operations the right plan to manage disruption and create a sustainable business model. With technological innovations, often the most dangerous risks are posed by the unknowns that cannot be predicted with historical reference models and often escape the imagination of risk committees. A scientific method to predictively quantify opportunities and universally manage risks can help stakeholders strategically time, justify and manage a disruptive move.

X-Act® OBC Platform is useful in these cases as it is the only mathematical dynamic complexity emulator that can realistically model business services and infrastructures. We use X-Act OBC Platform to replicate the dynamics and complexity of business implementations—allowing us to predictively compute system behaviors at different points in time and under various operational conditions. These insights can then be used to plan for and manage a disruptive move by supporting the series of complex decisions necessary to make the right trade-offs between sometimes conflicting objectives, allow acceptable time to market and preserve business continuity.

Using the emulator capabilities of X-Act OBC Platform, we tested various blockchain scenarios under different patterns of initial conditions and dynamic constraints to identify the conditions under which risk will increase, as well as the possible mitigation strategies.

By modifying the parameters of each scenario within the emulator, one by one, by group, or by domain, to represent possible changes, we are able to extrapolate each time the point at which the system will hit a singularity and use the corresponding information to diagnose the case. Additional scenarios can be created to explore viable and proactive remedial options that secure an acceptable risk mitigation strategy.