# Time in Ethereum | Caspar Schwarz-Schilling (February 2023) - Speakers: Caspar Schwarz-Schilling - Channel: [Berlin Ethereum Meetup](https://streameth.org/berlin-ethereum-meetup) - Date: 2023-10-07 - Duration: 35:17 - Watch: https://streameth.org/watch/yt-Zfqvke8BNhM - YouTube: https://www.youtube.com/watch?v=Zfqvke8BNhM ## Description Join us on Meetup to keep track of our events in Berlin: https://www.meetup.com/de-DE/berlin-ethereum-meetup See you at the next one! --- Apply to speak at our next meetups: https://forms.gle/bGXFc83MHAcnmMQM6 ## Transcript yeah hi I'm Casper I also work at the robust and centers group anyways long story short I'm going to be talking about the difference um between time and what that kind of implies and some of the good things and the bad things um right so what the [ __ ] is time it's complicated I'm not going to intend to be clever about it um in this talk what I mean but when I talk about time in the context of this talk is simply how do we make progress in our chain improve work it's random sometimes it took three seconds sometimes 20 but on average roughly 13 and then proof of stake we have these slots that happen every 12 seconds and that kind of works like clock time um Clockwork um yeah I know you don't have a question okay yeah not yet um so um some kind of ethereum Basics I mean ethereum basically is a composite of the available chain and some finality gadget on top in this talk we're kind of only concerned with the available chain and the way we make progress is basically slots um every 12 seconds there's a seconds there's a new slot and if everything runs smoothly usually um basically at the beginning of slot n a proposal will show up propose a block then there's a bunch of validators voting for what they see as the head of the chain and if the Block's valid and on time then you attest to it and then the next proposal 12 seconds later comes in and proposes their block on top of block and and so we extend the chain and here in slot M plus two for some reason the proposal didn't show up maybe he was offline or whatever no problem we just chug along by n plus three building on top of M plus one so that's simple enough um but I I want to take a take a step back briefly um before talking about the implications and kind of touch upon where this deterministic nature of time actually come from in proof of stake and the thing is basically in proof of work we have this exogenous Randomness fed into the system by the fact that um well we have this proof of work stuff going on where we're trying to find this nons and once we find it everyone acknowledges is that as a valid block and then proof of stake we need to make this selection of a valid proposal explicit and we need to kind of come to consensus from inside the system and essentially because it's a blockchain we kind of um have we we don't have true Randomness because we kind of have to agree on it and so we try to generate some pseudo-randomeness that's not biasable um doesn't really matter how this works um we have this rundown process where proposals essentially contribute to some some seed as part of their Duty or like as part of their blog proposal um that then yeah is used uh point being that we have this basically on-champ pseudor Randomness that is then agreed upon that we use to schedule these duties because we kind of have to agree on when who is supposed to propose so that we can say hey this is actually a valid block from a valid block proposal um and to what's coming up next ah so basically in proof of work we have this exogenous Randomness um giving us this random block time whereas um approval stake we have this on chain pseudor Randomness uh giving us this kind of schedule or deterministic time and in shitty meme version we have a race versus a timetable um or in in platform here Martin who I don't think is here um yeah basically that's basically around the merchant you can see when the merge hits block time becomes very very stable we see One Missed slot at some point but that's about it um and so yeah we can nicely see the difference between the randomness and time before and then the stability afterwards um now I want to talk about some of the implications of deterministic time and there's a bunch of good stuff actually um one of which is this stability in in the the decreased variance in when blocks show up um basically means Erp 1559 works better simply because you have basically less full blocks um that basically if there's long and if there's no blocks showing up for long enough time frame then the the transaction demand reverts to the usual Madness and so that's kind of nice and then Barnaby um who sits here um he um he and this part we basically see that the bombs against this 30 million 30 million gas limit in blocks um is hit much less frequent and so basically we can summarize this as better load balancing so we basically have a more constant load in terms of transactions but this load balancing actually also translates basically throughout transpires throughout the entire Tech stack on the P2P layer the messages are all more stable there's not these rushes Etc um so it has a lot of benefits um but I wouldn't be here if it would only be good things um and so what I want to talk about a bit now is the fact that we have these proposals that have basically a monopoly for the duration of their slot it's a very short Monopoly but it's a monopoly for the duration of the slot and so so the questions basically can they abuse it and that's basically where the principal agent problem to the protocol comes in because the protocol can only realize so much and uh no I think I need to get first some more ethereum Basics to then talk about what you can do um so basically what happens in the slot we know the slot is 12 seconds and at the beginning um The Honest valid data spec basically tells you to as a valid data is expected to propose the signed beacon block at the beginning of any slot during which blah blah blah returns through meaning if you're elected as a proposer show up on time and propose a block now four seconds into the slot there's this gestation deadline um basically there's I think roughly 15 000 validators at the moment per slot voting on what they think is the head of the chain um and so they are supposed to attest as soon as they hear a valid block or four seconds into the slot so whatever comes first so when you hear block that's on time let's say half a second after the slot began then you test immediately if you don't hear anything however until four seconds into the slot you test regardless and so what you then attest to is basically whatever you think is probably the block before whatever you think is head off the chain essentially then there's a bunch of aggregation stuff going on which is basically just a fancy like necessary thing to put all these attestations on chain so that the chain is aware of all these votes and then we move on to the next slot um and then basically to determine what the head of the chain is it's basically um the proposed a validator runs a function which we call the fog Choice rule which is roughly following the lmd ghost protocol lmd Ghost ish shout out to a new proposal by Francesco and Luca on what's called now rlmd ghost um I think is it recent latest message yeah and it's actually relatively simple in the sense that basically the function takes the block tree and a bunch of votes like the attestations and then you walk down the block tree and whenever there's a fork you walk down the subtree that is heavier meaning whatever subtree has accumulated more votes and so here in this very simple example you see that n plus one all is good and then n plus two for some reason Builds on top of block n so there's a split so now a test is need to decide whether they should vote for n plus one or n plus two the committee in slot n plus two votes for n plus one probably because n plus two was too late for them to see it and so then n plus 3 also runs the fork choice and sees all these votes for n plus one and uh fine that's it um it's the heavier uh subtree so that's the intuition behind it now what can the proposal do basically um and basically it's all about timing um and as I said like the testers they test as soon as they hear valid block or four seconds into the slot so any block that appears within this time frame of zero seconds to four seconds will be seen by a testers and so they will vote for it assuming it's a valid block Etc um that's kind of on time-ish is like let's say we receive the two seconds and that's kind of on time but it gets interesting um it gets interesting when what happens basically when a Blog proposal is very late so here it's like roughly 11 seconds late so we hit that test attestation deadline four seconds into the slot and everyone will essentially vote for Block n because they don't see a block because there's no block distributed at the moment and so n plus one um is seen late and basically the only condition for it to become canonical is for to be seen before the block proposal of n plus two builds their block because they need to build it on top of n plus one for n plus one to become part of the chain and the reason is that this Focus will basically because n plus 1 extends block n there's no conflict so basically n plus 1 inherits or the four Choice weight and so it's not in conflict and so basically n plus two just extends the longest chain which makes sense um however what's the problem with this the problem is as always Mev or in general um yeah I mean mov um idea being that essentially what the proposal of n plus one achieves by proposing a block late is they buy themselves time and time is money also in blockchains and essentially what you can do is you listen you have more time to listen to the transaction mempool and so you have the opportunity to build more valuable blocks um and the problem here is that it's unfair to the next proposal n plus two because now n plus 2 if you're honest and you propose on time essentially you have much much less listening time to the transaction mempool and so you end up being able you're not able to extract as much mov as someone that deviates from the protocol and proposes a block late which is this kind of lack of the protocol like the pro the protocol is not able is not aware of these timing games and so we can't really capture it um let me just check here um so that's basically the essence of the problem like time buying attack if you want to call it that um and so I mean natural question is like what can we do about it and another question is is it happening and to answer whether it's happening there's um as Barnaby laid out there's these so-called relays where um because basically just to set the context again I mean Barnaby mentioned it there's basically blog purposes who Outsource um the job of block building to experts who are very good at building valuable blocks AKA extracting Mev and these um these block Builders they submit bits to the relay um basically bidding for the right to build the next block um and they sent them to the relay because the relay is basically this mediator between block proposals and block Builders because they don't really trust each other because we have we don't have this fancy input called PBS where we have a commit review scheme in protocol and so we need this relay at the moment and essentially what the proposal does is like at some point it sends to the relay request saying hey what's currently the highest bid then the proposal receives a bit which is basically a bit by a block Builder with an amount of ease they're willing to give to the proposal and um the execution payload so basically the blocks content with all the transactions and next The Proposal will then assuming it's fine they will sign this bid and send it to the relay um after the which point basically the blocks content can be released with this um signed bit and consensus stuff outside forming this basically complete block um where the execution is done by the Builder and the consensus stuff by the proposer um and basically what I've there's this flashbots relay that has a bunch of um there's an API that you can pull some data from and so I've pulled data from the last roughly 16 days of these bits coming in which amounts to roughly 60 million bits in like less than 16 yeah 16 days for roughly like 500 bits each slot um thanks to First price auctions and so um what this data can tell us is basically the following essentially as soon as a proposal signs a bit they can't really deviate from from the Block's content anymore meaning they can't buy more time after that point they've locked in the amount of Mev they will be able to extract and so basically looking at bits and which bit wins and when you receive it at the relay layer basically gives you an indication of when proposes lock in this um Mev amount and like the block time essentially um and so this is um can you see anything sort of not really um looks much better on the laptop but basically what we see here is it's bits within one slot um so here we're talking about slot 5 million blah blah blah um and these are all these dots are bits by different Builders submitted to the flashbots relay um and essentially the time access here is negative um for the most part so like I mean this is what here we have zero seconds so that's basically the slot where the build is actually bid for so they wanna build the contents for the slot that's here um and they start bidding before because at some point the proposal will query and ask for the for the bit and then they will make a decision and so it makes sense that let's if you're if you're an honest proposer you're gonna propose a block at zero seconds into the slot and so at some point let's say one second before that you're gonna say what's the highest bid sign it and then release the block and so all the bidding basically for that slot will happen in the previous slot assuming things are timely and so what we see here is basically just the linear so roughly linear increase in in bits over this over the duration of this slot um and then at some point the winner is picked which is like this little star in the top right corner and it's actually slightly late this winning bit was received like just after the beginning of a slot um and this is in a low Mev regime so it's like actually only 0.01 if and the median is roughly 0.5 zero five leaves and here I mean honestly I'm just like the kind of interesting data I think here we see different Builders and their bidding strategies and there's these yellow dots on the top um uh what's he called Beaver build Beaver build somehow seems to have some sort of advantage that they can cons basically outbit all the bits by everyone else by some sort of constant amount and what this maybe probably implies is that they have some sort of private order flow meaning that they have access to transactions that only they have access to unless everyone else's algorithm sucks so badly which is very unlikely um meaning that there's a bunch of um yeah that's for another time but interesting data analysis maybe to be done is to understand to what extent private order flow may play a role here but still like what can we do about it because um another kind of topic that was I think more touched upon and and the question part is like this social slashing social like the social layer of blockchains is often I feel like underestimated and um I wonder to what extent social pressure of or social norms play a role here like coinbase Kraken Lido they all have a reputation and if they consistently were releasing blocks late um it it would be it's basically detectable like it's not that you don't know they're not doing it um anyways but we don't let's let's think about what we can do about it um there's some fog Choice fun that we can do today and are sort of doing already and it's basically using this concept of proposal boost which is in addition to the fork Choice rule that I have so far kind of skipped skimmed over um the idea is relatively simple that basically it says that if a block is on time a block has like it comes with a boost and this boost is worth 40 of the committee's of 40 of committee votes so M plus one here has 30 access like if a block is released around the four second deadline then some people will hear it in time to attest to it and some won't and so here in this scenario you see that 70 didn't hear it in time so they vote for Block n 30 here n plus one before the set four second deadline and so they vote on 12 n plus one and so n plus two now they could just simply extend the chain on top of n plus one and that would be the end of it things would work as today basically but because of this proposal boost 40 they can basically out compete n plus one and punish them for being late and built on top of block n and the committee in N plus two will run the fork choice and see 40 is bigger than 30 so I'm gonna vote for n plus two and then n plus one ends out ends up being re-orged out and so basically we have because of proposal boost we have this mechanism to reorg out late blocks and you actually have an incentive to do so because now n plus two can capture the nav that otherwise n plus one would have captured so you also have an incentive to do so so essentially you punish late block proposals that doesn't solve the problem overall completely obviously because we've just reduced the time spent from 12 12 seconds to to 4 seconds um it's it's much better but obviously it doesn't solve the the problem at the root um but it's definitely a very good step in the direction and Lighthouse shout out to um Michael sprawl who kind of pioneered this um it's live on my mainnet and the bunch like prism I think for example has it basically implemented it's just not released yet um so it's running already by default on on all Lighthouse nodes so there's several angles we can look at this one is constraining the Monopoly power which is what we've just done from 12 seconds to 4 seconds another one is explicitly incentivizing timeliness so why don't we try to find some heuristic to determine whether a block proposal was on time and rewarded with Rewards as we do with other things another slightly more more deep change would be thinking about okay hey can we change the contents protocol in such a way that for some reason there's some sort of competition going on between proposals so that they're not fully aware of basically strip them away of their Monopoly power um it turns out I mean I'm by no means a consensus expert um I just love sometimes but it's it's yeah like having multiple proposals doesn't actually help because you still need a rule to deterministically choose one and that one can still deviate and do the funny things they're doing now or could um there there's yeah you could think about some some other avenues but it becomes a very complicated and uh it's always a trade-off as well complexity versus um what are we actually trying to tackle um and then a Fourth Avenue is actually thinking more about um I don't know if you've heard about Mev smoothing or Mev burn these are kind of two proposals out there talking about um basically in protocol capturing the amount of MAV um that is uh basically block builders make bits and then the committee tries to enforce the maximum bit so that we basically have an Mev Oracle for each slot so that we can then use this Mev and either distributed to all validators or burn it like an Erp 1559 um but basically the idea here is that if we can capture this Mev in protocol and redistributed then the incentive for proposal or like let's say we burn it then essentially none of the Mev that the proposer manages to if if it would manage to extract more Mev and none of it ends up with a proposal might as well not deviate in the first place because there are some other incentives especially if you slap some timeliness incentives on top or just in general like you don't want to be too late because you run risk of not becoming canonical Etc um this is actually I think one of the more promising Avenues maybe and so basically we've talked about the constraining the Monopoly and now I'm gonna briefly touch on an idea of um how one could think about maybe incentivizing timeliness explicitly and so basically today block proposals are rewarded in proportion of to the profitability of attestations they include in their blog so basically people are tests and if they vote correctly um they get the most rewards and the proposer is rewarded in proportion to those so you incentivize to basically include all the latest attestations um if they're correct Etc and the idea is basically instead or not instead but on top to maybe scale the proposal's reward by the share of same slot committee votes that the block receives and are included in the subsequent block that sounds a bit complicated but it's actually the idea is very very simple namely that if a block is on time everyone sees it 100 a test to to it then um n Plus One will include these attestations because actually the fresher they are the more profitable they are to include and so um block n here has a share of 100 percent of same sort Community votes being included in the subsequent block so you just scale the block reward by one nothing changes however n plus one um for some reason slightly late maybe um only 90 percent hear it and so you would scale in plus one's reward by 90. that's it meaning um you kind of try and come up with the series yeah the idea is basically coming up with a heuristic on chain that is detectable by the protocol um to explicitly incentivize timeliness the obvious caveat here is that the rewards have to out compete Mev rewards which in these crazy scenarios where you have 150 ease is not going to happen so this alone again probably won't cut it but if you start thinking about stacking these things like Mev smoothing or burning which independently of this is um like proposals that make sense or ideas that make sense to to explore deeply um you can you can start to see that maybe actually this is uh become sufficient um so yeah to summarize there's a basically um the fact that we have this deterministic time proof of stake um means we have a schedule of Duties and this duty of proposing is basically um given to one single valid data and so they have this Monopoly for the duration of one slot which they can try to abuse to some extent and that's obviously bad but the good thing about this constant time is also the the load stability that we touched upon and so far we've seen that there's not too much going on in terms of uh um late block releasing and there's also a bunch of things we can do about it and are already doing about um so yeah I'm I'm yeah it's it's it's a good good conclusion and there's also yeah I guess thanks for listening and if you're interested in this kind of stuff we have this thing called rig open problems um which is basically a bunch of fun problems that we're trying to think about one of which is timing games which is what I talked about here and um yeah if you have too much time feel free to dig in thank you [Applause] hi thank you for the presentation um yeah maybe my question is not correct I don't know but uh couldn't the uh Release Me by tested and how this could impact in the Monopoly of can you say again sorry yeah I can't relays leave by pass it can I have avoid to send to the blocks to a relay and you know just send directly to the proposers yes but so basically um the the block Builders they send the um the execution payload so that the transaction in plain text so basically there's a trust assumption between the Builder and the relay and the the idea is that a builder doesn't want to reveal their um nav right but if I well in the same way that you can have a monopoly of proposers maybe you also had a monopoly of Builders right or this is enforce it somehow by the protocol that's you know I mean in general I guess you mean a monopoly of Builders meaning one Builder just out competes everyone and becomes the dominant Builder yeah that's I mean we already see like it got a bit better over time now flashbots was very much dominating at the beginning now we have like four or five very strong Builders but obviously you're right in this like there is always decentralizing tendency um in general the idea is obviously that um building centralized building is fine in the sense that um as long as we manage to deal with things like censorship um all they can do is build a valid block um that is maximally profitable to a proposal it becomes obviously tricky when um a block Builder is able to okay I mean personally I think yes decentralized building is is definitely something um to strive for and I think I mean I might like Barnaby knows much more about Suave and and their roadmap but decentralized building is definitely um desirable but at the same time it's also like the core idea of separating the duties between building and proposing is exactly that we allow the Builder to be special like specialized without it harming the the credible layer the protocol level and uh another question in your eyes uh is light up the proposal boost uh how do you know that 70 for example uh agree with that like you you wait for the 12 seconds to have this guarantee or so like in an event for example of a network splitter how do you know that this like a majority actually replied to it or um I mean the the four choice is a local property meaning that whatever like it's a local view if you don't see these attestations you you basically it works with whatever you see and know about um here the proposal boost actually applies only in slot n plus two meaning that if the the basically if the committee in N plus two things that n plus the block of n plus 2 was time D meaning that they heard it within the first four seconds of the slot they will slap a 40 boost on the fog Choice rule but the fog choice is always a local property you're the result of your fork Choice function call could be a different one than mine since we have different locations in the P2P layer having different information but obviously that's why we have also like this if you want to call them sub slots um we have four seconds for the block to propagate to the network then we have four seconds for the attestations to propagate and so basically the idea is obviously to to allow for some um some latency constraints um for the available chain and then for the finality finalized stuff on top we're working on a much larger time Horizons um and then yeah you get into like proving liveness and safety and all these all the fun stuff where's Francesco okay but you cannot violate say that uh no okay okay now all of this is only on the available chain like none of this has anything to do with the finality like I I completely ignored like source and Target votes uh finalizing stuff I hear everything is about basically the head of the chain and then whatever this available chain spits out we try to finalize with these checkpoints every 32 slots one epoch thank you thank you