Fast finality is essential for mass adoption

Transcript

Right. Hello. So, I am Ali. I am the chief product officer at Espresso and today I'm going to be talking about why fast finality is a requirement for mass adoption, but particularly institutional adoption because institutional adoption is quite the theme lately. Um but we'll we'll get into it. So, to start off with I kind of want to give the framing and this talk is a more kind of philosophical talk rather than perhaps a deeply technical talk, but the world itself completely disregarding chains runs on these sovereign systems and some examples are you know you have governments, you have companies, you have individuals and they each have these kind of weird dynamics between

them. So, for example, you have governments and governments interact with each other differently over history like over time. Um you know, companies can belong to multiple different governments. You have individuals, individuals belong to companies, they belong to governments, they belong to all of these different systems, but an individual itself is a system. And what this results in is that you have you fundamentally need to have trust between all of these systems in order to interact with between them. Uh but this trust is very ambiguous, it's ever-changing, and it's really complex.

Uh and it's very difficult to understand what's happening. Uh but we need to interoperate these systems and a lot of times in blockchain we talk about interoperability specifically in the form of bridging, but this is not unique to blockchain. Like interoperability is actually a problem that we have that has existed for a very long time. And the more efficiently we can interoperate between these systems, you know, the better that our world will work. And so, trust-minimized base layers are are most effective way to interoperate between all of these systems. And a base layer is not something that is unique to blockchain. A lot of the times we think of Ethereum as being, you know, the trust minimized base layer that we should all use, but

there's many other kinds of base layers that actually are not on chain at all. So, for example, you have certificate authorities. They are functionally very similar. You have someone that you trust at the top who is essentially operating as a base layer and the root of trust and then everything else falls down from there. You have CSDs. For example, like DGCC, Euroclear, Clearstream. These are off chain, but they operate as like this central root of trust so that you don't have to trust all of these individual counterparties.

And then, you know, you also have things like identity, right? You sign in to an account with your Gmail account or with your Apple ID. And the idea is that you only need to trust just that one core component and you don't need to trust all of this like complicated web of systems. So, what a trust minimized base layer does fundamentally is it simplifies this problem. So, it collapses all of these many bilateral trust assumptions into kind of one multi lateral trust assumption and this is much easier for us to reason about. And this is a pattern that we have seen completely disregarding blockchain. We have seen that this is a workable pattern in the world in order for us to kind of navigate

these very complex systems. And I'm going to argue in this talk that finality is like the primitive of all of this trust. And so, that is why we need to focus on fast finality specifically because it is the key primitive that enables this efficient interoperability. So, we have our favorite base layer, Ethereum. You know, Ethereum itself is kind of this root of trust for its layer twos and this model works very well, arguably. Layer twos can be highly customized. They can do a lot of their own thing and then they inherit this really strong security from Ethereum.

And when layer twos want to bridge or interoperate between each other, uh, you know, the most secure way to do it is to root that bridge in, you know, Ethereum finality itself. Uh, but Ethereum is not the only base layer. And it's not going to be the only base layer. So, for example, Espresso is also a base layer, but like I said, you also have base layers like, um, you know, these CSDs, things that are not associated with a blockchain whatsoever. And we kind of have this fundamental tension where we say, "Okay, we want to remove all of these trust assumptions." And so, the most ideal pattern would be if we have one single base layer that we can all agree on. But that's obviously not how the world works. So, for example, the world does not have a single government. The world does not

have a single body that governs all of the, you know, financial, um, activity across the entire world. You naturally have these different jurisdictions. And this is a kind of a good analogy to what's happening on chain. So, Ethereum is a wonderful base layer, but it's not going to be the only base layer and that's okay. What we want to do is kind of find a medium ground between having too many disparate systems, um, but also maintaining the sovereignty and the control that, you know, each one of these systems kind of needs. But we need interoperability between these systems and this is where finality comes in. And I'm going to argue in this talk that we need real-time interoperability, which means that we need real-time finality. And I don't think that this concept is new to

