[trustless://interop.landscape] Workshop - Faster canonical bridges with multi-proofs

Transcript

Right on. So, hello everybody. It's uh rather distracting with all the sound. So, I'm going to look at you guys and if you have anything to say, put your hand up because I would like to make this as interactive as possible. I'm gonna talk about faster canonical bridges with multi-proofs. So the canonical bridge is the bridge that is the one that's enshrined in the rollup where the ETH goes to Ethereum through. Now >> there's a few things here. First of all, before we get started, um I'd kind of

like to get a sense of who's in the audience. Do we have anybody from from bridges or liquidity providers of any sort here? >> Awesome. Okay, you probably have some context to add at certain parts. I would love it if you have anything to add. Just put your hand up. We'll we'll get you a mic. Um, and do we have any folks from that are involved with proof systems or other of any sort, whether it's from other rollups or any types of uh bridges with other proofs.

Cool. Okay. And same thing for questions. So, we're going to try to make this as interactive as we can in spite of the format. I'll try to get you a microphone if you need it. Okay, cool. So, we're going to basically cover three big things. Why faster is better, what it actually means to speed up the proof and make it uh to make it faster. What are the parts of the proof that actually take the time? And what are the options to give faster proofs?

>> So why is faster better? >> The thing is most people just think well all right I use a cross I use some other fast bridge I don't use the chains canonical bridge and this is actually true. So you are not necessarily sending just ether tokens to L1. you're probably sending them to some other chain and most people use these types of bridges. So there's a bit of a misconception that the speed of the bridge doesn't really matter because nobody uses it. But actually um there are some issues with the bridges that people do use. So like mint and burn bridges end up trusting the issuer. So if you use circles CCTP

bridge for example like this is this is free. It's pretty fast. But this is there's an example of a different kind of trust assumptions. And the real thing is the liquidity liquidity providers they actually have to provide liquidity. So that has a cost. They have to rebalance from one chain to another. And the longer that takes them for them to move if there's like a net outflow from a certain chain, the longer it takes to do that, the uh the more that they have to have capital locked up and that has a cost. In the end, that cost gets passed on to the users of those bridges.

And so we want them to be able to withdraw more quickly because that just makes everything cheaper and better for end users even when those end users are not using the canonical bridge. Okay, so what does faster mean? So first of all, I want to get something out of the way. Withdrawal time is not the same as finality. This is a bit of a side topic, but just it's kind of a point of confusion. um the finality when you talk when we're talking about like say an optimistic rollup taking seven days it doesn't take seven days for the chain to finalize the finalized rollup chain is really first of all it's determined by the node

and that's so that's the source of truth if you have access to a node you query its API that is the canonical version of what is final and just so that you understand how that that ties back to Ethereum security that what's what the node considers to be canonical is what went basically roundtrip through Ethereum got finalized on Ethereum and uh the the L2 blocks were derived from the finalized Ethereum blocks. So in this in this chart here you can see on L1 the green blocks are are the finalized blocks. The L2 the blocks that were derived from the data in blobs in

the finalized L1 blocks are the finalized L2 blocks. Okay. Um so >> that means that the L2 node is is the actual source of what's finalized which is essentially not instant but it's quite fast right it doesn't it doesn't take days or even hours uh under most conditions um but the bridge also needs to be able to check the final state of the rollup the finalized state of the rollup the bridge is just a smart contract on L1 so the bridge cannot actually query a node because the smart contra can't really do that and that's what proof systems do. So the proof system

um lets the bridge >> know what the state of L1 is. Sorry of know what the state of the L2 is. >> Okay. Um >> so let's dig into what actually makes the withdrawal time. There's the time for the rollup to finalize, but we'll we'll kind of ignore that because that's that's not very long. There's the time for the proof to resolve and there's waiting time to make sure it resolved correctly. And we're going to dig into what those mean.

So proof resolution is the time until the bridge sees uh a final um it's the time until the roof see until the bridge sees um the outcome of the proof that it trusts. So that means different things for different proof types. For a dis for an optimistic dispute game, it means either the seven days has passed without a challenge or the challenge period the challenge occurred and then the whole dispute game was played and um in the case of optimism a step of the of the uh L2 chain derivation was performed on

chain. In the case of a ZK proof, it means that the proof was verified on chain. >> So these are the different types of proofs we have. So there's like the the interactive dispute game which is slow. There's ZK, there's TE. So the dispute game right now it's seven days. So what if we just speed that up? Now we could do that. Um, but there's uh L2B has some good guidelines and I think what what they what they started with is that it should

be seven days. Well, that's the current that's the current definition of stage one. So, the challenge period has to be seven days. Now, the reason why >> is because um in seven days if if there was a censorship attack on L1 and nobody could um nobody could play the dispute game to dispute an invalid output route, somebody could actually um finalize an invalid withdrawal. So, if you have enough money at stake on the L2 and you have enough capital to do a 51% attack on Ethereum, you could prevent

the L2 in theory from posting uh you could prevent anybody from playing the dispute game. So, they thought, okay, well, what would be the solution to that? It would be a hard fork and that could take a week. I think there's all kinds of things that that you could debate about the realities of that, but anyway, that's where that's where we are today. That's kind of the part of the baked into the definition of stage one. Um, now recently this uh VBerin guy posted on Ethereum magicians that maybe it's okay to allow stage one rollups a

shorter withdrawal window. So, let's dig into that. Um, >> now you could have, by the way, >> if you have questions, I want to just say again, just jump in, put up your hand if you have anything to add. So, >> okay, we have um we have some options here. What what if we had one to two days of the dispute game and then we had an option where a security member security council member could just flip a switch and extend it to seven days in in the case of some kind of censorship attack.

That's that's a suggestion. Um so I think this is a good suggestion. I think it would help and this would allow the happy case to resolve quickly. say one day if nobody challenges it or if there's if there's no um >> well it's not if nobody challenges it it's it's if if nothing unusual was happening in terms of censorship on L1 and no security council member decided to uh to flip the switch. Um this is actually not an issue for optimistic ZK because um if you have no proof generated it's going to resolve um it's it's just going

to be a livveness failure. So this is mostly not an issue. It's an issue if you have to challenge um but it's not an issue for generating proofs. You don't need you don't need to worry about having a long period of time to generate proofs. Okay. Um looking at the time, there's a bit more we can dig into there, but I'm going to I'm going to move past it. So that's that's the dispute game, the interactive dispute game, but there's better options. There's fast proof types, right? So we have ZK. ZK is fast.

ZK can be decentralized easily. That's pretty much all there is to say about it. So that's actually a great choice for speeding up this part of the proof process. There's also tees. That's another option. Um very fast and cheap, but it cannot be decentralized easily. So for a single proof type, this is a bit problematic. Uh I mean it might actually be suitable in in some cases for some chains but I think as a general case it's it's not not a good suggestion on its own. The reason why it can't be decentralized easily is because you have these physical attacks. So you have to trust the operator. I think this is fairly wellnown but this is a bit of res uh some some links to follow up on if

you're interested. Um there's also chain of trust attacks because they use a search chain, a certificate chain like TLS. So the same sort of issues that you have with uh with with TLS. Um this doesn't mean the TES are bad. It's just you have to know what your threat model is and it's they have some uses. They do give you more ver verifiability of some centralized infrastructure. So I think for any of the centralized infrastructure that chain operators are running it it is actually good to have those inside a TE because if it's done right you can actually be confident that they ran the

exact version of the software that you're able to audit or or look at. the attestation can commit to uh like a specific hash for a boot disk image or whatever and you can actually verify all of that. Um it gives more protection for the operator as well. So for example, against your proposer's key leaking, which also may not matter in a permissionless situation, but this is just uh just like depending on how you're set up. This is an interesting benefit.

And one other thing about it is that you can actually use your TE in a stateful way. Nobody actually does this right now. Um, and most people uh don't like the idea, but it is just something to think about. You can just run a node inside a TE and have a a smaller diff between what's uh between like okay so your node is the source of truth. Your proof system is supposed to represent the node as well as it can. But the proof systems have a little bit of extra infrastructure to become stateful. a little bit of extra code that's written that's more surface area for bugs. So there there is maybe

the idea that you could run just literally run a node with some state inside the TE. Um it's kind of a little bit awkward for a lot of reasons. So I'm not sure if it's a good idea, but it's it's a possibility. You need to verify your L1 inputs, for example. So it would be uh I mean I suppose the naive way is you run an L1 node inside it but that's kind of terrible. Maybe you verify your L1 inputs as part of verifying the outputs. But anyway, do we have any TE people in the room?

>> We do. Okay. If you have opinions or thoughts on this, >> I can let's let's get you a mic. >> Do you have anything to say? Yeah, you look like you have something to say. So, >> hello everyone. Uh, I'm using >> I cannot hear you. It could be me. Does anyone else here? >> Is Oh, okay. It's probably my >> Oh, because my sound is off. >> Oh, now it's not working.

>> Okay, try again. >> Hello. Can hear me? Okay, >> maybe the battery is dead on this thing. >> Okay, now it's working. >> Hey, uh I'm Yoshin from Automata. Uh I have been working on these uh for years. I think uh T has a good point uh good has advantage and disadvant disadvantage. The advantage is that T is ready to market. Uh it is um compared to ZK um it is kind of easy to use and you can just get the TE from the cloud providers and just uh put put your especially uh we are talking about the

VMTS you can simply uh put uh your workload into the TE's without any modifications and then you get the proof and everything is easy and in this case T uh kind of uh because uh it used the uh hardware to do the end toend encryptions and this kind of encryption protect the workload confidentiality and integrity at runtime. Uh in this case uh u um we would I would say uh no one can easily attach or modify uh the workload running in the TE's. Uh however uh T uh from the from the other side T is very complex uh is super super complex. It

has uh many layers uh from the uh because uh uh take the AMD SEMP example uh all the all the all the T all the S&P T is uh is managed by the firmware and firmware is nowadays closed sourced. We cannot easily verify the t uh uh we cannot easily verify the frameware and uh it has it may has a lot of bugs. uh we don't know that's why we lot a lot of uh security people can launch the uh set channel uh set channel attacks but uh uh since we already find a lot of um bugs in the firmware and we already submit

the patches in this case uh we already I would say uh we already we already raised the bar for the attackers to attack the tees that's why uh I think te is a good solution uh for the multipural system although uh there might still box but I think the bar is higher and higher for the attackers. >> Yeah, >> thank you. >> Thanks. And I I should say that autonom has a framework that they've built for OP stack chains that that verify with with the TE.

Okay, >> so those are the options for speeding up the first part of your proof time. Now you have a fast proof, it resolves quickly. Now we need to reduce the second part of the withdrawal time. So most uh blockchains have a waiting period after the proof resolves. So this is after the proof is verified in the case of ZK. Um, the reason why is because we don't trust the proof system. So, every proof system probably has a bug whether it's been found or not. It's just a matter of of uh time until somebody finds it.

If that happens, then we need to be able to react. And right now, stage one roll-ups have a security council that can intervene in in exceptional cases. So if there was an invalid output route finalized then you need some time to be able to react. You have some monitoring and time to react to that. This is uh in in the OP stack it's called the proof maturity delay sometimes called the air gap. I think ZK sync calls it the time lock. These times vary but they're at least a few hours typically.

Um, so in order to reduce that, you just need to trust the proof bar. How can we do that? Well, there's a few ways. You could in theory have a trusted proposer with a fast lane, right? So, this doesn't necessarily reduce the um decentralization. It just means that in the average case uh the norm in the normal case if the rollup operator is proposing with a trusted proposer then it's fast. Um and then if other people are are proposing permissionlessly it would be a bit slower. This is obviously

not ideal. It's just it's it's an option. Um, you could potentially do that in in a in a TE, but kind of a similar more general way of doing that is just add more proof types. So, this is what we mean by multi-roofs. So, you're going to have to verify two different proofs in order to to uh to allow the withdrawal to proceed. There's another option as well which is not really available to existing roll-ups without a lot of modifications but just to put it on your radar there's this native rollups project there's um in the future there will be an execute pre-ompile which essentially allows you

to run the state transition on L1 exactly the same way that L1 would do it which means that it's bug free bugree means that if there is a bug, it's a bug in Ethereum itself and presumably that would be fixed somehow by forking Ethereum or whatever the solution is. But it's the same role, it's the same bug in uh Ethereum that would exist in in the L2. So that's a future option that looks pretty interesting. Oh, and if you uh yeah, we'll actually have a link for that later for some more info.

Okay. You could add a second ZK proof. >> Yeah. Let me grab a mic. >> Thanks. Yeah. I mean, for for the native execute pre-ompile, it's uh still pretty unclear how you actually provide the necessary witness data for that to work, right? Like when the data could be >> lost your sound. Sorry, one moment. It's back. Yeah. Okay. So, it's all about the witness data that would be necessary for the pre-ompile to make sense. Like it could be several megabytes, you know, example, for example, for base blocks that could be huge over 20 megabytes or so, right? That data is probably not

going to be available on chain anytime soon. >> Yeah, I I I don't think it's a viable option for existing chains right now. I'm just just throwing it in there as like, you know, I um potential future path to how could we theoretically trust the proof more? >> Do you do you know if they if it also if native rollups also propose like a standard derivation pipeline or something equivalent? >> I'm not sure. I think it would need to be pluggable in some way because each rollup has some, as you well know, have some custom things that they do. So, yeah, I'm not sure. There's um there's a link later on in the slides for the uh

the uh L2 beats native rollup book. >> Okay. Um Okay. So, you could add a second ZK proof. So, we're going through the list of things you could add as your second proof. It could be ZK. Um, this is a great option because it's decentralized. It is more expensive. Um, it could potentially be a optimistic ZK proof which which we can talk about the hybrid thing later if we have if we have questions or we actually we have an expert on that here.

Um, one question you might ask is, is it diverse enough? So, if there's a bug in one of your ZK proof systems, does it share enough with the other one that they have that they both have the same bug? Okay, you could add a TE and we've sort of talked about the benefits and disadvantages. Can't be central decentralized really. um the stateful thing we've we've talked about and verifying it on chain as well is potentially more complicated.

The folks at Automa have done some great work on this and I think if we we've only got six minutes, but maybe if we get into more they can they can talk about that. >> Um okay. Um actually we will mention one more thing. No we'll skip through it. Let's let's get to let's get to the proposal from Vitalik. So this is something that he posted earlier this year which is basically two of three between optimistic ZK and TE based provers. And I'm wondering if anybody has questions or any comments on that because I think there's a whole lot

of there's a whole lot of things that you can dig into there. Um why specifically those three? Does optimistic belong in there? Is two of two okay? Um does anyone have any thoughts or questions on that? >> Yes. So my question is uh so uh for this uh fast fin uh finalization uh currently we have uh we have three different options the op zk and ts. So uh as you mentioned

the OP has 7 days uh dispute but ZK and TE has uh kind of uh they generate the proof very fast. I I just kind of curious how how does the OP work with the the TE's. >> So I think the idea is that because it's two of three if you have two fast options that agree then you don't need to wait for the optimistic dispute game and it could just go ahead. However, if there's a disagreement, then you you still have two trustless options that that can also potentially agree even though it takes longer.

>> So, it it it's helpful for for getting to stage two. And then the other I could take that the other um the other consideration is with um with stage with stage two. I think the basically the main definition is if the proof systems disagree on chain, then you can still have a security council that can adjudicate. But it's obviously better if you can have trustless systems that can that can do it without anyone intervening.

Um, we mentioned native rollups and there's the the outbeat native rollups book URL to take a look. >> Okay, we're just about at time that that is all that I had. Just to summarize, we want faster withdrawals because it makes all of the decentralized bridges cheaper and better options for users. It's not because they necessarily need to use the canonical bridge. And to do that, we need two things. We need faster proofs.

That's the easy part. And then we need more trust in the proof itself. And that's the part that is a little more tricky. And that multi-roofs achieves. >> Thanks. Um, do we have questions or comments? Yes. Let me bring you a mic or you do you want to come up? I'll bring the mic to you. Maybe just one question um like what's the priority for the optimism proof team right now because you mentioned so many options I just would like to know like in the near term maybe three to six months what's the priority for your team right now thanks

>> well I I can't give you any any like product announcements or anything but I mean we're definitely interested in fast withdrawals >> so and working opt working iteratively is important. So I think whatever we do it will be in stages it will be done safely and um heading towards a multi-proof future. Um any other questions? We've got a minute left. >> Yes sir. Actually uh I have one comment uh regarding the

uh TE onchain verifications. Yeah. >> So uh um as you mentioned uh for verifying the native um TE proof onchain is very expensive uh because the the TE proof itself has u is very complex. you need to verify the signature, the certificate chain and everything. Uh so that that will cost like um millions of gas uh uh to uh to to decrease the gas fee. Uh React Automata has um uh proposed the ZK based uh approach uh to verify the attestation report. Basically we offload the TE attestation uh report verification to

the ZQVM. uh we we use the ZK we we use the attestation verifier uh in the uh ZK VM to verify the proof and generates the ZK proof and then we uh send this DK proof on chain and it only cost like uh 10,000 uh gas. >> Cool. That's awesome. Um, I'm I'm wondering, do you have any Yeah, I I've seen that there's um Tik Tok actually has an open source uh tool to do this for AMD. Have you Have you seen that?

>> Yeah. >> Cool. So, one thing that I would worry a little bit about is proof diversity. So, if if you're if your ZK If your ZK proof has a bug and your second proof is a TE, but if it relies on the same ZK, that that might be a problem perhaps, but that might be harder to exploit. So, depends on how decentralized it is. Yeah, that's very cool. Okay, >> we're at time. Thank you everybody.