EIP-7917: Deterministic Proposer Lookahead

Transcript

The primary use case right now is like L2 preconfirmations and base rule of preconfirmations. The only credibly neutral shared and decentralized sequencer that I know of is Ethereum itself. I had like kind of goosebumps when I was writing it. Like as Justin was mentioning, it's like the Ethereum is like the internet computer and the internet finance. I believe you know the future of Ethereum is extremely bright. EIP7917 is a relatively simple change like I was able to explain it in like three slides. The traditional world of finance will migrate onchain, specifically onto [Music] Ethereum. Hello everyone, welcome to

Penney, the podcast where we explore Ethereum improvement proposal and learn what's ahead for the Ethereum ecosystem. [Music] This is episode 146 brought to you by ECH Institute. Today we are diving into EIP 7917 deterministic proposal look ahead. A protocol change designed to pre-calculate and store a deterministic proposal look ahead in the beacon state at the start of every epoch. The proposal was documented in March 2025 and currently is in the draft status. It is also up for Fusaka upgrades. To provide an overview of this consensus

layer improvement proposal, we are joined by co-author Lynn Oshitani and Justin Drake. Welcome Lynn and Justin to Panip. Yeah, thanks for having us. Thanks for having us. Thank you both for joining us here today. So today's talk is divided into four sections. Introduction, presentation, Q&A and rapid fire round. So if it is all right, maybe you can share a bit about your professional background, how you discovered Ethereum and what project you are currently working on. Yeah, can start. Um, I'm Lynn. I work at Nethermind. I do protocol research and I've been working

around Ethereum for over an year now. Um I joined the other mind and that was my first Ethereum job and yeah before that I used to be core dev for another blockchain called Tesos and yeah but I thought Ethereum like seemed very interested and wanted to join. So yes I'm here and I'm a researcher at the film foundation. I've been there since uh 2017 and before that I was into Bitcoin. Discovered Bitcoin through Dankrat of Dankshing fame in 2013 and bought my first Bitcoin through him. We ended up operating a Bitcoin ATM together. I also started the Cambridge Bitcoin Meetup Group and also started a Bitcoin startup building a peer-to-peer

marketplace on top of Bitcoin. But ultimately I found Bitcoin frustrating and inadequate to build a peer-to-peer marketplace on and that gave me an interest to go discover and learn more about Ethereum. Pretty interesting backstory. We are happy and so honored to have you both here today to talk about another Ethereum improvement proposal which hopefully will make Ethereum consensus layer even more smoother. So with introduction out of the way, we can jump right into the EIP. Without further ado, let's peep in. So I guess I'm happy to provide a little bit of context here. So I guess there's three things that we're trying to do

with Ethereum. First of all, we want to try and provide a very robust and secure platform. And this is what I've been spending almost all of my time as a researcher trying to make Ethereum more secure. And this is part of what uh my research with the the beam chain is also all about improving uh security. But the beyond security there's basically two features that we want to work on. One is increasing throughput basically scaling and we have lots of ideas with rollups and data availability and you know there's a whole program there around densharding and pieras and then there's another idea which is to try and reduce the latency of uh user transactions and here we basically have two tools at our

disposal one is to reduce the slot duration or two kind of a more recent idea idea is preconfirmations. The idea of the pre-confirmations is that you keep whatever slot duration you have in your decentralized sequencer and you make use of the fact that the current proposer that has sequencing rights for the current slot can make promises about the transaction that they will include at the end of the slot. And from the perspective of the user, as soon as they get that promise, it's almost as good as if they had their transactions actually included on chain. And part of the reason why this promise is so good is

because it's backed by collateral. Can either be backed by financial collateral or today what is very common is being backed by reputational collateral in the case of centralized sequences. And we also have designs out there that make use of SGX where you're using secure enclave to have credible commitments about your preconfirmations. Now my hope was that we could do preconfirmations without any hard fork on Ethereum L1 and that's technically true but it turns out that there is an edge case and the edge case has to do with the proposed look ahead which is that in order for a user to receive a pre-confirmation they need

to know who the next proposers are going to be. But in this one edge case, the future proposes also known as a proposal look ahead is unknown. And that causes all sorts of complications and and makes the designs for pre-confirmations unnecessarily complicated. And I give all of the credit to Lynn to bas for basically identifying the problem, you know, coming up with a a solution and basically driving the the process of this EIP forward. and he's the one who can answer all of the the technical details about the EIP. Thank you so much for setting up this stage. So with that we can perhaps get into the

presentation. Yeah. Today I'm going to talk about EIP 7917 determinist proposer look ahead and this is by me Lynn from nethermind research and Justin from media. So the outline is this. So I heard this is more of a educational like session. So first I'll like cover a lot of the basics about based roll-ups and pre-confirmations. I think Justin gave a good overview but I'll get go into a little more of the like details and yes I'll talk about two issues around pre-confirmations that are related to the look ahead like look ahead access in the EVM and the look ahead instability and then I'll dive into the details of

