How fast is fast finality?

Transcript

All right. Hello. I am Ali. I am the Chief Product Officer at Espresso. And today I'm going to be talking about finality. Um this is kind of more of almost like a philosophical talk about finality and what it means. Um and kind of just diving into like a really abstract concept of, you know, what are these edge cases of finality and kind of like how do we think about it? Because ultimately finality is actually very subjective concept and we're often like, "Oh, we need faster finality, you know, oh multi-sigs are bad and we need to wait for full finality." Uh but in this talk I kind of want to think about that more abstractly.

Um so, yeah. Let's go in. So, first I want to start off by defining a confirmation. And this is just, you know, you're declaring the state of some system given some set of trust assumptions. And confirmations are the fundamental primitive that pretty much everything is based off of. Not only on chain, but just anywhere in the world has some sort of form of confirmation. So, like this is a very abstract concept. So, whenever you you want to do something, you get a confirmation and then you do something based on that confirmation. Obviously on chain, this is something like a bridge, you know, you see that someone deposited funds into the bridge and then you go and mint them on another chain.

But this can obviously exist outside of the world as well. When you are scheduling to go meet with your friends, for example, you get a confirmation of the time and then you go somewhere. You don't, you know, go somewhere before you know where you're going to meet. Um but there's many different kinds of confirmations and they all have very different sets of trust assumptions and so here's a few. And so, obviously you have something like Ethereum finality and you know the trust assumption. It's like, "Okay, um no greater than 2/3 of this or sorry, no greater than 1/3 of the stake is dishonest and you're also going to assume there's no social social forking." But this is like a very kind of well-understood confirmation. You have an L2 sequencer confirmation, which um if you choose to trust, you're assuming that the sequencer is not going

to equivocate and that they're not going to go offline or censor you. Um you know, that would then trigger something like force inclusion. Um there's also like, you know, in the off-chain world, you know, there's like traditional financial settlement. And this is uh when um you know, you're actually moving funds between these banks. And this assumes, you know, that you're basically these large institutions aren't going to collapse. Uh you know, so for example, settlement in traditional finance um could could break if something like the DTCC just all of a sudden lost all of their databases.

But I want to go with one of mempool inclusion because mempool inclusion is something we often don't think about as a confirmation, but I think it illustrates how you can take this concept very abstractly. So, the fact that your transaction shows up in the mempool in Ethereum is like a very weak confirmation, obviously, right? Like there's really not a very good guarantee it will be executed. But if you do recall several years ago, this is how you used to interact with Ethereum or like this is how I used to interact with Ethereum um because, you know, you would set your fee and it wouldn't necessarily get included in the next block. So, you'd be like, "All right, I'm going to walk, you know, as long as I see it's in the mempool, I'm going to assume that it'll eventually be included." And the point of this is that a mempool inclusion is

arguably a very poor confirmation, but it is a confirmation based on some trust assumption. Like you can assume that if some validator includes your transaction, that that is actually final and will not be reverted, even though it's very weak. And a lot of the times we like to order these trust assumptions along a spectrum. We like to say, "Ethereum finality is fundamentally more secure than an L2 sequencer confirmation." And I'm going to argue that that's not the case. These are actually very difficult to compare. A lot of times there is some sort of social consensus on the spectrum of trust assumptions. So, I think you'd be hard to find someone who would say, "Mempool inclusion is actually a stronger confirmation than Ethereum

finality." Like I would be interested to find the person who thinks that. But I would argue that like they actually are fundamentally incomparable because they rely on different assumptions. So, for example, you can imagine that all of us here think Ethereum finality is incredibly secure. But you could imagine potentially some sort of like large US governmental agency actually trusts traditional financial settlement more than Ethereum finality. But we trust Ethereum finality more than traditional financial settlement. You could also imagine the case where you do actually trust the L2 sequencer confirmation more than you trust Ethereum finality.

And I know that kind of seems kind of weird, right? But but the you could say, "Okay, what if this L2 sequencer is run by a very, you know, well-known product or well-known project and let's say Ethereum has some sort of social fork. Like the DAO happens. Maybe you trust that the L2 sequencer is going to follow a certain fork no matter what." An example of this would be like USDC. So, um let's say Ethereum something terrible happens, there's like another form of the DAO hack and um you know, there's a fork. You might trust that a sequencer confirmation based cuz you know that they're going to follow the fork that USDC follows.

