Note: Persistence has pivoted to liquid staking and building DeFi primitives to increase the utility for staked assets. This article is only for archive purposes.
(Visit here to read our latest blogs)
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 Chain (Hub) level. The second blog will present the world’s 1st ever IBC transaction done by the Persistence team.
Contents:
- Introduction
- Why is IBC important in the context of institutional use cases?
- How will IBC be used at Persistence Chain 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 institutional use cases, 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 main chain level but also in applications/applications specific chains built using 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
- Energy 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
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.
- Two chains with an IBC channel open between them, continuously keep on tracking the block headers to track the current state of a chain, block times, validator set etc.
- Each IBC packet is accompanied by a consensus transcript and a cryptographic commitment. The sending chain must generate it and the receiving chain must verify it.
- With ZKP, application logic proofs can be added to the IBC packet which will allow for validation of correct application logic execution.
- The validators on the observer chain can verify the correct execution of application logic on the observed chain without running full application logic by verifying ZKPs from point 3 and slash in case of collusion and incorrect application logic execution.
About Persistence
Persistence is a Tendermint-based, specialised Layer-1 network powering an ecosystem of DeFi applications focused on unlocking the liquidity of staked assets.
Persistence facilitates the issuance and deployment of liquid-staked stkASSETs, allowing users to earn staking rewards while participating in DeFi primitives, such as lending/borrowing and liquidity provisioning on DEXs.
Persistence aims to offer a seamless staking and DeFi experience for PoS (Proof-of-Stake) users and enable developers to build innovative applications around stkASSETs.
Join Our Movement
Twitter | LinkedIn | Telegram | YouTube | Reddit | [email protected]