Why Interchain Services Will Become the “HTTP” of Blockchains? | Interchain Conversations II recap

Published in

IRISnet Blog

6 min readDec 18, 2020

Jeffrey Hu, director of research at IRISnet, attended Interchain Conversations II. On the live event, he introduced interchain service (iService) and its effect combined with IBC to realize TCP/IP + HTTP of cross-chain on the application layer.

The main points are:
• What Application Layer Protocol should be in cross-chain?
• iService & its ability on a single chain, cross-chains, and off-chains
• iService’s use cases
• Achievements and plans

This article is a polished recap of the event.

What Application Layer Protocol should be in cross-chain?

Taking the internet nowadays as an example, for the dApp developer/user in the future, one should not be aware of what kind of blockchain infrastructure they are building/using. Cross-chain technology, represented by IBC, can help fulfill this vision.

IBC’s design follows a very similar idea with TCP/IP: It abstracted the designs of blockchain/distributed ledgers and how they can communicate with each other. So IBC can be regarded as Network Layer in TCP/IP, is a most generalized method that can be applied to heterogeneous blockchain/distributed ledgers.

Thinking back to what cross-chain can solve, I think the core problem addressed by cross-chain is trust between chains, corresponding to a blockchain is trust within the chain.

So how to solve this?

So following the idea of how to solve the trust problem, I concluded 3 kinds of methods related to cross-chain or interoperability between generalized ledgers and entities.

1. The first kind of method is no method, that is you have to trust someone or assume the ones are trustworthy, like gateway or notaries. Users have to trust the gateway or assume the gateway is trustworthy to transfer assets and other information.

2. The second kind of method is based on mathematics. Based on the math, you don’t trust, but can verify the proof, like Merkle proof from other chains. A similar idea also can be applied to layer2 solutions, like ZK Rollup which uses zero-knowledge proof. If we generalize it deeper, classical BFT-like consensus also follows the way that could be proved by math to achieve the agreement between nodes.

3. The third kind of method is based on assets. Actually, they are more game theory or incentive mechanism based on assets. The methods based on mathematics would be limited because of its rigorousness. While using the game theory and incentive mechanism, the methods could be more generalized. For example, Optimistic Rollup is much easier to support smart contracts for common use, because it uses an optimistic way to proceed and uses fraud-proof to detect users’ misbehaviors. If we generalize it similarly, Nakamoto consensus is using the game theory but not a rigid proof to achieve decentralized coordination on such a huge scale which BFT consensus hasn’t done before.

Today’s main topic, interchain service, a.k.a iService is also based on assets to maximize its systems integration ability. Users can get service fees after providing the expected service, while users can be punished by misbehavior, like the deposit be slashed.

And there is no gap between these methods, but they can be combined with each other effectively. For example, Optimistic Rollup also has proof that can be verified by users to identify misbehaviors. iService can also be combined with IBC to realize the internet of blockchains.

While, since IBC is a cross-chain protocol that can connect heterogeneous blockchains, why do we need iService that follows another way of idea?

Because the systems expected to be connected in the internet of blockchains should include those systems in many other forms like centralized legacy systems(no-chain) and permissioned blockchains. These systems, as the source of data and services, are likely to have no verifiable proof, so we need to combine with interchain service for applications to complete the whole protocol stack: using iService as Application Layer, while using IBC as Network Communication Layer to form the TCP/IP + HTTP of the internet of blockchains.

iService on a Single chain

However, iService can also be used without IBC and serve on one single chain as a service market. Users are able to define, bind, request and respond to services by depositing some IRIS tokens on the blockchain such as IRIS Hub which actually acts as a service exchange market.

iService on Cross-chains

When it comes to cross-chains, iService combining IBC plays a more important role regarding connection.

But it’s necessary to customize IBC and involve several functions implementation:
1. Relayer: light clients that connect AppChain (i.e. the blockchain needs to be connected via cross-chain and complete certain business application), analyse and convey messages of iService as well as relevant proof.
2. iService Ex: need to be deployed on AppChain normally in the form of smart contracts, be responsible for the interchain service management, normally including iService Core Ex and iService Market Ex:
• iService Core Ex: the core component of iService Ex, responsible for the core logic of service invocation and response.
• iService Market Ex: helps the access chain to get information about the services and the service providers.

iService on Off-chains

Besides, iService is able to connect with the off-chain systems, namely non-blockchain/distributed ledger systems.

Oracle is one of the typical usages of iService’s off-chain ability. Based on iService, IRISnet developed the oracle module; all the blockchains based on Cosmos SDK can have the ability to get off-chain data after integrating this module. Data feed implemented depends on iService, and its lifecycle is the same as iService, including creating, starting, pausing, editing, etc.

In addition, iService is allowed to integrate various types of systems, such as privacy computing service that can realize encrypted data sharing, legacy systems like ERP, OA, Bank systems in the enterprise apps. These traditional centralized services can be wrapped into services to interact cross-chain.

Achievements and Plans

Based on the above designs, IRISnet development team has achieved:

Made iService function available on IRISnet mainnet
Developed the oracle module based on iService
Implemented Relayer & iService Ex for Ethereum, Fabric, FISCO BCOS, etc., that can achieve the interoperability between public chains and permissioned blockchains
Deployed an instance (IRITA Hub on BSN) by customized IBC

For example, based on IBC + iService, the Cross-chain service hub in BSN can achieve interoperability between permissioned blockchains, public blockchains, and off-chain oracles.

For the next move, with the form of IBC+iService, we intend to improve the ability to connect more chains (both permissioned and permissionless).

At the same time, we plan to release more services and applications on IRIS Hub/IRITA Hub, such as the e-Ticket with StarryMedia (Using NFT module as well) .

Video: https://www.crowdcast.io/e/interchain-conversations-II/24