the IP first some background. So what are base roll-ups and pre-confirmations? But even before that, let's talk about like what roll-ups are. So roll-ups are a technology for scaling Ethereum by posting transaction data to the L1 but executing them in the L2. So like what this means is that the L1 blocks contain L2 blocks like this. So you have the L1 block and then within the L1 block you have this small L like this L2 block included within it. And the core thing here is that like the L1 block the transaction data itself is included in the L1 block but the L1 validators don't execute this L1 L2 block part. So this is where the scalability of ropes come from but one of the big questions here is like who builds these L2 blocks and

like it's kind of natural that this is becomes a central issue in L2s because if you look at L1 like if you got look at E3 research like most of the question is about like how do we build this L1 block. So it's only natural that in the L2 context too the big question becomes who builds these L2 blocks. Okay. So the answer right now is for most of the major rollups where you have centralized sequencers who build the L2 blocks. How it works is like this. You have a centralized sequencer in the network and these are like some server run by some foundation and the users will send their transaction their L2 transactions to the centralized sequencer and then the centralized sequencer will like aggregate all these L2 transactions and post L2 block through the proposer to

the L1 and centralized sequencers are really great like they pro can provide what's called preconfirmations. So what are pre-confirmations? Pre-confirmations are this. So like let's say that you're a user and you said send transaction C to a centralized sequencer. Now what the centralized sequencer can do it can immediately return what's called a pre-confirmation. What this pre-confirmation is it's saying that I will promise to include your transaction transaction C at the third position in the L2 block after transaction A and transaction B for example. Now like some time passes like centralized after this pre-MP is made and then eventually this centralized sequencer will post construct an L2 block post it to the

proposer and the proposer will include it in their L1 block and this L2 block that's included within the one block. It will like include the transaction C in the promised position. So the nice thing here is like you don't have to wait until this whole thing is built to know how your transaction is executed because you can have this like immediate preconfirmation and yes central sequencers are great like they bring fast UX which is I would say critical for mass adoption. However like one big problem here is as you can see from the name they're centralized. So the big question is how do you decentralize the centralized sequencer and here is where base rollups come in. So the idea of base rollups is like surprisingly

simple. Like the problem here was that you have a centralized sequencer that sit in the middle that is centralized. So let's just remove this entity. Let's just say that like the L1 proposers sequence the L2 blocks. So not just L1 block but also the L2 blocks. And yeah, base rollups are really nice. They inherit the L1 sensor resistance and livveness because like you don't introduce any of like additional bottlenecks to the whole system. like all you have is a plain old like L1 validator set and also like they enable what's called L1 composability meaning that like you can have composable transactions that goes between the L1 and the L2. So you can have the L1 and L2 like interact in a much more seamless way. And this is possible because like

this proposer, the L1 proposer is now sequencing not only the L1 but also the L2. Meaning that like they are can act as kind of like the shared sequencer for both L1 and the L2 and provide composibility guarantees. Okay, Philips are nice, but there's one problem and they're slow. like they must wait until this L1 block is actually built to know like how your transaction is executed which means that we must wait until the L1 block time which is currently 12 seconds. The big question here is how do we make them faster? Like how do we like have good UX in a base rollup setup? And here is where base preconfirmations from Justin that was proposed from Justin comes in. And the idea is this like who

is the entity who can provide pre-confirmations. It's actually if you look at it the L1 proposer they can provide pre-confirmations because they do have the ability to like give promises and eventually include it in the L2 block. So the idea is have the L1 proposer provide the pre-confirmations. Now one thing to note here is that the we need the proposers to explicitly opt in since they need to be exposed this incentivize equification. What I mean by this is like when you had a centralized sequencer that's run by some foundation like optins foundation or arbitum foundation like they have very high reputation.

So like you can kind of trust them to not equate meaning that they would provide a pre-confirmation saying that I'll put your transaction in position in the L2 block but eventually when you post L1 like you don't post it that way you can post it in a completely different position or not posted at all for example and the thing is that for when you are a base rollup the L1 proposers like they're not to be trusted because there isn't reputation because they're decentralized. What you need is slashing condition. So like instead of relying on reputation like you rely on slashing you say that if your base preconfirmation proposer if you equate

on the pre-confirmation you get slashed and you get slashed by proving the fact in L1. And this all means that you need the proposers to opt in to become a preconfirm. So how this looks like is this. So let's say that we are in like P1 a slot where the P1 is a proposer and P1 is like constructing the L1 block right now. Now as a user like but let's say the P1 and P2 like these two proposers are non pre-confer so they're not a pre-confer and P3 is a pre-confer what happened is that the users like they cannot get pre-confirmations from P1 or P2 because they're not like opted in and they're not exposed to the selection conditions so as a user what

