The Cost of Artificial Latency in a PBS Context | Michael Moser - Chorus One
Ethereum Denver·Wed, Oct 9, 2024, 12:00 AM
Speaker
Evaluating MEV-Boost inefficiencies, comparing the theoretical expectation with a real-case pilot. The findings reveal relay setup impacts on bid eligibility and MEV gains, indicating higher variances than theoretical models suggest, with implications for network dynamics and validator strategies. APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply
Transcript
[Music] okay so hi everybody I'm Michael I'm head of research at chorus one we're are staking provider with now more than $3 billion in stake and I want to talk about timing games today um I'm presenting a paper which we wrote earlier in the year it's called the cost of artificial latency in the PBS context and it's basically about what happens when validators delay bits um let's take a quick look at the agenda so three major points I want to start by defining what timing games are why validators would play Play Timing games and what upside so what Financial upside validators could capture by delaying bit selection in a timeing games context I'll then talk about U negative externalities that might arise from timing games um I think there's three major categories here and we'll take some time to walk through all of them and then lastly I'll talk a little bit about our timing games pilot so we we take an acceleration inist uh point of view here and we we've been um kind of testing out timing games since the summer but for us it was important to balance rational competition with uh with ecosystem alignment and for that reason the the study that I'll present to basically open sources all of our parameters and kind of makes it yeah open for for other people to to look into and to potentially imitate if if that's what uh somebody's looking to do um yeah so why playtime in games there's a certain Dynamic which is as the slot progresses more transactions hit Builders um so they have a larger pool of transactions which they can use to build an optimal block and secondly statistical arbitras are able to quote wider and more aggressively right so if you were to arbit let's say uniswap against binance and you were to do that at the beginning of the block you would have to be reasonably more confident about what you think the price is going to be by the time your arbitr settles then you would have to be if you would uh execute this Arbitrage closer to the end of uh of the slot and what that means the of that is that blocks become more valuable in expectation due to basically transactions and by proxy M are crewing at the builders and the the graph that you can see on the right side here is when validators usually um select uh the next blog and in the next slides we'll look at you know what that what that would look like in a timeing game context so let's set the stage here by putting a number on the upside if a validator were to um delay its bit selection to uh 950 Mill seconds in the slot uh this will and we will assume that uh execution layer rewards are approximately 30% of all rewards that basically uh means a APR upside of 1.67% in expectation and what that means is you know it's starting to get quite significant and people would be incentivized to to do something like that um this could reflect in different ways depending on how big you are as an old operator if you're a large n operator and you kind of pull your rewards across different clients so let's say you have 133% of the voting power which really would make you a very large node operator then kind of the the volatility that is inherent to MV it would smooth out a little bit and you would have a pretty good idea of what you could earn by playing timing games whereas if you're a small validator M Rewards mentioned are very volatile you would be situated at a different point of the risk reward curves what would happen is uh is uh that your rewards would would vary a lot more um this is both a way of you know kind of reflecting the law of large numbers which means if you run either a lot of valid datas or you run them for a long time you would be approximately uh aiming you would be approximately looking at the same result an expectation right um one thing we argue in the paper is that this theoretical assumption is actually not reflected in practice and the reason for that is that timing games impose several negative externalities which disproportionately hit small validators and with that said let's go to the next section and talk about these three big categories of negative externalities um the the first point here is XF burned Eve basically the dynamic that underpins that is as the auction progresses the the gas price in expectation Rises this reflects on the next slot which means that the E burned in the slots that are subsequent to a timing game slot would be higher than you would expect it to be without the T and game type dynamic in play um and the upshot of that again is that it's a it's a negative externality which disproportional hit small validators because it puts them on a worse point on the risk reward curve the these things don't really smooth out um as as quickly um and uh and yeah uh so there's two consequences of that it basically cuts into the profits of the next proposer and the upshot of that is a zero sum game so if everybody plays Kim in games what happens is that the the uh the slot basically just shift backwards in a way everybody would be would be cutting into everybody else's profit and at the end of the day you would just be redistributing the pie but if you're really small and you you can't you can't compete because of resource constraints that will go into later or because you're very aligned and you uh you don't want to play time in games you're basically subsidizing people that uh that uh feel feel a bit more liberal about that um yeah and for excess Eve burn the median increase for the slot subsequent to a timing game slot and again here in the theoretical part of things we assume that somebody playing timing games means that the get header request gets delayed to 950 milliseconds in the slot just to recap that the median increase of burned Eve works out at 0.4% in expectation which which is uh reasonably large and and that's the reason why we we wanted to address that as as a negative externality which is uh in expectation quite significant um let's go to the next negative externality which is basically based on the same Dynamic um as you delay your get header request as you playtime in games as a validator um the amount of transactions that might occur to your slot they uh increase an expectation and another way of saying that is transactions that may have been included in subsequence slots actually land in the current one which which is the slot that would be affected by timing games so again this is another way of describing the Zero Sum Dynamic and it's just to say that you know if you don't engage in timing games um it's going to it's going to decrease the rewards that you can expect as as a validator um so let's let's recap that by by um by specifically naming what the upshot of that would be right um it's an increase in centralization pressure um large operators in a timing node operators in a timing gain context benefit from comparatively higher APR at lower variance and small operators on the other side of things are disproportionately increase to variance from the long tale of bad externalities uh let me just recap the E bur example here and secondly small node operators might not even be able to um engage in timing games at the at the same amount of uh of expected utility in the first place and there's a couple of reasons for that one is lack of internal data if you're a big node operator and you you have a ton of validators you you have a way of getting uh to um of just acre more data and and forming a stronger opinion of what an appro appropriate latency parameter would be whereas if you're a small validator it just Tak takes you a really long time to to you know kind of find out how how you can play time in games efficiently and and if something changes if a relay were to start behaving differently for example it would take you a disproportionately longer time to change your opinion than than a large not operator would have right so so there's a big centralization factor here and then something which kind of comes in tandem with that is just the fact that large not operators are typically better capitalized so so you can you can have people spend time on on this stuff right um the yeah and the risk here is is basically centralization on the one hand and then on the second hand the on the second secondly this uh this risk manifests as a self-reinforcing cycle because if you if you don't play Play Timing games at all you're again disproportionately exposed so no operators are compelled to to employ Loy latency optimization play time and games as a matter of strategic necessity okay um with that said let's let's look at what our approach has been here um in the summer we started summer of 23 we started to play around with with a timing game setup um we named that Ado my core from the paper is is Italian and in Italian uh if you if you were to play a musical piece a doo it it would mean that it's performed slowly and and with great expression so so we kind of named it at AR as a as a nod to just going about uh calling get head slowly in a in a very thoughtful uh manner yeah and so this has not been a client facing product for us but more of an internal research initiative that that ran on on our own um our own validators now as soon as we as we kind of came to conclusions there which which seemed statistically significant for us we did two things on the one hand we we outsourced our data and we outsourced our initial parameters so again this is the study I'm presenting today and if you're interested in this find the study um it's it's on our website course. one and then secondly we kind of acknowledge that the timing games were something that you know would just happen with the way PBS is currently set up so if you're if you're competing rationally um you you're prob would would you know have to have to engage in this type of stuff and so we we we went very public with it and we started implementing it in in client side infrastructure but at the same time for us it's important to emphasize fre things right firstly we don't run parameters which would expose anybody to exess risk either the network or clients secondly we uh frequently publish our our research and we try to go about this whole thing in a transparent Manner and then thirdly liquid saking Services by lier would be the first that comes to mind to us this neutral infrastructure so this is not a place where where would ever um engage in this type of latency optimization um let's set the stage here our pilot basically employed different setups for for different relays um just in practice I think I alluded to it earlier the way you play time in games is you call the get header request a little bit later right so if in in your slot as a validator you would have to tell the relay that that you want to receive a block now um that's a so-called get header request you would call it a bit later um our Doo setup speaks to several relays and we put them into different buckets there's The Benchmark setup which is a relay for which we don't uh run a a a latency PR at all there's the aggressive setup which is a relay for which we delay the get header request as as much as reasonable possible on a risk adjusted basis so not as high as the theoretical expectation of 950 milliseconds but slightly be below that with a with a risk margin still rather aggressive and then there is what we CH in the normal setup and that's basically a a latency parameter which which is a bit uh below the the aggressive setup okay and the moderate setup that's just then again another another step below that and and super conservative um in the Box blot here you can see what um what what that looks like if you look at the the right side of the Box blot you you kind of see what Adra started to do after we uh implemented our our parameters and let's consolidate that into one graph and what you see here is how the how the network usually uh would solicit get headers in expectations so that's a box blot with a with with a rather uh large margin around it and then what adau would do and if I had to put that in words I would say that adjo calls get header a little bit later but it does it in a manner which is which is very riskware so the spread of that is is rather small right so if you play time in games I think it's very important to to to go about it in in a manner which which is uh which is very consistent and which is risk adjusted and and you know in in quantitative terms you would say that you want to reduce reduce your variance there and I think we did that quite successfully um let's look at how this practical type setup compared to what we would have expected in uh the theoretical part of our study which again is a latency parameter of 950 milliseconds so these graphs are quite closely clustered together you might not be able to see it from the audience or on the stream but basically what happens is that Doo actually did slightly better than what what we would have expected in in theory and so let's conclude by by putting a number on it um the the network distribution of payloads basically is a mean of 0.0 467 e press lot um you can see you can see the quants below here I'm not going to read it out but of course there's a there's a fair amount of of variant and the the Ado payloads have a medium which is median which is quite significantly above that right um again I I mentioned variance so you know this is a a data set which is of a reasonable size but it's not something that we've been running on for for years um I think the upshot here is just that you know it it it is something which has affected our bottom line um meaningfully and I think the yeah so despite remaining below the 950 MS seconds which we which we uh you know Quantified the theoretical expectation with um adajo outperformed outperformed uh the the amount of Revenue which which we would have expected um so let's let's conclude here by providing a quick Outlook um there's a couple of reasons why why Ado did better that than what we would have expected in theory and we we do have a lot of data so um we're looking at at rolling out AA 2.
0 now and for a doer 2.0 we we would be making some of these uh some of these Dynamics more explicit um which which you know kind of helped us outperform the theoretical expectation there I I think uh the first Insight is um that you know the the usual way timing games are described is you basically have a latency parameter and this is what in the you know kind of in our context here taking a step further is is described as naive parameter-based optimization um uh what what what we what we acknowledge there is that the M boost auction is not consistently timed so AER 2.0 dynamically adjusts for for divergences right and and the fact that it's not consistently timed is is definitely a reason why we outperformed the theoretical expectation and we we we kind of found an approach which which we think allows us to to adjust for this on on the Fly and and and do even better in in this regard going forward um secondly we as I mentioned have a lot of data and we noticed a small but significant performance difference by gear geolocation and by by data center right so so what you want to do here of course is uh you you want to run in in in spots which which look uh more attractive relative to to other spots and specifically in the in the context of AD 2.0 and timing games that means that you know it now optimizes for for nwork latency in in a few ways and what I mentioned at the beginning of the talk is you know that we we committed to being very transparent about that to to kind of you know balance balance alignment with with uh with competition so expect expect uh expect news expect us to to publish uh you know more more specific uh takeaways on once we feel the the statistics are in a good place that you know makes us makes us reasonable confident in in what we theorizing here and and then the the last point I want to make is some of the learnings that that we have had on ethereum um so for example I would highlight the last Point here in terms of network latency optimization they might also carry over to other networks so so again it's quite early days and I don't want to say anything that that doesn't seem statistically certain um but we've looked into some other networks and and we think there are definitely takeaways that that would not only work in an ethereum context but but maybe on on other chains as well um yeah and that's that's it the Outlook kind of concludes the presentation uh We've published all of this on WE research it it was really important for us to make sure that people are aware of these of these externalities and and kind of to to trigger a discussion um so if you're interested in that feel free to to scan the QR code um this presentation is also on our website and I think we we are tweeting it as well so you know if you if you don't want to scan it now feel feel free to to catch up with that later um join the discussion if anything here sounded interesting or relevant feel free to to find me after the presentation and and that's it so have a have a good conference everybody
Automatic transcript — names and jargon may be misspelled.