A few days back, we shipped NXTP,ย our protocol for enabling fully trustless transfers and contract calls between Ethereum-compatible domainsย (chains & L2s).
This blog post will attempt to explain why interoperability in the Ethereum ecosystem is difficult, and from there show why we think NXTP represents the beginning of a true long-term solution for the ecosystem.
The Need for Trustless Ethereum Interoperability
Multichain/L2 Ethereum is here, and itโs here to stay. Protocols and applications have all shifted their strategy towards migrating to multiple domains. Their users are now having to contend with the challenges of moving between layers or to other L1 systems/sidechains every day. This has spurred the creation ofย dozensย of new bridges and interoperability protocols as projects have scrambled to enable this functionality for DeFi.
As can be expected, this has also brought on a number of high profile hacks and scams:
Theย PolyNetwork hack.
Despite these examples, every bridging system out there markets itself asย trustless,ย secure, andย decentralizedย (even if thatโs not at all the case). This means big challenge for developers and users is now, โhow can I figure out which bridging mechanisms are actually cryptoeconomically secure?โ
In other words, how can users discern between types of bridges to determine who they are trusting when moving funds between chains?
What Does โTrustlessโ Actually Mean in Cryptoeconomics?
In the research community, when we talk about cryptoeconomic security and the property of trustlessness, we are really asking one very specific question:
Who is verifying the system and how much does it cost to corruptย them?
If our goal is to build truly decentralized, uncensorable public goods, then we have to consider that our systems could be attacked by incredibly powerful adversaries like rogue sovereign nations, megacorporations, or megalomaniacal evil geniuses.
Maximizing security means maximizing the number and diversity of verifiers (validators, miners, etc.) in your system, and this typically means trying your best to have a system that is verified entirely by Ethereumโs validator set. This is the core idea behind L2 and Ethereumโs approach to scalability.
Aside: Most people donโt realize this, but scalability researchย isย interoperability research. Weโve known we can scale by moving to multiple domains for ages, the problem has always been how to enable communicating to those domains trustlessly. Thatโs why John Adlerโsย seminal paper on optimistic rollupsis titled, โTrustless Two-Way Bridges With Sidechains By Haltingโ.
What Happens If We Add New Verifiers Betweenย Domains?
Letโs take what weโve learned above about cryptoeconomic security and apply it to bridges.
Consider a scenario where you have your funds on Arbitrum. Youโve specifically chosen to use this domain because it is a rollup, meaning that (with some reasonable assumptions) your funds are fully secured by Ethereumโs underlying verifiers. In other words, your funds are about as cryptoeconomically secure as they can possibly be in the blockchain ecosystem.
Now imagine that you decide to use a bridge to move your funds cheaply and quickly to Optimism. Optimism is also trustless, so you feel comfortable having your funds there knowing that they will share the same level of security (Ethereumโs security) that they do on Arbitrum.
However, the bridge protocol that you use utilizes itโs own set of external verifiers. While this may not initially seem like a big deal, your funds are nowย no longer secured by Ethereum, but instead by the verifiers of the bridge:
If this is a lock/mint bridge, creating wrapped assets, then the bridge verifiers can now unilaterally collude to steal all of your funds.
If this is a bridge that uses liquidity pools, the bridge verifiers can similarly collude to steal all of the pool capital from LPs.
Despite having waited years for secure, trustless L2s, your situation is now the same as if you had used a trusted sidechain or L1 construction. ๐ฑ
The key takeaway is that cryptoeconomic systems are only as secure as their weakest link. When you use insecure bridges, it doesnโt matter how secure your chain or L2 is anymore. And, similar to the security of L1s and L2s, it all comes entirely down to one question:ย who is verifying the system?
A Taxonomy of Interoperability Protocols
We can break down all interoperability protocols into three overarching types based on who verifies them:
Natively Verified
Natively verified protocols are ones where all of the underlying chainsโย ownย verifiers are fully validating data passing between chains. Typically this is done by running a light client of one chain in the VM of another chain and vice versa.
Examples include Cosmos IBC, and Near RainbowBridge. Rollup entry/exits are a special form of this as well!
Advantages:
Most trustless form of interoperability because the underlying verifiers are directly responsible for bridging.
Enables fully generalized message passing between domains.
Disadvantages:
Relies on the underlying trust and/or consensus mechanisms of the domain to function, so it must beย custom builtfor each type of domain.
The Ethereum ecosystem isย highlyย heterogenous: we have domains that are everything from zk/optimistic rollups to sidechains to base chains which run a large variety of consensus algorithms: ETH-PoW, Nakamoto-PoW, Tendermint-PoS, Snowball-PoS, PoA, and many others. Each of these domains requires a unique strategy for implementing a natively verified interoperability system.
Externally Verified
Externally verified protocols are ones where an external set of verifiers is used to relay data between chains. This is typically represented as a MPC system, oracle network, or threshold multisig (all of these are effectively the same thing).
Examples include Thorchain, Anyswap, Biconomy, Synapse, PolyNetwork, EvoDeFi, and many many many others.
Advantages:
Allows for fully generalized message passing between domains.
Can easily be extended to any domain in the Ethereum ecosystem.
Disadvantages:
Users and/or LPs fully trust the external verifiers with their funds/data. This means the model is fundamentally less cryptoeconomically secure than the underlying domains (similar to our Arbitrum to Optimism example above).
In some cases, projects will use additional staking or bonding mechanisms to try to add security for users. However, this typically does not make a lot of economic sense. In order for the system to be trustless, users have to be insured up to the maximum ruggable amount, and that insuranceย mustย come from the verifiers themselves. This not onlyย significantlyย increases the capital required in the system, but also defeats the whole purpose of having minted assets or liquidity pools in the first place.
Locally Verified
Locally verified protocols are ones where only the parties involved in a given cross-domain interaction verify the interaction. Locally verified protocols turn the complex n-party verification problem into a much simpler set of 2-party interactions where each party verifies only their counterparty. This model works so long as both parties are economically adversarialโโโi.e. thereโs no way for both parties to collude to take funds from the broader chain.
Examples include Connext, Hop, Celer, and other simple atomic swap systems.
Advantages:
Locally verified systems are trustlessโโโtheir security is backed by the underlying chain given some reasonable guarantees shared by rollups (e.g. the chain cannot be censored for more than X days).
They are also very easy to extend to other domains.
Note: notย everyย locally verified system is trustless. Some take trust tradeoffs to improve UX or add extra functionality.
For example, Hop adds some trust assumptions through their need for a fast arbitrary-messaging-bridge (AMB) in their system: the protocol unlocks bonder liquidity in 1 day rather than waiting a full 7 days when exiting rollups. The protocol also needs to rely on an externally verified bridge if no AMB exists for a given domain.
Disadvantages:
Locally verified systems cannot support generalized data passing between chains.
What the above means is a bit nuanced and comes down to permissioning: itย isย possible for a locally verified system to enable cross-domain contract calls but only if the function being called has some form of logical owner. For example, it is possible to trustlessly call a Uniswap swap function across chains because the swap function can be called by anyone who has swappable tokens. However, it is not possible to trustlessly lock-and-mint an NFT across chainsโโโthis is because the logical owner of theย mint
ย function on the destination chain should be theย lock
ย contract on the source chain, and this is not possible to represent in a locally verified system.
The Interoperability Trilemma
Now we get to the thesis of this article, and the mental model that should drive user and developer decisions around bridge selection.
Similar toย the Scalability Trilemma, there exists anย Interoperability Trilemmaย in the Ethereum ecosystem. Interop protocols can only have two of the following three properties:
Trustlessness: having equivalent security to the underlying domains.
Extensibility:ย able to be supported on any domain.
Generalizeability:ย capable of handling arbitrary cross-domain data.
How Do Connext and NXTP Fit Intoย This?
Thereโs no easy way for us to get all three desireable interoperability properties. Weโve realized, however, that we can take the same approach to solving the Interoperability Trilemma that Ethereum does to solving the Scalability Trilemma.
Ethereum L1 optimizes for security and decentralization at the cost of scalability. The rationale behind this is that these properties are likely the most important for the longevity and utility of a blockchain. Ethereum then adds scalability via L2/sharding as a layer on top of an existing secure and decentralized backbone.
At Connext, we strongly believe that the interoperability system with the most longevity, utility, and adoptability in the Ethereum ecosystem will be one that is maximally trustless and extensible. For this reason, NXTP is a locally verified system specifically designed to beย as secure as the underlying domainsย while still beingย usable on any domain.
So what about generalizeability? Similar to scalability in the Ethereum ecosystem, we can add generalizeability by plugging in natively verified protocolsย on topย of NXTP (as a โLayer 2โ of our interop network!). That way, users and developers get a consistent interface across any domain, and can โupgradeโ their connection to be generalized in cases where that functionality is available.
This is why we say NXTP is theย base protocolย of our interoperability network. The full network will be made of up of aย stackย of protocols which will include NXTP, generalized crosschain bridges specific to a pair of domains, and protocols to connect them all together into one seamless system. ๐
Huge thanks to James Prestwich, Eli Krenzke, Dmitriy Berenzon, and in general the broader L2 research community for the many conversations that contributed to the ideas in this post over the past couple of years, as well as for proofreading my silly typos.ย
๐Want to Get Involved? Try out Connext atย https://xpollinate.io!
Weโre hiring! Check outย our job postingsย if youโre interested in joining the core team.Join our discord chatโโโwe have a super active community that would love to meet you!
If you want to use Connext as part of your project,ย check out our docsย and/or reach out to us on our discord above.
Connext is fully open source, so community members are always welcome and encouraged to contribute to the protocol!