you have to do is you have to look into this proposer schedule and say that hey the next optin proposer is P3 so I'll send my transaction to P3 three and then I'll get my pre-confirmations. So yes, they have to send the next opted in proposer which we call the pre-confirm and what happens eventually is that like the time will come for this P3 to actually propose an L1 block and at that time the L1 block they will propose an L1 block that includes the L2 block containing the precon transactions in the order that they actually pre-mp. So like one of the key things here is that like the for base preconfirmations it is important to know the proposer schedule that this proposer schedule is called

the look ahead. So like as a user you have to know like who's the upcoming proposers so you can actually route your transactions to the next opted in proposer. Okay. So this is like the context around base pre rollups and base pre confirmations. Now let me talk about like some of the issues that we have with the current L1 and the look ahead. Okay, the first issue I want to talk about is like the look ahead availability in the EVM. But before that like let me give some more context around the proposer look ahead. So in current Ethereum the proposer look ahead is like this. So at the start of each epoch and epoch is like 32 slots. So how ether works is you have like like many

slots and for each slot you can propose one block. So there going to be one proposer and one like block being proposed and with 32 slots you call it an epoch. So at the start of each epoch we have visibility of two epochs worth of proposers in the current L1. This means that you always have at least 32 slots worth of look ahead. So like at this point at this like start of the epoch let's say P 0 at this point you have visibility against like all the 64 proposers and this like epoch will like continue and when at this point at the slot of poser 31 like you'll have a look ahead of 32 so you'll have at least 32 worth of look ahead and here it's

actually critical kind of as in like this is not completely accurate like there is an edge case but for now like think of it as this. Okay. So like this is you have this look ahead and one thing that base preconfirmations or base rollups with preconfirmations want to do we want the L2 block inbox contract to limit block submissions to the next opted in proposer in the look ahead. What I mean by this is like here you have P3 and like whoever can construct this L2 block it has to be limited to this guy. You don't want P2 or P1 to like just inject this L2 block in the L1 and like propose blocks because like that will damage the pre-confirmation

that this guy is proposing. Like he's saying that like include your transaction in specific position but if this guy just proposed their block, it kind of like ruins that pre-confirmation. So you want to limit the pre-confirmation to be only able to provide by this guy P3 this pre-confirm. So how you do that is you want to limit it in the L1. So you want and how you limit in the L1 is that like the L1 inbox contract or the L2 inbox contract which is where you actually post these L2 blocks in the L1 like you want to do something like this. So you want to fetch the next preconfer in the look ahead. So you have look ahead.ext preconfer and check that the the entity who called this proposed batch. So message sender of this function is

actual pre-confer. Now the big question here is like how do you implement this like get next pre-confer function and the issue here is that like in the EVM only past proposers are visible via historical beacon roots current and future proposers are not accessible. So let's say that you're in this slot like you can know that my historical like past proposers were this guy and this guy but in the EVM itself like you don't know who the proposers are with all this duration like offchain you wouldn't know like because as I mentioned before like you have the look ahead of like two epochs but onchain within the EVM you don't know like what the proposers are so you cannot do like this check easily

so to overcome this issue like you have we need some hack or like you need some way to make the AVM like know the look ahead. So one scheme that we have implemented is what we call optimistic look ahead scheme and this is what we implemented for the tao never mind preconf work our team worked on in collaboration with tao like what we do is we have the first pre-confer of the epoch optimistically post look ahead for the next epoch to an L1 contract so if you're like let's say that this is the first pre-confer in this epoch he will post the look ahead about the whole look ahead to an L1 contract. So because it's

posted to a L1 contract, the L1 will now have visibility against the look ahead. But this is optimistic like because like the L1 there's no way to check directly that this is correct because again they don't have visibility against the look ahead. But what happens is that the submitter is retroactively slashed if the look ahead is incorrect. So what they put some here if this is incorrect retroactively when like this epoch ends like at this point you can retroactively slash like check whether this look was actually correct or not and you can check because like as I mentioned like historical proposer this is available in the AVM. Okay. So like we had to implement this kind of hack and yeah this was one of the pain points but it was kind of like yeah manageable in a sense. But now here comes like another

issue that we found which is I call the look ahead instability issue. Okay what this is is that like I mentioned that you have two epochs worth of look ahead at the start of the epoch but this is like not completely accurate. And one thing and is that there's an edge case and this edge case is that like this look ahead of the next epoch like that you have access to or like have visibility against at this like epoch boundary it can change in certain edge cases. So like thought that it was proposer 33 but it can change to proposer 33 prime and what this edge case is like to understand this you will have to actually understand how the look ahead is actually calculated. Okay. So

