Why do I write about bridges now? 

Cross-chain bridges, especially between L1s, have been a popular topic over the past few years as crypto welcomed the alt-L1 race in 2020. The demand for a cheaper, faster, and more scalable blockchain soared together with the daring need for secure and reliable bridges across those chains. However, it soon becomes overwhelmingly clear to anyone that BRIDGES SUCK. With the semi-quarterly announcement of major bridge hacks shivering the spine of all who “bet” their liquidity on one or more of the trusted bridges, investment and liquidity provisions on bridges become highly risky activities with a low risk-adjusted return. So why am I still talking about bridges right now? At first, I was somewhat dismissive of the entire cross-chain thesis, hence the bridges themselves. However, I believe strongly in the future of L2s on Ethereum, and bridges seemed like an inevitable first step towards increasing access to and between L2s and mitigating the liquidity fragmentation issue around them. Only with sufficient interoperability and liquidity infrastructure will I foresee L2 space welcoming more builders to develop diverse applications/app-specific rollups on top (an exaggeration ofc). While I am looking forward to seeing the development of L2 interoperability space, I cannot and would not distinguish bridges between layers/chains on a technical level. Thus, for the sake of this article, I would focus on the discussion around the general bridge security model from the lens of trust minimization.

How is the bridge secured? An intro on trust-minimization

We should be fundamentally asking three questions when looking at bridge security: Who is verifying the system? How are they verifying? And how much does it cost to manipulate the system? Answering these questions reveals how secure and trustless the system is; note that trustless in this context would mean the inheritance of security from the underlying chains on which the bridge transactions are processed. As such, a trustless bridge should be permissionless (for decentralization) with an economically infeasible manipulation cost, which realistically should be as high as manipulating the underlying chains. However, creating such a bridge is an extremely difficult task. Most bridges to date make tradeoffs in varying degrees. The best they can do so far is trust-minimization with the exception of IBCs and other natively verified bridges whose security rests upon the chains themselves. To better understand the bridge ecosystem and those tradeoffs, let’s BriEfLy go over some of the security models we‘ve seen across bridges (if interested, there is a succinct overview here where I quoted some graphics).

Natively Verified Bridge: the kid that everyone does not even need to trust

Natively verified bridges run a light client of chain A on chain B and vice versa, hence the bridge security is inherited from the underlying chains and is arguably the most trust-minimized bridge design, meaning that the bridge is as secure as the two chains themselves (assume no bugs ofc). Some examples include IBC, TBTC, EOS Bridge, and Near Rainbow Bridge. The downside, however, is the low reusability, potential compatibility issues, and difficulty of maintenance. For example, Near has a signature system of Ed25519 which needs to be verified on Ethereum, but such type of signature cannot be pre-compiled and executed on EVM due to a lack of compatibility with EVM-native signature. Although many have attempted to submit EIPs to implement such external signature systems natively in EVM, most, if not all, are not approved for the reason mentioned here (essentially those signature systems only benefit a small group of people, like other ecosystems lol). Hence, the verification of the transaction signature cannot be done on-chain and has to rely on Optimistic verifiers with a challenge period (refer to the Optimistic bridge part later). Furthermore, the complexity associated with signature verification and the maintenance of such bridges reduces their reusability across other ecosystems (unless all are EVM compatible). Therefore, some natively verified bridges end up using an Optimistic model for security backdrop due to compatibility issues or are constrained within their own ecosystem, like Cosmos IBC.

Natively verified bridges generally have not been a popular choice for weaving different ecosystems together under one bridging architecture. This leads us to the most popular and widely deployed bridge type that excels at cross-ecosystem bridging – externally verified bridges.

Externally Verified Bridge: the kid that everyone has to trust with their balls

Externally verified bridges rely on 3rd party validators, like off-chain or 3rd chain, to verify the transactions on sender and receiver chains. This is the most popular type that is deployed across many ecosystems such as Ronin Bridge, LayerZero, Synapse, Anyswap, Biconomy, Celer, Axeler, and more. Among those bridges, their design could vary from a simpler Multi-Party Computation (MPC), more specifically multi-sig (note that MPC is an umbrella term), to Threshold Signature Scheme (TSS), aka a bit more sophisticated multi-sig. Most of the TSS/MPC is integrated with a third-party blockchain or oracle that has a high threshold for signature signing and relies on PoS or some forms of cryptoeconomic security (including insurance, bonding, and more).

While being widely popular for their simplicity and scalability, externally verified bridges are the least trust-minimized design. All of them rely on external parties instead of the underlying chains for security. For example, Across (technically an OP bridge but will explain later) and LayerZero rely on the security of oracles which typically run on PoS model with the staked oracle-native tokens. Similarly, Axelar and a few others run their own blockchains with a DPoS model that would require staked bridge-native tokens for security. As such, all of them are building their own layers of cryptoeconomic security instead of inheriting the underlying chain’s security. And since their cryptoeconomics are based on their protocol-native tokens, it would be dangerous to decentralize the network (aka making it permissionless) until their tokens hold an over-threshold amount of economic value that would be deemed economically infeasible for any attackers. This partially explains why many oracles and bridge validator networks to date have not been fully permissionless and decentralized yet. To some extent, I would even argue that building an externally verified bridge can be as resource intensive as building another L1; both need to align verifiers’ incentives, decentralize the verifier network, and accumulate crypotoeconomic values for security.

