Inside Ethereum's Lookahead Logic EIP-7917

Transcript

Now I would actually argue that for the vast majority of use cases unless it's a billion dollar plus transfer then the light the incentives from me and fees are going to go down to zero. So you're condensing and minimizing your security assumptions and you're getting both the scale that L2 promise which is you know potentially millions of transactions but I would say that it's fairly orthogonal in the sense that um these are separate concerns that can be tackled independently and so when you combine preconfirmations which removes the latency from confirmation and you have real-time proving then I think >> [music]

>> Welcome back to the Fusaka Files, a limited episode podcast [music] exploring Ethereum's upcoming Fusaka upgrade through the lens of real world use, ecosystem readiness, and impact [music] from enterprise side. I am Puja Ranjan from EC >> and I'm Paul Brody the chairman of the Enterprise Ethereum Alliance >> and [music] we believe the truth is out. Today we are going to focus on validators operation. The Fusaka upgrade includes EIP7917 deterministic proposal look ahead to explain what this means for people and project. We are joined by Justin Drake from Ethereum Foundation. Welcome Justin.

>> Hi there. Thanks for having me. Justin, we would like to get into the details and would love to hear from you how this proposal is going to help the enterprise side of the ecosystem. But before we get into those part, may I request you to quickly provide a brief introduction? Maybe you can talk about what is your current role and what is your present focus followed by simple summary of this proposal. >> Absolutely. So I'm a researcher at the film foundation. I'm part of the architecture team and right now I'm working on two big projects. The first one is called ZKevm which is a road map to dramatically increase the gas limit on L1 by removing validators as a bottleneck for scalability. So instead

of having to reexecute transactions, you can simply verify these succinct proofs called snarks. And then the other thing that I'm working on is a big upgrade to the consensus layer called lean consensus. And this gives us for example postquantum security which is something institutions care about as well as faster finality and shorter slots. And both of those things are that enterprises care a lot about. I I hear a lot of talk about sort of instant finality or fast finality and I definitely hear a fair amount of talk about postquantum. And I I think you know my sort of answer to them is I have a lot of confidence that the Ethereum Foundation has these things in hand right I think you've done so much to lay out a really nice kind of road map for

massively scaling L1 and making it more reliable more predictable more businessfriendly and I think all of those things are great for this specific proposal tell us where it fits into the bigger picture roadmap of like massive scalability predictability and reliability. >> Absolutely. So the L1 can only be scaled so far. So I think the end game is close to 10,000 TPS, which is a fantastic start, but not enough for the whole world. And part of the reason is that it's only 0.1 transactions per day per human. And so what I'm hoping we can have, and this is what the whole Ethereum ecosystem is working towards, is much more scalability through the L2s. And specifically the goal that I

have is 10 million transactions per second which is a 100 transactions per day per human. Now right now what we've seen is that a lot of the L2s have centralized sequences and that has been a great way to get started but has uh come with very downsides. One downside from an institutional perspective is that you've potentially created a regulatory target and choke point and that could be potentially a target for for censorship and um it's also something that some institutions don't want to even bother with right because there there's a there's a DevOps burden and you have to stay uh online otherwise you degrade the performance for your

users. And then the other downside of this approach uh has to do with composability where we have these siloed ecosystems that have friction communicating with each other. Certainly much more friction than we currently have on L1 between smart contracts. And so one of the things that I'm hoping we can achieve is find a canonical sequencer for Ethereum which has these two nice properties. The first one being that it's decentralized. It doesn't have to be maintained. It's not a regulatory choke point, but also it can be a shared sequencer for many different L2s and thereby reduce the friction in in composability.

Now, one of the biggest challenges to have a shared and very successful decentralized sequencer is very fast UX. So today one of the superpowers of these centralized sequencers is called preconfirmations where as a user I'm going to communicate with this centralized entity and within one ping time so the time it takes to communicate on the internet which is about 100 milliseconds you will get a pre-confirmation that your transaction will get included at the end of the slot. And so it has been a whole research and and development challenge to try and replicate these preconfirmations in a decentralized context in particular for Ethereum L1.

