Ecosystem

An Analysis of Interoperability Protocols

There are three different types of interoperability protocols. Let’s have a closer look at each type in the following.

Classification

Of Interoperability Systems

The existing interoperability protocols can be classified within three overarching types based on who verifies transactions. In the following, we will explain each type and have a closer look of the advantages and disadvantages of each system.

Natively Verified Protocols

With the Chain’s Own Validator’s

In a natively verified protocol, the chain’s own validators verify transactions. This means that the underlying chain’s verifiers are responsible for fully validating all data passing between chains. In practice, this is typically achieved by running a light client of a given chain within the VM environment of another chain and vice versa.

Examples for natively verified protocols are Near RainbowBridge and Cosmos IBC. A special form of this are rollup entries and exits.

Let’s have a look at the advantages such protocols provide but also their inherent disadvantages.

Advantages

  • This form of interoperability is the most trustless one as the chain’s underlying verifiers are directly responsible for verifying bridging transactions.
  • Fully generalized message passing between different domains is enabled.

Disadvantages

  • Natively verified protocols rely on the underlying consensus mechanism and/or trust of the domain to function securely. As a result, the bridge must be custom built for each type of domain, which complicates adoption.
  • Not decentralized

Key takeaway

Ethereum has established the framework for the establishment of a highly heterogenous ecosystem. Its domains range from base chains to zk/optimistic rollups. Consequently, each of these domains require unique strategies to implement a natively verified interoperability protocol. This introduces great barriers towards the adoption of such systems.

Externally Verified Protocols

Via Third Party Validators

In an externally verified protocol, third party validators verify transactions. Such protocols use an external set of verifiers to relay data and transactions between chains. Typically, these systems are introduced as MPC systems, threshold multisigs, or oracle networks.

Examples for externally verified protocolsinclude Thorchain, Biconomy, PolyNetwork, and many more.

What are the advantages of such protocols and their limitations?

Advantages

  • Fully generalized messages can be passed between domain
  • Seamless extension to any domain within the Ethereum ecosystem

Disadvantages

  • The external verifiers are fully in control of user’s funds and data. Users and LPs that use such protocols therefore need to fully trust the external verifiers with their funds/data.
  • Fundamentally less cryptoeconomically secure mechanism

Key takeaway

Externally verified protocols can only offer full, trustless interoperability when verifiers themselves offer the users of such protocol insurance up to the maximum amount that can be stolen. Consequently, this increases the capital requirement for validators, prevents transfers of high value, and defeats the purpose of liquidity pools.

Locally Verified Protocols

Via Verification Through Counterparties

The last iteration are locally verified protocols in which counterparties verify each other. As such, only the parties that are involved in a given cross-domain interaction verify the transaction. Adopting such a system simplifies a complex problem (n-party verification) into a simpler solution (2-party interactions in which each party verifies only the counterparty). As long as both involved parties are economically adversarial, the system works. However, if there’s an incentive for both parties to collude, funds can be stolen from the broader chain.

Examples for locally verified protocols include Connext, Celer, Hop, and other simple atomic swap protocols.

What advantages do such protocols provide and what are their disadvantages?

Advantages

  • Fully trustless interoperability (unless tradeoffs are added into the system). The underlying chain backs the protocol’s security – assuming that reasonable guarantees are shared by rollups (e.g. censorship of the chain is not possible for more than a predefined period of days).
  • Locally verified protocols can be easily extended to other domains

Disadvantages

  • Generalized data passing between chains is not supported

Key takeaway

Cross-domain contract calls can be enabled for a locally verified system. However, this is only possible if the called function has an owner. For example, a Uniswap swap function across chains can be called by any user who has swappable tokens. At the same time, it is not possible to mint and lock a given NFT across chains. This is because a logically verified system is not able to represent the owner of the mint function on one chain and the lock contract on the source chain.

Summary

While natively verified protocols are the most trustless, a high level of trust in the underlying domain needs to be established to function securely. Externally verified protocols introduce the challenge that external validators can collude to steal user funds. Lastly, locally verified protocols are not able to pass generalized data between chains but are fully trustless and can be easily extended to other domains.

Ecosystem

Solving the Interoperability Trilemma