Interoperability established through bridges always carry a element risk
Till now, the most popular way to transfer tokens from one Blockchain to another have been bridges. Bridges carry the risk of getting hacked, as hackers in the past have been successful in being able to exploit a vulnerability in the Bridge’s smart contract where the token is stored.
Bridges were also exploited by stealing access keys of Bridge gatekeepers( bridge validators) who oversee the security of the bridge chain as well.
Therefore, till now interoperability that’s come depending on bridging solutions provided by third party entities always carried a element of risk.
Interoperability without bridges possible with Cosmos’s IBC protocol
However, Cosmos Blockchain’s Inter Blockchain Communication (IBC protocol) brings about interoperability solution that does not use 3rd party bridges.
Interoperability that comes about leveraging IBC is secure, authenticated and reliable.
IBC is not a simplistic interoperability solution only capable for conducting cross chain token transfers, it’s capabilities are advanced as it can pass any form of data cross chain.
Understanding how IBC functions
Let’s understand how IBC makes interoperability possible without using bridges. It is noteworthy understanding this to appreciate the marvel of the IBC mechanism brought about by Cosmos Blockchian.
IBC’s functionalities are brought about by two main layers
IBC has two layers, the Transport layer and the Application layer.
Transfering of data along with it’s authentication done by IBC’s Transport layer
The transport layer provides the infrastructure that makes communication between two Blockchains possible, while the Application layer is the interface which users use that supports this IBC functionality.
Structuring & interpretation of data defined by IBC’s Application Layer
Application layers are built on top of transport layers for UIs that provide cross chain functionality powering token transfers, fetching of data cross chain using Oracles, Interchain Account, Interchain security etc.
It’s the application layer that structures the data and defines how the receiving chain should interpret it.
Diving into how IBC’s Transport layer functions …
Transport layer works using Light clients and employing the services of relayers.
Light clients are used to fetch and verify Blockchain Data…
Light clients are light weight representations of Blockchains. They verify Blockchain data connecting to full nodes. As they don’t store historical Blockchain data nor do computations necessary to validate Blockchain transactions that full nodes do, they are very light weight & functionally efficient.
So, when sending messages through IBC the Blockchains involved in the process will have light clients of the other Blockchain it is communicating with.
Here an example of how lightclients are used by Blockchains communicating through IBC
Blockchain 1(BK1) wants to send a message ‘k’ to Blockchain 2(BK2) using IBC. BK1 will send proof of the message ‘k’ to BK2, by providing Block header of the block on which message ‘k’ exists along with commitment proof.
A Block header provides the summary of data that’s in a Block, so BK2 can evaluate the Block header and commitment proof sent by BK1, to cryptographically verify if message ‘k’ was initiated in BK1.
Relayers pass the message communication to the destination Blockchain
So, using lightclients Transport layer is able to authenticate communicated data. However, Blockchains don’t communicate messages to another Blockchain directly, they take the help of relayers.
Let’s understand this again with the help of an example. Bk1’s message of ‘k’ to Bk2, will be sent as a data packet. The data packet will contain message ‘k’ along with the blockchain header containing the message & commitment proof as explained earlier.
This datapack will now be stored as a hash by Bk1 in its State Machine. This is now ready to be picked by Relayers and dropped to Bk2. Relayers lookout for messages they need to relay from one Blockchain to another.
This process happens off chain, and its important to make note that Relayers are not centralised but like Blockchain validators are permissionless. They are not controlled by any centralised entity, anyone can become a relayer.
Data format inside data packets defined by ICS 20 by Application Layer
The format of the sent data in data packets is defined by Application layer through Interchain Standard 20 (ICS 20) which also defines how the receiving chain should make sense of the data.
When a fungible token transfer takes place to another Blockchain using IBC, the data packet that comes to the receiving chain will contain information providing wallet address of the sender, receiver, amount and denomination (IBC denom).
IBC denom, shows the path the token has taken to reach the destination chain.
Data Packets are routed through Channels to reach destination Module
Lightclients of two communicating Blockchain are connected through connections.
Channels are the pathways, the route which data packets are directed to take between modules of two different Blockchains. Every channel end has a specific Channel ID, that’s used to precisely transfer data packets between two modules.
From mintscan
Conclusion
IBC is an interoperability solution that is as explained functions without using 3rd party bridges. This is a decentralised interoperability solution, that works on chains that are IBC compatible.
Map of Zones
Entire Cosmos Ecosystem is interoperable without bridges using IBC
Rightnow, work is on, to connect to outside Blockchains out of Cosmos like Bitcoin, Ethereum, Polkadot using IBC, so the future of of decentralised & secure interoperability in large scale can be a reality in the coming years.