Now one of the things that you need to have these preconfirmations is to know who will be the next sequencer in the future. And this is what's called the look ahead in the context of the L1. And so today, prefusaka, the L1 has a little bit of an edge case where in certain rare circumstances, the look ahead changes at at the very last minute. And so what this EIP does is that it it provides um a minimum of of one epoch of look ahead. So you always have 32 slots and you have this guarantee that these 32 future proposers will indeed be the future proposers for the L1. Now be once we have that we can start unlocking L1

preconfirmations also known as base preconfirmations and then the L1 becomes an extremely attractive sequencer not just for itself but also for all of the L2s and rollups and L2s that opt into the L1 sequencer are called base L2s and base rollups. And so my hope, my vision is that over the the longer term, we're going to see this convergence towards a shared sequencer, specifically the R1 sequencer. >> Okay, I have so many questions and there's things I need to unpack here. So first of all, just for regular normies, unpack what is an epoch?

>> An epoch is just 32 consecutive slots. So on Ethereum L1, we have a heartbeat every 12 seconds. That's called a slot. And when you take 32 of those slots, you get 6.4 in 4 minutes and that's one epoch. >> And what is transaction finality like? How many epochs does transaction finality take? >> So today transaction finality takes two epochs. Technically between two and three depending on when in the epoch you submit it. So think about 15 minutes to get transaction finality. >> Okay. So median sort of time to transaction finality is about 15 minutes and an epoch is about 6 minutes. And then what is a preconfirmation? like why do I care about having a preconfirmation?

>> Yeah. So preconfirmation and economic finality are two extremes in the spectrum and it turns out that there's other things in the middle. So economic finality is something which is actually quite unique to Ethereum because we have slashing and we also have a hundred billion dollars of economic security which means that if two economically finalized checkpoints are kind of inconsistent with each other we know that at least oneird of the validators will get slashed which is about $30 billion and I think institutions will appreciate this level of security but there's actually something called light finality which I think is worth mentioning because for many use cases is for example deposits into a centralized

exchange. This lighter version of finality which is non-lashable and relies on on other things namely synchrony and honesty. So these are like technical terms but this is what most other blockchains do and we have that on the order of one slot. So we have light finality on the order of one slot. We have economic finality on the order of two to three epoch. But even one slot is too slow. Right? One slot is 12 seconds. Imagine making a payment and it takes 12 seconds at the checkout. That's not acceptable. And users today have grown accustomed to the 100 millisecond pre-confirmations that they get with all of the L2s.

>> It's not just the L2s. I mean, basically, you get 100, you know, you swipe your credit card at the grocery store, you get 100 millisecond pre-confirmation effectively at that time. >> Yeah. I mean actually it turns out that for card payment it's a couple seconds but it's getting faster and faster and 12 seconds we know for sure is too slow and the pre-confirmations basically give us the endgame right that you literally can't do any faster than one ping time on the internet and the way that they work is that instead of being backed by the reputation of the centralized sequencer or by some sort of legal contract they are backed by economics.

So you will get a financial guarantee that if your transaction does not get included at the end of the slot, then the sequencer will get slashed. And so they have all of the incentives in order to honor the pre-confirmation that we've made, which is just a promise to you as a user. >> Is there a like upper transaction limit size on like how big you're willing to do a pre-confirmation for? Right? Because obviously there's a tiny bit of risk involved in a pre-confirmation. Yeah, that's a great question. So, if you look at the incentives, especially if you're doing a trade, there is an an edge case where the price volatility is so high that could be greater than the collateral that the pre-confer has. And

