Interoperability is the characteristic of a computer system or network, to interact, exchange and make use of information with an independent, outside system or network.

For the majority of its existence, Bitcoin was thought to be the roots from which everything would be based,the trust layer of the internet, and that all other needed functionality would be built upon it, hundreds of blockchains processing millions of transactions, as layers, all secured by Bitcoin. What has instead happened is an explosion of diversity in the blockchain ecosystem with many projects based on many differing cryptographic structures offering a variety of solutions on their own independent blockchains. Many of these projects come and solve one problem really well but none of them will be able to solve EVERYTHING well enough to be useful. This slow realization has caused the demise of the age of Bitcoin maximalism. The idea of the single chain trust basis of the Internet is dead. The future is full of many chains existing, side by side, and the kings will be the ones that bring the many blockchains, living in isolation, together in interoperable harmony.

Currently, if we want to move value from one chain to another, we need to use centralized exchanges which are costly, slow and add substantial risk. If you want a transaction to only be processed based on data or transaction finality from another chain, you must manage that process yourself. This lack of interoperation is stagnating the progress of the applicability of blockchain and therefore, mass adoption.

Because of this rising need, interoperability has been getting more attention in the past few years as blockchain diversity reaches maturity. Networks like Ark and BTCRelay are working to bridge the gap between blockchains, allowing actions in one, to cause effect in an another. Interledger is working to create a seamless payment network regardless of specific cryptocurrency. Polkadot and Cosmos are creating a more generalized framework to become the metachains in an “Internet of blockchains” approach. Internet Node Tokenon the other hand is looking to use this same idea in a much more application specific way in the area of IoT by creating a network of subchains dedicated to certain IoT device types, data types and needed blockchain mechanics, thereby creating a network of interoperable blockchains dedicated to the Internet of Things.

No matter the intended application, cross-chain interoperability is the key to mass adoption and those that can execute it well will become the leaders in blockchain.

Possible applications

The myriad of possible applications for cross-chain interoperability can be bucketed into five categories.

1.Portable assets — Trust-minimized 1-for-1 backing. Essentially this is transferring a digital asset from one chain to another with the ability to transfer it back to it’s home chain. A two-way channel between blockchains. This could be in the form of a government issued cryptocurrency that could be transferred into Ethereum as an e-USD token, traded, used and then transferred back onto the government chain. This requires the locking of the assets on the “home” chain which, then, is only releasable by re-locking the assets on the secondary chain which the initial transfer unlocked.

2.Transfer-for-transfer —Trust-minimized trading. Also known as “atomic swap”, where user A transfers their asset on chain 1 to user B and user B transfers their asset on chain 2 to user A in such a way that guarantees that either both transactions take place or that neither does.

3.Cross-chain oracles — one-way information reading causing action. Simply put, this is an entity or the chain itself having the ability to prove or read that something is true or that some action has taken place in another chain or network. A smart contract in a chain might have a condition that requires a proof of transaction in an outside chain in order for it to be finalized.

4.Asset locking — trust-minimized escrow. This may be used to lease assets or data upon payment for a given time period. An IoT device may be leased to an entity that wants full use of it’s capabilities for a short period of time, paying for use by the minute. Once that time is up, the contract would release ownership of that asset back to the primary owner.

5.General cross-chain contracts — multi-chain dependent smart contracts. This is a large category of applications from atomic swaps that rely on two or more chains to many-chain dependent smart contracts that use a web of data to trigger action. This type of contract would be the application basis layer of the IoT functional network. A smart home would be making decisions and causing actions based on many different IoT devices on many different chains. Your car might have it’s own wallet that uses information from the traffic data on a traffic network, time of day, miles per gallon consumption rate and number of people in your car as input to a smart contract that automatically calculates and pays a road tax given those variables.

Implementation Strategies

There are several strategies that can be taken in order to enable such cross-chain operation, with each one having differing abilities with varying trade-offs.

Notaries

The simplest way to facilitate most cross-chain operations is through the use of a notary. In this system, a trusted entity or group is used in order to claim that a given event on a subchain* has taken place or that some claim is true. These may be actively listening and automatically acting based on events on a given chain or passive, issuing signed messages only when prompted.

These can be in the form of multisig wallets or contracts that are released by the notary’s signed message of verification of conditions.

The most advanced effort in this space is the Interledger project developed by Ripple. This system can be used to facilitate the exchange of payments between ledgers without the need of exchanges and bank intermediaries (any cryptocurrency or currency backed by a bank -> your bank or currency of choice).

The drawbacks to this system are the requirement for active participation from a trusted and centralized entity.

Hash Locking

Relatively simple and limited in their capability, this is one method for achieving atomic swaps. It does this by having both users locking their funds in a smart contract that only releases after the first user provides the key which unlocks both.

More specifically:

User A locks his asset in a smart contract using a key that User B doesn’t know. Once User B sees User A’s asset locked, they lock their asset to exchange into the contract. User A then reveals the secret key that allows A to claim B’s asset and B to claim A’s asset. Now if User A doesn’t reveal the key in X seconds, the assets are released back to the Users.

This system is what is used by the Lightning Network where a Hashed Time-lock Contract is created between two users allowing bidirectional payments that are not finalized (therefore no network/transaction fees are paid) until the secret key has been released, symbolizing agreement for the payments made.

They can also be used as a “bounty claim ticket” posted on the blockchain that as soon as some transaction takes place with a certain known (preimaged) hash, the contract would release reward, i.e., “the first to provide this specific data to this address will get 5 Ether.” In this scenario, you would have to know what it is you want before you set up the contract so you know what hash you are looking for.