people. I don't think that's, you know, I don't think anybody out there would argue that, "No, Ethereum should actually have worse finality times." Um, I think everybody's fairly in agreement. But what I'm going to argue here is that it's actually a requirement for like massive institutional adoption rather than this kind of like nice-to-have. I think a lot of the times they're like, "Hey, well, you know, institutions are slow today. They have T+1 settlement. You know, Ethereum finality time is way better than than So, it's really not a requirement." And I think one, we shouldn't we shouldn't compromise. Having real-time finality really is the most optimal architecture to interoperate between all of these things.

And second of all, there's like very meaningful benefits and efficiency that you get from real-time finality. So, yeah, like I said, the future is that you have real-time finality. And I'm going to define real-time as essentially sub-second. I would say like 500 milliseconds is kind of a good benchmark of what real-time finality is. So, well, why do we have poor finality today? Not just among chains. Like I think a lot of people argue, "Actually, you don't have poor interoperability between between, you know, L2s and Ethereum today. You have things like solvers and um, you know, that give you very fast bridging. So, we don't." And I'm going to argue that that's not quite true.

But the reason that we have a lot of friction is because you have slow finality and slow proving times. So, as many people are aware, finality and proving times are not quite the same thing. They can be intertwined. Um, you know, but finality itself is the point where, you know, something is irreversible. And how you prove the state on top of that can come in a variety of different ways depending on your use case. So, for example, Ethereum comes to finality after 15 minutes. And that is where, you know, it is irreversible and anybody can deterministically derive the state. Now, if you run your own full node of Ethereum, you can deterministically derive that state immediately. So, you know, your proving time is essentially a few milliseconds, whatever it is to

execute that Ethereum block that you're following. If you do not want to run your full node, then maybe you need to wait on a ZK proof to be derived and that's going to take quite a bit longer. So, proving times are a big part of interoperability, but like finality is really the fundamental primitive. And so, I'd kind of put it in a pyramid where fast finality is the primitive and then proving times are kind of on top of that, but they're like use case dependent. Uh, but I think it's really interesting look at the structure of interoperability here because, you know, I talk about fast finality, but in today's landscape, proving time is actually the bottleneck. Like, I am all for Ethereum should get faster finality.

You know, Espresso has very fast finality, but finality time is actually not the bottleneck today at all. It's proof time. So, let's look at the structure of an interoperability, um, in a trustless way of an optimistic roll-up. I have these teeny tiny slivers to show the latency of like a sequencer inclusion. How long it takes for you to actually your data to Ethereum, how long it takes for Ethereum to come to finality, and then you have the time it takes to generate the fraud proof, which right now is 7 days. And that is just massively longer than anything else. So, I think the number one thing that you can do right now to improve interoperability, not only among Ethereum, but just in general, is you need to reduce the proof time.

And I think, you know, reducing it via like using a ZK proof or a multi-proof framework is quite good. Um, but then let's actually look at the interoperability of like traditional finance today. So, some things that aren't on chain whatsoever. And let's you have a small amount of So, this is kind of on a different scale than the previous one because the proof time is a lot smaller. So, you have, you know, the time it takes you to do a trade, maybe a few milliseconds. You have some kind of like post-trade accounting where you kind of take everything together. Um, but then you have this T T+1 settlement. So, T+1 settlement is essentially a proof. We often don't think about proofs in the terms of like traditional finance, but that is essentially what T plus one settlement is doing is you're waiting

for your funds to actually move. It's functioning like a proof. And that takes 1 day. Then we have a ZK roll-up. So, a ZK roll-up is a lot better. And so, now we're kind of seeing like, yeah, proof time is still the bottleneck, but maybe, you know, now finality time is kind of coming coming in there. Um, and then we have where you're using something like a TEE or just a full node. So, you run a full node, you trust yourself that you run a full node, um where you can execute a block instantly. And this is where finality time really does become the bottleneck. However, um obviously there's a lot of advancements in ZK proving where even the ZK proof model will eventually look like this.

Uh so, here's the thing. We have kind of this slow proving and we have this low uh finality. Um you know, not just on Ethereum. It's kind of like a meme at this point that Ethereum has low finality, but really like that's not the core fundamental issue. Uh but the reason but I'm going to argue here that the whole thing is like we're using uh these base layers to reduce our trust assumptions, but we're adding on all of these extra trust assumptions as band-aids because we need to like get around this, you know, slow proving time and slow finality. And I'm going to argue that solvers are in fact a band-aid. Um so, the the function of solving, like finding the best route, that's like a separate thing. But the idea that a solver is essentially fronting liquidity