now the pre-confer has incentive to not include your trade and instead include their trade and collect the arbitrage opportunity. Now in the proposal that we have the amount of collateral is one E for the 12 seconds and what you can go and do is have a look at historical events and see when was one E not sufficient and it's essentially sufficient 99 plus% of of the time. Now if you're making transactions which are small trades or if you're making transactions which are not trades at all, >> they're purchases, payments, smaller things.

>> Yeah. Then the incentives are such that the proposer should include your transaction. >> But what if I want to send you $10 million? That's a lot more than one ETH. I'm not going to send you $10 million. I want to be clear about that. I don't want this to be implied as a promise in terms of like my retirement income. But if I wanted to send you in a single transaction $10 million because that is an enterprise size of payment, right? What happens then? >> Yeah, a great question. So, one of the things that pre-confirmations don't give is, you know, a guarantee for the receiver. It's kind of more of a guarantee for the sender. So, if you as a receiver of this transaction are going to give out real world goods, then you shouldn't be relying on on one ETH. If

the the value of the goods that you're going to give away is is greater than one ETH. But, you know, usually speaking, when you're receiving these large amounts of money, it could be because you're selling a car or a computer or maybe you're receiving a deposit, it's a big supplier transaction, in which case 12 seconds or you know, one of the jokes I used to make a lot is in the business world net 30, right? Being paid 30 days after the invoice, that's not 30 milliseconds, that's 30 days. So you know a system that provides sort of economic finality in 15 minutes just fine right like for almost all enterprise use cases that are not financial services trading and not retail payments you know 15 minutes is

absolutely fine so basically you know you would not if you were waiting for payment in advance you would just not you would wait it would be okay for a multi-million dollar transaction to wait 15 minutes to release the goods. >> Yes. Now I would actually argue that for the vast majority of use cases unless it's a billion dollar plus transfer then the light finality is sufficient and this concept of light finality hasn't been broadly disseminated and we've done a very poor job to highlight it its existence but over the coming months we have now a dedicated team at the film foundation who will be pushing forward this idea of light finality and for most use cases for bridges between L1's and L2s and and exchange changes this light finality is sufficient. So I think the

the 15 minutes is a bit overkill like from my perspective the main value of a finality is to prevent these very deep reorgs where an attacker would just completely rewrite Ethereum history just to make that extremely expensive. But for most transactions that are done today on L1 and I'm talking about you know 69s or seven 9ines of transactions you only need the light finality which takes on the order of one slot. But what pre-confirmations are all about is giving almost all users kind of this this green check mark on their wallet transactions. So instead of having to wait a few seconds for the wallet to tell them, hey, you have been included, you can know ahead of time how your

transaction will execute even before the transaction has hit your block. So if you're doing a trade, then for example on unis swap, you will know how the transaction executes. So that is what's called an an execution preconfirmation which is different to the weaker flavor pre-confirmation which is an inclusion preconfirmation where the only thing you know is that your transaction will be included but you don't know exactly know how it will be included. So let me turn a little bit to privacy. too. At EY, we've been building privacy infrastructure, one of them called Nightfall, and we sort of took a look at this concept of based roll-ups and make use of pre-confirmations. And it's very exciting. But we determined that the

math involved in a zero knowledge proof for privacy is too large for us to fit anywhere close to the pre-confirmation window time. And if we care a lot about privacy and and I certainly do and I think a lot of enterprise and institutional users care a lot about privacy, what are your thoughts about a future of predictable look aheads and block times that will help make privacy more scalable or does is there a future in which privacy enabled transactions which are very computationally intensive get included in this world?

>> I see. So I guess if you're a user and you're trying to make a private transaction, you have to suffer two different types of latencies. The first one is the time it takes to just generate your proof and that could be you know a whole minute or like several slots. >> It's actually for just to give you a sense like when we do a rollup in Nightfall when we do a full block in Nightfall it's about 20 minutes to include all the transactions and do the rollup. So your cycle time is currently 20 minutes. Now, that's obviously continuously going down, but it's, you know, roughly speaking at the moment, the state-of-the-art is about 20 minutes for for rolling all these together.