Although there are many challenges faced by externally verified bridges, they are by far the most widely used version of bridges. I believe there is a future where such trusted bridges would exist and prosper under certain assumptions despite the security risks (will elaborate later). For now, let’s also take a look at the more practical and optimistic attempt at trust-minimized bridges.

Optimistically Verified Bridge: the kid that everyone assumes to trust

Optimistic bridges verify the transaction by approving the transaction first and checking for any fraud later via off-chain verifiers during its challenge period. Since all transactions are approved on the assumption that they are valid, optimistic bridges only need at least 1-of-n verifier that flags any potential fraud instead of n-of-m verifiers in the case of externally verified bridges. Reduced trust assumption from a minimum of n honest nodes to one honest node grants optimistic bridges the trust-minimized security. The tradeoff here, however, is the requirement of a challenge period which could result in a latency of up to a few hours. To settle the bridge transactions instantly for a better user experience, optimistic bridges have to rely on some liquidity sources for “credit line”. And those liquidity layers are either built in natively or integrated with external bridge liquidity protocols such as Hopp and Connext.

At a glance, optimistic bridges have a better trust-minimized security design than what externally verified bridges possess, but that comes with one caveat; “heavily-trusted” liveness. I made up this word and would appreciate any suggestion for a better term, but basically what it means is that the liveness of bridges is trusted on the assumption that there aren’t any malicious entities. In other words, if there is a single malicious verifier, all the bridging transactions could be censored and the bridge stops working. If there is no adequate dispute mechanism when a verifier flags suspicious bridging transactions, the bridge will be vulnerable to censorship attacks. Such attacks simply rewind all the bridging transactions, and they shift the loss of funds from the bridging layer to the liquidity/settlement layer that is built on top of them, such as Connext and Hop. Currently, most of the verifiers, like watchers on Nomad, are permissioned, hence centralized. But if they want to sustainably scale and decentralize their optimistic bridges, a dispute mechanism needs to be introduced, and there are a few ways so far that have been proposed or implemented by projects. Across, an “optimistic” bridge uses UMA’s optimistic oracle for its dispute mechanism. However, Across has negated the trust-minimized property of being an optimistic bridge by using the optimistic oracle whose dispute mechanism is governed cryptoeconomically; Across needs UMA token to vote during the dispute process, so technically someone can buy up UMA token to meddle with the voting if given enough incentives. Others have suggested ways to economically disincentivize the censorship/over-flagging without relying on cryptoeconomic security of the bridge-native tokens. However, such a model would be susceptible to attacks as long as the potential value capture surpasses the cost of collusion. And that value capture does not have to come directly from stealing the bridged assets. It can also come through other means, such as profiting from deliberate market manipulation of the associated tokens.

As described above, optimistic bridges still have fundamental issues that have to be resolved to be truly trust-minimized. But in the meantime, there is another type of bridge that attempts to crack the code for trust-minimization using SUPER-DUPER well-known/hyped cryptographic proof: THE ZKSNARRRRRK.

Zero Knowledge Verified Bridge: THAT kid in the math class who everyone trusts for math

zkBridge verifies the transaction using zkSNARK, which is succinct non-interactive proof of knowledge (more details found here). The proof would allow a light client on the sender chain to prove to the light client on the destination chain that the bridge transactions are in fact committed to a new block by validating the block header and the state transition of the sender chains. There are off-chain provers who would generate and relay the proof validating the block header with the bridging transactions, which is then verified on the destination chain by verifiers (verifiers have no knowledge about the specific transaction signature). Because the verification and generation of such zkSNARK will be pseudo-deterministic (some may be deterministic), the security of the chains rests on the correctness of the proof which would be near impossible to tamper with. Hence, zkBridge is theoretically the most trust-minimized bridge model besides natively verified bridges.

Just like other bridges, however, there are also tradeoffs/challenges for zkBridges. First, they are computationally resource-intensive. While zkBridges are trust-minimized on the security and liveness of the bridges due to the minimum requirement of one honest prover, the performance heavily depends on the computational resources (potentially determined by the number of provers). Generating proofs with minimal latency would require parallel computation with highly efficient proof circuits. This leads to the second issue: the high cost. Aggregating computational resources require zkBridges to provide enough prover incentives to sustainably scale and decentralize the underlying computation; it is also far from trust-minimized if most of the provers are running on AWS (acceptable at its early stage). In addition to the incentive cost, there is also a high on-chain verification cost of the zkSNARK which has to be minimized by reducing the proof size. All of the aforementioned costs should be lessened to make zkBridges more affordable and usable. There are some attempts at cost reduction, such as minimization of proof size through recursive proofs and batching of block headers. But most of them are yet to be deployed in production. Lastly, and perhaps one of the bigger challenges, is zkBridge’s complexity compared to other types of bridges. Light client implementation for the on-chain verification of the zkSNARK would resemble some of the natively verified bridges (though much more scalable in design as zkBridges do not perform signature verification), such as Near Rainbow bridge, where the higher implementation and maintenance difficulties may result in additional operational costs as well as a higher chance of bugs. This leads to another interesting aspect of bridge security that may be overlooked by many: human errors.

