6 min read · Apr 3, 2024
--
Cross-chain bridges are a critical part of facilitating the chain-agnostic future of the DeFi space. Yet, bridges introduce yet another opportunity for malicious actors to try to steal user funds. Bridges are a particularly enticing target for hackers given the massive volume of assets they process. Moreover, many bridges that exist today place significant trust in third parties to behave in certain ways, making these bridges more vulnerable to misbehavior or even attack by these counterparties.
Thus, when constructing cross-chain bridges, it is important to prioritize the minimization of trust assumptions in order to best protect users and their funds. In this article, we present an in-depth comparison of different bridging mechanisms, highlighting the different trust assumptions of each. Using this trust-based model for evaluation, it is clear that the Inter-Blockchain Communication (IBC) Protocol is a superior solution to existing bridges.
In 2020, Ethereum co-founder Vitalik Buterin set forth a system for evaluating trust models of blockchain applications. Today, with a growing number of bridges and a similarly high number of bridge hacks, evaluating trust assumptions is more important than ever in order to ensure users’ funds are optimally secured.
In this system, Vitalik defines trust as “the use of any assumptions about the behavior of other people”. He further defines trustlessness as “the ability of the application to continue operating in an expected way without needing to rely on a specific actor to behave in a specific way even when their interests might change and push them to act in some different unexpected way in the future”. In other words, trustlessness (also referred to as native verification) is the lack of any assumptions/requirements that others behave a certain way. These definitions are important to keep in mind when considering the following analysis of different bridging mechanisms.
Vitalik’s model positions zero knowledge (ZK) rollups as the standard for trustlessness, with these rollups having no liveness or safety failure risks and no reliance upon the behavior of third parties. Similarly, in their article comparing trust assumptions and security in various bridges, VanEck states that rollup-based bridges such as those between Ethereum and its Layer 2s are the most trustless solution. However, ZK rollups are limited to connecting Ethereum and its Layer 2 networks. As VanEck shows below, the Inter-Blockchain Communication (IBC) Protocol has similar trust assumptions to rollup-based bridges:
We further break down the trust assumptions of these different bridges below:
Definition: Centralized bridges mirror traditional finance systems, and lack the decentralization of most blockchain systems and applications. In these bridges, one entity (typically the exchange/bridge itself) remains in full control over bridge operations.
Examples: Centralized stablecoin issuers like Tether, asset management platforms with bridges like BitGo, private blockchain connectors like Hyperledger Fabric (used by IBM), and bank-operated blockchain bridges like J.P. Morgan’s Link
Trust Assumptions: Trust remains entirely in the hand of one actor, who must behave as expected or the entire functionality of the bridge is jeopardized.
Verdict: This is the worst case scenario in bridging, with trust assumptions being at a maximum and decentralization being at a minimum.
Definition: This is a broad category of bridges wherein a number of different actors have various trust assumptions placed upon them that are critical to the bridge’s operations. Many of these bridges such as Axelar rely upon standard proof-of-stake (PoS) validation.
Examples: LayerZero, Multichain, Wormhole, Axelar, Synapse
Trust Assumptions: Generally, the simple majority of actors (specifically validators, for PoS blockchains) must behave as expected. These actors are incentivized to behave in this manner, meaning they must simply be rational actors and not altruistic actors, increasing their chances of behaving as expected. This trust model is the norm for many blockchain applications and PoS validation.
Verdict: Permissioned bridges have a similar level of trust assumptions to many other blockchain applications. However, a trust model requiring a simple majority of actors to behave as expected remains vulnerable to 51% attacks and is therefore still not an ideal trust level. A number of new innovations in bridging (as shown in the other categories below) present a much more secure trust model.
Definition: Both Optimistic and ZK bridges take their design from rollups of the same name. Rollups in general are a hybrid layer 2 solution that move a significant amount of computation and storage off-chain, while keeping some data per transaction on-chain. Optimistic bridges in particular use fraud proofs, which can be published by anyone who discovers an incorrect state root on a batch. These proofs revert that batch and all subsequent batches.
Examples: Pheasant Network, Optimism Bridge
Trust Assumptions: Liveness requires either one centralized party or the simple majority of a few actors to behave as expected. Safety requires the simple majority of a large number of actors to behave as expected.
Verdict: The trust assumptions in optimistic bridges are not significantly better than those in permissioned bridges; in fact, liveness trust assumptions are often higher in optimistic bridges.
Definition: In contrast to optimistic bridges, zero knowledge (ZK) bridges use validity proofs; every batch has a proof that the state root is correct, which can be quickly verified on-chain.
Examples: zkBridge, ZetaChain, LI.FI
Trust Assumptions: Liveness requires the simple majority of a few actors to behave as expected. Safety does not require any actors to behave as expected.
Verdict: ZK bridges offer significantly lower trust assumptions than permissioned and optimistic bridges, particularly for bridge safety, which is a trustless model.
Definition: The Inter-Blockchain Communication (IBC) Protocol is a protocol for communication between different blockchain ecosystems. More details on how the IBC works is available here. To summarize, IBC has three key features:
- Native Protocol Security: Light Client verification on both sending and receiving chains ensures that all IBC transactions are secured by the consensus of each of the two chains.
- Censorship Resistance: There are no centralized entities that can censor transactions. If one relayer decides to not send the packet, there will be other relayers.
- Permissionlessness: The decision to connect or not sits at the individual blockchain level and is not governed by any centralized entity.
Examples: Picasso
Trust Assumptions: IBC trusts only the consensus of transferring and receiving chains. It relies upon light clients to facilitate communication between connected chains. Light clients are lightweight representations of one blockchain that live in the state machine of another blockchain. Specifically, light clients keep track of a blockchain’s consensus algorithm by verifying block headers and Merkle proofs.
Verdict: In terms of trust assumptions, IBC-based bridging is superior to centralized, permissioned, and optimistic bridges. It is comparable to ZK bridges, which are a trustless mechanism for bridging but are not suitable for connecting all chains.
As we have presented, the IBC Protocol is emerging as the gold standard for cross-chain communication. Its trust levels parallel that of ZK bridging, which is limited to the Ethereum ecosystem and its layer 2s. Originally, the IBC Protocol was also limited to one ecosystem: the Interchain, which includes Cosmos SDK chains and the Cosmos Hub. However, IBC has now been expanded outside of the Interchain/Cosmos ecosystem for the first time by Composable’s Picasso Network.
Now, via the Picasso Network, Ethereum, Cosmos appchains, and Polkadot and Kusama parachains are connected along IBC. Moreover, for its Ethereum IBC connection, Picasso combines zero knowledge mechanisms with its IBC-based bridge, merging the benefits of these two trustless bridging techniques.
Ultimately, the goal is to use the IBC to connect all major blockchain ecosystems, uniting the DeFi space in a manner that best serves and protects users.