>> Okay, got it. But I guess in the context of private rollups, there's there's two types of proof that that you're doing, right? There's the individual user that's doing a proof for its transaction, and then there's some sort of block builder or sequencer that's doing the proof for the whole block, which is multiple transactions. And what you can do is you can have the user spend, you know, a few seconds, whatever it is, for the first snark, for the first proof, and then get a preconfirmation from the block builder or the sequencer that they will include that transaction.

You can do the inclusion, but not the finality pre-confirmation. >> Exactly. >> Or you can do an inclusion pre-confirmation. And I guess how far ahead does the look ahead go, right? is if I can do an inclusion pre-confirmation, I can also do a execution preconfirmation as long as I know that my block will be included, right? It takes us about 20 minutes. So, how far how many epochs does a look ahead go for in this this proposal? >> Yeah. So, the look ahead is one epoch. And so what this means is that for whenever there's 20% of of validators that have opted in to give these pre-confirmations then you have the guarantee that at least one such opted in proposer will be in the look ahead

and it suffices to just be one of them in order to get these execution preconfirmations for the the base rollups and the base L2s. So right now we're at this point we're building the groundwork. We need this EIP. We also need what's called the the universal registration contract so that some subset of the validators can deposit the one E collateral. And once we have 20% that have opted in then we have this magical moment where you can have the pre-confirmations. Now going back to the spectrum it's preconfirmation, confirmation, light finality and then economic finality. And really what preconfirmations are about is bridging

the gap between confirmation and preconfirmation. So it's just about shaving a few seconds. Now going back to your comment around snarks taking a very long time either at the individual transaction level or at the block level. We've made fantastic progress with what's called real-time proving or low latency proving. So for Ethereum L1 today we can now proof blocks with an average of 6 seconds. So that's a whole mainet Ethereum block in 6 seconds. And um there's been a lot of engineering at the software level to achieve that. But part of the trick is to use a a relatively large cluster of GPUs. So think 16 GPUs uh 5090s of high performance gaming GPUs and um my

expectation is that the latencies will will keep on dropping down. And so when you combine pre-confirmations which removes the latency from confirmation and you have real-time proving then I think we can imagine a world where you have both the privacy and the the fast URX. >> This is maybe a little bit off topic but do you see a transition over time to GPUs in order to enable these? I mean, you know, we stayed away from GPUs early on because they weren't so widespread, but AI has made GPUs widespread, and it's probably going to mean that in the in the foreseeable future, there's going to be a lot of not sophisticated enough GPUs for the the bleeding edge AI that are available at very low prices for onchain proving.

>> Yeah. So, we're seeing GPUs everywhere. Like literally every phone, every computer has a GPU and many modern proof systems are leveraging these phone GPUs, you know, to have fast per transaction approving. Now for the blog builders, these phones and laptop GPUs are not sufficient. You need the the more powerful clusters of GPUs. And I think yes, the community is very comfortable considering those to be commodity hardware that you can just buy off the shelf and it'll be delivered to you. um you know within a few days and there's millions of them uh that have been manufactured across the world and you don't have to use the state-of-the-art you can use the 4090 for example which

is I believe something like 3 years old and that will do the job as well >> okay so a couple more questions just maybe more focused on like who this impacts right so let me just start with saying so it sounds like this EIP is mostly going to be transparent to users as application developers, but people who run L2s are going to care a lot about this. L2s and validators. Is that a fair statement? >> Yes. I think it will take time before like the majority of L2s really care. I'd say a small minority of L2s that are the bleeding edge will start caring about this. But uh my hope is that eventually the economic incentives are such that the vast majority of L2s opt

in to becoming based. And the reason is that by having a shared sequencer you unlock all sorts of new applications and you create more transaction volume which means more transaction fees and so the the incentives are very much aligned here. So one example, let's say that you are having a really hard time bootstrapping some liquidity in your dexes in your L2, which is the reality for the vast majority of L2s and the few that have achieved liquidity have done so through, you know, massive incentive programs that have been uh, you know, very expensive for them in terms of uh of token incentives. And so what if instead you could just tap into the

