# The Case for Fast Finality | Ellie Davidson - Espresso Systems - Channel: [Ethereum Denver](https://streameth.org/ethereum-denver) - Date: 2026-03-09 - Duration: 13:41 - Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum - Watch: https://streameth.org/watch/yt-b-Sh6Fm27Kg - YouTube: https://www.youtube.com/watch?v=b-Sh6Fm27Kg ## Description πŸš€ Get Ready for ETHDenver 2026! πŸš€ We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2026β€”it’s going to be epic! 🌟 ## Transcript All right, guys. Moving right along. We have Ellie from Espresso here to talk about fast finality. Take it away. >> Thank you. Um, all right. Yeah, let's jump into it. So, I'm Ellie. I am head of R&D at Espresso and I'll talk a little bit more about Espresso today, but we're also going to be talking about fast finality in general and specifically on Ethereum. So, I'm going to start out with faster consensus protocols aren't enough. I myself am very interested in consensus protocols, but um and there's a lot of research being done. So, for example, Salana came out and they have Alpenlow. They're claiming that they're going to be able to get finality in less than 300 milliseconds. Um there is minimum wear and they claim they're able to get finality in less than 300 milliseconds. So there's a lot of focus on making consensus protocols faster. But that's important. But what I'm going to argue here is that that's not enough and there's actually other bottlenecks that we need to focus on first um alongside making our consensus protocols faster. So just to give us context into what we're doing here, like why do we want fast finality? And the reason is because the world runs on these sovereign systems. And the point I want to make here is that this isn't about you know chains having fast finality. This is the entire world both onchain and offchain are essentially systems and you know you have governments you have companies and you have individuals and they all have very complex relationships between people between these systems. So companies can belong to multiple governments for example at the same time. Individuals can belong to multiple governments at the same time. Individuals are kind of part of a company. They're part of the company system, but they're also part of the government system. And the point of this is that this is an abstract view of what we're trying to do um by creating blockchains. And like I said, all of these systems have these really complex, ambiguous, bilateral trust relationships. and they're not like operationally they're a pain to manage but they introduce a lot of risk. And so what we want to do is we want to navigate and interoperate between all of these systems as efficiently as possible. Efficiently usually means as fast as possible and trust minimized base layers like Ethereum or Espresso are the most effective way to do this. Um and so uh base layers are not a new concept in blockchain. So you can think of certificate authorities. Certificate authorities are essentially trust minimized base layers. We've decided that hey instead of having all of these bilateral trust agreements that you can't keep track of, you you decide you're going to trust kind of one base layer and then everybody else can um roll up to that root of trust. So we have Ethereum and we have Ethereum and its various L2s. But what we're actually going to see and what we already see in the future is that Ethereum is not the only base layer that exists. Um, so even though these all have the Ethereum logo, you know, we have Ethereum, we have the Salana ecosystem, we have, you know, Tempo. Um, and then we also have things that are completely offchain. So like traditional finance is its own ecosystem. You can imagine that the DTCC, you know, before they become come on chain is its own ecosystem of all of these trust relationships. And what we're trying to do is interoperate between all of them. So how do we do that? Well, the fundamental component of interoperability is a confirmation. And a lot of times a confirmation is essentially what we call finality. But I'm going to say for the sake of this talk, I'm going to define it a little bit different because finality is going to be something very specific. But a confirmation is just a declaration of the state of some system given some set of trust assumptions. And the key point here is that everything is always based on some set of trust assumptions. There is not philosophically a correct set of trust assumptions. A lot of the times we like to assume that Ethereum always has the correct set of trust assumptions. Um and Ethereum has very good trust assumptions, but that doesn't mean that every single system needs to use those same trust assumptions. Um, but we want to minimize the trust assumptions because that helps us minimize risk and ambiguity between all of these things that we want to connect with. And obviously today systems take more risk than they need to um in order to interoperate because that's how they interoperate quickly. So sometimes we approach this from the wrong angle. We say we want to build trust minimized systems. So we build that and then we figure out how to make them fast. But the way the world actually works is that they require speed and then you have to figure out how to shoehorn trust minimization in afterwards. And this is why today we see things um like a lot of multi-IG bridges. Multi-IG bridges are not very trust minimized um but they are prolific. Uh we also see things like Ethereum uh finality. So a lot of people like to say how oh Ethereum finality is 15 minutes. So that's technically true, but if you ask the vast majority of people of projects, etc., they do not wait for full Ethereum finality. There are use cases that do. For example, you know, Circle CCTP waits for full Ethereum finality. A lot of um canonical bridges of roll-ups wait for full Ethereum finality. Um but even a lot of exchanges and things like that do do not wait anywhere close to full Ethereum finality because it is currently too slow. So we're trying to get efficient interoperability with fast trust minimized confirmations. So uh let's look at kind of the structure of a confirmation and uh it has three components. So one is inclusion. This is like the time it takes your transaction to actually get sequenced. Um you have actual finalization of your data and then you have the proof of your data. And your proof is only as good as your data's input. So for example, a lot of times we like to think that ZK proofs are very very secure. But if your ZK proof is proving something that has, you know, um been conf confirmed by only a centralized party, really your trust reduces just to that centralized party. Your ZK proof is giving you very minimal extra security. And obviously if you want to have faster confirmations, we need to make these components smaller. So we can make these components smaller by making each component faster through say you know adding more GPUs to a ZK prover that doesn't really change the trust assumptions of your prover. Well I'll get into that. Um you can swap them for components with different trust assumptions or you can pipeline them in some cases. So I want to give an example of visa because um it's an off-chain system but it actually functions completely the same as onchain systems. So Visa functions completely the same as a sequencer in a rollup. The time to inclusion is the time for when your credit card transaction has to reach Visa's server. Finalization in Visa is essentially them writing to their database. And then proof execution is them literally just executing the transaction and then signing it. But it is functionally the same as a confirmation on Ethereum. And uh yeah, it's the same as a sequence or a proposer confirmation. And notably uh how do you like which things kind of influence the latency for inclusion? their network delay, the time it takes your transaction to actually get to the sequencer. Uh but it's also congestion and this is kind of something that we when we talk about fast finality uh we don't talk about which is that you can have a very fast consensus protocol but if it doesn't have adequate throughput uh you know people are not going to be able to get their transactions included in a timely manner. All right. So, uh, just to briefly go through this, um, you know, Ethereum rollup confirmations, 1 hour to 7 days. Um, and then let's kind of look at this. So, for an optimistic rollup, here's kind of how the structure of the confirmation breaks down. And you can see the proof time for a fraud proof is by far the largest bottleneck. So, if we're talking about interoperability, really the number one focus is not fixing Ethereum finality. Ethereum finality is long, but it's nowhere near as long as 7 days. So really what we need to focus on is switching to faster proof systems. So things like ZK proofs um or things like um a TE proof or a full node proof. But you will notice that a like a TE has just different trust assumptions than a ZK proof. And another part though about the proof system here is that it also matters about the cost. So, one of the reasons that ZK roll-ups do not post to Ethereum as frequently as they could, it's not it's not actually just the cost to generate the proof. A lot of it is the cost to verify the proof on Ethereum. And so, this is what keeps them from posting very frequently and um gives you long confirmation times. All right, here's the structure of an Ethereum confirmation and then an espresso confirmation. So, haven't really talked about espresso yet, but here is what espresso is. So Espresso is a very low latency, high throughput base layer specifically designed for roll-ups. So it doesn't execute um so it's compatible with any sort of like VM uh stack proving system etc. And it just focuses on giving really really low latency while giving high throughput. Its aim isn't to give the highest throughput possible. Its aim is to give enough throughput such that you can always get low latency. Um all right. So what are the levers that we can kind of pull to get faster confirmations? Well, you can do faster block times. That's a easy one. You can have higher execution throughput. Um, you know, like increasing your gas target, your gas limit. Um, but notably, these change your trust assumptions. So, like for example, you could say, well, an easy way to get faster inclusion time in Ethereum is let's just make Ethereum have 1 second blocks. We'll take the 60 million gas limit, divide it by 12, and that'll be the gas limit for each block. And that does give you faster inclusion on average. Um, but that changes your trust assumptions because now maybe certain nodes can't keep up with the network etc. All right, finalization. So clearly to get faster finality, you can change your consensus protocol, you can get higher data throughput. Um, and then you can also do new conf uh confirmation rules. So I don't think I'll have time to go into it in this talk, but Ethereum has something called the fast confirmation rule, FCR. And this is a it requires no hard fork to Ethereum. And the idea is essentially that a lot of the times today we use block height as a huristic for security in Ethereum and we don't want to wait for full finality. Um that's actually not a very secure way because you can imagine in Ethereum if you have six blocks but each one of those blocks received like zero at like one attestation those blocks can actually be very uh easily reorded. So what the fast confirmation rule does is it kind of formalizes um this like block depth huristic such that um you actually have like precise uh precise guarantees. So if you um you you get a precise guarantee that so long as you're assuming that the network is like synchronous um you know that that block will not reorg if this fast confirmation rule passes. And finally obviously we can make proofs a lot faster. So um use a different kind of a proof system um and you know we can also use like better hardware etc. A couple of observations here are that trust assumptions always change to some degree whenever you change part of your protocol but sometimes trust assumptions actually get better with speed. You could argue that a multi-proof that uses, you know, ZK uh TE proofs and fraud proofs actually gives you better speed on average than just a fraud proof. And you arguably get better security. But something I want to point out is that there is generally this trade-off between speed and security, but it's not a linear line. And so this is kind of what Espresso does is that it tries to find the most optimal point on this line where it says we can maximize speed while maintaining a lot of security. Um I'm going to just quickly go through this. This is just more of a comment that you know you have your base layer and obviously in this case B only needs to trust the base layer. Um which is great. That's a function of the base layer. But as a caveat um except for assets issued on on A but anyway I'm running short on time so I'm not going to go into that. But the point here is that so requirements alongside faster finality are so yes we need faster um consensus protocols. Mostly we need way faster proving and it's not just that we need faster proving systems. We need a chain that has adequate throughput and adequate execution such that you can post proofs very frequently and verify them very cheaply. So it's not just the pure proving time. It's also the fact that we need it to be cheap to do on chain. And I say adequate throughput because again you don't necessarily need the maximum throughput or the maximum execution. You just need the maximum throughput and execution uh such that you can achieve low latency. So I'm going to skip through these because I'm running running short on time. But um anyway, the end goal though is like real time trust minimized native interactions between systems. And to do this, we need fast finality, but we also need to fix our proving systems. We need to fix our time to inclusion. Um and we also need to make sure that we have cheap block space. And anyway, with that, I will wrap up.