like how is the look ahead calculated in the Ethereum L1 protocol and here like two factors are used to calculate the look ahead one is a randow so this is like a randomness seed that's available in the L1 this is like a source of randomness let's say and another factor is the effective balance the EB of validators this means that like each of the validator they'll have to deposit in to Ethereum to actually become like a validator and this effective balance is basically like the amount of balance that well they have deposited and is used when you like what the Ethereum sees as their balances and this balance

is important because like whether you're a proposer or your like will be proportional to how much effective balance you have okay so let's say that like to understand how the look ahead is calculated let's think of this like epoch how is this look ahead calculated And first like so there's two things the rando the rando like which rando was used like is one question and the rando used is like what's available the rando that's available at this epoch boundary that this point like the randomness seed to calculate this epoch look ahead is already available. So this is why like we can say that you have two epochs worth of look ahead because like the randomness is already like determined at this point at this point you have the

randomness seed to calculate this part. However like randow is not the only input here actually you also need the like effective balance and the thing is that effective balance is used from here. So what's available here? So like whatever the balances of all the validators are at this point is used to calculate this look ahead. Now as you can see see there like there's a mismatch between these two right which mean namely like the effective balance can change during this epoch and this is like the source of the instability that we're talking about here because the randomness is already determined the rando is already determined but the effective balance of the proposers that were in this look ahead can change and they can change in a way that like will change the look ahead because these two

are the input to calculating the look ahead and they can change in ways is and or yeah and like as a result of changing yeah the can change basically and one thing here or like how this can change is important and one thing to note here is the unpredictability is worsened due to the increase of max EB EIP 7251 as the EB of active outers can now grow beyond 32 E. So before like mostly like the EB of validators they're like pretty stable or like very stable I would say because like every validator you can only have 32 ETH like the

effective balance is capped to 32 ETH even if you're like like have some proposal rewards or attestation rewards during this epoch and it won't affect like the effective balance or it won't change the effective balance during this epoch because like it's capture 32. too. However, with the max EB change like now the cap of 32 E is removed which meaning that like if you attest or propose it during this epoch like as a result it can change the look ahead of this E. So like this is like one of the sources of the instability that like increased with max EB increase. Okay. Okay, so like one question here is like is this really an issue because like from preliminary

analysis like look ahead change due to EB change like remain rare like they are much like more possible than before when we didn't have the max EP increase but it is like still very rare because like attestation rewards are not that much and like the condition for this to happen like you have to actually bump the testation like the effective balance enough so that like you actually be be able to affect the look ahead here. But like the thing is here and like yes yes is that even if it is rare the rewards based look ahead changes are not provable onchain like unlike slashing which is like another source of effective balance change. So

consequentially the optimistic look ahead scheme breaks as we risk incorrectly slashing the honest look ahead submitters. So like even if it's like very rare that like this kind of thing actually happens like where the proposer look at changes like when it happens like we don't want to be slashing like an honest entity like that's very bad and that will disentivize like adoption of pre-confirmations at least in the this design. So yes it's still an issue even if it's rare. Okay. So those are the two issues that we had around the look ahead and here comes the EIP which is EIP 7917 the determinist proposer look ahead. Okay. So like the the idea here is very simple actually like as I mentioned here like what we have is this

like rand is used from this epoch boundary effective balance is used from this epoch boundary and there's a mismatch between this and this mismatch is the cause of the instability because the effective balance can change during this epoch. So let's just do this. Let's say that in this epoch boundary let's use a randow from here and also the effective balance let's use the values that are available here. So you align these two and based on like that you calculate the look ahead here and like how we do this is that we have introduced a new field in the beacon state. The beacon state is like the state of the consensus layer basically.

So it stores things like what the current slot is or like what the validator like set of validators are for example anything needed to like calculate the consensus is stored in the beacon state. And what we do is we introduce a proposer look ahead field in the beacon state and we pre-calculate and store the next epoch lookhead at the epoch boundary. So we add this field here and we pre-calculated epoch boundary and like one thing to note here is that because we added this to the beacon state it is accessible via the EVM in the EVM via the beacon route because the beacon route which is like the root of this the beacon state is accessible in the EVA. Okay. And a little more on like how we actually

calculate the look ahead is that at the start of each epoch the proposer look ahead is updated by shifting out the previous epox look ahead and upending the new one at the end. So before the epoch boundary let's say that like in this field you have like 28 97 63 and like this kind of like look ahead. These are like ids of the validators. And when you pass the epoch boundary, what happens or like at the epoch boundary, what you want to do is like you would shift out like this is the next epoch look ahead. You would shift in like this guys to the left and shift out this part because like that epoch has already passed and then you'll append like the new epox look ahead at the end and yeah that's basically this

is like the core logic of the whole EIP basically. Okay, conclusion. So conclusion like EIP7917 is a relatively simple change like I was able to explain it in like three slides and spec-wise it's also very small like it's like 22 lines of spec change ignoring the comments but have like large benefits like first and foremost like it unlocks robust pre-confirmation protocols by making a stable look ahead that is available in the EVM via the beacon via the beacon route which completely removes the need for hacks such as the optimistic look ahead scheme that we introduced before.

