Game of Bridges
Prior to diving into the technical specifications of projects like bridges and other cross-chain services, we’d like to highlight a few key points that will be discussed in this article:
- What goes into building a multi-chain bridge?
- Why is it nearly impossible to develop a trustless multi-chain bridge?
- What are the closest available options for building such a solution?
- Are bridges themselves the best multi-chain solution?
- What kind of key infrastructure is needed to build something like a multi-chain liquidity engine?
The purpose of this article is to provide a bit of insight into some setbacks we currently see in the market, and where there is room for improvement.
This article is written with the assumption that it is clear why cross-chain bridges are vital to a multi-chain metaverse. This has not only been highlighted several times in other literature but also sufficiently proven through the demand for existing services. If you’d like to get familiar with cross-chain bridges, read this primer.
A Chaotic Metaverse of Blockchain Madness
It should not be a surprise to anyone that Ethereum is no longer the only blockchain locking billions of value in DeFi. Ethereum has started suffering from high transaction costs, and low throughput for years now. This created an opportunity window for other EVM side chains like Binance Smart Chain, Polygon, Fantom, Avalanche — which have all gotten significant traction, and people move beyond the Ethereum (EVM) narrative to blockchains like Solana, Polkadot, etc.
The space is innovating in terms of scaling and decentralization, and the users have been migrating accordingly.
An analogy that accurately encapsulates our vision of why we built Symbiosis is found by looking back to the beginning of the Internet era, where there was no World Wide Web, but only LAN. Back then, each LAN could only interact within its own area network, which basically meant there were only silo’s and walled gardens that led to fragmentation of information.
A snapshot of the Web3 ecosystem today shows the same fragmentation in the form of inefficient liquidity across cross-chain pairs, with no seamless integration between chains to allow for an efficient market. This fragmented environment is very similar to the early days of the Internet.
Clearly, a solution is needed to connect all of these networks seamlessly. The market has already proposed a solution in atomic swaps, which is a fully trustless setup. However, this solution didn’t take off as much as some may have hoped, which led to the evolution of centralized and decentralized bridges. So, let’s take a look at why this shift happened, and what are the options for building a bridge while meeting the requirements for a successful cross-chain solution.
How did it all start?
The first concept for cross-chain communication began with atomic swaps, which were first conceptualized in 2013. The first atomic swap was later conducted in 2017 between Decred and Litecoin. For a brief primer on atomic swaps, watch this explanation.
Atomic swaps are a trustless process, meaning there are no assumptions required by a trusted third party prior to the process of bridging or swapping assets. In any atomic swap design, the entire process should be conducted this way.
How to define “trustless”
Atomic swaps are a trustless process because both parties have to fulfill the requirements of the trade, which are defined in the contract. If either party fails to meet the requirements, the time-locked contract will refund the other user.
But then, why didn’t it get any market traction and users’ love? The answer is harmful but easy: it’s a pretty complicated process in terms of user experience and liquidity (find someone to trade with).
So, what could be holding back atomic swaps from gaining market tracking and user affinity? The answer is simple: combining a good user experience with sufficient liquidity is easier said than done.
The process requires both enough capital and willing counterparties looking to swap the desired assets. For example, in order to swap 1 BTC for 15 ETH, one would need to find someone willing to exchange this exact amount of ETH for BTC. These requirements result in a complex, time and energy-consuming process.
The first goal of a cross-chain solution needs to be a simple and easy-to-grasp UX where users don’t need to worry about finding someone to trade with. Uniswap has adequately satisfied and proven demand for this in the market and is a successful example. As a result, the first goal of a cross-chain solution should aim to have a Uniswap-like experience.
For a comprehensive overview of all of the risks associated with atomic swaps, visit the following document.
Sometimes Trust is Inevitable
Eventually, cross-chain solutions evolved into bridges. In this section, we will go over the basic design behind building one.
In a bridge setup, one can create an ERC20 token pegged to the value of a bridged asset (i.e xBTC or yBTC, or any project). These tokens, in this example, are backed by actual BTC (from the Bitcoin blockchain) managed by one or multiple entities.
To ensure full collateralization of pegged BTC, the BTC used as collateral must be sent to Bitcoin addresses custodied by either a central party or a group of parties (i.e. validators). It is clear by their design that there is an element of trust involved in order for these types of projects to work properly. There can be several components of a project that require trust, and the level of trust can vary as well.
For some projects, trust is centered around the BTC custodian. For others, a set of validators must coordinate to perform the necessary functions of a pegged system — namely mint, burn, and secure assets. They must reach a consensus on their collective actions, and the various approaches in how they reach consensus result in different trust assumptions.
“Are there trustless bridges?”
Yes, there are. A working example is Rainbow Bridge, a new concept introduced by Near.
The core idea behind the bridge is that it implements two light clients:
- An Ethereum light client implemented in Rust as a NEAR contract;
- A NEAR light client implemented in Solidity as an Ethereum contract;
The overview above provides a visualization of the light client bridge design. Essentially, a blockchain light client is a specification or implementation of that specification that monitors the state of the blockchain without performing heavy computation, but can still check the state it is tracking trustlessly. The main innovation is being able to track and verify status with a small amount of computation.
Notice how, in addition to smart contracts they implement light clients, the Rainbow bridge has two services called relays that regularly send headers to light clients. Eth2NearRelay sends each header to the EthOnNearClient contract, and Near2EthRelay sends one header every 4 hours to the NearOnEthClient contract.
For more information, visit Near’s blog: https://near.org/blog/eth-near-rainbow-bridge.
So, as one might imagine, this trustless setup comes with some tradeoffs:
- Every block from each chain needs to be actively verified. Currently, Rainbow bridge verifies Near block headers only once in 4 hours (otherwise it would cost a lot of money) meaning users need to wait for 4–6 hours for their Near to ETH transactions;
- You can’t really build a bridge with this design between ETH and BSC or ETH and Polygon, cuz of consensus incompatibility;
- You need to work around every edge case of both connected blockchains such as forks, chain split e.t.c raising the complexity of such a solution enormously;
- Rainbow bridge is not really trustless, but rather “optimistically” trustless, meaning that it relies on fraud-proof techniques.
The Rainbow bridge is way more compelling for end-users that want to transfer a huge amount of liquidity between ETH and Near and respects security over time. But if we are talking about blockchain interoperability, it’s not a sound solution.
So to summarise all the above we understand to build a generalized cross-chain solution that can connect as many chains as possible, and the only two options for that are either centralized or decentralized.
Hard pick?
To Trust or Not To Trust
As mentioned earlier, a trustless setup is not really an option. The only option is to implement pegged assets to protect the whole system from malicious actors.
Essentially, the question becomes whether to build a centralized/PoA protocol or a decentralized one. To do that, we need to understand the tradeoffs for such a solution. On this note, let’s try and compare the tradeoffs between CEXs and DEXs as closely as we can.
Centralized exchanges, or CEXs, have gained massive traction over the last decade due to their ease of use, speed, and liquidity. While they arguably fall short in some aspects, such as privacy and KYC, their services are still desirable enough to attract millions of users. However, CEXs don’t come without significant risks.
Multicoin Capital outlines the main problems with centralized exchanges and I believe it can be extrapolated to any centralized custody solution such as bridges:
- Counterparty risk. In the case of centralized custody, the users totally lose full control over their funds for some time. There are multiple risks associated with it, including fractional reserves, omnibus accounts, chances for exchanges to go insolvent, and so on. Let alone front-running on their customers and market manipulation.
- Transaction speed. To minimize counterparty risk, users have to withdraw their assets after every single transaction. Besides withdrawal limits, it requires some time and thus can lead to missed arbitrage opportunities (in case of the huge price fluctuation).
- Regulation. Since centralized exchanges are subject to local regulations, delisting of specific assets is quite frequent. Besides, in severe cases, exchanges have to terminate all operations and that could be a threat to the safety of users’ funds.
- Attack risk. Even though centralized exchanges do the rotation of funds (transferring from one to other wallets) quite frequently, they are still the sole owners of users’ funds, thus becoming prime targets for hackers.
Ideally, a company that is well-known and reputable could create a centralized bridge and alleviate most of these problems, but this centralized solution, as previously discussed, would create new risks around solvency.
It is impossible to overstate the immense value that DEXs already bring to the ecosystem. The key feature of decentralized exchanges is that users never give up control over their funds. Otherwise known as self custody, this is a major improvement over the current centralized infrastructure. For the first time, people all over the world can trustlessly exchange tokens without any counterparty risk. By looking at real examples, we can already see the profound impact these products have had on the market.
So naturally, the goal for a cross-chain project should be full decentralization.
The Quest for Scalability
The final area of focus is scalability. It is important to take another look at the same projects we previously mentioned, but from a different perspective, because scalability is inversely correlated with levels of decentralization.
The inverse correlation is due to the fact that more decentralized systems come with more implicit costs. Maintaining a bridge between two blockchains requires a new security model to ensure that the bridge is properly maintained. The costs required to maintain the bridge need to be borne by some party, whether it’s minters, validators, holders, etc. and in turn can lead to additional friction in the pegged product.
So if you are moving away from a trustless setup and centralized setup is not an option, the design space can vary depending on a balance between the trust elements of custodianship, consensus mechanism, and price feeds for each project. You can read more on that in the following article.
So the requirement for a cross-chain solution, that this pegging mechanism should be scalable.
The Bridge is Not a Solution per se
Let’s look at this problem from one more angle: there are several bridges on the market today, yet none are emerging as a clear market leader. Instead, each chain has built its own custom bridge with a different UX and process, ultimately creating a bit of a learning curve.
We even found that even power users had trouble figuring things out.
Ideally,cross-chain solutions should be as easy to use as possible, and it is clear why users still choose to use centralized exchanges for moving liquidity. When a product is introduced to the market that will save time and mental energy for its users, that product stands the best chance to emerge as a market leader.
Aside from UX, the second problem that arises with bridges is Liquidity (it cannot be overemphasized so I put it with capital L). There are currently more than 30 bridges available with liquidity inefficiently scattered across all of them. Each bridge needs its own liquidity provision; making it very capital inefficient with a lot of redundancy, and subsequently diluting the potential impact of bridges.
To further convey this problem, let’s look at another example that users might relate to.
A user has BNB on BSC and wants to add liquidity to a new farm on Avalanche in the form of token X/AVAX — how is this achieved
Please allow for the following visualizations to show that there are currently two main ways to do so:
- Through centralized exchanges:
2. Or to go through multiple bridges:
The process above not only takes a lot of time to complete, but it is not very friendly for end-users who need to navigate between multiple interfaces and make sure to have native tokens on both chains in order to pay for gas fees e.t.c. Additionally, the ‘’too many bridges’’ problem scatters liquidity across all of them, leaving users potentially confused with an arbitrary W/S/Z/E token without proper liquidity, or native tokens to transact with.
We believe this type of thinking is flawed, the average user only wishes to move liquidity from Chain A to Chain B, from token X to token Y.
We are proposing a cross-chain solution for this problem by outlining our first requirement: A product must be a one-stop service for every user with unpredictable liquidity requirements and quick finality. Ideally, it should allow for any token on any chain to swap with one another with no compromise.
Where does this lead?
In summary, a robust, efficient, cross-chain solution should meet the following set of requirements:
- Fully decentralized based on scalable pegging mechanism: no authority can freeze the protocol or censor users from accessing the protocol.
- Interoperable: it connects to every chain with enough market attention.
- Non-Custodial: Users maintain control of their funds at all times.
- Easy to use, limitless cross-chain liquidity: the protocol will target as many token pairs as possible across all chains, while still providing the best prices for swaps between any arbitrary token pair.
Symbiosis — a multi-chain protocol we’re working on — actually meets these requirements. We’ve been working behind the scenes for a while, and are excited to finally share more details about product design and architecture in upcoming articles.
Stay tuned to learn more and subscribe to our social networks.
Website: https://symbiosis.finance
Twitter: https://twitter.com/symbiosis_fi
Telegram: https://t.me/symbiosis_finance
