How Bridges Can Be the Next Big Risk in Crypto
A Simple Risk Framework for Cross-Chain Bridges
Blockcrunch VIP subscribers receive weekly research briefs and investment memos and lock in their price forever.
You’ve heard about bridges like Synapse, Multichain, Stargate, Thorchain, Cosmos. You’ve probably used or invested in a few too!
But do you understand how risky they are?
In this week’s Blockcrunch VIP memo, we will present a simple risk framework for bridges for you to become a smarter user and savvier investor, even if you are not technical.
The Largest Honeypots after Luna
Cross-chain bridges are shaping up to be massive security honeypots in crypto.
In February, Wormhole was exploited for a record $325M in an avoidable technical breach, among the top 5 largest hacks of all time. At the end, trading firm Jump bailed out the bridge with its own capital after the fatal bug was patched.
In March, Sky Mavis’ Ronin bridge was exploited via potential social engineering, leading to $540M in loss. What’s more: the attack was only discovered a week after it happened!
But that’s still a drop in the bucket compared to the $16B locked in various cross chain bridges today. That being said, if the future truly is multi-chain, bridges are only in their first inning.
The First Inning of Bridges
There are over 100 public active blockchains today. Despite the apparent consensus around a multi-chain future, there is no mainstream adoption of bridges within crypto yet, let alone consensus around which bridge should be dominant.
To put it in perspective:
As of this piece’s writing, the total value locked in bridges is only $16 billion - mere 8.81% of the ~$194 billion assets locked in DeFi protocols
The number of unique wallets that have deposited on an Ethereum bridge is a meager 1.02 million - 21.74% of the 4.69 million unique wallets that has ever used a DeFi protocol
Now that we have some context, let’s dive into how risky bridges actually are…
To understand what risks bridges have, we need to understand what types of bridges there are.
As cross-chain bridges primarily bring data from a chain A to chain B, neither of which can know what’s happening on the other one, it can be thought of as a subset of the oracle problem.
Or in simple terms: “How do we let Chain A know what’s going on outside of Chain A in a trustless manner?”
For instance, if I hold 10 ETH on Ethereum and want to transfer it onto Avalanche, how can Avalanche validators know that I do in fact have access to the 10 ETH?
Under this example, bridges can mostly be broken down by their two main functions:
Verification: How they verify that I in fact have the 10ETH on Ethereum
Liquidity: How they supply the 10ETH onto Avalanche
Types of Bridges And Their Risks
Most of the security assumptions users make depend on the former use case: verification.
Today, there are roughly 4 overarching types of security models for cross-chain communication protocols.
Note that when we qualify something as “secure” below, we are discussing how economically secure they are, not how solid the code is.
Even secure protocols can have software bugs!
Natively verified bridges are as safe as the underlying chains (read: usually very safe)
As you probably know, blockchains maintain and add to their overall transaction histories through decentralized full nodes, which require a lot of resources to run. Luckily, we have something called Light clients - a less resource-intensive way of interacting with a blockchain, compared to running a full validator node.
Someone figured out that if you run a light client of chain A on chain B’s virtual machine, and vice versa, you can let both chains know what’s happening on the other one. Cross-chain communication achieved, baby!
This is the basis of “natively verified” bridges such as Cosmos IBC, TBTC, and Near’s Rainbow Bridge (which is natively verified from Ethereum going to Aurora). As validators of each chain are verifying cross-chain transactions, this is the most secure method and has the same security assumption as the underlying chain.
In other words, if you trust the blockchain enough to use it, you can trust the natively verified bridge built on top.
However, it’s quite hard to scale as every chain added to the network requires the light client for that chain to be run on every chain in the network. This is ok if every chain uses the same consensus mechanism (e.g. Cosmos), but a hassle in most other cases.
Locally verified chains adopt the security of the weaker chains, but you likely won’t lose funds using them
Instead of needing to run a light client for every chain connected and have each chain’s validators verify every cross-chain transaction, locally verified bridges have a more lightweight approach: only parties involved verify the cross-chain transaction.
Examples of this include Hop and Connext.
As they inherit the security of the underlying chains as well, this is a highly secure method of bridging (i.e. users likely will not lose funds). This is also easier to scale as it doesn’t require the massive developmental overhead that natively verified chains do,.
The downside is it’s hard to do much beyond sending tokens across two chains. If you want to build an app that straddles two chains, you may find it easier to use externally verified bridges (see below).
Oh and read the fine print! Some bridges, like Hop, are not completely trustless all the time.
Externally verified bridges are the most popular, but expose you to the most risk.
Externally verified bridges rely on an external set of validators to monitor two chains, and verify transactions that occur from one to the next. Think of them as toll booth operators, and the bridges they operate are tunnels between two chains. They are fast, and easily extensible to chains.
These solutions rely on an external oracle network or some threshold multisig used to relay data between chains. Based on usage, most users seem to prefer externally verified bridges due to their ubiquity, but it’s very important to remember that by using them, you need to introduce a new trust assumption: unlike natively or locally verified bridges where you need only trust the economic security of the chains you’re transacting on, you now need to be certain that the external verifier is also secure…otherwise it could be a $540M mistake!
Examples of externally verified bridges include Multichain, Axelar, Thorchain, Synapse and Stargate.
For these bridges, users need to be comfortable that the value staked by the external validators are larger than the value controlled. If a hacker can spend $100M to corrupt a bridge and steal $500M in value, the bridge is economically insecure.
What’s also important is to know that this doesn’t just mean the value staked needs to be larger than the value controlled in the bridge. Since externally-verified bridges can have arbitrary contract calls, we must also factor in the value that can be stolen via cross-chain contract calls.
For example, if a large actor can spend $100M to exploit a bridge with $50M in value locked, then pass messages via the bridge that somehow net him $100M in value by interacting with a DeFi protocol, that’s still a $50M profit (i.e. very attractive) exploit to pull off.
It’s also worthwhile to note that for some projects, having validators stake their assets are not live yet. Synapse for example plans to move to its own blockchain with its own validator set, but currently runs on a MPC with a few signers (i.e. quite centralized still).
Optimistically verified bridges don’t expose you to the same risk as externally verified ones, but are not as safe as natively verified bridges
What if we want the extensibility of externally verified bridges without the security risk, and approximate the security of locally verified bridges but without the limitation in use cases?
Enter optimistically verified bridges.
Basically, the bridge assumes transactions are valid (hence “optimistic”), and opens a dispute period whereby challengers can contest the validity of the transactions. If the contesting is successful, the transaction is reverted.
An example of such a bridge is Nomad.
That means users don’t need to trust an honest majority in an external set of validators to approve transactions. In fact, since any fraud can theoretically be disputed and refunded in the 30 minute window, it’s never positive EV for anyone to attempt to exploit an optimistically verified bridge.
The downside of this is the longer latency for users - whereas using externally verified bridges like Synapse can provide finality as long as transaction is approved on both chains, Nomad requires users to wait for 30 minutes when bridging to Ethereum. This might be more applicable for large transactions (e.g. whales, DAOs, protocol treasury, protocol TVL rebalancing).
Optimistically verified bridges are also less secure than native verification because it allows for the possibility of fraud, and relies on a bit more than just the reliability of the two interacting chains. In its current stage, Nomad also relies on whitelisted fraud monitors.
Synthesis
Well, there you go - you can pretty much summarize every bridge live today under the above four methods, and broadly categorize their risks as above.
While the market seems to prefer externally verified systems today (see usage and valuation multiples below), it is highly recommended that users, liquidity providers or investors in these solutions understand the precise risks they are taking on.
For those eager to learn more, below are a few valuable resources.
Resources
Links to full episode with Nomad:
Bridge Data
Synapse’s data here
Other Data
Further Reading
Disclaimer
Jason Choi has direct exposure to Nomad and Connext via angel investments. The Blockcrunch Podcast is an educational podcast and newsletter for informational purposes only. The authors invest in cryptoassets actively and may hold assets discussed in the newsletter or podcast. All content contained within this email is intended for educational purposes only and should not be construed as any form of financial advice. The Blockcrunch Podcast, its associates and affiliates are not liable for any decisions third parties choose to make.
 | A guest post by
|
Great writing. I'd love to read during every morning coffee time :D