largest dexes in the world which are on Ethereum L1 and and now every time you have an application that requires this this liquidity it can do so at the best possible prices. So you're unlocking a whole design space for for applications which are otherwise impossible on most L2s today. you bring up a really good sort of point which is and you touched on this right at the beginning of the conversation which is we have a lot of L2s that are building silos right and they're going to try to protect some of those silos what's the incentive for the L2s that have been very successful to become based rollups like am I sacrificing some of the things that made my L2 unique or differentiated and and am I being sort of sucked into a

commoditybased price war >> yeah let's touch on differentiation and incentive separately. So on differentiation there's many ways to differentiate. You can differentiate on on governance on tokconomics on the execution engine. So if you use EVM or SVM or Cairo or or many other things you know you can distinguish yourself in terms of privacy if you have something like Zcash or there's just so many ways to distinguish yourself. I don't think that's that's an issue. In terms of the incentives for the L2s there's two primary fundamental incentives. Uh the first one is transaction fees and me that are currently being collected by the sequencers and the second one is what we call base fees that are basically congestion fees. Whenever

there's a lot of traffic you can start collecting those. Now my personal thesis is that the incentives from me and fees are going to go down to zero. And part of the reason is that applications, users and intermediaries like wallets are becoming more and more sophisticated. So such that they're not leaking me unnecessarily. Basically this value which is currently extracted by the sequencers is being upstreamed all the way back to the users sometimes. And so what I see happening is that almost all of the revenue let's say 99% of it is going to come from congestion fees.

So this is the equivalent of F9 for the L1. And this is something that can be captured regardless of the sequencer that you have. So even if you have a base sequencer, you'll be collecting these these congestion fees. And my mental model is what I call the ME gambit whereby you give away 1% of your revenue, which is the me, but you're boosting, for example, you're you're doubling, you're tripling, you're quadrupling your traffic, and therefore you're correspondingly increasing your >> potential for congestion. >> Yes. Exactly. >> That's an interesting hypothesis. I I would say my own hypothesis is that for the the foreseeable future, network capacity is going to grow much faster than transaction volume. We we're doing such an amazing job of drawing growing

network capacity that I'm having a hard time envisioning a lot of congestion fees in the future. But let me turn to a couple of final questions. What is the single most important thing if if you could think of some single most important thing that enterprises need to do or care about with this capability? like is is this something that really business users should worry a lot about and and do some preparation or is it going to happen and the impact will be sort of seen in the in the performance of the infrastructure but not require any substantial changes. >> Yeah. So let me just quickly go back to your comment. So I think I I do agree that we're going to see a period of growth where both the MEV and the transaction fees and the congestion fees are low. But having said that, there is

a little bit of a trick that you can play where you can artificially set a low gas limit. So as an L2, you control your gas limit and you don't have to make it infinite. You can make it as low as you want and that is going to lead to congestion fees. Now to your last question. So I think the most important thing that they could be doing is staying open-minded to a potential future where they don't have to have a centralized sequencer intermediate their roll up or their L2. So I think in the short term it's fine to you know maybe cut corners if you will with a centralized sequencer. Over the long term I think you should still be striving for this decentralized sequencer. And part of the reason has to

do with with security. So there's there's two aspects of security. There's what we call safety and there's livveness. So the whole selling point of L2s is that you have the same safety as Ethereum L1. So you have cryptography like SNOX plus the finality of L1 whether it's light finality or economic finality that will give you this this this strong safety. But then on the livveness side of things, having these centralized sequences is is a real degradation, right? Because we've seen, for example, there was an AWS outage and some of the L2s like base just went offline. So that's a livveness failure.