Furthermore, like it simplifies the proposer scheduling protocol like in general in the Ethereum protocol which simplifies the security analysis and the the consensus layer like client code cuz like you remove this like specific edge case where like the proposer can change in the next epoch and in general it just like feels natural I would say like it feels like a natural change and to like back this final point I would just want to share one quote here like this is one quote from Danny who is like the core architect of like the POSOS Ethereum and he's saying here that like is a discussion about this like look ahead instability and he saying that it was a

misguided design decision to give like less look ahead on proposers but in fact it just makes an edge case prediction in near zero cases but one you still have to account for and this edge case is exactly like this effective balance changes that can happen. So yeah and yes he's saying that he's misguided which like backs this like feeling natural part. Okay that's my presentation and yes if you have any questions feel free to ask. Very well. Thank you so much for this presentation. I really appreciate you sharing with the big picture like providing context on what is the issue why this proposal is there in place and also explaining how look ahead is

actually calculated. I'm sure that that will bring us to a few more [Music] questions. I already see there is a question in the chat here by Alex. Alex, would you like to read your question? Hello. Yes, sure. So, my question is actually what preconfirmation times can be as users expect in real world conditions and uh if you want to go to dive deeper, what different factors or what are the primary factors that could dictate the the actual latency? Like that's a good question and I think it really depends on like this

pre-confirmation protocol that you build but like theoretically you can just be like speed of light basically like this preconfirmation it can happen via an an RPC somewhere that you just call in and get an immediate preconfirmation and there can be other designs where like you can have like the proposer like precon actually like not individual transactions but like a batch of transactions and that have like some benefits um around like pricing and like and so forth But yeah, cerically it can just be like a speed of light basically. Did you have anything to add? I mean one piece of terminology that we introduced is the notion of a tick which is a segment of a slot. So one slot might be 12 seconds and then you have ticks which

is the the order of magnitude to do the pre-confirmations by the proposer and the tick size might be 10 milliseconds or 100 milliseconds. But you know as Lynn said at the very least you need to have the time it takes for the user to communicate with the proposer and receive a response and that's one ping time. So overall the total response time for preconfirmation is one ping time plus one tick. And if one ping time is roughly let's say 100 milliseconds and one tick is let's say roughly also 100 milliseconds then your total latency will be about 200 milliseconds. Okay, got it. Thanks. I see another question here with Tim Simona. Yeah. So, um thank you so much for the presentation. First

of all, I just wanted to ask like from a user's perspective like what are the steps that need to happen uh after the EIP implementation so that the faster perceived transaction times to become like widely noticeable in wallets and apps. Yeah. So like the primary use case right now or like at least what I had in my mind is like L2 preconfirmations and L2 like base rule of preconfirmations. So right now this is like basically tao and there's like a lot coming up right now and like for them I think you could basically like as soon as they upgrade and like actually enter based pre-confirmations and like you'll just

have faster UX basically like you'll have the comparable UX as you have in like current optimism or arbitrum for example like in the fastest case and like we're not sure like if we'll immediately get there because like one thing as you mentioned here is like for example like the wallet and like the whole infra structure adaptation on like handling this kind of like very fast preconfirmations. So like the approach that we're taking with psycho is that we first start with like L2 block preconfirmations cuz and L2 blocks like this concept of L2 blocks it already exists in like indexers. It already exists in wallets. So they're nothing new. It's just like very faster L2 blocks. So this is like a very nice first stepping stone here because you don't need to upgrade anything in the

infrastructure. you just have faster blocks and like everything just works. But yeah, once you want to get into that like 100 millisecond pre-confirmations like that will like complicate things in a sense that like the watts have to adapt to it like the indexes have to adapt to it and you need some route like routing protocol. So you find the next RPC endpoint and all that. I think that will yeah take time and I mean the way that I see it is that there's going to be two pathways to getting preconfirmations. As Lynn said, we can either have a rollup that starts as a base rollup and then enables preconfirmations for example Tao. But there's another approach which is that you can take a roll up with a centralized sequencer add preconfirmations there centralized

preconfirmations and then decentralize your sequencer and I think many more rollups are going to go down the second path. So for example, we have bass which has 1 second slots but they've on test net right now they have 100 millisecond ticks. So within one slot they have 10 ticks and that um dramatically improves the latency. Right now we have optimism which has two second slots. I expect them to have preconfirmations relatively soon. Inc. similar story and once they've d-risked all the infrastructure around preconfirmations that infrastructure is forward compatible with decentralizing the sequencer and so I'm expecting and and hoping that a lot

