Cross-Chain Bridging - Next Generation of Safer Bridges & How Bridges Still Suck with Daniel Lumi
Ethereum Denver·Mon, Oct 9, 2023, 12:00 AM
Speaker
What is the next generation of bridges which are much more trust-minimized & more secure? Can we ever make cross-chain bridges fully safe or do we need to stay in a specific blockchain? Are L2 rollups, which are also technically bridges, any better? Does fractal scaling on l2 fix these bridge issues? We will discuss these the future of bridges so users can make informed choice. Daniel Lumi Web3 Researcher & Consultant Independent Specializing in L2s, ZK, Privacy, & DAOs https://twitter.com/zklumi
Transcript
Hey, good morning everyone. Uh, welcome to my speech on the next generation of safer crosschain bridges and how old bridges still suck. Uh, first a little bit about me. I'm a web 3 researcher and consultant specializing in L2s, ZK, privacy and Dows. Today we'll be talking about the current uh generation of crosschain bridges, next generation crosschain bridges, how are L2s better than crosschain bridges, as well as some steps we can take to improve old bridges.
So why this talk? Um, honestly, I'm not a fan of bridges. I'm from the ETH ecosystem, so I kind of prefer staying in my base, but I honestly believe that we will live in a world with many different chains. This is because of scalability issues that every single blockchain has as well as um every application has different uh requirements for security. Uh if we do live in this world with many chains, we really need better bridge designs than we currently have.
And just to give an idea of this, um in 2022, uh 69% of all of the funds that were hacked were from bridges uh that resulted in losses over $2 billion. Examples of this are the Axi Infinity Bridge, the Nomad Bridge, and the Wormhole Bridge, which were all hacked. And here's sort of our current categories of bridges. You don't really need to pay too much attention to all the details on this page yet. The idea is there's a spectrum of trust that you get in bridges from trust a human to trust a code.
And each of those different categories breaks down into two different types. Wrapped asset bridges and liquidity provider bridges. And again, both of those have their different their own spectrum of trust in them. So here's sort of our current generation of crosschain bridge designs. We have three different types.
We have custodial bridges where there's one entity that is in charge of all the bridge transaction in charge of custoing custoing the uh the actual assets. Then we have multisig bridges where there's a set of trusted actors who are essentially acting the same role as the custodian except there's many people. Then we have optimistic fraud proof bridges. Uh this is similar to um an optimistic chain. Essentially all of the bridge transactions are considered valid until someone spots some fraud and then they can contest that transaction.
And there's usually a delay period of about 30 minutes in which watchers can do this. And so here's kind of where we're at. Uh custodial, multisig, and optimistic bridges, they all bridge assets. Cool. Uh uh and optimistic bridges, they also can lie about state essentially the math behind optimistic bridge will always tell the truth, assuming they can actually submit the contesting transaction.
But there's all these other issues that we have in our current crosschain bridges. So how do we fix some of these issues, right? Well, light clients and ZK bridges to the rescue. And I'm calling these sort of the next generation of crosschain bridges. And light clients kind of break it down into two different categories.
Native light client bridges and then the newer uh zay bridges. And just to get you guys excited on like clients, uh Satoshi actually had an entire section in the Bitcoin white paper on like clients. He didn't talk specifically about bridges, but it tells you a little bit about the power of light clients in a blockchain. So, what is a light client? Essentially, light clients help users interact with a blockchain in a decentralized and secure way without having to sync the entire blockchain state.
That's compared to a normal blockchain where essentially you need to download the entire history, re-execute every single transaction just to know the current state today. With a light client, you essentially just download the latest checkpoint, the block headers, and that tells you what are the current account balances or the current storage and smart contract. So, how does this apply to bridges? Well, block headers are substantially smaller than the entire state of a blockchain, right? And in bridges, we just really need to know the current state, people's account balances or smart smart contract storage.
So essentially light clients allow us to store uh the current state of each blockchain onto another blockchain. So we can essentially interact uh directly with a blockchain state on a different blockchain through a smart contract um and uh directly you know so the first type is native like client bridges. There are some protocols that support Litecoins today like Cosmos or Polka Dot and these chains already allow you to do essentially trust minimized bridging between their own ecosystem, right? But you still need to trust the consensus of the two chains. If either one of those chains gets attacked or is reorded, the bridge lost all the funds.
And a note about native light clamp bridges is the chain has to support it natively. For example, Salana's design can never really support like clients. Etherum in the future will have like clients with some changes like veral trees and some other changes. Then there's this concept of ZK like client bridges or ZK bridges or proof of consensus really. And the idea is this is chain agnostic.
We can take the state of any blockchain, make a proof of it and then submit it onto any other blockchain for bridging purposes. And this is substantially better than current bridges. You still need to trust the consensus of the two chains. Again, if there's a reorg or chain attack, that's going to be an issue, right? Examples of this are ZKIBC and the Nosis succinct to e succinct zk bridge to Ethereum.
Both of those are being worked on right now. So the sort of benefits of like client bridges are unlike custodian or multisig or optimistic bridges you can lie about the current state right and optimistic you also can lie but that assumes that they're able to submit a contesting transaction and sometimes maybe gas spikes and they can't afford to cons contest it or it doesn't make financial sense. Um, another great part of ZK Litecoin bridges is that any user can force their own transaction. So, let's say the relayer stops working or starts censoring, any person can withdraw their own funds by making a proof of the chain. And so, here's where we're at.
We don't kind of have to trust the relayers anymore. There is some asterisk there depending on the design of it, but we solved one of the other issues in this list of issues with bridges. So, how are L2s better than any crosschain bridge? I'm kind of calling these the next next generation bridges. Get it?
Because there's two layers. Next, next. Okay. Uh there's three different types of multi-chain bridges. Note, multi-chain, not crosschain.
There's locally verified third party L2 bridges. There's native L2 bridges. And then there's fractal ZKL3 bridges. And there's an important note on the third party L2 bridges. Uh most of them currently are actually custodian or multi-IG or optimistic.
So most third party L2 bridges don't fit into this category. The only one that I can actually really find is HOP HOP exchange and they they essentially have as a full back a trustless force exit that's locally verified. Then there's some newer bridges like uh storage proof based bridges which we'll come back to that are working on bridge designs and that'll be better. And some of you might ask wait L2s are bridges. Yeah, they actually are.
But there's some important differences between L2 bridges and crosschain bridges. So here's some examples of how multi-chain rollup bridges are better than any crosschain bridge. So, this is arguably the biggest problem for any crosschain bridge, which is if the chain reorgs or is attacked, you lose all your funds in the bridge, right? If 51% attack, if you 51% attack a P chain, it's over. The bridge lost everything just from that one moment of attack.
And so if either chain in a bridge reorgs or is attacked maliciously either to wipe out bridge funds or for whatever reason they're attacking the chain, any wrapped asset bridge, all of the wrapped assets become completely worthless and unbed and everyone loses their money wrecks major havoc on the entire DeFi ecosystem. For any liquidity based uh bridge, the LPs lose money uh for any transaction that's currently happening in the bridge. Oh, an important note on this is because of the weakest link property of bridges, let's say you have a bridge with 10 chains connected. If one of them gets reorged, all of the other chains might lose their backing too. That's really bad.
So, compared to crosschain, what happens if L1 reorgs or is attacked? Well, if a L1 reorgs, so do the L2s, right? This is the same security guarantee that we have in any probabilistic blockchain like um Bitcoin or Ethereum, right? And just as an example of this, let's say you're swapping ETH to USDC on L2. If there isn't a reorg, you get your USDC.
If there is a reorg, you get your ETH back, right? This is again same guarantee that we have in any blockchain. Um so how about if a L2 reorgs or is attacked but the L1 is not? Well, it's it's not as ideal as a L1 reorder, but essentially all L2 users and all of their funds completely fine, completely safe. Um, any native uh L1 to L2 bridges are fine.
They don't lose money. Again, these are the same assumptions as any probabilistic blockchain like Ethereum or Bitcoin. But third party bridges get a bit more uh complex than that, right? Um, and any third party bridge that wait for L1 finality of the L2 states is theoretically fine. That being said, there is no bridge that does this because that adds latency to the bridging transaction, right?
So hopefully we'll have those in the future and you'll have to wait some hours, but we don't. Uh, any bridge that uses proof of storage, which we'll come back to. The funds are probably fine. Depends a bit on design. uh any thirdparty bridge that doesn't wait for the L1 finality of L2 states or use proof of storage.
Essentially, we're back in the same paradigm as crosschain bridge. The LPS lose money or the wrapped assets become unbed. And one of the cool features of uh L2 chain or L2 bridge is you can trigger L1 or L2 trustlessly from the other one. Right? So, this allows us to do trustless multi-chain messaging.
The essentially the idea is the L2 contract is already on L1 and for any nodes that validate the L2 they have to run a L1 and L2 node and this allows us to interact for example uh L2 can send a direct message through its bridge to any contract on L1 right this allows us trustless L1 to L2 messaging as well as token bridging uh assuming that that L2 is designed in a way that can't be censored which they most of them are um and it allows us trust minimize L2 to L2 messaging and token bridging and this depends a bit on the bridge design again if you message directly through L1 it's fine if you use storage proofs it's probably fine or if the relayers wait for L1 finality of L2 states it's mostly trustless right another cool thing about L2 is we can read L1 state on L2 or we can read L2 state on L1 and this is actually the same zk like client that we were talking about but in multi-chain we call it storage proofs so it's the zk bridge for multi-chain and zk like clients are uh substantially better on a layer 2 because uh you can essentially send the state directly trustlessly through the L1 and this allows us for example to in approve information about L1 state on for example startnet L2 right there's examples of this is let's say you lock your funds on L1 L1, you can take a loan on L2 without ever bridging those tokens to L2 because you can read the state of L1 on L2. Or for snapshot X, you can essentially do voting based on your L1 assets trustlessly on any L2 without having to pay L1 gas, right? Um, then there is this concept of ZKL3 bridges. Again, I'm calling this the next next gen bridges. Three next layer three.
Yeah. Um the idea is for these recursive zk or fractal hyper hyper bridges you can bridge between L2 to L3 to L4 to L5 much safer than any crosschain or even multi-chain bridge right essentially all of the different fractalss the L3s the L4s L5s use exactly the same bridge circuit as the L2 so as long as the L2 bridge doesn't have issues all of those other layers get essentially trustless bridging with no problem. Substantially better than any bridge, right? In fact, it's not really even bridging. It's more of accounting, right?
Because everyone locks their assets on L2 and then you essentially have a synthetic representation on L3, L4. So, you can just kind of teleport your funds from L5 to a different L7 without going through the branches. There is an honorable mention here as well besides the fractal ZKL3 bridges. Uh, Optimism has been talking about Super Chain for a while, but they just announced Coinbase L2, right? Um, and there isn't much details on this, but the idea is essentially you can have one bridge contract on layer 1 and all of the different L2s built on OP stack would use the same bridge contract and that essentially allows you to again teleport assets natively bridge assets from, for example, Optimism L2 to Coinbase L2.
There is a 7-day delay right now on that because of optimistic uh fraud proof design, but they are planning on moving to ZK in the future. Optimism and arbitum. So then it'll be anywhere from seconds to 30 minutes to do the same. And uh again there isn't much details on this but this is worth a mention because a single bridge contract and then a concept called shared sequencers uh could really solve bridging and security issues when going from L2 to L2 that is built on the same stack. So here's where we're at with our layer 2 multi-chain bridges.
Uh L2 third party bridges uh kind of fix reorgs and chain attacks. That's huge, right? That's truly one of the biggest problems of any bridge. So, it looks like it's only one dot, but it's actually a big change. Uh, native L2 roll-ups also solve weakest link problem because there aren't wrapped assets or LP loss in native bridging, right?
Um, and there's no fragmented liquidity or crosschain me possibilities again on the native bridge. There might be fragmented liquidity on layers, but that's a different thing. the bridging, right? Then with a recursive ZKL3 roll-ups, we essentially get trustless L3, L4, L5, L6 bridges that essentially beat by a long shot all of these other bridges. And you might notice we we haven't ticked these last two rows, right?
Bridge upgrades, smart contract bugs, prover or verifier bugs, right? So, how can we improve these? And here's some steps we can take to improve essentially all bridges to minimize trust in a project. So the first thing we should do is every single bridge including L2 or crosschain should have circuit breakers. So if over 10% of the uh bridg's assets are bridged out in one day, the bridge just freezes for that day.
And this allows the team and the project to take some time if there's a bug or a hack, they can essentially fix the bug. um before all the assets are drained. Then there is we should add for any bridge upgrades we should add delay periods because the problem is maybe you've been using a bridge for years and you love it then they upgrade it there's a security bug and everyone loses all their money that's what happened with Nomad bridge right and this is a problem because every bridge currently including L2 bridges including crosschain bridges even if they're not multi-IGs they use multisigs to upgrade the bridges right doesn't matter what category of bridge it is right. So we should put a delay period on upgrades to let users and LPS exit if they find a issue. for proofbased bridges.
Um, instead of just having one type of proof, for example, ZK, which I I specialize in ZK, it's essentially PhD level blackbox magic math, right? If that breaks, you could lose all the funds, right? So, the idea is you can actually use multiple approver systems. So you could have ZK and Intel SGX verifying the bridge transactions and a traditional multisay committee for example for freezing the bridge right and if two of three of them say that there's something wrong with the bridge and one of them broke you can freeze the bridge no one loses any money and Vitalic calls this concept multiprover plus governance uh tiebreak and then torul uh from scroll came up with this concept of multi-verifier so separate from the proofs. The proofs are verified on L1 via smart contract.
Maybe that verifier has some issues or bugs. So you could essentially implement that verifier in two different languages. For example, Solidity and Viper and then hopefully if one of them has an issue, the other one can freeze the bridge or stop the transactions. Um any rollup and proof based bridge should allow users to force transactions. So again, if you get censored or something's wrong, the user can force their own transaction through.
So you minimize the trust. Uh for any centralized assets like for example, USDC, Circle is already the only authority that can mint and burn USDC across chains, right? So we don't need to have wrapped versions of USDC. There's native versions. So Circle actually has this centralized bridge called crosschain transfer protocol and that allows you essentially to quote unquote trust Sisley.
um bridge assets between chains as long as you trust Circle in their nodes. Again, only works with centralized assets, though. So, here's where we're kind of at. We kind of fix bridge upgrades and smart contract bugs and proven verifier bugs, but honestly, not really. I'm being a little disingenuous if we if I say that um we fix those.
I'm a programmer. There's always always bugs in code, right? The only thing that tested is time x money. How much money is there and how long has it been around? So, we're never really going to fix those.
Time is the only thing that helps, but we still won't fix those. The point of this speech is all bridges suck. Just kidding. Okay. Well, they do kind of suck, but there there's always going to be essentially additional trust assumptions, especially in crosschain bridging.
Um, and it's going to be a long time before we fix these and really get trust minimized bridges. Uh for right now you should keep most of your assets on one chain in native assets but there are steps that we can take to improve bridging. Please practice safe bridging. Uh you can also watch the full version of this speech where I go much more into detail on all the different attack vectors as well as um some of the other benefits of L2s and Optimistic's new system. I haven't put it online yet.
Uh, follow me at ZK Lumi on Twitter and I'll get it online in the next week or two. Uh, we talked about ZK, Practal ZK today. Um, if you want to find out in a sort of mathless explanation of what ZK is, how it works, why you should be super excited, I have uh ZK 101 uh zero knowledge proofs and why should you care. Also, we talked about L2 uh L2s today. L2s have some additional security assumptions outside of the bridge that we didn't really have time to go into or really some of it is applicable to bridges, some of it isn't.
Uh I moderated a panel at ETH gathering called um L2 security with L2B scroll polygons EKVM and chain security. So you can watch that if you want to learn more about issues with L2s. And then finally check out L2 bridges or sorry L2 beats bridge risk analysis. It'll give you a much better idea of the risks that you're incurring while using uh a specific bridge that includes crosschain bridges or layer 2 bridges. And you can follow me on Twitter at ZK Lumi.
Thanks for all your um time, guys.
Automatic transcript — names and jargon may be misspelled.