Bridging vs Relaying: Saga’s Approach to Interoperability and Composability
As Drew Beaudry — crypto OG and marketing wiz for Saga — likes to say: “The whole space can be boiled down to just two things: blockchains and bridges.”
Introduction
As more users adopt Web3 technology in the coming decade, two key things will be required: abundant block space and seamless communication between blockchains. As Drew Beaudry — crypto OG and marketing wiz for Saga — likes to say: “The whole space can be boiled down to just two things: blockchains and bridges.” During the 2021 bull-market, the crypto space saw the proliferation of both. A number of alternative layer-1s like Solana, Terra, Avalanche, Fantom, Binance Smart Chain, and Harmony to name a few, added a tremendous amount of blockspace than what was previously available on the Ethereum or Bitcoin network. To address cross-chain communication between these different networks, many bridge protocols like AnySwap, Wormhole, and Layer-Zero were also developed in tandem.
While these bridging protocols have opened the door to some level of interoperability between chains, they haven’t been without their problems: over $1 billion has been lost via bridge hacks in the last year. Fragmented liquidity and poor UI have made bridging a cumbersome experience for even the most advanced crypto users. Anticipating some of these issues, the Cosmos ecosystem designed a novel approach to cross-chain messaging known as Inter Blockchain Communication, or IBC. In this post, we’ll review how traditional bridges work today and compare these bridge architectures to IBC. We will also examine how Saga will utilize IBC to unlock a host of new features like interchain security, interchain accounts, interchain queries and unlock true interoperability and composability across app-chains.
Web3 Bridge Infrastructure in 2022
Most bridge infrastructure in crypto today utilizes a middleware solution that facilitates communication with a specific set of smart contracts on two separate chains. Consider Wormhole Network, a project built by Jump Crypto. The Portal Token Bridge, a key part of Wormhole, allows for token transfers between a dozen blockchains. For example, let’s say a user wants to transfer USDC tokens from Ethereum to Solana. This user would lock USDC tokens in the Portal smart contract on Ethereum and specify a deposit address on Solana. The Portal middleware blockchain would recognize the USDC that was just locked in the Ethereum smart contract, unlock an equivalent amount of tokens from the corresponding Solana smart contract, and send a wrapped version (something like wUSDC) to the user-specified address. While the wrapped asset on the destination chain (wUSDC on Solana) is not canonically the same as the asset on the originating chain (USDC on Ethereum), the two tokens can be swapped for one another via the transactions specified above or by reversing the transactions in the opposite order.
While this kind of approach has been successful to initiate billions of dollars of cross-chain transfer, it does have a few issues. The first issue is that there is implicit trust that an end-user must have in the Wormhole infrastructure. If the smart contract on either the Ethereum side or the Solana side is hacked, wUSDC would no longer be fully collateralized by USDC on the other chain. If the validator keys of the middleware bridge are compromised, the smart contract on either chain could be drained for all of its value. In fact, both of these trust assumptions have been broken in the last year. The Wormhole smart contract on Solana was hacked in February 2022, resulting in a hacker being able to steal over $300 million in crypto assets. In March 2022, the Ronin bridge, which connects Ethereum to the Ronin side chain, was hacked to the tune of $650 million when the private keys for the majority of the validators of the bridge were compromised. The fundamental issue is that the extra set of trust assumptions that is implicit in the bridge and smart contract may be violated, creating an insecure system.
The second issue is that of fragmented liquidity. Because a wrapped asset is specifically tied to the trust of the validator set and smart contracts of a specific bridge protocol, the wrapped asset is not the same as other wrapped assets from other bridge protocols i.e. wUSDC from Wormhole is not identical to wUSDC from Anyswap. This results in many versions of wUSDC that are all unique assets. Sunny Aggregrator on Solana is a protocol that attempts to address fragmented liquidity for several versions of wrapped USDC on Solana.
Needless to say, having so many versions of wrapped USDC is not desirable and leads to a poor user experience. It’s also important to note that while popular bridge projects today have implemented protocols to initiate cross-chain transfer, most bridge protocols are confined to chain-specific messaging. There are projects, like Layer-Zero, that are attempting to build generic cross-chain messaging protocols, but there are many technical difficulties that arise from cross-chain messaging across heterogeneous chains, which are blockchains that may not necessarily need to be built on a similar tech stack. One of the advantages of a protocol like IBC is that it is specifically designed to enable trustless cross-chain messaging between heterogeneous chains.
Inter-Blockchain Communication
Extending far beyond token transfers, IBC is designed to be a generic cross-chain messaging protocol and utilizes a light-node architecture with far fewer trust assumptions than bridging protocols. Let’s examine how IBC works.
IBC has been likened to the TCP of blockchains. IBC is a specification that defines communication between blockchains that have two generic requirements. As long as a blockchain has 1) instant finality and 2) a light client implementation, it can add an IBC implementation and communicate with any other IBC-compliant blockchain. Currently, almost all IBC-enabled blockchains are Cosmos SDK-based blockchains because the Cosmos SDK automatically gives developers access to the IBC module. However, using the Cosmos SDK is not a requirement. For example, there are multiple IBC implementations being written for other blockchain protocols. Agoric is working on an implementation called Dynamic IBC (dIBC). Composable Finance is working on an IBC implementation to connect Polkadot to NEAR, two blockchains that do not utilize the Cosmos SDK. While the current implementations of IBC for token transfers are considered secure, the security of these new IBC implementations will depend on the quality of the code that is written.
Take Osmosis and the Cosmos Hub as an example. In order for there to be IBC messaging between the two chains, Osmosis token holders must vote to enable the IBC module, and ATOM tokenholders must do the same for the Cosmos Hub. If both proposals pass governance, only then can cross-chain communication occur. Since there is an agreement at a protocol level, there is no need for an external bridge with a validator set to establish trust between the two chains. After a commitment is made between two chains to communicate with each other via IBC, each chain will maintain a ‘light client’ of the other chain. The light client allows one blockchain to cryptographically verify that the other blockchain did indeed send a certain message to it. A ‘relayer’ observes messages on chain and sends those messages to the light client on the other chain for verification. The combination of the light client and relayer is sufficient to enable cross-chain messaging.
By utilizing the light-client architecture described above, there are fewer trust assumptions than there are for other bridge architectures. The validator set for one blockchain would have to collude for IBC to break in the same manner that other bridges have been hacked over the past year. IBC has enabled more than $500 million of token transfer in the past month and has suffered no hacks to date.
Axelar is a protocol built on the Cosmos SDK that utilizes IBC for cross-chain transfer across the blockchain ecosystem. Axelar also integrates bridge infrastructure that utilizes a light-client architecture to initiate transfers from non-IBC chains like Polygon, Avalanche and Binance Smart Chain. Axelar’s go-to-market is to connect non-IBC assets like ETH into IBC-connected exchanges like Osmosis or Crescent with a long-term vision to enable generic cross-chain messaging across non-IBC and IBC chains in the future. Some of this vision is complementary to the roadmap of IBC and the implementation of Interchain Accounts.
Interchain Accounts
Because IBC is designed to be a general purpose messaging protocol, it can unlock cross-chain messaging, interchain queries and a whole host of new features. One of the most exciting modules being developed right now for the Cosmos SDK is Interchain Accounts. Interchain Accounts allows for an account on one blockchain to control an account on another blockchain. The following picture gives a broad overview.
Imagine, for example, an account on the Cosmos Hub wants to make a trade on Osmosis. The instructions could be something like “Swap 10 ATOM in the ATOM/OSMO pool for OSMO”. This instruction (along with 10 ATOMs) is transported from the Cosmos Hub to Osmosis via IBC. The IBC module then internally routes the instruction to the appropriate module to handle that instruction. By utilizing the Interchain Accounts module, there does not need to be a specific implementation of IBC to process such a specific request. The nuance for utilizing IBC exclusively vs the Interchain Account module is shown below.
For IBC to be exclusively utilized for specific types of cross-chain messaging (such as a token swap), a standard implementation must first be created. Currently, such a standard exists for token transfers and other standards are being developed for other kinds of cross-chain messages. The power of Interchain Accounts is that by interacting directly with an account on another chain, it bypasses the need for a standard implementation of IBC. All that is required is that the instruction logic is compatible with the core programming logic of the IBC-compatible chain. Interchain accounts will be a critical component of the Saga ecosystem.
Bridging vs. IBC Summary
What Will Saga Utilize?
The vision for IBC is that it will enable far more than cross-chain asset transfer. Along with Interchain Accounts, it can be utilized for strong interoperability between blockchains. Saga will be utilizing IBC, Interchain Accounts and traditional bridge infrastructures. For example:
- IBC will be utilized to enable interchain security between Saga mainnet and every chainlet. This will allow chainlet developers to access their own dedicated blockspace while not having to bootstrap their own economic security.
- At the most basic level, the current implementation of IBC for cross-chain asset transfers will be enabled to allow tokens to transfer from one chainlet to another.
- IBC can be utilized to enable Interchain Accounts within the Saga ecosystem for more efficient and generic processing of cross-chain messaging. For example, gaming applications on one chainlet will be able to much more seamlessly interact directly with other gaming chainlets across a variety of assets. With an interconnected gaming ecosystem, a true metaverse may not be too far away.
- IBC can also be utilized to enable interchain queries. For example, in DeFi applications, the borrow rates on a borrow/lend chainlet can be used to inform a leveraged trade on a DEX on another chainlet.
- Traditional bridges can connect non-IBC chains to Saga. These bridges can bring in liquidity and community from other crypto ecosystems and maintain composability with our L1 partners outside of Cosmos.
Conclusion
Saga is positioned to fully utilize IBC to enable a host of features not yet seen in crypto today. IBC light-node architecture allows for trust minimized communication between Tendermint chains and, soon, between chainlets on Saga. As IBC, Interchain Accounts and traditional bridges continue to gain adoption in the next few years, there will be an explosion of cross-chain messaging that will lay the rails for the next generation of crypto adoption as web3 goes mainstream.
To learn more about Saga, follow us on Twitter or join our Discord.
Good Articles to Read
[1] https://blog.cosmos.network/eli5-what-is-ibc-a212f518715f
[3] https://ibcprotocol.org/lightClients/
[4] https://layerzero.network/pdf/LayerZero_Whitepaper_Release.pdf
[6] https://medium.com/osmosis/thoughts-on-osmosis-and-bridges-f8ca958b71e0