Making IBC work to establish interoperability with Blockchains beyond the Cosmos Ecosystem!!
Cosmos’s IBC; Inter Blockchain Communication Protocol, now is getting enhanced to establish secure connections between different Blockchain for seamless cross chain messaging and communication.
IBC has been very successful in connecting chains within the Cosmos Ecosystem, as over 50 chains within the Cosmos ecosystem communicate using IBC.
Total volume of IBC transfers per day at the time of writing this article is showcased as $10,866,000 with 58261 IBC transactions on mapofzones.
However, IBC interoperability beyond Cosmos to connect with EVM chains is experiencing difficulties because of high Gas fees and light client implementation costs.
TOKI provides a solution for IBC to work cost effectively and efficiently when connecting with other Blockchains especially Ethereum and EVM based chains.
TOKI’s improvisations on IBC establishing cost efficient interoperability with external Blockchains
TOKI would make it possible to do secure one click cross chain native swaps that get settled on the source chain instantly at low gas costs without compromising on User experience and composability.
Yes, read between the lines now and digest — native token swaps between dapps on different chains like Ethereum/ EVM chains and Cosmos SDK chains all settled at the chain the user initiated the transaction on.
Break this down it means -:
- TOKI leverages, the power of IBC messaging protocol, so this interoperability between Cosmos SDK chains and Ethereum & EVM based chains comes without use of bridges that heavily rely on external validators.
- Second, TOKI builds unified liquidity that makes it possible to conduct native token swaps between these Blockchains instead of users needing to acquire wrapped version of the tokens.
This is a big deal!!
Main Issues with Bridges, the most common way to establish interoperability between Blockchains
Read this section from TOKI’s website which explains how using bridges leads to fragmentation of liquidity and scores low on user experience, as wrapping of assets is required.
The process is cumbersome, apart from risks of exploitation as asset is deposited in a smart contract controlled by centralised external validators managing bridge operations.
After this, wrapped tokens will be issued on the destination Blockchain, this leads to fragmentation of liquidity and user needs to do swaps in another dapp platform in the destination Blockchain to acquire back native tokens. Composability is not good as well in this process.
Fragmentation of liquidity is the case as there are different wrapped versions of the token asset, and each wrapped token needs to bootstrap liquidity with native version of the token, leading to fragmentation of liquidity.
TOKI sorts this issue establishing unified liquidity for conducting native token swaps across Blockchains.
Going further, read my article which elaborates on how IBC makes it possible to establish interoperability between Blockchains here.
Understanding how native IBC works is basic.
Secure interoperability between Blockchains a reality today with Cosmos’s IBC protocol
This article will talk about TOKI’s improvisations on native IBC process to make IBC work to establish instant and cost effective interoperability of Cosmos with external Blockchains especially with Ethereum and EVM chains.
Struggles of native IBC establishing interoperability with Ethereum & EVM based chains
Now, let’s see why native IBC which works great in connecting IBC compatible Cosmos SDK chains within Cosmos Ecosystem has issues connecting with EVM based chains.
Cosmos developers have developed IBC-Solidity, for EVM based chains to have IBC- enabled solidity smart contracts. So, IBC-enabled EVM chains are a reality today with IBC-Solidity, and it’s possible for IBC transfers to happen between EVM chains and Cosmos SDK chains but they will be very costly and time-consuming.
Role of Light clients on native IBC mechanisms
Native IBC requires each Blockchain to have specially designed light client implementations that’s compatible with the counter Blockchain. These light clients work connecting to full Blockchain nodes.
So, when a Blockchain wants to relay a message to another Blockchain, the light client of the source Blockchain will collect the message committed and available on the Blockchain, to be sent to the destination Blockchain.
This message will be inside the Blockchain header, which provides summary of the Block on which the message exists. The Block header along with validity proof (that’s proves validity of the message) will go to the destination Blockchain, with that process facilitated by relayers.
The light client of the destination Blockchain that’s receives the sent data packet will verify the validity proof and evaluate the consensus state of the source Blockchain. The message is accepted by the destination Blockchain if it’s proved valid.
This is a very rough explanation of what light clients do on an IBC transaction, for proper understanding you need to read my article .
Difficulties to address establishing IBC connections with Ethereum and EVM chains!!
Still, as said every Blockchain connection requires a light client implementation that’s compatible, so a Ethereum and Cosmos connection needs a specific light client implementation that will be different than what’s required for another IBC enabled Blockchain connection say between Cosmos and Polkadot.
The cost of designing these specific light client implementations required for each connection is high.
Besides this, the light client verification process where the destination chain’s light client needs to verify the validity proof and consensus State of the source chain involves high gas costs, particularly when verifying details sent by Source chains such as Ethereum and other EVM chains.
This is because to verify consensus State of Source Blockchain, the light client needs verify the smart contracts of the Source Blockchain.
This is why IBC in its primary form is unpractical for establishing connections with Ethereum and EVM chains.
How TOKI’s version of IBC is different from native IBC!!
TOKI’s IBC works differently from Cosmos’s native IBC, as verification of proof is done by a node powered by Trusted Execution Environment (TEE), instead of light clients.
TEE is a hardware feature inside Intel SGX processors, that’s successful in powering privacy technology. This is so as TEE is a secure isolated section in a processor, from where data can’t be accessed by other components of the computer.
Cosmos’s Secret Network, that’s a privacy preserving Blockchain has built up its privacy features leveraging TEE technology.
So, on TOKI’s TEE powered version of IBC, verification process is done by a Light Client Proxy(LCP), that’s a node using TEE technology to verify proofs & other accompanying information sent by the Source chain.
LCP replaces, the need to require a specially designed light client created for that Blockchain connection that generally performs the verification process.
The LCP will have a light client implementation of the individual source Blockchain, that will verify the proof inside the enclave; the secure area inside TEE, and provide evidence of having verified the inputs by providing commitment proof generating a key inside the enclave along with a single signature.
This will be sent to the light client of the destination chain, that will only need to verify the sent proof. There is no need for the destination chain’s light client to conduct any on chain verification.
Huge reduction of costs obtained with TOKI’s TEE powered IBC
THis way, LCP saves on gas costs, as the LCP has already conducted all the verification even of the consensus State of the source Blockchain.
The commitment proof that’s generated only needs to be verified by the light client of the destination Blockchain to make sure everything is verified in a valid manner.
Plus, there is no need to design specific light clients for each Blockchain combination as only light clients of the individual Blockchain would suffice leading to low implementation costs.
Work process of TOKI’s LCP enhanced IBC explained
Now, let’s put everything together by understanding how TOKI’s TEE powered IBC works.
- The source Blockchain’s LCP light client packs up message along with proof, awaiting a relayer to take this data packet.
- A Relayer, detects this and informs LCP to verify the commitments sent.
- A implementation of the source Blockchain’s light client inside the LCP will verify the sent commitments inside the enclave and generate commitment proofs along with key .
- Destination chain’s light client for LCP will verify the commitment proofs and approve the message if its valid.
TOKI’s version of TEE powered IBC enables secure inter Blockchain transfers, as verification happens happens inside TEE, which is hard to hack.
Since, LCP only verifies the source Blockchain, not the destination Blockchain, there is no common linkages for any data leakage or exploitation to happen.
There is trust element only on TEE technology and light client scheme, so minimum trust is kept.
To understand all this clearly read these original articles explaining TOKI fully.
IBC-enabled Unified Liquidity Bridging Across Cosmos and EVMs
How TOKI and LCP Bridge Cosmos SDK Chains and Ethereum via IBC
You can read my Articles in these platforms -:
Hive — https://ecency.com/hive-150329/@mintymilecan
Steemit — https://steemit.com/hive-175254/@mintymile
Publish0x — https://www.publish0x.com/@greenchic
