This is a two-blog series highlighting how Inter-Blockchain Communication (IBC) Protocol is relevant for Enterprise use-cases.

The first blog introduces IBC and goes into detail of how IBC will be used at the Persistence Hub (Enterprise Hub of Cosmos) level. The second blog will present the 1st IBC transaction done by the Persistence team in late 2018.

Contents:

Introduction

Why is IBC important in the context of enterprises?

How will IBC be used at Persistence Hub level?

- Interchain Transaction Proofs

- Interchain NFT exchange

- Interchain Governance

Introduction

To date, each of the Blockchain protocols have existed in their own close-ended silos, without the ability to exchange information trustlessly. The lack of solutions for interoperability between the different Blockchain networks has significantly restricted publicly available decentralized and distributed applications, in terms of their compatibility with the other native Blockchains thereby reducing the potential user-base.

As for enterprises, the lack of structurally sound Blockchain interoperability solutions has, till- date, limited them from availing the benefits of increased scalability on offer through the use of application-specific side-chains (can be zones). In addition, enterprises have been restricted from the ability to exchange high value data between distinct native chains that have their own governance and unique owners.

Persistence aims to bring interoperability to enterprise Blockchain networks by leveraging the IBC module which will not only be implemented at the Persistence Hub level but also in private or consortium Blockchain applications built on the Persistence SDK.

Why does IBC matter for Enterprises?

Application interoperability

“Enterprise Blockchain ecosystems of the future will involve communication between a network of industry-specific, specialized chains working cohesively in an environment secured in a trustless manner.”

Multinational Companies (MNCs) all over the world are constructing their own consortium or permissioned chains to ensure integrity of the operations executed on the decentralized applications as well as the privacy of the data involved.

Larger-scale enterprises operating in the following industries have been developing native chains for a number of years:

Commodity Trade Industry

Global Shipping Logistics Industry

Pharmaceutical Industry

Energy Industry

Agricultural Industry

Smaller-scale enterprises may not have the bandwidth and resources or even the requirement to maintain their own chain and governance structure. However, for organizations that require a highly customized or a fully centralized governance structure along with dedicated network resources for maximum throughput, Inter-Blockchain Communication is essential for the secure exchange of data with the native chains of other relevant stakeholders.

Scalability

Whether enterprises operate distributed applications on a public network or private network, there are several limitations to scalability that exist due to the lack of interoperability.

Enterprises running their applications on a public Blockchain face scalability issues because of the shared processing bandwidth offered by public chains. Multiple applications running on a public chain have the ability to potentially clog its network with their transactions, stopping critical business processes of other applications.

While on the other hand, a similar disadvantage of restricted throughput is seen on private networks where more distributed applications on the same chain also implies slower transaction times.

The IBC protocol solves both interoperability and throughput issues. Different applications with asymmetric logic could operate on their own chain with no throughput sharing, while also communicating with each other through IBC. If the load on one application chain increases, it could be replicated into two with load sharing and communicating outputs to a Hub through IBC, allowing for almost infinite horizontal scalability while still allowing interoperability with other applications.

In addition, enterprise applications commonly utilize Non-Fungible Tokens (NFTs), which have heavy transactions (in terms of byte size) that require a high degree of computation power and storage. With an interoperable structure involving a Hub and zone model, NFT transaction speeds can be increased. This is achieved through handling of the NFT metadata storage on a zone chain and processing all the ownership exchange transactions on the Hub chain while referencing back to the zone chain.

How will IBC be used at the Persistence Hub Level?

Inter-chain Transaction Proofs

Persistence provides enterprise with a spectrum of governance options based on the enterprise’s specific requirements. The governance structure of an enterprise zone may range from a fully third-party decentralized structure to a fully permissioned centrally governed structure.

Regardless of a zone’s governance structure, the zone can take advantage of IBC in order to post transaction proofs on the Persistence Hub, thereby establishing a new chain of provenance. Transaction proofs do not expose any of the data in a transaction. However, it can be used retrospectively to verify the authenticity of the proposed activity within a chain.

Interchain NFT exchange

The NFT creation and metadata storage is handled at the zone level, while the ownership and wallet of the asset is maintained at the Hub level. A wallet is zone agnostic, and can hold NFTs and Refungible Tokens (RFTs — Refunged NFTs) from any zone.

The ownership transfer transaction at the zone level is communicated to the Hub through IBC. At the Hub level, owners of a NFT or RFT may initiate a negotiation and escrowed exchange for their tokens, against any other token present in any other zone they see fit. Some zones in the future may require KYC of the wallet holder to redeem the value of the NFT/RFTs.

A chain to chain NFT exchange through IBC without the Hub would require a common interface and recognition for NFT/RFT value across-chain.

Interchain Governance

The validators present on Persistence’s enterprise zones (except self-hosted), are a subset of the validators present on the Persistence Hub. Disincentivization as well incentivization for performance or actions taken at the zone level is conducted on the Hub through the use of the IBC module.

Staking and slashing of tokens occurs at the Persistence Hub level while an enterprise is abstracted away from any token-economics at the zone level where there is no involvement of any form of tokens. Even though there are no tokens at the zone level, participating validators are dissuaded from attempting to compromise a zone due to the direct effect of slashing that will occur on the Persistence Hub along with the possibility of unbonding on other networks.

The two forms of interchain governance include:

Performance Related Governance Application-Specific Governance

Performance Related Governance:

The validators on the zone application chains are a subset of validators on the Hub. The Hub chain application will track the block headers of each zone chain through IBC, and acquire data such as block time, participating validators, and transactions committed per block.

This data is recorded on the Hub chain, and can be utilized to create a governance proposal to blacklist a validator from the validator list in cases of validator absence from consensus, malicious activities, collusion or transaction censorship.

Based on performance parameters/SLA set for validators for each zone, the stake of the validators could automatically be slashed if the performance metrics fall below the decided parameters. The performance criterion could be monitored through the block headers communicated through IBC.

Application-Specific Governance:

The block headers from the zone application chains can be utilized to verify validator participation and Merkle hash proofs, but cannot be utilized for the application logic proofs. With Zero Knowledge application logic proofs being added to block headers (in roadmap), communicated through IBC, the correct functioning of zone application logic can be succinctly verified.