A user may have an asset on one blockchain and wish to move the asset to another blockchain.
A user may have an asset on one blockchain and wish to swap it for an asset on another blockchain.
A trade finance application creates a crosschain function call that goes across five contracts on five blockchains to execute a trade for a shipment of goods. The entry point function is the executeTrade function in the Trade Wallet contract on the Wallet blockchain. The Trade Wallet contract could be a multi-signatory wallet that parties to a shipment have to submit a transaction to, indicating that they agree a shipment for a certain quantity of goods has been made and should be paid for. The executeTrade function calls the shipment function in the Logic contract on the Terms blockchain to determine the price that should be paid and to affect the transfer of stock and payment. The shipment function calls the getPrice function on the Oracle contract on the Price Oracle blockchain to determine the price that should be paid for the goods, then calls the transfer function on the Balances contract on the Finance blockchain to affect the payment, and finally calls the delivery function on the Stock contract on the Logistics blockchain to register the changed ownership of the goods.
It could be argued that some of the contracts could exist on the one blockchain, thus reducing the need for crosschain transactions. However, the Finance blockchain and the Logistics blockchain in particular are likely to be consortium blockchains involving different participants. The Price Oracle blockchain could be operated by a consortium that charged for access to the information. It might be a requirement to have the logic on the Terms blockchain visible to government regulators, but the participants in the trade wallet on the Wallet blockchain may wish to remain anonymous. A crosschain transaction capability is needed to meet these requirements.
Supply Chain Selective Transparency and Selective Privacy
In this scenario have three blockchains:
- The Supply Chain blockchain that has all the information related to a supply chain. The membership of this chain is strictly limited to the members of the supply chain consortium.
- The Regulatory blockchain has the members of the Supply Chain, plus a government regulator. The information published to this chain is information required for compliance reasons, but does not include the detail that is in the Supply Chain blockchain.
- The Customer blockchain that holds information that gives customers assurance of the provenance of the goods they are purchasing.
An Atomic Crosschain Transaction would allow events in the Supply Chain blockchain to be selectively published to the Regulatory blockchain and the Customer blockchain. This would allow for selective privacy with selective transparency. Atomic behaviour is required to ensure events that should be reflected in the Regulatory or Customer blockchain don’t appear solely in the Supply Chain blockchain (or just in the Customer or Regulatory blockchains) due to a failure.
The Hotel and Train problem is a common example distributed transaction problem. In this scenario, a travel agent needs to ensure the atomicity of a combined booking transaction. In other words, the travel agent needs to ensure that they either book both the hotel room and the train seat, or neither, so that they avoid the situation where a hotel room is successfully booked but the train reservation fails, or vice versa. There are three blockchains involved: the travel agency runs a blockchain, the hotel company runs a blockchain, and the train company also maintains its own blockchain.
The diagram shows Lockable and Non-Lockable contracts being used. A Lockable contract can be locked. A Non-Lockable contract can not be locked. Combining the two types of contracts allows for systems such that a Non-Lockable Router contract can locate an appropriate unlocked Item contract. In this way, multiple atomic crosschain transactions that cause contracts to be locked can be processed in parallel.