# Time in Ethereum - on the implications of replacing our dear friend Poisson - Channel: [Devcon](https://streameth.org/devcon) - Date: 2023-10-07 - Duration: 30:22 - Watch: https://streameth.org/watch/yt-gsFU-inKRQ8 - YouTube: https://www.youtube.com/watch?v=gsFU-inKRQ8 ## Description Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more. https://archive.devcon.org/archive/watch/6/time-in-ethereum-on-the-implications-of-replacing-our-dear-friend-poisson/ Time in PoW is a random process, whereas in PoS we make progress in fixed time intervals. This has far reaching implications and incentivizing timely behavior by validators is non-trivial - especially in the context of MEV. Speaker(s): Caspar Schwarz-Schilling Skill level: Intermediate Track: Layer 1 Protocol Keywords: L1 research,reorgs,fork choice Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum Learn more about devcon: https://www.devcon.org/ Learn more about ethereum: https://ethereum.org/ Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022. Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/ ## Transcript foreign [Music] I'm with the ethereum foundation working as a researcher at the robust and centers group we kind of work on anything in centers which is in ethereum's 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 a bit clarify what I intend to talk about as you probably all know in proof of work ethereum block production was a random process called AKA plus all process hence the subtitle implications of replacing our dear friend prosor and which basically means nothing else that other than that at a constant average rate a miner 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 ethereum as we heard already blocks show up every 12 seconds like clockwork so there's no Randomness in this round time but blocktimeness doesn't necessarily uh that does necessarily is it's not necessarily 12 seconds but so basically this difference in Randomness versus deterministic time may not immediately appear as 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 improve of stake having these slots and a single proposal for each slot we kind of give this proposer some kind of Monopoly guaranteed Monopoly and this Monopoly power can kind of be at least screwed 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 um time is funny business very confusing um 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 and proof of work um this progress was random in time sometimes blogs 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 um 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 valuable 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 propositions up like here in slot n um we we just chug along people will vote for it next slot comes along we build on top of it and then here we have the scenario that was discussed um 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 Miner tries to create a block but on average only one minus succeeded every 13 seconds roughly improved working theorem and importantly you don't actually know who will win the next round improve of stake this random selection needs to be explicit now clearly there is no true Randomness in a blockchain since all notes must come to consensus on it and so different notes calling random a Randomness function will just 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 seat 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 pseudor Randomness on chain to sign and schedule duties and the 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 ethereum we chose this arbitrary parameter of 12 seconds as our block time it's not completely arbitrary because obviously things like latency Etc and block processing are considered but it could have been 11 or 13 um and it would probably work just fine um now to kind of boil this down a bit more heavily in proof of work we are fed this exogenous Randomness into our system um which gives us this random block time and in proof of stake we have to generate um this Unchained pseudor Randomness um giving us this notion of uh deterministic time in ethereum and to make it even more blunt basically you can think of proof of work as a continuous race um 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 improve 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 the proposer has and can abuse so uh yeah basically um this nice graph by Martin here not sure if he's here but I saw him earlier um essentially it's it's about block time around the merge you can easily see here yeah improve of work obviously you have this very large variance 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 um 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 um illustrates it quite well and I want to kind of continue on it vitalik here notes basically um I'm actually in the way am I not basically it's immediately obvious that this block time is less volatile and there's less decreased volatility means that the Galaxy Market is more stable and as vitalik points out basically eip1559 works better since um we hit the 2x gas limit of 30 million gas less often and basically removing this huge variants of block time leads to a more stable gas free market with fewer people overpairing compared to yeah when basically basically 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 uh basically just visualized again it's not as immediately obvious but you can basically see um the the gas limit is not hit as often in the second half of the plot um 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 translates throughout the stack on the P2P layer in terms of messaging load Etc so there are huge benefits to this constant progress um that we make in proof of stake ethereum but obviously that's not the end of it otherwise I wouldn't be talking about it probably um 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 the block um 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 um 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 testers voting for what they consider as head of the chain and then we have the aggregation phase which we can kind of ignore which is the way of efficiently packaging attestations so that we can actually fit them on chain um so the honest validator spec guide basically specifies that a valid data is expected to propose a signed beacon block at the beginning of any slot during which is proposal yada yada returns true so basically if you're the valid the elected proposal proposal block at the beginning of the slot um so zero seconds into the slot ideally now then the next phase is basically testing um and we have this test 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 Block's 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 um and in order to know what to test for these testers run our beloved fog choice I see photos here um and basically um dysfacturer's rule is um 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 um the foxes is a flavor of lmd ghost which stands for latest message driven greediest heaviest observable subtree which is a mouthful but it really intuitively is quite simple if you look at the Block tree here um 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 um but now basically the committee in N plus 2 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 rule basically tells you to walk down the block tree and go down the heavier subtree which means basically going down the path path where more votes have been accumulated and here you can see that block n plus 1 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 name plus two you will vote for n plus one um and then n plus three sees these words and uh makes a similar decision and so basically n plus two gets kicked out of the chain um now um 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 were on the P2P layer receive them at different times probably one seconds in two seconds probably everyone has heard it um but so as long as you hear the block zero or four seconds into the slot um a vlog is basically considered on time in terms of a testing because you you hear about the block before a validator test so in this case nothing really happens business is usual but the more interesting case is what happens if the block proposal is really late say 11 seconds into the slot um essentially as you can see here 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 1 comes along and once we get to the next slot block n plus 2 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 fog Choice um The Weight by is the weight of block n is actually inherited by block n plus one and so n plus 2 will extend that chain um for a good reason actually um so we have maybe to go back how does this here we go um so what basically happened here um we have a very late block proposal 11 seconds late um why is this bad this is bad because it simply unfair to the next block proposal why because basically listening time to the transaction mempool is valuable transactions have transaction fees priority fees but obviously Mev dramatically increases this uh notion of unfairness in this sense that more listening time to the mempool basically gives you more transactions to extract Mev 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 um that my previous proposal didn't have available to include in their blog I'm worth off um and so basically anyone following the honest spec guide will actually um have less Mev to extract now that obviously can lead to centralizing effects that if you're not a sophisticated proposer you uh yeah you simply earn less than sophisticated once so what can we do about it um essentially there's I think roughly three categories to think in um one is containing this Monopoly power right now basically you can release the 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 a 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 proposals 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 proposal 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 um in a world where we have attestations with thousands of attestations happening each slot um what can we do there's some Fork Choice fun that we can do today for reasons unrelated to this is proposal boost and essentially proposal boost is a is um is it called is is something that the fox it's like part of the fork choice where if you propose a block on time the block will be treated as if it had already received 40 of a commit of committee votes basically you have a head start in terms of fork Choice weight but only for the duration of the slot um now how can we basically use this um to defend against this quote unquote guaranteed Monopoly um 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 um doesn't inherit in time before they test and so they vote for Block n 70 and 30 inherit before they test so they test 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 re-org 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 we you can basically overpower the blog 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 um being able to release your block late while still becoming canonical because if you release up at four seconds at test this will have already voted and you won't manage to accumulate at least 40 percent of the attestations and some clients are actually starting to work on this I actually saw Michael sprawl made a commit earlier who unfortunately could make it to Defcon this year um Fox Choice fund that we can do tomorrow or in some time is basically a similar idea block slot voting um where we also basically soft and force this four second deadline um here it it works a bit differently um 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 um 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 um 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 um 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 two The Proposal runs the four choices 60 versus 40 and so they will vote for the 60 um now um yeah there's some ones that I could add but I think in terms of time I I need to keep going um another idea that I mentioned briefly is that um why don't we try to incentivize timeliness explicitly today a Blog proposal is basically they're rewarded in proportion to the profitability of attestation they include in their blog so basically attestations that already exist floating around um this the fresher they are the better and so they are included 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 um but why don't we try to incentivize timeliness now the obvious problem is basically what does timeliness mean in terms of uh on chain um like how do we Define timeliness on chain um 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 um 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 log proposal seems to be on time such that a hundred percent of the committee votes for that block um 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're on time nice good um block n plus one for on the other hand seems to be slightly late only 90 vote for that block ten percent probably didn't have didn't hear it in time so they vote for Block n um now in with this idea what we would basically do is scale the reward as of today by a factor of 0.9 effectively decreasing um the reward ideas basically um to punish people for being too late um now some um like what I want to say is basically that it should be incentive compatible in the sense that the next proposal is also incentivized to include these attestations on chain um because they're fresh and so they're more most profitable and I don't see an immediate way to basically grief um one way or the other essentially another the the one problem that it does have is that Mev rewards may actually be able to dominate these timeliness rewards um 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 um we could think about using that Oracle to scale timeliness rewards to ensure they are dominating Mev effects based basically making sure that the timely in the rewards are big enough to fight off any kind of Mev Dynamics but honestly seems like a dangerous path in terms of making consensus decision decisions on some Oracle like that um basically in short um 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 is 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 will certainly certainly be thinking about it more going forward as well and yeah thank you and if any of these kind 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 foreign audience now is your chance yeah yeah over here please talk into the microphone for the Stream um thank you for the presentation um 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 build proposal there are some other stays right where you will get like a 40 percent boost of the votes if you are enough in time how do we deal with time actually being subjective to validators as you understand there's no global view of time of such granularity between the validators so we have them globally distributed and latency and all that like how does that not result in us getting a lot of chain splits um if I understand correctly yes there's no Global notion of time it's essentially a local property of your node 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 yep hi thank you um so I had two questions one was uh on the one of the later slides about incentivizing timeliness um kind of reducing the reward for uh proposure 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 um you only have the current chain State and you kind of only go back to the one that already happened or I didn't catch the last part so you're saying why don't we give the the part that we subtract from the current proposal to the proposal of the next slot yeah to the child rather than the parent um you mean and the idea would be to to basically because the Block's laid but still becomes canonical um to kind of compensate for the lateness of the previous block yeah um might be a fun thing to actually think about I don't know yeah okay I mean to be honest this is more of an idea at this point um it's not a formalized proposal but it's more like putting out ideas um of how to think about timeliness um going forward but okay and then uh one more question is uh to better understand uh why more validators don't propose their block late uh 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 [Applause]