These can be written as an application in a network of sufficiently interoperable blockchains, where the smart contract or more appropriate, daemon has contract components on chain A, chain B, etc., and listens for certain preimaged hashes from these chains, therefore triggering events. These can be run on the relay chain much like the salary work reporting mechanism in INT, which upon the reporting of data (on chain A), payment is made (on chain B), where the daemon has control of an address on chain B and authority to sign transactions.

Because hash locks are cryptographically based and open source, they can be run by anyone and does not need to be trusted.

Relays

Significantly more difficult to implement, relays are a more direct and wide-ranging method of facilitating interoperability that solves the need to rely on trusted third parties to verify outside information by giving the chains themselves the power to do so. In independent chains, this requires independently verifying the block header which contains the transaction important to it’s use.† This effectively** verifies all branches of the Merkle tree within that block without the need to download the entire blockchain for verification [Fig. 1]¹. Because this data is cryptographically secured and self-verifying, this removes the need for trusted entities.

Fig. 1 The entire dataset doesn’t need to be downloaded to verify the integrity of 

Transaction 5.

The drawbacks of this system are that the time between transactions is directly dependent on the block time associated with each chain with the “worst possible” scenario time-to-verify for the cross-chain transaction as

2Tₐ+Tₑ

Where Tₐ is the block time for chain A and Tₑ is the block time for chain B (“b” is not an available subscript, I know…). You can see that transaction verification time quickly balloons in “long” block time-based chains.

In networks that are inherently self-contained, the relevant information and how to read it from the secondary chain would have to be inputted by the user unless there was some sort of established API dictionary for interacting with the network.

In general, these steps for verifying the validity of a subchain state can be standardized into smart contracts to be called by anyone for widespread use. This can itself become a blockchain of smart contracts that can be called to verify events on other chains, basically making it a state chain of unconsumed events as the UTXOs of this blockchain.

In summary, the three implementation types solve a variety of problems with varying trade offs. Each have their place whether it is in centralized payment processing, simplified and decentralized asset exchange or multi-chain dependent smart contracts.

Fig. 2 Interoperability Type Table ²

INT’s Quest for the Cup

There is perhaps no other application more in need of holistic interoperability than in the field of IoT. In order for the Internet of Things to truly work as envisioned, everything needs to communicate with everything, decisions need to be made with many contributors and data needs to be widely shared. This ecosystem will need to be a collection of many chain types to accommodate the many needs; data chains, value transfer chains, identity chains, asset ownership chains, privacy-centric chains.

This is where the real beauty of the INT framework lies. By separating the transaction validation from block formation and constructing one central block chain (the Thearchy chain) of blocks for each subchain, interoperating between subchains becomes greatly simplified [Fig. 2]. There is no out of network interaction that has to take place, no independent transaction confirmation and verification that needs to occur, no trusted entities that need to sign off that an action has taken place. It is all on one chain, available to every subchain in the network.

Fig. 2 INT Chain Network Diagram. With the validator/block generator nodes (Supernodes) outside the subchain and hashing all subchain data into one blockchain, cross-chain transactions and smart contracts become greatly simplified.

Each supernode will maintain a table of subchains, the datasets present on that chain, and how to interact with them. This will make the process automated and trustless. The blockchain and node structure itself becomes the relay mechanism making all interoperation between subchains part of it’s core functionality.

This relay/node structure opens up a world of possibility only limited by the ability to create a subchain to support it. Subchain smart contracts could easily access data or transactions from any other subchain, they can use data or files from the IPFS DAG operating above the network, they could even use some form of Zero Knowledge Proofs (like zkSNARKs) to hide the sender, receiver, data or action that satisfies the smart contract without the whole network needing the ablity to support ZK proofs.

Operating as a web within the network, INT proposes to not only have the relay chain pass information between subchains but to enable the nodes in the network to collaborate computationally to make more complex usage of the data within it. This cloud computing network would facilitate machine learning algorithms to make intelligent decisions based on realtime data.

As I said at the beginning, the future is going to be full of many chains existing, side by side, and the kings will be the ones that bring the many blockchains together in interoperable harmony. Ultimately, this multi-chain framework is the best suited for solving this problem in the space today. The leading projects in metachains (Polkadot, Cosmos), supply chain (Waltonchain) and IoT (INT, IoTeX) are working to take this theoretical framework into real world application.

*A technical side note: INT and other projects use the term “subchain” or “sidechain” when referencing these cross-chain actions. This implies a dependent relationship on a parent chain or external validator. This is not necessarily true and these cross-chain actions can be done between two independent and standalone blockchains (or networks) with the existence of a trusted relay or notary. Subchains or sidechains that depend on an external chain or validator are “pegged sidechains” where pegged refers to the direct connection between the two and can read data from the chain it is pegged to.

†In PoW systems, this would be verifying that this header is part of a chain that has a sufficiently greater amount of PoW generated for it than that from any competing chain. In PoS systems, this would be verifying that 2/3 of validators’ signatures have signed the header.

**Finality in PoW blockchains is not guaranteed. Transaction roll-back only becomes less probable as they get deeper in the block chain. PoS systems don’t run the risk of having competing chains and therefore transaction finality upon block verification/signing is more of a guarantee.

Annotations

¹ This Merkle Diagram was pulled from this article from Hackernoon: https://hackernoon.com/merkle-trees-181cb4bc30b4

² This table was taken from, and much of this article was inspired by Vitalik Buterin’s paper titled Chain Interoperability for R3 Research

From：https://medium.com/@graytrain/interoperability-the-holy-grail-of-blockchain-eac8e689d50d.

By Graytrain