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

Изображение

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.


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

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.

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.


Конструктор сайтов от 
Т-Банк