What are the different underlying logics of cross-chain and cross-L2 bridges? What are the pros and cons?
Written by: Arjun Bhuptani, Co-founder of Connext Compiler: Perry Wang
A few days ago, Connext launched NXTP , the underlying protocol used to implement completely trustless transmission and contract calls between Ethereum-compatible domains, that is, link different blockchains and second-level/L2 projects.
I hope to use this article to explain why it is so difficult to achieve interoperability in the Ethereum ecosystem, and why we believe that NXTP represents the beginning of a true long-term solution for the ecosystem.
The need for trustless interoperability
Multi-chain/L2 Ethereum has become a reality and will continue to exist. Both the agreement and the application have changed the development strategy to migrate to multiple domains, and users now have to deal with the difficulty of moving between layers or moving to other L1 systems/side chains every day. Various projects are scrambling to enable this migration feature for DeFi, spawning dozens of new “bridges” and interoperability agreements.
Unsurprisingly, this has also led to some high-profile hacking and scams:
• The cross-chain transaction protocol THORChain was attacked ;
• PolyNetwork was hacked ;
• Pure scam .
Despite these examples, every “bridge” system advertises itself as trustless, secure, and decentralized-even if it is not. This means that the huge challenge facing developers and users now is: “How do I determine which bridge mechanisms are truly secure in the cryptographic economy”?
In other words, when transferring funds between chains, how do users distinguish the type of “bridge” to determine whom to trust?
What does “no trust” mean in cryptoeconomics?
In the research community, when we talk about the security and trustless properties of the encryption economy, we are actually asking a very specific question: who is verifying the systems and what is the cost of breaking them?
If our goal is to build a truly decentralized, uncensorable public product, we must consider: Our system may be attacked by very powerful opponents, such as sovereign states, large corporations, or arrogant evil geniuses .
If your threat model does not include the assumption that (Amazon founder) Bezos will eventually turn to the evil side, you will not succeed.
Maximizing security means maximizing the number and diversity of validators (validators, miners, etc.) in the system. This usually means doing your best to have a system that is fully verified by the Ethereum validator set—— This is the core idea behind the scalability of L2 and Ethereum.
Narrator: Most people don’t realize this, but scalability research is interoperability research. We have been clear for many years that we can expand by moving to multiple domains. The question has always been: how to achieve trustless communication between these domains. This is why the title of John Adler’s seminal paper on optimistic rollups is “Trustless Two-Way Bridges With Sidechains By Halting”.
What happens if we add new validators between domains?
We apply the knowledge about the economic security of encryption that we learned above to the “Bridge”.
Consider a scenario: Assuming you have funds on Arbitrum, you specifically choose to use this domain because it is a rollup, which means (under some reasonable assumptions) your funds are fully protected by the underlying validators of Ethereum. In other words, your funds may be as safe in the crypto economy as in the blockchain ecosystem.
Now imagine that you decide to use the “bridge” to transfer your funds to Optimism cheaply and quickly. Optimism is also trustless, so you can rest assured to put your funds there, knowing that they will share the same level of security as Arbitrum (the security of Ethereum).
However, the “bridge” protocol you are using uses its own set of external validators. Although this may not seem like a big deal at first, your funds are no longer secured by Ethereum, but by the “bridge” validator:
• If this is an asset locking/minting “bridge”, creating a packaged asset means that the “bridge” validator can now unilaterally collude to steal all your funds;
• If this is a “bridge” that uses a liquidity pool, the “bridge” validator can collude in a similar way to steal all pool funds from the liquidity provider (LP).
Although everyone has been waiting for a safe, trustless L2 for several years, your current situation is the same as when you use a trusted sidechain or a trusted L1 architecture.
The key point is that the security of an encrypted economic system depends on its weakest link. When you use an insecure “bridge”, the security of your chain or L2 is meaningless. Moreover, similar to the security of L1 and L2, it all boils down to one question: Who verifies the system?
Interoperability protocol classification
We can divide all interoperability protocols into three types according to the type of verifier:
The first type: native verification
The native verification protocol is a protocol that is completely verified by the verifier of the underlying chain for the data passed between the chains. This is usually done by running a light client of one chain in the Ethereum Virtual Machine (VM) of another chain, and vice versa.
Examples include Cosmos IBC and NEAR RainbowBridge. Rollup entrance/exit is also a special form!
Advantage:
• No need to trust the highest degree of interoperability, because the underlying verifier is directly responsible for the security of the “bridge”;
• Achieve completely universal messaging between domains.
Disadvantages:
• Rely on the underlying trust and/or consensus mechanism of the domain to operate, so it must be customized for each type of domain.
The Ethereum ecosystem is highly heterogeneous: we have many domains, from zk/optimistic rollups to side chains, to the basic chain running various consensus algorithms: ETH-PoW, Nakamoto-PoW, Tendermint-PoS, Snowball-PoS , PoA, there are many consensus mechanisms. Each of these domains requires a unique strategy to implement a natively verified interoperability system.
The second type: external verification
The external verification protocol is a protocol that uses a set of external validators to relay data between chains. This usually manifests itself as a secure multi-party computing (MPC) system, oracle network, or threshold signature (all of which are actually the same thing).
Examples include THORChain, Anyswap, Biconomy, Synapse, PolyNetwork, EvoDeFi, and many other projects.
Advantage:
• Allow completely universal messaging between domains;
• Can be easily extended to any domain in the Ethereum ecosystem.
Disadvantages:
• The user and/or LP fully trust the funds/data of the external validator. This means that the security of the model in terms of encryption economy is basically lower than the level of the underlying domain (similar to the comparison between Arbitrum and Optimism mentioned above).
In some cases, the project will use additional staking or bonding mechanisms to try to increase security for users. But this is usually economically inefficient. In order to make the system trustless, users must cover the highest possible loss with mortgage assets, and these mortgage assets must be provided by the verifier. This not only significantly increases the capital required by the system, but firstly goes against the entire original intention of casting assets or liquidity pools.
The third type: local authentication
The local verification protocol is a protocol in which only parties participating in a specific cross-domain interaction verify the mutual information. The local verification protocol turns the complex n-party verification problem into a much simpler set of two-party interactions, where each party only verifies its counterparty. As long as the two parties are antagonistic in their economic interests, this model is effective—that is, the two parties cannot collude to obtain funds from the entire chain.
Examples include Connext, Hop, Celer, and other simple atomic exchange systems.
Advantage:
• Locally verified systems are trustless-their security is supported by the underlying chain, because rollups share some reasonable guarantees (for example, the review time of the chain cannot exceed X days);
• They are also easy to extend to other domains.
Note: Not every locally verified system is trustless. Some projects take a certain degree of sacrifice without trust to improve the user experience or add additional features.
For example, Hop added some trust assumptions by requiring a fast arbitrary-messaging-bridge (AMB) in the system: the protocol unlocks Bonder’s liquidity within 1 day, instead of waiting a full 7 days when exiting the rollup. If there is no AMB in a given domain, the protocol also needs to rely on an externally verified “bridge”.
Disadvantages:
Locally verified systems cannot support generalized data passing between chains.
The above meaning is a bit subtle, and it may boil down to permission: a locally verified system can implement cross-domain contract calls, but the premise is that the called function has some form of logical owner. For example, the Uniswap token swap function can be called cross-chain without trust, because anyone with exchangeable tokens can call this function. However, this method cannot lock and mint NFTs across chains without trust-this is because the logical owner of the mint function on the target chain should be the lock contract on the source chain, and this is done in the local verification system. Can’t be reflected.
Interoperability dilemma
Now we enter the topic of this article and the mental model that should push users and developers to make decisions around the choice of “bridge”.
Similar to the impossible triangle of scalability, there is also an impossible triangle of interoperability in the Ethereum ecosystem. Interoperability protocols can only have two of the following three characteristics:
• No need to trust: have the same security as the underlying domain;
• Scalability: Any domain can support;
• Information versatility: able to handle arbitrary cross-domain data.
How do Connext and NXTP fit this point?
We cannot find a simple way to achieve the desired result of all three interoperability properties. However, we have realized that we can use the same method as Ethereum to solve the impossible triangle problem of scalability to solve the impossible triangle problem of interoperability.
Ethereum L1 optimizes security and decentralization at the cost of scalability. The rationale behind this is that these attributes may be the most important to the longevity and usefulness of the blockchain. However, Ethereum uses L2/sharding as a layer on top of the existing security and decentralized backbone to enhance scalability.
At Connext, we firmly believe that in the Ethereum ecosystem, an interoperable system with the longest lifespan, strongest usability and adoptability will be a system that is trustless and scalable to the utmost. For this reason, NXTP is designed as a locally verified system, specifically designed to be as secure as the underlying domain and can be used on any domain at the same time.
What about the versatility of information? Similar to the scalability solution in the Ethereum ecosystem, we increase the versatility of information by inserting a natively verified protocol (as the L2 of our interoperable network!) on top of NXTP. In this way, users and developers can get a consistent interactive interface in any domain, and can “upgrade” their connection to realize the generalization of information when the function is available.
This is why we say that NXTP is the underlying protocol of our interoperability network. Our entire network will consist of a series of protocols, including NXTP, a generic cross-chain bridge specific to a pair of domains, and a protocol to connect them into a seamless system.
Many thanks to James Prestwich, Eli Krenzke, Dmitriy Berenzon, and the broader L2 research community for conversations over the past few years, which helped spawn many of the ideas in this article and proofread my stupid typos.
Source link: medium.com