of the rollups will choose this common shared sequencer and in order for all of these rollups to land on the same place I think we need a decentralized sequencer which is credibly neutral. Right? If you have optimism that comes up with its own decentralized sequencer, is arbitrum going to opt in and vice versa. And the only credibly neutral shared and decentralized sequencer that I know of is Ethereum itself because it doesn't introduce a new token, a new brand or a new security assumption. And the good news is that once we've patched this UX latency aspect with pre-confirmations, it will be a relatively easy cell for the rollups to

to opt in to the base sequencer and therefore have shared sequencing and therefore unlock network effects that are otherwise not possible to have, especially through what's called synchronous composability where one contract in one rollup can call a contract in another rollup and get an immediate response and the typical example here is a that would call another contract like the UNISOP contract in order to immediately liquidate an open position because the oracle price has um gone under the liquidation price. These kind of network effects currently are broken down because of fragmentation at the sequencer level. Yeah, that makes sense.

Thank you so much uh Lyn and Justin. Cheers. Thank you for the question. Um my next question is with respect to the window of look ahead. I wonder if a longer look ahead perhaps 1 week or 1 month is feasible or useful. Why or why not? So yes it is possible to have a long look ahead. One of the constraints here is that it's going to affect how fast the validators will want to exit or can exit. Because if you have a one- monthl long look ahead window and you want to exit but you've already been selected then it's actually irrational for you to exit. And if you do exit then then it

leads to mislot which is something the protocol doesn't want. Is it useful to have a long look ahead? Yes, for two reasons. Reason number one is that you can build longdated futures. So you can think of a preconfirmation as being a shortdated future. meaning that you're making a promise. So you're basically selling a future, but the future is dated, you know, in the next few seconds. Longdated futures can be useful, for example, to hedge against the variation in the the base fees. So as a rollup, you know, I'm providing I'm basically reflecting the fee that I have to pay immediately on the L1 to users.

But if we had a week-l long look ahead, well, the rollups could buy up front in bulk, you know, block space and they could lock in a specific price that they would offer to users and it would be stable. The other reason for having a slightly longer look ahead, maybe from one epoch to two epochs or maybe three epochs, is that it increases the probability that there's at least one optedin proposer when a small percentage of L1 proposers have opted in. So this is trying to solve a bootstrapping problem. So in order to get preconfirmations off the ground with a one epoch look ahead, you need about 20% of the proposers to be opted in. And

that's something that you know is definitely possible to do and various largeish operators have signaled an interest to opt in. But if we were to increase the look ahead to two epox that number would go down to something like 10% and if it was a three epox it would be even lower. So, one of the things that I'm considering in the context of the beam chain is do we want to review the length of of the look ahead? And actually, I believe that Max from the Estus relay is also working on an EIP for the beacon chain to increase the look ahead to a few more epochs. That is very good to learn that the present window is perhaps

the optimized window as per the present scenario and in future if we have increased demand this can be considered. Thank you for that. I see there is another question in chat if you want to read your question. Yeah, you mentioned that the main issue for the instability of the look ahead comes from the discrepancy between Rando and the effective balance validator but can you recall when the US of Rando comes from please I'm sorry maybe I didn't follow thank you again for the presentation yeah sure so the randal value is taken from the epoch boundary just before P 0

in the slide that Lynn has has opened And the way that it yeah just before the the P 0 here. And the way that it works is that P minus one the entity before P 0 if they do produce a block they reveal what's called a randal reveal which is basically a secret that only they know and the rest of the world doesn't know. And then that revealed secret is mixed into what's called the randal mix. So you basically hash in this secret value and so assuming that P 0 has not previously revealed their secret to the world the randal mix at the epoch boundary is unpredictable to the whole world except for P 0 who wouldn't know

what this this random value is but I guess the way that rando is generated in some sense is is a detail that is not super relevant like the important thing is that there is a mismatch between the randal value that's used which is at the epoch boundary before P 0 and the effective balances snapshot that is being used which is the one before P32 and I can tell you that as designers of the beacon chain the intent was not to have this discrepancy so this is definitely a bug that was discovered postfacto and you know Lynn's EIP is a fantastic and very simple solution

to the problem and on top I would like to add if people are interested to learn more about Rando I believe there is an episode done by Mikuel Kalanin at the time of merge where he explained uh the calculation part of it as well so people can also watch the conversation over here hopefully that will be helpful all right I have one more question with respect to the proposal when we have any consensus layer proposal especially on sale side because uh that is related to like carrying money carrying ETH validator and all there are some consideration about the possible attacks. I wonder what types of threats

like DDoS or proposal collusions were considered and how does this EIP mitigate them? I would say that like this like this is a actually like a common question so thanks for asking it and like one of the concerns here is that like you have to look at it deterministic for 64 slots like wouldn't this be a DOS vector because like you have this whole look ahead that's available and the thing here is that like this EIP doesn't really change like the look ahead like the available look ahead right now it's already like this two box worth look ahead is already available for anyone in the network it's just that like one like it's not available in the AVM and two it's like in certain edge cases it can change but

