Insolar Blockchain Platform Interoperability with other Distributed Ledger based systems
Blockchain shows much promise, but enterprises and businesses are so far hesitant to adopt this technological innovation. One of the main reasons for this is the risk of vendor lock-in, whereby a business invests heavily in a company’s technology and the data is not transferable to other providers should the company wish to switch. Insolar is creating a platform that is interoperable with other major distributed ledger technologies (DLTs) to foster wider adoption of the tech.
According to Deloitte’s 2019 global blockchain survey, 53% of organizations which responded place blockchain among their top strategic priorities for the next two years ahead. Whilst this is a rise of ten percent on 2018, blockchain adoption is still approached cautiously and is not widespread. Part of this hesitancy and wait-and-see approach is down to lack of interoperability of blockchain platforms.The industry needs freedom of choice in terms of using different DLTs and conventional systems together, creating hybrid architectures. The choices can be split into three categories:
1. Communication between different DLTs
One aspect hindering adoption of the blockchain and distributed ledger technology at present is the lack of standards for interoperability between different DLTs. This is a kind of the chicken and the egg causality dilemma in that an accepted standard can only become so when a large section of the market adopts a particular technology. Before this happens we cannot have any standard set. However, until this point, platforms such as Insolar can make their technology integratable with other DLT platforms. As such, the Insolar Blockchain Platform is being created to be interoperable with several other leading platforms in the blockchain arena.
2. Interoperability with Conventional Technology
Data sharing between a blockchain platform and conventional systems is a necessary aspect of any platform that wishes to become adopted on a large scale. This is since almost all data is currently held on such systems. If we think about the arduous task of digitizing paper documents (i.e. scanning them and saving them digitally), this replication takes up time and space. As such, the idea here is to have conventional systems interoperable with blockchain so that said blockchain systems are able to access data saved to previous generations of digital technology. Should this take place, migration from legacy systems to blockchain can be envisaged in three stages:
- Integrating blockchain so that it records the same information as the conventional system.
- Gradual switch to recording information only on blockchain with the interface being able to access both conventional and blockchain-based databases to retrieve data.
- All data stored on blockchain and reduction of legacy tech usage, perhaps by switching all data to blockchain-based management.
3. Interactions within a DLT platform
A DLT platform can be made up of several networks and these networks do not necessarily have to be interconnected. If they are not, then they may even not be interoperable with one another, even though they are built using a single technology. This can be the case with public and private networks belonging to one platform provider that are unable to share data with each other. The creation of hybrid blockchain networks allows for interoperability and data sharing between open and closed networks. On Insolar Blockchain Platform there can be many different clouds operating private or public networks. However, they are able to communicate with each other via internal protocol, synchronizing Merkle proofs (see below) between the different clouds.
Interoperability via Merkle Tree Hashes
Merkle trees are a core feature of blockchains. They condense data into a more manageable format, while they also make data transactions easier to verify and check whether they have been tampered with. A Merkle Tree is created by cryptographically hashing (converting data into a unique text) several transactions to give a value (hash) and then hashing the resulting hashes (unique texts) in pairs to form a hierarchy in which the top level hash becomes the root sum of the hashes below it. Should any transaction be tampered with, it results in changes to the hash values created from it, and so it is easy to work back and see where something has been altered.
Establishing what is the truth is therefore done by providing an independently verifiable cryptographic proof — a Merkle hash — on the object state in the network.
In blockchain, the paradigm for interoperability means how particular versions, dependencies or hash codes for blocks are referenced. In Insolar, a reference to a transaction’s Merkle root provides the basis of interoperability between different Insolar clouds, and is planned to be used when connecting to other DLTs. As such, contracts can receive calls and validate proofs without having to resort to direct access to the ledger.
DLT interoperability with Insolar
On Insolar, there will be two options to establish communications between the platform and other DLT clouds. The first is via remote calling of the high-level APIs, similarly to communication with conventional systems. Specifically, for Hyperledger Fabric this will be the only option. This option, however, does not provide any cross-DLT validation: Insolar and the DLT will be talking to each other essentially through oracles. The second option is to run the code of different DLTs side by side wrapped into the Insolar domain creating a so-called “parachain” configuration. It will basically work like buffer zone with Insolar code and data from both platforms. The Merkle proofs between Insolar and the other DLT will be validated by this special Insolar domain.
There will also be a possibility to run native contracts on Insolar. Initial plans are to run Hyperledger Fabric chaincode, but Insolar will also be capable of running Go or Java-based contracts in its virtual machine.
Interoperation of competing platforms is needed to give the industry a wide set of options for constructing heterogeneous architectures. Thus we avoid vendor lock-in and this, in turn, will lead to greater adoption of DLT as it will be easier to experiment with different platforms using the same data. Insolar has identified that executing native contracts from other platforms is key to blockchain adoption at this relatively early stage of the technology’s development.
- Check our Github and leave feedback on the code.
Follow Insolar on social media: