The Future of Cross Chain Communication, Ft. MAP Protocol, Cosmos IBC, and Antelope IBC
If you wish to support articles like these, please consider donating to my pomelo grant ❤: https://pomelo.io/grants/articles
A Look At Cross Chain Bridging
Cross chain communication has proven itself to be a very tricky problem to solve, with billions in hacks and exploits just in 2022 alone. With all this loss of funds there begs the question as to whether or not the technology will ever be safe enough to support this functionality?
Reversibility
This question has led to a group of Stanford students and others to propose the idea of centralizing the blockchain through enabling “reversible transactions” in the paper “ERC-20R and ERC-721R: Reversible Transactions on Ethereum”, just to prevent these kind of hacks and others from happening.
Antelope’s Recover+
Other chains like Antelope (formerly EOSIO) have enabled a system called Recover+ where projects can register with the block producers in order to allow them to take quick and decisive action if a contract acts in an unintended manor. This is a big potential plus for large capital entering the space. These entities could experience better insurance against loss of funds versus other chains.
The Centrality of BSC
When the BSC hack occurred, the validators were quick to freeze accounts taking what would have been more than a half billion dollar hack down to about $100m.
The decisive actions of chains like BSC and EOS could prove to be large value adds for large capital while the technology continues to mature.
Insurmountable Problems or Early Days?
In my opinion this is very new technology where much of it is still in beta and this is simply the price of adoption far outpacing the education of best practices and experienced / cheaper auditing services and products. The idea of giving up decentralization just because some funds were lost to me seems like giving up the core value add of blockchain technology for little to no tangible gain in the long run.
And if you tally up the amount of funds lost on CEX’s, it dwarfs the amount lost in DeFi by at least one order of magnitude. According to DeFi Llama the total hacks (not just bridge hacks but all hacks) amounts to around $6b. Celsius or FTX alone would cover that by a multiple. So it seems there are other problems that should be solved first as the majority of DeFi has worked properly and as expected.
How Trustless Bridges Have Done
I would argue that if you look at the trustless bridges, they’re doing much better. For example the NEAR <> ETH Rainbow bridge has never been hacked and its optimistic 4 hour window fraud proof has caught a few hackers trying to steal user funds.
Also you have Cosmos’s IBC which I’m unaware of having any issues, despite the Tendermint merkle proof verification BSC exploit that led to $110m in lost funds on Binance Smart Chain, but again that was BSC and not on Cosmos.
There is also Antelope (formerly EOSIO) IBC which is well on its way to completion with a proof of concept already on testnet, you can find out more by joining the Telegram here.
Benefits of Trustless Bridges
Trustless bridges have a few key benefits and advantages.
For starters they move the needle from a centralized solution where transactions can be censored or keys can be hacked to where the validators or contract owners would need to censor.
Second they remove the middle man leaning out the process as much as possible by not up charging users as much for transfers.
I do see a possibility where you use Intel SGX instead of a chain itself to approve fund transfers between chains, but for now I am more of a fan of putting a blockchain in the middle as SGX has many problems.
It’s worth re-emphasizing how big of a deal it is to not have a centralized entity ultimately controlling the fate of bridges. History has shown that if enough value is exploited, major actors will step in to save their own skins rather than watching as their company or protocol collapses in on itself.
Issues With Trustless Bridges
Until the MAP Protocol emerged, there was no universal layer where all chains could cross communicate with one another. This has a lot to do with how the Ethereum Virtual Machine works along with its block hashing method.
In order to run a trustless bridge between two EVM chains, it requires passing each and every block between chains to prove that a transaction was inlcuded in that block. This is very expensive to do and thus far has prohibited any such solutions from gaining mass adoption.
NEAR’s Rainbow Bridge gets around this because the process of proving all blocks on the ETH side happens on NEAR’s side where transactions are much cheaper.
Then when transactions are sent to ETH from NEAR, there is a contract that allows someone who spots fraud to spend the very expensive fee of calling out the fraud, proving it on chain, and receiving a reward which has proven to be a viable and effective method as it is very cheap to run such a server just to detect and act on this.
NEAR would not require this optimistic approach if eip-665 passed enabling Ed25519 signature verification as a pre-compile.
Some Existing IBC Solutions
I’ve already discussed Rainbow, but there’s also Polkadot’s solution as well as Cosmos and Antelope. I haven’t read much into Polkadot, so I I’m not going to discuss it hear, but Cosmos’s IBC is the bomb digity and Antelope’s is in testnet so let’s lets check that out.
Cosmos IBC
Cosmos has its own IBC solution, if you’re interested in learning more, see here.
The solution has very fast finality, it works between separate chains, and it’s very cheap to do. And most importantly no one needs to be asked for permission to utilize it.
(video on IBC from Billy Rennekamp, Product Lead for Cosmos Hub)
IBC Routing
Cosmos also released an idea for a cross chain communication relay market in their Atom 2.0 whitepaper which has now failed to pass voting.
IBC Routing: A market for IBC relay contracts and multi-hop connections, aggregating relay providers to create a simple, cost-effective, and
reliable IBC connectivity subscription for a wide coverage area
Antelope IBC
More details on Antelope’s IBC can be found in this working document.
Basically there are 2 kinds of proofs, heavy and light proofs.
When a valid heavy proof is submitted, the merkle root of that block is saved to the contract state, and it becomes possible to prove actions that occurred prior to that block using the light proof scheme.
Cosmos IBC is also looking to integrate antelope IBC.
Enter MAP Protocol
I stumbled across MAP Protocol recently and a light went on in my head. Of course this is the solution to solving cross chain trust minimized IBC, just put a chain in the middle of all of it and create light client validators for each chain type.
MAP protocol is backed by IEEE Blockchain and Certik. If you don’t know who IEEE is, they’re responsible for setting the standards you’re using right now for bluetooth and wifi.
This is a very elegant and interesting solution that scales horizontally as well. There are vault contracts on each supported chain and these contracts can support routing between multiple MAP Relay chains.
If you couple this with the SUAVE mempool / block builder chain coming out from flashbots (link to my article here) then you have an elegant solution where large liquidity can move between chains in a MEV minimized way. The team has not expressed an interest in doing so as of writing this article.
This is a slide from their lightpaper comparing to different solutions
Other Potential Architecture to Achieve Same Outcome
The only other way I currently see to be able to run trustless bridges would be with Intel SGX validating the transactions. But I still think there are issues with that approach as Avalanche’s bridge relies on the integrity of the Wardens sending them transactions to which the secure enclave signs. So you’re basically creating a multi party trusted setup which is what a blockchain is the best at solving by making that relationship trust minimized.
Criticisms of MAP Protocol
The MAP protocol is setup to be a general purpose chain in addition to performing the core bridging functionality. I think this is a mistake because this will cause unnecessary congestion of block space. This also creates confusion as the relay chains scale up as to which relay chain a particular DAPP is operating on.
Though on the flip side as a team that has taken no VC money, increasing the utility of the token seems like a wise move. Also the system is designed to scale horizontally. As blockspace becomes more expensive, a new chain can be spun up to alleviate that demand-driven pressure.
Conclusion
Cross chain bridging is a hard problem to solve, but I believe that the future of cross chain communication will be trust minimized and ideally we will see multi chain compatible solutions emerge such as the MAP Protocol, Cosmos and Antelope’s IBC.
