 I'm Kasper. I'm with the Ethereum Foundation working as a researcher at the robust incentives group We kind of work on anything incentives, which is in a theorems case a good excuse to Kind of look at anything you're really interested in and centers are all over the place I'll be talking about time in Ethereum in particular I mean this talk title talk talk title is a bit mysterious So let me maybe bit clarify what I intend to talk about As you probably all know in proof of work a theorem block production was a random process aka process hence the subtitle implications of replacing our dear friend for saw and Which basically means nothing else that other than that at a constant average rate a minor would find a new block Sometimes it takes three seconds sometimes 13 or 23, but on average roughly 13 and and today in proof of stake a theorem as we heard already Block show up every 12 seconds like clockwork. So there's no randomness in this round time but block time this doesn't necessarily It doesn't necessarily is it's not necessarily 12 seconds, but so basically This difference in randomness versus deterministic time May not immediately appears a big deal But it comes with some implications that I want to explore There's some good and some bad implications At first hand it might seem that it should only or predominantly be good In terms of load balancing the gas fee market should be a bit more relaxed, etc But basically in proof of stake Having these slots and a single proposal for each slot we kind of give this proposal some kind of monopoly guaranteed monopoly and This monopoly power can kind of be at least good to some extent to the advantage of the proposal If that doesn't make sense right now Hopefully it will at the end of this talk. So what the hell is time? Time is a funny business very confusing At least for me, but when I talk about time in this talk, I don't intend to be clever or philosophical about it I really just mean how do we make progress in in our chain in proof of work? This progress was random in time Sometimes blocks come up very quickly after three seconds or 20 seconds, but on average 13 seconds in proof of stake it's constant every 12 seconds assuming that a block proposal shows up and Basically when I talk about deterministic versus random time I talk about how we make progress in our chain That's kind of it. Now. How do we make progress in? Ethereum today it really is quite simple We have this available chain Which we then try to finalize But for this talk we can safely ignore the finality gadget that lives on top of this available chain and just look at how the available chain grows and Again, we have this time unit called slots, which is 12 seconds long And so every 12 seconds we slot and so When the block proposal shows up like here in slot n we Just chug along people will vote for it next slot comes along we build on top of it And then here we have this scenario that was discussed If the block proposal doesn't show up, that's okay The next block will just build on the previous block simple enough I want to kind of briefly touch upon where does this deterministic nature of time actually come from and So basically in any proof-of-stake system, we need a mechanism to select a proposal for a block from a set of bonded validators and In proof-of-work, this is clearly happening randomly just by nature of it being a race Every minor tries to create a block, but on average only one minor succeeded every 13 seconds roughly Improved work in theorem and importantly, you don't actually know who will win the next round in proof-of-stake This random selection needs to be explicit now Clearly, there is no true randomness in a blockchain since all nodes must come to consensus on it and so different nodes calling random a randomness function which is create chaos by Basically outputting different results in each case so instead what we do is we generate pseudo randomness on chain from a seed that is computed and updated as part of the blockchain and The challenge is basically to make this seed unpredictable now for the purpose of this talk We can safely treat it as a box and just pretend it works. It actually does and So essentially what we do is we generate pseudo randomness on chain to sign and schedule duties and this sequence of duties is scheduled deterministically so we as as validators We need to agree on a view of when duties are scheduled and also of their time And so in a theorem we chose this arbitrary parameter of 12 seconds as our block time It's not completely arbitrary because obviously Things like latency etc. Block processing are considered, but it could have been 11 or 13 And it would probably work just fine Now to kind of boil this down a bit more heavily in proof-of-work we are fed this exogenous randomness into our system which gives us this random block time and in proof-of-stake we have to generate this on-chain pseudo randomness giving us this notion of deterministic time in a theorem and To make it even more blunt basically you can think of proof-of-work as a continuous race You never know who will win and when could be anyone at any time whereas in proof-of-stake we have the scheduled sequence of duties and This different this difference here already implies what the core of the problem is that I will talk about in proof-of-work There's no notion of late whereas in proof-of-stake there is you can basically show up late for your duties such as block proposing and You can basically show up late, but early enough to still become canonical and that's basically the wiggle room that a proposal has and can abuse so Yeah, basically this nice graph by Martin here. Not sure if he's here, but I saw him earlier Essentially, it's it's about block time around the merge. You can easily see here Yeah, in proof-of-work obviously you have this very large Variants in block time and as soon as we hit merge we have this very boring beautiful 12-second slot time Block showing up beautifully until there's one missed slot So block time jumps up to 24 seconds once, but that's kind of it now That's let's think about the implications of this deterministic time and this plot really kind of Illustrates it quite well, and I want to kind of continue on it. Vitalik here notes basically I'm actually in the way. I might not Basically It's immediately obvious that this block time is less volatile and this less decreased volatility means that the gas fee market is more stable and as Vitalik points out basically EIP 1559 works better since we hit the 2x gas limit of 30 million gas less often and Basically removing this huge variance of block time leads to a more stable gas fee market With fewer people over pairing compared To yeah, when basically base fee hikes hits the limit every time There's a block that shows up after a long time in proof-of-works case. So Basically There's another tweet here by Barnaby who's sitting right there Basically just visualized again. It's not as immediately obvious, but you can basically see The the gas limit is not hit as often in The second half of the plot and essentially we can just summarize this as better load balancing And I've now talked about transaction load balancing essentially But this really kind of translate throughout the stack on the P2P layer in terms of messaging load, etc So there are huge benefits to this constant progress That we make in proof-of-stake is here, but obviously that's not the end of it. Otherwise, I wouldn't be talking about it probably Essentially proposes can abuse their guaranteed monopoly power and What I really mean is that What do I mean by guaranteed monopoly? I mean that in proof-of-stake There's only a single unique validator that has the right to propose a valid block in a in a given slot and improve of work that obviously is not the case and this Guarant basically Now that we have this unique proposal that is allowed to propose a block For the duration of a slot. There's this leeway of timing your block that is possible But before going there I need to briefly introduce some ethereum basics and Basically a Slot, there's something several things happening on the one hand We have a block proposal on another hand We have a committee of a testers voting for what they consider as head of the chain And then we have the aggregation phase which we can kind of ignore, but it's just a way of efficiently Packaging at the stations so that we can actually fit them on chain So the honest validator spec guide basically Specifies that a validator is expected to propose a signed beacon block at the beginning of any slot during which is Proposer yada yada yada returns true So basically if you're The valid the elected proposal proposal block at the beginning of a slot So zero seconds into the slot ideally now then the next phase is basically testing And we have this attest Attestation deadline four seconds into the slot which basically the rule or the spec says a Test as soon as you hear a valid block or four seconds into the slot whatever comes first So if the slot if the blocks on time you hit after one second You immediately attest to it if you don't hear anything until four seconds you attest probably to the previous block that you heard and In order to know what to attest for these attesters run our beloved fork choice. I see photos here And basically this fork choice rule is a Function that takes as input the block tree and some previous attestations and gives you the head of the chain as Output that you will then vote for or build on top of if you're a block proposal so The fork choice is a flavor of LMD ghost which stands for latest message driven greediest heaviest of double the subtree which is a mouthful But it really intuitively is quite simple if you look at the block tree here Essentially as long as there's no fork you just yeah, you just extend the the chain And here you see the scenario once we get to n plus one Extending block n easy, but then comes n plus two and for whatever reason the proposal is on top of n creating a split in the block tree Now that might happen if the proposal was offline for whatever reason But now basically the committee in n plus two has to make a decision will I vote for block n plus two or will I vote for block n plus one and the LMD ghost will basically tells you to walk down the block tree and Go down the heavier subtree which means basically going down the path where more votes have been accumulated And here you can see that block n plus one actually accumulated a hundred percent of the votes in that slot And so it's heavier than block n plus two and so as the committee in n plus two you will vote for n plus one And then n plus three sees these votes and Makes a similar decision and so basically n part n plus two gets kicked out of the chain Now now we have the basics and so let's talk basically about what the proposal can do I've mentioned it. It's basically about timing their block releases and There's basically different notions of on time like Ideally you release your block zero seconds into the slot then some validate like notes will on the p2p layer receive them at Different times probably one seconds in two seconds probably everyone has heard it But so as long as you hear the block zero or four seconds into the slot A block is basically Considered on time in terms of a testing because you've you hear about the block before a validator tests So in this case nothing really happens business as usual But the more interesting case is what happens if the block proposal is really late say 11 seconds into the slot essentially As you can see it as you can see on this diagram you have this attestation deadline four seconds into the slot and Because they haven't seen a block yet. They will just vote for block n now at some point block n plus one comes along and Once we get to the next slot block n plus two has to make a decision on what block to extend On what basically to build on block n or n plus one You might think that n plus one shouldn't become part of the chain because no one actually voted for it But in terms of folk choice The weight by is the weight of block n is actually inherited by block n plus one and so n plus two will extend that chain for a good reason actually So We have maybe To go back. How does this here we go? So what basically happened here? We have a very late block proposal 11 seconds late Why is this bad? This is bad because it's simply unfair to the next block proposal. Why? Because basically listening time to the transaction mem pool is valuable transactions have transaction fees priority fees, but obviously Mev dramatically increases this Notion of unfairness in this sense that more listening time to the mem pool basically gives you more transactions to extract me V from which basically means that if as a block proposal, I only have two seconds worth of Listening time that my previous proposal hasn't That my previous proposal didn't have available to include in their block. I'm worse off and So basically anyone following the honest spec guide will actually have less me V to extract now That obviously can lead to centralizing effects that if you're not a sophisticated proposal you Yeah, you simply are less than sophisticated once so what can we do about it? Essentially, there's I think roughly three categories to think in One is Containing this monopoly power right now basically you can release a block at the end of the slot What about making it so that we can kind of enforce a shorter time frame where block can still be released? But become canonical I will go through some things in the second another one is explicitly incentivizing timeliness Which we currently don't do in our protocol And the third one is I'm not actually going to talk too much about but is Trying to think about how can we maybe introduce competition to propose this again? In the sense of right now, we have this guaranteed monopoly Maybe there's a way the protocol can introduce some notion of competition where the proposer can't rest assured that They have 12 seconds to release their block But that would require like fundamental changes to the protocol And I'm actually not entirely sure if it even is possible in a In a world where we have attestations with thousands of attestations happening each slot What can we do? There's some folk choice fun that we can do today for reasons unrelated to this is proposal boost and Essentially proposal boost is a is a Is a card is something that the fortune it's like part of the folk choice where If you propose a block on time The block will be treated as if it had already received 40% of a Committee votes basically you have a head start in terms of folk choice weight, but only for the duration of the slot Now how can we basically use this to defend against this? quote-unquote guaranteed monopoly Here in this scenario we see block n plus one is Relatively late around the four second that it's released around the four second deadline such that some of the committee that votes Doesn't hear it in time before they attest and so they vote for block n 70% and 30% hear it before they attest so they attest for block n plus one now Block n plus two basically with proposal boost has an option They can choose to either extend the chain by building on top of block n plus one Or they can try to reorg it out by building on top of block n and because of this proposal boost we actually have The power because 30% greater than 30% you can basically overpower the block proposal of n plus one and Reorg them out and essentially what this does is it enforces a kind of soft four-second deadline in terms of Being able to release your block late while still becoming canonical because if you release up at four seconds Attest this will have already voted and you won't manage to accumulate at least 40% of the attestations and some clients are actually Starting to work on this. I actually saw Michael sprawl made a commit earlier who unfortunately couldn't make it to Defcon this year Forkshaw is fun that we can do tomorrow or in some time is basically similar idea block slot voting where we also basically Soft enforce this four second deadline and here it works a bit differently Essentially what we're trying to do is that if I don't see a block Instead of just voting for block n like I did previously. I basically Vote for block n while also saying I want to vote and enshrine emptiness. So here what you can see is Block n you basically in block n plus one you vote for block n with the information that this is from slot n plus one and Essentially what you're doing is you're creating a fork that competes with this late block then and you have the similar effect that now instead of the 60% voting for block n In like on this side here You have them vote on this kind of block which is not a new block as such in terms of transactions But it's just like saying I want to enshrine emptiness and now block n plus to the proposal runs the fork choice these 60 versus 40 and so they will vote for the 60% now Yeah There's some nuance that I could add but I think in terms of time I need to keep going Another idea that I mentioned briefly is that Why don't we try to incentivize timeliness explicitly? today a block proposal is Basically, they're rewarded in proportion to the profitability of attestations they include in their block So basically attestations that already exist floating around This the fresher they are the better and so they include it and these incentives are good because we need to make Create incentives for them for the attestations to actually land on chain so that we have this notion of finality on chain but Why don't we try to incentivize timeliness now the obvious problem is basically what does timeliness mean in terms of? on chain Like how do we define timeliness on chain? And an idea could be to scale the proposal reward by the share of same-slot attestation Attestations that the block receives and are included in the subsequent block now that sounds More complicated than it has to be Essentially the idea is we have block rewards as of as today and we scale them by The share of same-slot attestations what I mean is here in slot n Block proposal seems to be on time such that a hundred percent of the committee votes for that block And so what we would do in this with this idea is we would scale them by a factor of one So nothing changes you on time nice good Block n plus one fall on the other hand seems to be slightly late only 90% vote for that block 10% probably didn't have didn't hear it in time. So they vote for block n Now in with this idea what we would basically do is scale the reward as of today by a factor of point nine effectively decreasing the reward ideas basically To punish people for being too late now some like What I want to say is basically that it Should be incentive compatible in the sense that the next proper poser is also incentivized to include these attestations on chain because they're fresh and so they're more most profitable and I don't see an immediate way to basically grief One way or the other essentially another the one problem that it does have is that MEV rewards May actually be able to dominate these timeliness rewards That is probably In some cases always going to be true But regardless, I think rewarding timeliness Makes intuitive sense regardless of this problem as such. It's just it just seems like it's a bit strange that we actually don't do it in my opinion And a spicy hot take that I don't actually personally agree with would also be something like in a world of MEV smoothing Where we have an on-chain Oracle of MEV of the value of MEV in a given slot we could Think about using that Oracle to scale timeliness rewards to ensure they are dominating MEV Effects basically making sure that the timeliness rewards are big enough to fight off any kind of MEV dynamics but honestly Seems like a dangerous path in terms of making consensus decisions on Some Oracle like that and Basically in short We can summarize this as load stability being a good thing and a guaranteed monopoly being a bad thing Thankfully we have things we can do about it and Things we can do today's things we can improve going forward even further and Yeah, I just wanted to kind of put this out there a bit more and I was certainly certainly be thinking about it more going forward as well and Yeah, thank you. And if any of these kinds of incentive games are of interest to you then Yeah, the robust incentives group is actually hiring right now. So feel free to reach out and Apply if you feel like it. Thank you if there are any questions so many audience knows your chance. Yeah over here Please talk into the microphone for the stream Thank you for the presentation I'm just curious about the fork choice rules like Currently as a validator I will either sign something or I will not if it's too late, right? But if we're looking at the PB proposal, there are some other States right where You will get like a 40% boost of the votes if you are enough in time How do we deal with time actually being subjective to validators as I understand? There's no global view of time of such granularity between the validators And we have them globally distributed and latency and all that like how does that? Not result in us getting a lot of chain splits If I understand correctly yes, there's no global notion of time. It's essentially a local property of your note and There needs to be some notion of being synchronized with your peers in that sense. Yes But it's a local property Okay, another one in front here over here I Thank you So I had two questions one was on the one of the later slides about incentivizing timeliness Kind of reducing the reward for Proposer that proposes their block a little late. Why would we not give the subtracted reward to the Next proposer given that they were the ones kind of I guess robbed of some MEV opportunity. Is that kind of a problem of just You only have the current chain state and you kind of only go back to the one that already happened or It didn't catch the last part. So you're saying why don't we give the The part that we subtract from the current proposer to the proposer of the next slot. Yeah to the child rather than the parent You mean and the idea would be to to Basically because the blocks late but still becomes canonical To kind of compensate for the lateness of the previous block. Yeah Be a fun thing to actually think about I don't know. Yeah I mean to be honest. This is more of an idea at this point It's not a formalized proposal, but it's more like putting out ideas of how to think about timeliness Going forward, but okay, and then one more question is To better understand Why more validators don't propose their block late like what is the additional incentive for proposers to? Propose their block on time like we're discussing potential ideas for it, but I guess in the current state. Why do more validators not propose late? Good question. Okay Thank you Thank you, customer. Thank you so much station