it is an edge case so you you already have like a very very accurate like approximation of what the look ahead is so like whatever DOS vector that you have like through this a look ahead it's like existed before this EIP and after this EIP will like not change but this EIP is definitely not like worsening the situation there. Yeah, this entire EIP is a result of an edge case. So that is great. I see one more question in chat. TT if you would like to read the question for the guest. Oh yes, I wanted to ask if there is any edge case in which now to block would be full so that the user can get a precon during that

current slot. Yeah, that's also actually a very good question. So I like if this L2 block can be full. So like you cannot no longer provide preconfirmations here right and this can be one way to mitigate this is that like this pre-confer who is like ahead not far but like in the future look like look ahead this guy can actually post the L2 blocks like early on in like B2 or B1 through the Pokemon blue or like through some builder RPCs and like by doing that they don't have to like just fit all the L2 blocks in this specific like part of their L1 block they can spread it out into like these blocks. Especially important when like the pre-confer like is pretty sparse and like for example

one pre-confer has like 10 or 20 or 30 like worth of slots to precon 4 like they would want to like spread out the L2 block inclusion throughout the slots that they are like allocated to and that way like they prevent the fact like the situation where they just can't fit the L2 block they'll do transactions. I mean the other thing that I'll say is that there will be another pre-confer after P3. So it might be P7 for example and what the pre-confer can say if indeed they really have no more space available in their block is say I'm done with pre-config if you want a pre-confirmation go talk to the next pre-confer go talk to P7 and give him this message saying you

know that P3 is done. So it's kind of a a preconf chaining mechanism where you have the pre-MPS from P7 that are conditional on P3 settling its preconfirmations as it promised to to its users. Okay, there was one more question. Go ahead, please. Yeah. So I just wanted to ask um whether a proposer that has already been scheduled could basically renounce its role uh after issuing a pre-MP and in that case what would happen with the with the transaction that was premped in terms of scheduling not in terms of penalties and maybe a follow up to that if increasing the granularity of the look ahead

updates from epoch to slots would in any way help with predictability in the is proposer's job. So the proposer like oh first like whether it's possible for like this pre-confer to like be prior pre-confirmation then just say that hey I'm not going to be a proposer anymore like this is um right now not possible because like they are already like scheduled for being a proposer for this slot and there's not really like way to like say that hey I just don't want to be a proposer anymore and like I'll opt out and this is especially the case like once we like have this EIP and like the proposer is like 100% deterministic like there's no way that like once you're

allocated in a specific slot here that you like say that hey I don't want to be a proposer anymore but like in a very very like small edge case that we were talking about it might be possible that like you are a proposer here and you provide free confirmations and you say that I don't want to be a proposer anymore and you like somehow change the effective balance in some way here so that you don't be a proposer anymore and like you can like not be slash for example but and this is a very small edge case and it's we're not even sure if this is possible like it's probably not but it is an case to consider when we are thinking about undeterministic look at that we have right now and what this EIP does is it makes this part completely deterministic so they

completely like say that this is not possible like if you're a proposer because you're a proposer you're 100% going to be a proposer and there's no way that you can opt out so that's like actually another hidden like benefit of the CIP yeah I guess like that's kind of like answered here Because yes this itself is not an issue and if you have like look ahead of like one slot then yeah be conf like be very hard to do because like you don't have the look ahead and you don't know who the next opted in proposer is. Thank you for sharing that. I know this is like very interesting session very knowledgeable as well but I would like to make it a little bit more fun for people who are watching this to know you more to maybe know your views on Ethereum ecosystem.

So uh let's move towards another section of uh this uh conversation which is called rapid fire [Music] round. In this round what we generally do is try to collect answers from you in 1 minute or so. You can respond in one word or options if there are any. All right let's start with Lynn. Your favorite programming language? Okamo.

One word to describe your coding style. Minimalistic hacky elegant pragmatic. I would want to be pragmatic, but sometimes I find myself trying to be elegant. Not actually being elegant, but like trying to be elegant and failing. What's the first thing you check in the morning? GitHub, Telegram, email, or Twitter? Twitter. Dark or light mode? Dark. Best part of working on Ethereum? Community? Innovation, open source or freedom community CLI or GUI used to be CLI but recently because the AI editors like much more GUI focused so GUI a project you admire in the ecosystem. Tao and the last one here is favorite side

project or hobby outside blockchain. One side project that I have is Game Boy Emulator. I write it in Okamel and it actually runs in the browser and yeah, recently I haven't been able to hack around it but sometimes I yeah it's fun like working on it. Thank you so much Lynn. I have my next set of questions for Justin. Your favorite EIP that is not authored by you. I mean I've only offered two EIPs. I guess I do like EIP559 that introduced the burn. Yeah, one of the most popular EIPs. Well, my next question is a bit tricky. Vitalic in one word. Genius. Visionary. The layer you love most. L1, L2, L3, all of