So, this is kind of an example where like these these confirmations and the trust assumptions are like they are not apples to apples and this is like the abstract way of thinking about it. Um but the problem with this, of course, is that like all of these trust assumptions are so complicated. Like um you know, often times you say, "Oh, Ethereum finality." Which, you know, I'm using Ethereum finality cuz that's kind of like the base trust assumption everybody has. Um you're not just trusting, as I showed on the previous slide, you're not just trusting like that there's 2/3 honest stake. You're also trusting social consensus.

And we often don't think about that, but like it's very true in all of these. So, then it kind of begs the question, how do you define finality? And I would argue defining finality is kind of a lot of times not really a very useful exercise, but I'm going to do it anyway. And I would say finality is the confirmation that you treat as risk-free. So, you treat the trust assumptions as risk-free and you do not price them in. So, um if we go back to this example, why do we treat Ethereum finality as risk-free?

Why do we call it finality? It's because we assume that um there will always be, you know, 2/3 honest stake and we don't need to account for that risk. Like we don't add any sort of um like extra, you know, fees or anything like that. But you could imagine like that isn't always the case. But we treat it as risk-free. And this gets into another thing, which is, "Okay, well, what is the nature of a confirmation?" And a lot of times, you know, we talk about how when an L2 post data to Ethereum, that's when an Ethereum finalizes that data. That is when the L2 is finalized. And for a long time I was, you know, I was in that boat

as well and I've actually quite recently changed my opinion that um finality ultimately does include proof execution. The reason that we treat L2s as final once they post data finalized on Ethereum, even if they have not posted a ZK proof or a, you know, the fraud proof has not elapsed, is because we treat the proof system as risk-free. The proof system is itself like comes with many trust assumptions, but we treat it as risk-free, which is why we treat um just data being finalized as finality.

And so if a confirmation is ultimately and finality is ultimately about proving some sort of execution, then why do we have, you know, all of these other steps? Well, the reason is because you can kind of have this like branching off based on your trust assumptions. So, for example, if you kind of only trust this inclusion phase and you can treat the rest of this as risk-free, then you can trust an an L2 sequencer confirmation as final. And so, you can branch off. So, like this is kind of why we have the structure of these confirmations today.

And generally speaking, we have decided that this is like the social consensus of the risk-free boundary. And that's not always the case, but this is what you see in the L2s in Ethereum is that you need to come to consensus on the data, but we assume once you do that that the data will be deterministically executed and so we don't need to care about execu- like the execution proof part um as part of finality. Uh but again, like there's there are trust assumptions in the provers. And I think that that's a very reasonable trust assumption to make. Like this is a very reasonable risk boundary to make.

Um but it's like fundamentally there are trust assumptions in there. So, okay. So, we have all of these trust assumptions and it's kind of an absolute mess. And this is often when you talk about interop between L2s and L chains and all of these different chains, uh the issue that you come up with is like these trust assumptions create this web that is just absolutely unmanageable. Um so, when you look at a lot of uh the bridges, for example, between chains, a lot of them are multi-sigs. And um you know, a multi-sig is just a trust assumption. A multi-sig is a form of a proof. So, when we talk about a proof, it doesn't need to be a ZK proof or an a fraud proof. It's just something that we

trust to prove the state. But the issue with a lot of these multi-sigs and like this isn't getting into the issue of like this talk isn't about why we shouldn't use multi-sigs. The issue is that each of these multi-sigs has different trust assumptions. So, you have chain A, chain B, and chain C. And to bridge between chain A and B, you have to trust one multi-sig set of operators. But then to bridge between chain B and C, there's a different set. And then C to A is a completely different set. And now you have this like exponentially growing web of these trust assumptions that's like impossible for us to understand. And that's really not very good.

So, we kind of come along this design of these trust to minimize base layers, and it collapses all of these trust relationships into like a few trust relationships that we can understand and that are very strong. So, for example, I might be totally fine using a multi-sig bridge to, you know, bridge some token that like isn't worth a lot, but that doesn't mean that the party on the other side is. And so, instead of having to constantly negotiate trust assumptions, we just say, "Hey, we'll just use like something that's very strong and covers all of our bases." So, this is what Ethereum is. Like, this is what Espresso is. It's like these trust minimize base layers that just simplify this web.

Um so, okay. So, we've kind of talked like abstractly about what is finality, but I don't want to get into why fast finality matters. So, of course, fast finality matters. Everybody's always like, "Oh, Ethereum has such slow finality." Um but I kind of want to go into like why you actually want real-time finality and maybe why in a lot of cases it actually doesn't matter to get real-time finality. Um because real-time finality is incredibly important for like capital mobility specifically. I think that's the biggest use case. Uh but there's other other things where like arguably 15 minutes on Ethereum is probably perfectly fine.