And there's another more subtle type of livveness failure, which is a censorship attack where you could either be, you know, censoring specific trades or liquidations and then you can game the markets. That's that's a bad thing. or you know there's also this this other vector of censorship which is things like the the OFAC SDN list and so if you don't want to have to bother with all of these livveness issues then the most robust thing to do is to have a decentralized sequencer and if you happen to pick Ethereum L1 sequencer then you have the exact same livess and safety guarantees as the L1 so you're condensing and minimizing your security assumptions and you're getting both the scale that L2 promise which is you know

potentially millions of transactions per second in aggregate and the the hardness of the R1. >> Awesome. Thank you. I think Puja has a question that she wants to put in as well. >> Yeah. Right. So Justin you have talked about a lot of finality stuff like in the beginning you also mentioned about the faster finality we have transaction finality economic finality light finality. So above considering all these finalities my question is around looking ahead how does 7917 set up the stage or maybe facilitate the future design with all these things into consideration.

>> Yeah I would say that it it's fairly offonal in the sense that um these are separate concerns that can be tackled independently. So on the finality side of things, what I expect will happen is that over the coming months, more and more people will get excited about light finality. And the reason is that we have it today in some sense. And the reason is that we don't need a hard fork to implement it. And there's already one client, the prism client that has implemented an API to make use of this light finality. But what I'm hoping will happen is that all of the consensus layer clients implement it and the exchanges and the bridges actually start using it. Now on the economic finality side of things, what we need to do is first of all reduce the slot duration

and there's various ways to to do that. So for example, there's a proposal by Barnab to reduce slot durations to 6 seconds. I want to bring them down to 4 seconds with lean consensus or even less something maybe closer to to three or two seconds. We'll see. And then the other very important thing is to reduce the number of slots in order to achieve finality. So the two epochs, that's 64 slots. That's way too much. The the theoretical minimum is two or or three depending on exactly what properties you want. So we've been working on something called three slot finality, 3 SF.

There's also a 2SF variant, two slot finality. And this is something that I'm hoping we will be launching uh with with lean consensus as well. But yeah, in the short and medium term, I would put a big emphasis on light finality because it's the most relevant thing for the most users. >> Fantastic. So, let me see if I want to just wrap up here with a couple of key takeaways from the enterprise user perspective. So, I think for most enterprise users, the short-term impact is relatively limited, but there are a couple of important things to keep in mind as we go forward. First of all, the foundation is being laid for what I think is an amazing and great vision of scalability, which is 100 transactions per human on a planet every single day, which I love this idea. It's certainly

how we think about it, right? Everybody should be able to to be doing transactions. They should be keeping track of everything on chain, right? Secondly, fast finality. This is something people in the world of finance have been asking for forever. It's coming. This EIP helps lay the foundation for speeding that up. It's already pretty fast and it is only going to get faster, right? With things like pre-confirmation, light and light finality, you're going to have kind of any reasonable definition of transaction finality is going to be much much faster. And then lastly, you know, it is becoming increasingly clear that there are significant attractions for becoming a base rollup and getting not only the economic security of Ethereum, which you

get as any kind of an L2, but also the livveness guarantee that comes with being a fully decentralized, globally available kind of participant. So those are kind of the major takeaways and I want to thank you Justin for allowing us to grill you for like 45 minutes on this topic. I can tell you know it in great detail and you care a lot about it and I you know am a big fan of the vision that you are laying out for this massive massive scalability. >> Absolutely. Thanks for having me. >> Thank you Justin and Paul for having this very good conversation around enterprise side of changes that are being introduced with Ethereum upgrade.

Dear listeners, we hope that today's episode might have helped you understand the upcoming changes. If you want to get into technical details, please check out episode 146 on peep and e podcast [music] with Justin Drake and Lenoshitani. Follow ECH Institute and Enterprise Ethereum Alliance on LinkedIn and Twitter. Stay tuned for future episodes. Until next [music] time, keep building on Ethereum. Cheers everyone.