to a user, essentially loaning, you know, the user um this and then, you know, money and then getting repaid later on, this is like fundamentally a band-aid. The actual optimal architecture is if you had true finality and that you could actually do native burning and minting across these chains. Like that is the optimal architecture and if you can do that in real time, you would not need to have solvers take on this risk that they do to essentially like lend out funds. And where this kind of fits into the institutional case is that when we talk about solvers a lot of the times we're like, "Okay, yeah, but the user doesn't have to inherit these um you know, this risk, so it's very ideal." But the thing

is the institutions, when we talk about bringing institutions on chain, like they're the essentially what would be the solvers, the liquidity providers. And uh they don't want to take this kind of risk. When you're talking about operating on the orders of magnitude of like the global traditional market system, uh you can't take on the kind of uh essentially counterparty risk that solvers take on. Um or if you did, you need to charge quite high for it and it makes markets operate like inefficiently. We don't see this inefficiency so much because realistically crypto is quite small. But if you're talking about, you know, moving trillions of dollars a day, um you need to have finality like as the backbone primitive that you're relying on for interoperability.

And so this is one of the reasons that institutions need they like they need to rely on finality. They cannot rely on something that is less than final. Even if that thing is like still pretty strong, you know, you could say, "Okay, like well, you know, this chain has never had a reorg more than X number of blocks." But I think the point is that finality is a very um it's in a way it's a like not well-defined, but it's something where you decide something is irreversible and that needs to be the basis of all of this interoperability.

Oops. So, uh let's say we had instant settlement and we had real-time finality. What this opens up is like way more capital efficiency. So, today, if we're you looking in the context of blockchain, um a lot of times solvers are not very capital efficient. They either have to lock their funds up in a you know, in the canonical bridge for these optimistic rollups for 7 days, um or you know, they find someone else to offset their trade. But fundamentally, someone is always paying the cost of the fact that there's very difficult to move native liquidity between chains.

And if you have real-time finality, you can literally have real-time capital mobility. And this is something that actually doesn't exist in traditional finance and it doesn't exist really today in blockchain, either, unless you're on a single chain. And the future, though, is that we can actually get real-time, and I really do mean real-time interoperability, real-time capable mo- capital mobility across these chains, so long as we're relying on the fundamental primitive of using finality um to root the trust of that uh interoperability.

So, fast finality is the optimal architecture. Like, that is the end game. Having real-time interoperability not only among Ethereum, but between all of these base layers. So, the thing is, we don't like yes, you course you want interoperability between Ethereum L2s, but you actually want interoperability in real time also with Solana, also with completely off-chain traditional financial systems. And in order to do that, you need to have like very strong roots of trust. And so, like this is the future. Like, the future is in fact not using these kind of like solving-style, intent-style lending.

The future is like rooting all of this in finality. So, a lot of the times, just to wrap up here, uh we talk about like, "Okay, but we reduce risk from users." But really what we're doing is we're taking that risk and removing it onto someone else who is more tolerant of taking that risk. And that's fine. That's how like, you know, finance works. Someone has to take risk at some point. Um but I'm going to argue that not only should we focus on reducing risk from these end users, which is often what we focus on, but we need to focus on reducing risk from these like infrastructure users, which would be the traditional financial institutions, the like the large liquidity providers. And reducing risk from those users is actually going to

give us the most market inefficien- efficiency and capital efficiency gains. And this is why um have relying on very real-time finality is like a requirement if we're really to realize this like massive market efficiency that all of traditional finance coming on chain can offer. All right. So, to quickly wrap up, uh you know, the future is many of these systems interoperating in real time. And finality is the root of that trust. And if you want to operate in real time, you need real-time finality. Not just on Ethereum, not just on Espresso, not just on Solana, but also within the traditional financial system. You need every system to have this concept of real-time finality so that you can operate between them. And we should not

compromise. We should not say, "Okay, it's okay to have, you know, slow finality here or slow finality there." Everything the like the we shouldn't compromise and the ideal architecture is using finality. It is not using any thing else. All right, thank you.