Summary of Proposal
This proposal is by the Celer Network team. Quick introduction to Celer. Celer is a blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, privacy solutions and more across multiple chains. cBridge is a decentralized and non-custodial asset bridge that supports more than 40 different tokens across 21 different blockchains and layer-2 rollups. Built with the Celer Inter-chain Message Framework, cBridge has processed more than $4.6 b cross-chain asset transfers volume with $460M TVL on 26 different blockchains for more than 110K unique users and is quickly growing. cBridge like Terra, is built on Cosmos SDK and supports two security models at the same time: Cosmos consensus based security model and an optimistic rollup like security model. We would love to support UST bridging to multiple chains that we support and that would be straightforward with our Terra support coming soon.
However, this proposal is not even about us. In this proposal, we argue that it is dangerous for Terra community to be locked-in to a single bridge for UST bridging needs to any chain and it is possible to have multiple bridges serving Terra UST bridging at the same time without liquidity fragmentation. What’s more important is that this multi-bridge architecture actually provides much higher security for the entire Terra ecosystem compared to just using a single bridge as well! We propose that Terra can do a simple mitigation to leave the door open for a better future of multi-bridge UST without delaying the current planned chain extension.
With this proposed multi-bridge architecture tragedy like the Wormhole $300M+ hack would have never happened in the first place.
In the following, we will first discuss why it is harmful for Terra ecosystem to choose a single bridge and fall into the vendor lock-in trap. Then we will discuss how we can solve the key challenges of liquidity segregation and security issues in a multi-bridge system. Finally, we provide a solution without causing any delay for the current planed UST bridging launch but leave the door open for the future.
Vendor Lock-in is Extremely Dangerous
If you have read this previous post and understand vendor lock-in risks, please feel free to skip this whole section.
When thinking about UST bridging to chains where there is no official canonical token bridge built by Terra, third-party canonical token bridges can serve the purpose. To understand a bit of the history behind canonical token bridges and how they work, please refer to this blog.
There are many different bridging solutions out there. So which one to choose?
Well, that is not actually the right question to ask. Because if Terra chooses only a single bridge for UST bridging to any single chain, it faces the significant vendor lock-in risk.
Vendor lock-in, in terms of these third-party canonical token bridges, occurs when it becomes extremely difficult if not practically impossible to switch from a specific third-party canonical token bridging service to a different one for a blockchain. Effectively “locking” or taking away the choice from the entire Terra community. Unfortunately, many blockchain ecosystems are choosing to use or strongly endorse a single bridge as if it was officially supported.
However, the differences between an official canonical token bridge and a third-party one are not often talked about or considered, adding to the vendor lock-in issue. This is concerning as there are some major differences between the two. Take these three key differences as an example:
-
Entirely different and decoupled security assumptions. Third-party bridges use their own security mechanisms for the bridging process and do not share the security properties of the underlying blockchain.
-
Interests are not fully aligned. Unlike the official bridges, third-party ones are not fully aligned with the interests of the projects using them. Once a project is locked-in with a single bridge, it surrenders a significant, if not monopolistic, portion of their controlling powers to that bridge.
-
Entirely different and decoupled decentralization and reliability model. A blockchain might be fully decentralized and permissionless with incentives for the validators and miners, but a third-party bridge that connects to it may be a more centralized or closed system and the liveness assumptions are also drastically different.
Due to these differences, it creates devastating security and ecosystem risks for projects or blockchain ecosystems that get locked into a single third-party canonical token bridge. The scary part about it is, this is already happening.
First, let’s talk about security. Because some third-party bridges control unlimited mint/burn and lock/burn authority for the bridged asset. This means that the security of that asset being bridged is essentially reduced to the security level of that single bridge. What’s worse is that, in some cases, if the bridged assets are major DeFi assets like WETH/WBTC/USDT/USDC that are widely embedded everywhere in the blockchain, the security of the entire blockchain is effectively reduced to that single bridge’s security level.
Second, interest misalignments create huge ecosystem risks. Just to name a few examples:
-
The bridge can decide to monopolistically increase fees or charge unreasonable fees.
-
The bridge can rate limit your users in favor of some of your competitors that more closely align with their interests.
-
The bridge can stop iterating on and improving user experiences or be slow in innovating on and introducing new functionalities. This, by extension, slows down your blockchain’s innovation.
Finally, on decentralization and reliability. What if the bridging system experiences congestion? What happens if there is service degradation? What if the bridge project goes out of business? It is the users who are left holding the bridged tokens that are the ones left high and dry.
The Fight between Clones
Okay, single bridge and vendor lock-in is scary, blah, blah… Let’s just connect with multiple bridges and let all bridges freely compete in community voting wars and community reward wars like we are having now in Terra ecosystem.
Yeah, we can do that, but let’s play this out a bit. In the beginning, you will end up with a situation where for the same UST, there will be multiple different bridged UST on Ethereum from many different bridges that are ABSOLUTELY incompatible between each other. This is of course not optimal because of the degraded UX and segregated liquidity. Unfortunately, this is already happening on many different blockchains.
Bad as it is, in our opinion, this is still infinitely better than choosing a single bridge and therefore trapping a blockchain ecosystem into a vendor lock-in situation. Given time, after some cut-throat competition between different bridges, probably 1 or 2 bridges will be left to play. What this leaves Terra community is a hectic time of figuring out which token is which and still finally goes back to essentially the same vendor lock-in situation.
Naive Mutual Trust Between Bridges is Harmful
So, can we just ask all bridges to simply mint to the same token address for UST on every destination chain?
Well, it’s not that simple. We need to consider the security implications of this. Let’s examine the following scenario.
Bridge A and Bridge B formed an alliance: for UST on Terra, they will mint into the same token address on Ethereum. Let’s say for UST, the bridged version on Terra is called brUST.
Alice bridged 100 UST to Ethereum via Bridge A. What happened underlying is that 100 UST is locked into a contract on Terra that Bridge A controls and Bridge A mints 100 brUST on Ethereum to Alice.
Bob bridged 50 UST to Etheruem via Bridge B. What happened underlying is that 50 UST is locked into a contract on Terra that Bridge B controls and Bridge B mints 50 brUST on Ethereum to Bob.
Now, Bridge B got hacked like Wormhole, and minted 150 brUST out of thin air on Ethereum to Hacker. Now, because Bridge A also recognizes the same brUST token, Hacker can quickly bridge back the 150 brUST from both Bridge A and Bridge B and get the 150 UST while emptying both Bridge A and B’s reserve.
Now, the sad thing is that even though Alice never used the compromised Bridge B, her asset is also gone. Should Bridge A also be blamed in this case because Bridge A chose to trust and share the security of Bridge B? We believe Bridge A is indeed to blame here and that is precisely why we have never seen any bridge alliance formed in real-life yet. In fact, cBridge came so close to an alliance with another friend bridge and we aborted at the last minute due to this concern and responsibility we both need to undertake for the community.
Don’t Trust, Verify: the Magical Tradeoff of Two-Phase Commit Protocol
So, what do we do now?
Well, history has told us once again that the solutions to many hard computer science problems are just about finding the right tradeoff.
Canonical asset bridges’s core logic is dead-simple : if some tokens go out of the bridge on one chain (by release or minting), the same amount (minus fee and etc) of tokens must have gone into the bridge on another chain (by burning or locking) before that. We can call the above statement the Bridge Invariant . The problem of the above scenario is that Bridge A has no visibility of what is happening in Bridge B. If we have a way for Bridge A to see every action of Bridge B before it actually happens, Bridge A can then stop an action from actually happening if the said action violates the Bridge Invariant (e.g. Bridge B trying to mint 1000 brUST without anything already locked in Terra side).
But how can Bridge A know Bridge B’s minting action before it actually happens?
We call upon the classic computer science design pattern of a Two-Phase Commit protocol with a mandatory delay between prepare and commit step. Whenever a bridge wants to take any action that will release more tokens on any chain (say minting new bridged tokens or releasing locked original tokens), it has to first make an on-chain “prepare” message containing the intended action along with all relevant informations for other bridges in the same alliance to verify the Bridge Invariant. This on-chain “prepare” message can only be “committed” with real-world effect of minting the actual token after a certain period of mandatory delay, say 30 minutes. During that time, all the other bridges that are minting the same token should check for the Invariant and can pause the action should sufficient amount of bridges in the group agree that a Bridge Invariant is violated (e.g. the offending bridge is minting token without actually receiving anything in the original chain).
With this kind of shared sentinel service and a 2PC protocol, multiple bridges can co-exists naturally and more bridges can be added to an ecosystem easily. Because one bridge’s actions is now monitored by all others in the alliance, we in fact achieve an even more secure bridge environment comparing to using any single bridge!
The only tradeoff is the added delay between the “prepare” and “commit” for any bridge action. However, that can be solved by augmenting a liquidity pool based bridge easily like Connext or Celer cBridge’s liquidity pool model.
What can UST do now?
This mutual monitoring solution is not ready. Yes, we understand that. But the good news is that right now, all we need to do is to leave the door open by deploying a bridge contract that allows multiple minters like this one. And yes, Terra community can choose to use one bridge or another to begin with, but Terra community should push for this multi-bridge model with enhanced security and no vendor lock-in risk in the future.
However, if UST uses a single minter contract on the destination chain, then all is lost and UST will be vendor-lock-in forever. Therefore, we strongly urge the community to consider our proposal for the greater good of the Terra community.