them. L1. The next one is quantum computer in 2030. Yes. No, maybe. Yes, but they won't break cryptography. Where do you like to spend more time? Specs, podcast, research, or community? I do enjoy podcasts because they're a forcing function. So when I get invited to a podcast, I usually mle over it for several days before the podcast. So I do spend a lot of time there. But I am looking forward to writing the beam specs and spending a lot of time there as well. Rollups are future. Yes, no, or too soon to say. So this was actually, you know, the content of some of my recent tweets. I think rollups are

necessarily part of the future of Ethereum just because the L1 is bottlenecked. The L1 EVM instance can only do so many transactions per second because the EVM itself is kind of this this single threaded machine which has these sequential bottlenecks. So maybe we can push the EVM to 10,000 TPS, maybe to 100,000 TPS, but it seems very very unlikely that we can get a million TPS, let's say. And the world just needs more than a million TPS. I think we need maybe closer to 10 million TPS, let's say. And the only way to provide that is through horizontal scaling. And I think this is where the L2s will will play a role. And to try and quantify this, I believe that if we are to max out the L1

EVM and max out the L2s, the rough ratio will be roughly a,000 to1. So the L2s will provide a thousand times more capacity than the L1. So I think the L1 is is extremely important as a settlement layer, as a bridging layer, as a source of uh unified liquidity, as the shelling point for the shared sequencer, also as the shelling point for the execution. But uh ultimately I think uh a lot of the activity will be on L2. Very well. My last question for you is favorite ETH event where people can follow you. Events which are organized by local ETH community like

ETCC, ETH Denver, organized by Ethereum Foundation like Devcon connect, Devcon or organized by outside Ethereum community like uh Coindesk. Yeah. So um I really like CCe which is not very well known is the Colombia cryptoconomics conference. It's organized with Colombia University and the FM Foundation and it's very much focused around economics. I also very much like ECC. The problem with ECC is that there's so many events and I get to run around the city like like a headless chicken. So, it's very exhausting. Defconnect, it's a similar vibe. And uh Defcon, I think, is one that I enjoy the most because there's

not that many events, right? Defcon is the the main event and so I I get to enjoy more more of the content that's presented there. Thank you so much for answering all these questions. Uh we are heading towards the end of this uh conversation today. Is there any message that you would like to share from this platform? I mean in general I'm a very very you know optimistic person and I guess I want to share a message of optimism. um that I believe you know the the future of Ethereum is extremely bright in many many different metrics. I think the whole story around pre-confirmations are going to give us optimal UX right something close to speed of light close to to ping

latencies. I think we're going to be able to scale the blobs and scale the L1 so that there's capacity for everyone in the world for the whole of internet finance. And I'm also hopeful that the traditional world of finance will migrate onchain specifically onto Ethereum. And we're talking, you know, tens of trillions, hundreds of trillions of dollars. And I'm also hopeful that Ethereum as a platform will be able to withstand the total value secured on top of it. In doing so, I think it will require large amounts of economic security, trillions of dollars of

economic security. And so that means that the total value of the stake teeth has to grow and ultimately that also means that the value of E has to grow. So I've been in the space for about 10 years now. Um, and I'm very very optimistic to see how the next 10 years pan out. Yes, I am optimistic as well. Yeah, let's hope that we have a brighter future ahead. Lynn, I wonder if you would like to add something how people can maybe be able to support this proposal or anything in general that you would like to share from this platform.

Yes, like any support for this EIP like we are aiming to be included in the next Faka fork, but it's still like in discussion. So if you're supportive of this, if you can raise a voice or something, that would be very helpful. And like actually very very interesting writing an EIP. This was my first EIP writing experience. And I actually had like kind of goosebumps when I was writing it. Like as Justin was mentioning, it's like the Ethereum is like the internet computer and the internet finance and like being able to like write code like it's not the actual client code that's going to be executed, but it's like the logic there like is going to be included there and run there. I was like like super cool and I'm very very honored to be able to like

participate in this. So yeah, it was very interesting and yeah, thanks Justin for like this. Thank you Lynn and Justin. I'm sure I may not be able to help you with like your spec writing experience but in case of EIP writing experience if you face any challenges or any roadblocker there we are happy to help. We do organize multiple meetings. One of them is called as EIP editing office hour to provide support to new authors and yes if there are any question we would be happy to help you around that. Well, that's a wrap on our deep dive into EIP7917. Huge thanks to Lynn and Justin

for sharing their insights. Viewers and listeners, be sure to check out the discussion thread and specs link in the show notes. Until next time, keep building the perfect ecosystem. This is Puja Ranjan signing off. Thank you everyone.