But I would make an analogy to kind of this like pipe, which is um you can imagine like liquidity flowing through this pipe, and your trust assumptions are the outside of the pipe. And so, if you have very little capital throwing flowing through your system, so like this would be for example um very small capital flowing between like two different chains, you know, your trust assumptions are probably fine. They're They don't carry a lot of risk. But when you start putting a lot more capital through, then all of a sudden, uh you know, your trust assumptions can break, and it's a mess. Or rather, if your trust assumptions break, it's like very, very bad. And this is kind of the fundamental reason why you want to use something that's highly

secure for a mint and burn bridge. So, um obviously there are many mint and burn bridges that use multi-sigs, unfortunately, but this is why all like so many L2s and so many of the largest L2s that have tons of capital on them only use Ethereum and like the fraud proof mechanism for their canonical mint and burn bridge. Because what you need is like a strong set of Well, I guess you could say you need to have strong finality, which means you have very few trust assumptions or weaker It depends on how you define it, but um something like Ethereum finality or true BFT consensus finality to like hold you in. And I think that this is not a new concept.

Okay. So, faster finality though equals more capital mobility. And the specific thing about this is because you do mint and burn bridging. So, um the way to get true capital mobility is to like actually be able to, quote, physically I guess it's not physical, but physically move your capital from one place to another. When you think about the traditional financial system, when they settle, they're Well, they're also not physically moving their capital, but they're essentially moving it from one place to another. And the more capital mobility you have across all of these chains in the ecosystem, the more capital efficiency that you have. So, for example, I think sometimes it's good to make analogies to traditional finance.

When traditional finance uh it used to take 3 days to settle something, and then it went to 2 days, and now it's 1 day. And when it went from 2 days to 1 day, they actually saw a 30% incre- or decre- or um [clears throat] a 30% increase in uh capital efficiency, basically, because you had so much capital that did not have to sit around. And actually, I'd argue that today, you know, we think about the tra- traditional financial system being like terrible and on-chain is so much better. Today, we arguably have worse capital mobility on-chain than you do in the traditional financial system uh because most rollups in Ethereum are optimistic rollups, and it takes 7 days to move your capital.

So, this is actually quite a huge problem. So, faster finality, more interoperability. Um So, I guess I was going to go through like a quick example to kind of sh- showcase this. Um This can be super quick, but the idea is like, all right, let's say you have some sort of like collateral chain, and you have some asset chain, and you know, you want to you need to like access this asset on the other chain, um and you know, then you need to kind of like pledge pledge it back. Uh this could essentially be the same thing as like, you know, you need to take out You want to Essentially, what this is is you need to access liquidity on a different chain.

And of course, you're only going to use some notion of finality for this, which I'll get into why. But the thing is like all of this is like this huge risk that you take. So, going back to this idea that finality is risk-free um uh but this is a kind of a different risk, but it's like you have all of this time here. And so, if you have faster finality, you reduce your risk. And that's incredibly important when you have like huge amounts of capital flow going through the system. Um but Okay, so here I kind of have this diagram, and you have slow finality, fast finality, or sorry, slow confirmation, fast confirmation, weak confirmation, strong confirmation. And obviously, these are kind of uh

arbitrary buckets. But this is where I'm going to kind of make a comment specifically about some of the other interoperability solutions, specifically solvers. Um So, when you have weak confirmations, this is like fundamentally the reason we have solvers. And a lot of the times we think interop is solved between chains because you have solvers who front liquidity on one chain, and you know, um they get paid back on the other chain. That is actually not a solution to interoperability. I mean, it is it is, but really what it is is a band-aid over the fact that you have slow finality and slow proving times. Like that's fundamentally what it is.

And solvers are fundamentally They actually do not improve capital mobility because they are just, you know, taking funds um on a chain. Like they are fronting you funds that already exist on that chain, but they are constrained by liquidity. So, there have been many examples for um in which, you know, you have a ton of demand on one chain to buy like some NFT, for example, and solvers all of their liquidity dries up, and they can no longer serve users. So, solvers are a very good solution, and I also want to separate the solving aspect from the actual liquidity providing. So, um solvers actually perform two functions.