Trust-minimization faced with execution risk & human errors (Why does trust-minimization matter?)

I have talked a lot about security design for bridges and how they are trust-minimized or not, but if we look at the causes of major bridge hacks that happened over the past years, we notice that most hacks are caused by human errors. Some are private key leakages through phishing attacks and negligence, while others are smart contract bugs and smart contract logic vulnerabilities. This begs the question of how we should consider bridge security in consideration of the execution risk and the security design. For example, there could be a perfect bridge design that is trust-minimized, decentralized, cost-efficient, and scalable but has a highly complex architecture, like some of the natively verified bridges. And even if the bridge is built, there are non-negligible risks of smart contracts and logic bugs associated with the inherent complexity. Such execution risks have driven many people to build bridges with simpler designs that can be managed easily, which tend to be externally verified bridges. This is another form of tradeoff that some teams are making; essentially saying that instead of building a complex bridge that has the best security design in theory, why not build a simple bridge with a manageable security design? Put it in another term, why build even more complex bridges, like some trust-minimized bridges, when existing bridges already have so many execution issues? To answer this question, we have to put the entire history of crypto and its future in perspective.

Over the past few years, crypto has received numerous publicities across the world and has ignited the hearts of many who believe in the future of decentralization. However, in comparison to the rest of the economy, crypto is still nascent and most people in crypto are still early adopters and innovators. As more and more web2 and the mainstream public adopt crypto and use blockchain applications, there will be value accumulation (an increase of TVL) to the bridges and other infrastructures that support those applications. Although there hasn’t been a single major bridge that experienced a cryptoeconomic attack, or at least not that I am aware of, the growth of crypto overall and disproportionate value accrual to a few major bluechip tokens (L1 tokens like ETH & BTC) would create more incentives for well-resourced hackers, such as nation-state or large entities, to cryptoeconomically attack the trusted bridges whose staked tokens have comparatively less value accrual. Even worse, there could simply be a malicious entity who wanna see the world burn or indirectly profit from costly attacks, disregarding the entire assumptions by cryptoeconomic security (where attackers will not want to lose more than what they gain). Therefore, the pursuit of technically superior and perhaps complex bridges that have trust-minimized security future-proof the healthy and safe growth of the crypto industry beyond mass adoption. And I believe that is the reason why bridge should pursue a trust-minimized security model even when facing such execution risks, and leave the cryptoeconomic securities to the underlying L1s who can better capture the values. This is also another reason why some may understandably consider building and investing in bridges to be a “public good”; it is hard to build a bridge that withstands the test of time.

Any future for trusted bridges?

While I stand with my view that a trust-minimized bridge with meticulous execution by the team would be able to take the crown in the bridging world over the long term, or at least I hope it would, I also see the importance of early-mover advantages and BD effort in creating the ecosystem on top of the existing bridges, such as Stargate by LayerZero. One could even argue that building a bridge is like building an ecosystem where tech is only part of the equation. Analogous to the L1 and L2 competitions, whoever builds the strongest ecosystem with the most technically innovative community tends to take the crown in the race. Perhaps, there could be a future where the same scenario plays out for bridge competition as well. And as long as the trusted bridges maintain their reputation and the trust of the community, they would remain dominant. For now, I expect that trusted bridges would dominate the space for the short term as more trust-minimized bridges mature over a longer term. But if we stretch the timeline long enough, I believe the anti-network effect will become stronger for those trusted bridges that rely on cryptoeconomic security due to reasons mentioned previously (an increase in usage leads to increased assets on bridges hence increased rewards for cryptoeconomic attacks). Therefore, slightly contrary to what Vitalik has famously mentioned in his reddit post, I foresee the anti-network effect to appear on trusted bridges first before reaching L1s, where hackers would be more incentivised to cryptoeconomically attack the bridge layer where the cost of collusion is lower.

What is the takeaway from all this?

Most bridges to date are still unsafe, especially against well-resourced and smart hackers who know how to extract values beyond the TVL on those bridges. Most of the externally verified bridges, the trusted ones, rely on the assumption that hackers do not want to lose money when attacking a bridge, hence the cryptoeconomic security. However, there are ways in which hackers could extract profit beyond the TVL sitting on the bridges as I mentioned previously, and there will be more ways to indirectly profit from hacks as different entities with different intentions come into the crypto space. While I acknowledge a path in which trusted bridges remain dominant for years to come, truly trust-minimized bridges, such as zkBridge or IBCs, will be the future-proof bridges that have the best chance of surviving the wrath of ruthless hackers for the long term. Lastly, be safe and let us pray to the god of trust-minimization that one day we all can step on a cheap and decentralized trust-minimized bridge.