Inter-Blockchain Communications (IBC)
One of the primary advantages of building the Platform-D on cometBFT, cosmos-sdk & CosmWasm is the native support for IBC protocol, which is a trust-minimizing and permission-less solution for interoperability bridge.
IBC minimises third-party risks
Bridges with centralised third parties
Most bridge solutions requires a trusted third-party to relay messages between chains and/or to onboard a new chain. This is a valid solution for specific use cases, notably Circle's Cross-Chain Transfer Protocol, which requires Circle as an entity must be the only master minter of USDC. This means that:
- Chain Onboarding: Circle is the only entity that can add a new chain to the CCTP ecosystem
- Permission and Trust: Circle is a centralised entity to "burn/lock & mint" from one chain to another
It is also worth noting that there is a trusted implementation of IBC by using a centralised / multisig Light Client Proxy verification with [TEE] offchain then using the TEE to submit the verification onto another chain. There is ongoing project with this method for Cross-Chain settlement of Stable Coin with banks in Japan.
Permissionless and Trustless bridging
However, outside of the stable coin application, it is important to minimise third-party risks when it comes to chain interoperability. IBC allows for each implementing chain to verify the light client of the other, via cryptographic proofs; these proofs can be submitted onchain by anyone and will not depend on the bridging entities.
If the states proofs are incorrect, e.g. the client hash does not reflect the previously accepted one, then the submission will fail, therefore finality is set. Because of the design of the consensus algorithm implemented in cometBFT, finality is provided per block and therefore the updates that are required on the remote chain light client is final.
IBC allows for normal users of either chain to run a stateless IBC-relayer, implemented in different languages and maintained in open-source (hyperspace-relayer, ts-relayer, hermes (rust), cosmos/relayer (golang), yui/ibc-relayer), to submit state updates from one chain to another chain. In simple terms, as long as the chains themselves are considered trusted (e.g. requires verifiable credential, decentralised, has qualified validators, etc), then interoperability via IBC minimises third-party risks.
Proven Technology across multiple ecosystems
IBC is a proven technology with ~70 Cosmos-sdk based chains already connected and over [25B USD transacted] with no , others are being developed / used described below:
| Projects | Target Ecosystem | Details |
|---|---|---|
| Polymer Labs | Ethereum | |
| Union | Ethereum | zkIBC proof of ed25519 curve (consensus) verification, not state transition |
| Electron Labs | Ethereum | |
| LCP - Light Client Proxy | Ethereum | Offchain [TEE] for light client verification & ibc-solidity contracts on EVM chains |
| Hyperledger Fabric | yui-fabric-ibc | |
| Corda | yui-corda-ibc | |
| Ethereum | [yui] | |
| Landslide | Avalanch Subnet | A subnet in Avalanch ecosystem building on the forked Tendermint consensus |
| Composable Finance | Polkadot / Kusama | Unique project bridging Polkadot & Kusama with IBC-substrate Pallet |
| Polkadot | Production | |
| Ethereum | (Testnet) | |
| Solana | In development |
IBC on Platform-D
Platform-D is an application specific chain that runs the business logic and has qualified validators to validate and replicate state change. For external settlement or interoperability, i.e. if we want to consider Platform-D states to also update states on external blockchains for any reason, or would like to interact with other blockchains, Platform-D can either utilise [TEE] for IBC verification (where it requires existing validators to verify), or have the out-of-the-box IBC module in cosmos-sdk to interact trustlessly with the various open-source relayers.
It is worth noting that any external state updates via IBC on Platform-D also follows that same requirements as any transactions, i.e. only those with verifiable credentials.
Last updated: Belsy Yuen, 28-11-2023