One is solving, and one is providing liquidity. Solving is a separate I'm mostly talking about providing liquidity. Um But yeah, so solvers are like a band-aid solution over this, and what you actually want is real-time finality so you can do native mint and burn bridging between all of these chains. That is the most optimal solution and um unlocks the most capital mobility. And this is the solution that we should aim for. Um I think sometimes uh we don't realize the cost that we are paying. So, even in the solver case, you say, "Okay, well, solvers have to wait 7 days to rebalance through the canonical bridge of L2s."

And you say, "No, they don't. They just like rebalance through a centralized exchange, or they rebalance, you know, they go to someone else, and they rebalance." And that is how it works in practice. But ultimately, someone is paying the cost of not being able to move their capital across these chains. Usually, it ends up then being the centralized exchange, and they are then charging fees, you know, to account for the fact that they can't move that capital. And this is it is not the most optimal system. It like fundamentally, I think that we know that. And so, we should move towards a system that has real-time finality so you can get real-time capital mobility.

And um this is the same for the traditional financial system as well. Uh so, anyway, kind of this top part is you have strong strong confirmation. This would be like finality. Um and then you also have fast, and they basically do get real-time interop. So, we always talk about liquidity fragmentation and all of the, you know, what all of this junk between chains. And the only way you can truly fix that is you need real-time finality. And like that should be our goal. So, okay. I only have like 2 minutes left. So, I briefly want to comment, I suppose, on uh synchronous composability cuz this kind of sits outside of the box, and there's a lot that could be said about synchronous composability.

And you say, "Okay, well, actually synchronous composability solves all of this. Like you actually don't need real-time finality if you have synchronous composability because they both compose in real time." And so, okay, maybe we should just our goal should just be to have synchronous composability. And what I'm going to argue is that uh that is very nice in theory. Like the actual most optimal solution for all of this would just be that everything runs on Ethereum. Not on Ethereum L2s, just literally on the Ethereum L1. Like that would be the most optimal outcome. But that is fundamentally unrealistic. And, you know, even if Ethereum scaled massively, like just we see in the world, nothing runs on a single system.

There's not one single financial system. And a lot of that's not only due to scale, but it's due to the need for sovereignty and control, right? There's not one single financial system that all of the countries in the world use, for example. So, I'm going to argue that synchronous composability is like a very good theoretical solution, but it is it's impractical. And this is why the optimal solution is real-time finality because if we can get synchronous composability between a few chains, that is great, but you are not going to get synchronous composability across all chains because that is equivalent of having all chains essentially run on the same system.

Um and then the final thing I want to point out though is that I will admit you get diminishing returns the faster finality you get. So, for example, going from a 7-day canonical bridge to a 1-hour ZK proof gives you massive liquidity improvements. And like I would argue that the biggest thing that we can do today is to get rid of fraud proofs and move towards like a multi-proof system of like ZK TE proofs or something like that. That is the largest thing that we can do. Like when you actually look at it, you know, we all talk about how Ethereum has this really slow finality, but that that that's not the bottleneck at all.

The bottleneck is on the proving time. But um once we get there like your your returns get smaller. So going from 15 minutes finality to 1 second finality gives you a ton of like improvement, but it's not as much as going from 7 days to 15 minutes. Um okay. Anyway, just to very I guess very quickly kind of wrap up this like philosophical kind of talk is that like finality is very subjective, but I'm going to define it as like finality is the set of trust assumptions that you treat as risk-free. So this is like you assume that your prover is doesn't have bugs in it. You assume that the proof like your ZK proof is going to produce the same output as a full node.

Fast finality is a key for like greater capital mobility and efficiency and having real-time finality like is the most optimal solution. The question is just can we get there in practice, which I think it's completely possible using a variety of different solutions. Um you know, either Ethereum or other other solutions, but like that it's fundamentally the most optimal architecture. Uh solvers are great, but they are fundamentally band-aids over the problem of having slow finality. And actually a more optimal solution would be real-time finality with mint and burn bridging for everything.

Um and I'm also going to argue that the more capital you have flowing through your system, like you need stronger finality. So that this is why we can't rely on something like an L2 sequencer confirmation from mint and burn bridge because at a certain level like that is just the risk it doesn't work out. Um so anyway, the optimal solution is that we need real-time secure finality. Obviously Espresso offers that, uh but obviously there's also a pathway to doing that on Ethereum as well. Um but I think the whole point of this talk is that real-time finality, which I'm going to define as sub-second finality um is pretty much like the key to the most optimal market structure that we want. Okay. Thank you.

>> [applause]