Mitigation of timing games was heavily discussed during the MEV-Boost community call this past week. Here we provide a summary and general thoughts, as well as a full transcript of the call. The transcript was auto-generated by YouTube, cleaned by ChatGPT, and then enriched with speaker information and verified for accuracy by us.

These calls are fantastic and we highly recommend them to Ethereans who follow the MEV space. Earlier in the call, but not transcribed here, participants discussed early results from the ultrasound relay public goods test, a request for relays to include getHeader() call times in their public data APIs, and a yet to be announced public goods project.

Speakers:

• Alex Stokes - Ethereum Foundation

• Caspar Schwarz-Schilling - Ethereum Foundation

• Mike Neuder - Ethereum Foundation

• Uri Klarman - bloXroute Labs

• Justin Drake - Ethereum Foundation / Ultrasound Relay

• Benjamin Hunter - bloXroute Labs

• Toni Wahrstätter - Ethereum Foundation

• Max - Aestus Relay

Timing games are not a new phenomenon, but the explicit marketing done by P2P and the resulting visible shift in proposer behavior has brought the topic into public discourse.

As noted in by Caspar and Mike in their ethresearch post, the first-order equilibrium where all proposers play timing games provides no benefit to proposers compared to a dynamic where no proposers play timing games. Unfortunately, the dynamic where no proposers play timing games is not a stable equilibrium and economically rational proposers are encouraged to defect to capture extra yield.

Caspar and Mike propose two mitigations: using relays to enforce out-of-protocol deadlines or encouraging relays to provide Timing Games as a Service. These are framed respectively as decelerationist and accelerationist strategies.

Justin proceeds to emphasize that using relays as enforcers doesn’t create a long-term stable equilibrium because relays are encouraged to defect. Although the relay landscape is currently dominated by four actors and social coordination could be effective in the short-term, the barrier to entry for relays is not insurmountable and other relays who choose to deviate from this strategy could quickly gain market share by generating for higher yield for proposers. Justin mentions that Titan Builder will soon be releasing an ultra-fast relay written in Rust.

Uri objects to using relays as enforcers on a more fundamental level and emphasizes that relays should stay as neutral as possible. He brings up a slippery slope argument comparing timing games to sandwich attacks, and asks the group to ponder what the roll of a relay should be. Considering that bloXroute ran (and sunset) the only relay that attempted to filter sandwich attacks his opinion carries a lot of weight in our eyes.

Together Justin and Uri represent the interests of 63% of the relay landscape, so their shared distaste for using relays as enforcers makes this mitigation strategy nearly impossible.

The conversation then pivots to simpler mitigations and addressing ‘low-hanging fruit’. The main suggestion here is that the current default getHeader() call time is set at the canonical block time, but the +4 second deadline for blocks to get sufficient attestations is too generous for the sophistication of the network.

We discussed the reasons for (and the timing game implications of) this attestation safety buffer in long-form in September when analyzing MEV-Burn.

There was no consensus reached, but the idea floated by Justin was to delay the default getHeader() call by 2 seconds, effectively shortening the buffer and shrinking the extractable value from these timing games. Instead of proposers being able to risk 12 seconds of rewards for up to 4 seconds of extra yield, this dynamic would see proposers risking 12 seconds of rewards to gain 2 seconds of extra yield. This changes the risk-reward dramatically, but it also brings the network much closer to the negative externalities of timing games.

The math on this is a little bit more complicated because the intrablock value of time is not linear late in the slot, so the risk-reward is a bit better than it initially appears. The timing games being played by P2P (and Coinspot) are well ahead of 2 seconds, which shows how much MEV could still be captured by proposers without degrading the network.

Frankly, delaying the default getHeader() call is basically changing the default to all proposers playing timing games automatically. We personally think this is a good idea, but for readers who were outraged at P2P for risking the liveliness of the network for extra yield, this should either terrify you or should demonstrate that your knee-jerk reaction was extremely overblown and that P2P was never risking degradation of the network.

The conversation then shifts to the idea of attester-proposer separation (APS), which allows validators to run two nodes: one colocated with relays to maximize yield from block proposals, and one that is geographically decentralized to handle attestations and ensure the decentralization of the network. Justin and Mike are apparently posting long-form on this soon, so we’re not going to summarize the brief conversation in the call, but interested readers can jump to 00:53:46 in the transcript or the video.

I think, at this point, unless anyone has anything else to add, there's one more agenda item. Caspar, I think you wanted to say something about your post around timing games. Would you like to say something there?

Sure, so yeah, Mike and I recently published a post on timing games on ethresearch, and I just thought it might be worth mentioning one or two things that are in relation to relays, specifically. TLDR; timing games are starting to be played, so block proposers are delaying blocks to earn more MEV. I think Toni actually might have more data on this, but aside from that obviously there are some implications from timing games being played, some being more missed slots and some more involved implications around attester timing games. The idea is that if proposers start delaying their proposals, there might be incentives for testers to delay their attestations.

Lots more details in the ethresearch post, but the two things I wanted to mention more specifically are potential mitigations that would involve relays, as opposed to mitigations on the protocol side. They represent opposite approaches: one is more the decelerationist approach, and the other is the accelerationist approach. Currently, the honest specs are defined as proposing blocks at T equals zero, so basically at the beginning of the slot. We know that's not incentive-compatible, and so we're starting to see deviations.

One way to mitigate this in an unsustainable, non-incentive-compatible way, but possibly using social coordination, would be for relays to stop accepting bids after T equals zero. This would mean that to extract more MEV, you would need to have a direct relationship between proposers and builders to circumvent the usual MEV-boost pipeline via relays. There are obviously drawbacks and benefits to this approach. The benefit is that it reduces social coordination from all validators to a set of relays, but the drawback is that it's still rational to defect, and it's unclear how long this would hold, but essentially vertical integration between builders and relays would enable defection for validators.

The second approach, which is the opposite of relay enforcement, was brought up by Justin, I believe. It's the idea of timing games as a service, which is basically saying that relays are well-positioned to know the latency between relays and validators. Instead of validators requesting a header, the relay could push a header at a point in time when they think it would be optimal, essentially democratizing access to timing games MEV. The benefit here is clear, as relays are well-positioned for latency considerations, allowing home stakers to easily access MEV. The drawback is that it's accelerationist and gets us immediately very close to the negative externalities of timing games.

One thing that's not entirely clear is how, as a proposer, you would not end up relying on a single relay doing these timing games as a service without reintroducing some complexity. If this timing games service is a push format from the relay to the validator, you have to make a decision if you get a push from relay A at, say, two seconds into the slot, and you know you might receive a later push from relay B. Which header should you sign? This becomes a complex decision in itself. That's at least one open question, aside from the broader cost-benefit analysis. I think these two ideas, relay enforcement versus timing games as a service, are two mitigations on the table, besides others, that I think make more sense to discuss offline, but I wanted to bring them to attention since many relays are present here.

Mike, please feel free to add anything.

He covered it perfectly.

I'm curious what the other relays think about it.

I mean, we're starting to get a feel for what's happening on the proposer side of things. Some proposers have been stealthily playing timing games for some time, and then P2P made an announcement, and now we're seeing the floodgates open. My prediction is that within a few months, the majority of proposers will be playing timing games.

In terms of relays, so far, it hasn't been very competitive, but there are examples like Titan. Kubi is on the call, maybe he can talk about this. Titan built an ultra-fast relay in Rust, and they could defect. It just takes one defector to force the hand of everyone else. I don't see the equilibrium lasting very long. I'd be happy to try and come up with some short-term agreement, but it feels like it depends quite a lot on the social layer, and it's not necessarily sustainable.

The good news, in my opinion, is that once we've picked the low-hanging fruit, the timing games are fairly minimal. We're talking about optimizing the last 120 milliseconds for someone who's really sophisticated. And 120 milliseconds is only 1% of the slot time, so you're potentially just optimizing 1% of MEV, which is hopefully very small. This 1% optimization comes at a cost—it means that sometimes you miss a slot. If you were to miss more than 1% of slots, then you're more likely not going to be net negative because you're making 1% 99% of the time, but 1% of the time you lose more than 100%.

So, one good outcome is that we have more sophisticated MEV boost software that picks all the low-hanging fruit. Right now, there's a good two, three, maybe three and a half seconds of low-hanging fruit, and once that's picked up, we're left with the really advanced timing game, which is fairly minimal.

My own sense here is almost like a knee-jerk reaction. I really don't want relays to police anything. It makes no sense, and it's kind of like; centralization is always easier, no matter what. It's like "instead of doing the hard thing can we do the easy option". So, even before the specifics, the idea of taking the relay, which is already there, and having them coordinate something just feels like the wrong approach for me.

I lean more towards the other approach that Justin proposed. Not even talking about the attestation boost, instead of doing it just like 400 point whatever that is, do we want to do it over time.

There are some long-term considerations outlined in the ethresearch post. But really, if the entire point of PBS and MEV boost is to ensure that everybody behaves in the right way, let's avoid the bad things. I even wrote about it – all the stakers together now have $60 billion worth of stake. To do what's better for eth is the right thing for them if they coordinate, but they don't, they do what's the right thing for them.

It feels off to choose and let them sandwich users or whatnot because you can say, "Oh, how about the relays throw out all the sandwiches too because it's bad?" This approach seems incompatible from my perspective. The entire idea of MEV boost and PBS, is that these are the incentives, these are what people are going to do, let's work around that, and putting relays as a policeman to say, "Don't do what you're supposed to do even though it's their incentive".

[bloXroute is] not playing any latency games, but since the days of proof of work, I would argue that they should wait as long as they can. They should be playing the latency games and adjust based on factors like the orphan fork rate and how much money it makes them. Choose the optimal one that's also very PBS and MEV boost-aligned. That, to me, is the right approach. Anyway, that's my take. Specifically, I don't see relays taking the policing role in any way. It's just off.

Yeah, I mean, generally, the more we can keep relays as neutral operators that are just doing a very minimal set of things, I think that's definitely for the better. Justin made this point that there's probably a lot of low-hanging fruit that might not even touch the relay. Once that's taken care of, there might be some stuff on the margin, but the complexity needed to profit from them is so advanced that it ultimately might not be an issue because so few people even try to go after it.

If anything, Alex, relay enforcement is simpler than relay timing games as a service. Asking relays to do this timing games as a service thing is a bigger lift for them, I guess.

No, certainly, but I mean, it sounds like it might not have to, right? I think that's kind of the point. If timing games as a service only captures this last 1%, then it just might not even be important.

Well, I guess timing games as a service is like... we could start by having MEV boost default call at, say, T equals 2 or something, and then timing games as a service is compressed. But going from what we have now to timing games as a service is potentially a large amount of MEV, right? The default behavior of calling at T equals zero versus timing games as a service, that delta is currently very big.

The suggestion is not to do timing games as a service; the suggestion is to make a few lines of code changes to MEV boost to pick up the low-hanging fruit. This way, the optimization opportunity is only 1%, and then maybe timing games as a service is not even required.

But to get to the point where, you know, that last 120 milliseconds matters, everyone on their local MEV boost has to make the decision about when they call, right? So, you do need to do that latency calculation at some point. Who's doing that? Are we having the relay do it, or are you suggesting having the validator configure it based on their local estimate?

I mean, there's going to be some amount of time to do the broadcasting to the validators, let's say 500 milliseconds. Then, the proposer can see that they're at most, let's say, 200 milliseconds away from every single relay. They can just pick the highest header 700 milliseconds before the end of the slot, and, you know, end of story. Sure, the 700 milliseconds can be compressed by a few tens of milliseconds if you want to be really, really sophisticated, but the low-hanging fruit can be picked just by making simple modifications to the MEV boost software.

I mean, even just adding one line of code, which is delay by 2 seconds before calling a header, that already reduces by half or more than half the low-hanging fruit.

What do you mean by that? What's the proposal that you call the low-hanging fruit here?

Right now, there's a 4-second window to work with, and 4 seconds is just unnecessarily long, so you just call "get header" two seconds in and now the play opportunity to just two seconds. Or you know, you could consider a delay of 2.5 seconds or something similar.

But sometimes proposers do require that time. Not long ago, some Lido operator took 3.6 seconds to process. It depends on their location, it depends on the machine, etc. So, it's not always the case, I would argue. If we cut it by two seconds, these operators are affected, and maybe that's okay, but we should be aware of it.

I think this also becomes a centralizing vector. To maximize your APY as a validator, you'd want to be as close as possible to relays. This would really fight decentralization if relays start doing these timing games as a service.

Right, I mean, we're trying not to do timing games as a service, that's the idea, right? So, I think Justin is just saying that there is a lot of low-hanging fruit where you could imagine that MEV boost is calling multiple times across this 4-second window, or even just waiting, you know. Assuming block rewards are monotonic, which generally I think they are, then you get to a point where, yeah, wait two seconds, two and a half. There's some natural back pressure because the more you wait, the more risky you run of missing your slot. So, in equilibrium, you might get to a point where a lot more of this timing game MEV is being extracted via the proposer, and then you just, you know, the return on investment you get from waiting longer and playing this game will just be so low beyond that point that we might have a nice equilibrium that is more compatible than, say, having relays do any policing, so to speak, on their end.

I'm not sure about that. Just calling "get header" as a standard at second 2 because we do see a lot of reorgs, especially in the first slots, and I guess this is not the big sophisticated validators; this might be already the small ones. So, I think it's just making their life harder.

Well, right. So, now you need to be aware of your proposal with respect to the slot in the epoch. That's also not a huge ask for the CL to be determining because ultimately this is all driven by the validator client, and something like that they should know. So, again, I don't think there are any silver bullets here, but we can probably do, you know, low-hanging fruit. There's probably a lot we can do to improve the situation quite drastically without putting more of these concerns at the relay, which I think everyone wants to avoid.

I would be afraid that if we delay the call by default, some validators will also delay their attestations by default.

Well, hopefully not. That would be a pretty advanced modification.

Not really. It's equally easy to change and possibly also rational, so that's the whole other side of the coin. Yes, certain things are not incentive-compatible, but there are some sort of negative externalities to timing games being played very aggressively. So, it's a very funny trade-off space. Timing games as a service is a very natural endpoint, almost like enabling proposers to stay, quote-unquote, naive and extract that MEV timing game. Arguably, even the relay might be better at updating the timing of their message than a home staker who now has to consider, "Oh, now we all of a sudden have blocks. Do I need to adjust my release time?" So, if you expect every home staker to be aware of this kind of thing, it's unclear if that's better. But then also, if you do timing games as a service, it has other drawbacks. So, it's a complex trade-off space that's very much not clear to me.

Yeah, I mean, that's true.

I just agree that giving solo stakers competitiveness should be a primary concern here. If we have large numbers of staking pools eventually playing these games themselves, it would feel, if you zoom out a bit, healthier for the economics of the space to provide a safe way of allowing solo stakers not to have to do a huge amount of work to keep their APY competitive.

Right. So, yeah, I mean, I think in the limit, it does look like timing games as a service. And this is what I was just going to say a second ago: let's say that we have some low-hanging fruit fixes we can deploy in the next few months that buy us time before we see the advent of these really advanced strategies in, say, 12 months. And maybe by that time, you know, we've bought more time for research; there are things we can do in protocol around incentivizing timeliness that might make these moot completely. So, yeah, I mean, I hear everyone, but we also need to keep in mind that there are things we can do that might have different horizons of effect. And to the extent that we can delay putting all this complexity and like, you know, latency optimization and geolocating proposers and all this stuff within the relay, I think the better.

One idea that I've been toying with is what I've been calling attester-proposer separation. So, what a validator could do in theory is have two nodes: one that does the proposing, which is colocated with the relay, and then the other one that does the attesting, which is much more decentralized. Because if the timing games really become sophisticated, we don't want the attesters to be geographically distributed since that's where the security ultimately comes from. But it is fine for the proposers to be geographically centralized, and that can be achieved in software by having two nodes in two different geographic positions. But this can also be done at the protocol layer. That's something we've been thinking about, and I think Mike and I will be releasing a write-up on that fairly shortly.

Justin, taking this further, have you considered the idea that, it's not PBS really at that point, but if you consider that it should be the attesters who require payment to attest. Basically, attesters capturing the MEV. If you pay me 50% of whatever you're taking to yourself, I will sign it, and if not, then I don't. And that becomes the end, because it always feels to me that the MEV supply chain stops at the proposer, which is one step too early. It's really the attester. So, if you're thinking about attester behavior and whether they sign it or not, then attesters should really start charging the proposer because they have power.

Yeah, so what you're describing is actually pretty much exactly what Francesco wrote on ethresearch called MEV Smoothing, where the MEV is smoothed equally across all the attesters. It doesn't go to the proposer, and then there was basically the same construction, but instead of distributing to the attesters, you burn it, and that was called MEV Burn.

The nice thing about the attester-proposer separation is that you have this auction mechanism where the chain itself sells the execution slots. So the end of the pipeline or the end of the chain is the protocol itself; it's no longer the attesters. So you can have the protocol capture the MEV.

I'm not too worried about that, and also, these things become a little different with attesters. The dynamics are a little different; we're talking about group dynamics versus individual dynamics. Also, what I call entropy, which is basically the different types of messages that make sense to sign, kind of changes quite dramatically. As a proposer, I can sign whatever block hash I want. On the other hand, as an attester, I can really only sign two messages: message number one being, you know, I saw the proposal on time, and message number two being I didn't see it on time. So things do change quite dramatically.

Yeah. That's actually the reason, and I was saying, like, proposer does keep half and pass half, and you could even think about passing some to the next proposer, but I agree proposer also has power. So anyway, we could jam on it some other day.

I mean, one thing I would note at this point is that attester-proposer separation is extremely exciting as a research direction, but it's also, I think, in terms of time scales, on a different order. In terms of timing games, they are just going to be played very quickly. If we see attested timing games, they will be found out much sooner than we will ever be able to ship APS, should it come to that. But yeah, there's a bunch of nice things that APS could get in terms of, you could basically treat proposers as sophisticated actors who you can then penalize extremely heavily for missed slots, and so that kind of prevents attester games and to the extent that it's not worth it to play timing games so aggressively. But yeah, different time scales, I would argue.

And in some weird sense, it might actually be good if attesters do start playing timing games because we'll have real-world data, and you know, Ethereum being anti-fragile can just learn from that and have ultimately a better long-term design.

Cool, yeah. APS is definitely an exciting direction to keep exploring, and I think on that note, we might go ahead and table the call. Are there any closing comments?

[silence]

Okay, great. Thanks, everyone, and yeah, I'll see you all in the new year.

Mitigation of timing games was heavily discussed during the MEV-Boost community call this past week. Here we provide a summary and general thoughts, as well as a full transcript of the call. The transcript was auto-generated by YouTube, cleaned by ChatGPT, and then enriched with speaker information and verified for accuracy by us.

These calls are fantastic and we highly recommend them to Ethereans who follow the MEV space. Earlier in the call, but not transcribed here, participants discussed early results from the ultrasound relay public goods test, a request for relays to include getHeader() call times in their public data APIs, and a yet to be announced public goods project.

Speakers:

• Alex Stokes - Ethereum Foundation

• Caspar Schwarz-Schilling - Ethereum Foundation

• Mike Neuder - Ethereum Foundation

• Uri Klarman - bloXroute Labs

• Justin Drake - Ethereum Foundation / Ultrasound Relay

• Benjamin Hunter - bloXroute Labs

• Toni Wahrstätter - Ethereum Foundation

• Max - Aestus Relay

Timing games are not a new phenomenon, but the explicit marketing done by P2P and the resulting visible shift in proposer behavior has brought the topic into public discourse.

As noted in by Caspar and Mike in their ethresearch post, the first-order equilibrium where all proposers play timing games provides no benefit to proposers compared to a dynamic where no proposers play timing games. Unfortunately, the dynamic where no proposers play timing games is not a stable equilibrium and economically rational proposers are encouraged to defect to capture extra yield.

Caspar and Mike propose two mitigations: using relays to enforce out-of-protocol deadlines or encouraging relays to provide Timing Games as a Service. These are framed respectively as decelerationist and accelerationist strategies.

Justin proceeds to emphasize that using relays as enforcers doesn’t create a long-term stable equilibrium because relays are encouraged to defect. Although the relay landscape is currently dominated by four actors and social coordination could be effective in the short-term, the barrier to entry for relays is not insurmountable and other relays who choose to deviate from this strategy could quickly gain market share by generating for higher yield for proposers. Justin mentions that Titan Builder will soon be releasing an ultra-fast relay written in Rust.

Uri objects to using relays as enforcers on a more fundamental level and emphasizes that relays should stay as neutral as possible. He brings up a slippery slope argument comparing timing games to sandwich attacks, and asks the group to ponder what the roll of a relay should be. Considering that bloXroute ran (and sunset) the only relay that attempted to filter sandwich attacks his opinion carries a lot of weight in our eyes.

Together Justin and Uri represent the interests of 63% of the relay landscape, so their shared distaste for using relays as enforcers makes this mitigation strategy nearly impossible.

The conversation then pivots to simpler mitigations and addressing ‘low-hanging fruit’. The main suggestion here is that the current default getHeader() call time is set at the canonical block time, but the +4 second deadline for blocks to get sufficient attestations is too generous for the sophistication of the network.

We discussed the reasons for (and the timing game implications of) this attestation safety buffer in long-form in September when analyzing MEV-Burn.

There was no consensus reached, but the idea floated by Justin was to delay the default getHeader() call by 2 seconds, effectively shortening the buffer and shrinking the extractable value from these timing games. Instead of proposers being able to risk 12 seconds of rewards for up to 4 seconds of extra yield, this dynamic would see proposers risking 12 seconds of rewards to gain 2 seconds of extra yield. This changes the risk-reward dramatically, but it also brings the network much closer to the negative externalities of timing games.

The math on this is a little bit more complicated because the intrablock value of time is not linear late in the slot, so the risk-reward is a bit better than it initially appears. The timing games being played by P2P (and Coinspot) are well ahead of 2 seconds, which shows how much MEV could still be captured by proposers without degrading the network.

Frankly, delaying the default getHeader() call is basically changing the default to all proposers playing timing games automatically. We personally think this is a good idea, but for readers who were outraged at P2P for risking the liveliness of the network for extra yield, this should either terrify you or should demonstrate that your knee-jerk reaction was extremely overblown and that P2P was never risking degradation of the network.

The conversation then shifts to the idea of attester-proposer separation (APS), which allows validators to run two nodes: one colocated with relays to maximize yield from block proposals, and one that is geographically decentralized to handle attestations and ensure the decentralization of the network. Justin and Mike are apparently posting long-form on this soon, so we’re not going to summarize the brief conversation in the call, but interested readers can jump to 00:53:46 in the transcript or the video.

I think, at this point, unless anyone has anything else to add, there's one more agenda item. Caspar, I think you wanted to say something about your post around timing games. Would you like to say something there?

Sure, so yeah, Mike and I recently published a post on timing games on ethresearch, and I just thought it might be worth mentioning one or two things that are in relation to relays, specifically. TLDR; timing games are starting to be played, so block proposers are delaying blocks to earn more MEV. I think Toni actually might have more data on this, but aside from that obviously there are some implications from timing games being played, some being more missed slots and some more involved implications around attester timing games. The idea is that if proposers start delaying their proposals, there might be incentives for testers to delay their attestations.

Lots more details in the ethresearch post, but the two things I wanted to mention more specifically are potential mitigations that would involve relays, as opposed to mitigations on the protocol side. They represent opposite approaches: one is more the decelerationist approach, and the other is the accelerationist approach. Currently, the honest specs are defined as proposing blocks at T equals zero, so basically at the beginning of the slot. We know that's not incentive-compatible, and so we're starting to see deviations.

One way to mitigate this in an unsustainable, non-incentive-compatible way, but possibly using social coordination, would be for relays to stop accepting bids after T equals zero. This would mean that to extract more MEV, you would need to have a direct relationship between proposers and builders to circumvent the usual MEV-boost pipeline via relays. There are obviously drawbacks and benefits to this approach. The benefit is that it reduces social coordination from all validators to a set of relays, but the drawback is that it's still rational to defect, and it's unclear how long this would hold, but essentially vertical integration between builders and relays would enable defection for validators.

The second approach, which is the opposite of relay enforcement, was brought up by Justin, I believe. It's the idea of timing games as a service, which is basically saying that relays are well-positioned to know the latency between relays and validators. Instead of validators requesting a header, the relay could push a header at a point in time when they think it would be optimal, essentially democratizing access to timing games MEV. The benefit here is clear, as relays are well-positioned for latency considerations, allowing home stakers to easily access MEV. The drawback is that it's accelerationist and gets us immediately very close to the negative externalities of timing games.

One thing that's not entirely clear is how, as a proposer, you would not end up relying on a single relay doing these timing games as a service without reintroducing some complexity. If this timing games service is a push format from the relay to the validator, you have to make a decision if you get a push from relay A at, say, two seconds into the slot, and you know you might receive a later push from relay B. Which header should you sign? This becomes a complex decision in itself. That's at least one open question, aside from the broader cost-benefit analysis. I think these two ideas, relay enforcement versus timing games as a service, are two mitigations on the table, besides others, that I think make more sense to discuss offline, but I wanted to bring them to attention since many relays are present here.

Mike, please feel free to add anything.

He covered it perfectly.

I'm curious what the other relays think about it.

I mean, we're starting to get a feel for what's happening on the proposer side of things. Some proposers have been stealthily playing timing games for some time, and then P2P made an announcement, and now we're seeing the floodgates open. My prediction is that within a few months, the majority of proposers will be playing timing games.

In terms of relays, so far, it hasn't been very competitive, but there are examples like Titan. Kubi is on the call, maybe he can talk about this. Titan built an ultra-fast relay in Rust, and they could defect. It just takes one defector to force the hand of everyone else. I don't see the equilibrium lasting very long. I'd be happy to try and come up with some short-term agreement, but it feels like it depends quite a lot on the social layer, and it's not necessarily sustainable.

The good news, in my opinion, is that once we've picked the low-hanging fruit, the timing games are fairly minimal. We're talking about optimizing the last 120 milliseconds for someone who's really sophisticated. And 120 milliseconds is only 1% of the slot time, so you're potentially just optimizing 1% of MEV, which is hopefully very small. This 1% optimization comes at a cost—it means that sometimes you miss a slot. If you were to miss more than 1% of slots, then you're more likely not going to be net negative because you're making 1% 99% of the time, but 1% of the time you lose more than 100%.

So, one good outcome is that we have more sophisticated MEV boost software that picks all the low-hanging fruit. Right now, there's a good two, three, maybe three and a half seconds of low-hanging fruit, and once that's picked up, we're left with the really advanced timing game, which is fairly minimal.

My own sense here is almost like a knee-jerk reaction. I really don't want relays to police anything. It makes no sense, and it's kind of like; centralization is always easier, no matter what. It's like "instead of doing the hard thing can we do the easy option". So, even before the specifics, the idea of taking the relay, which is already there, and having them coordinate something just feels like the wrong approach for me.

I lean more towards the other approach that Justin proposed. Not even talking about the attestation boost, instead of doing it just like 400 point whatever that is, do we want to do it over time.

There are some long-term considerations outlined in the ethresearch post. But really, if the entire point of PBS and MEV boost is to ensure that everybody behaves in the right way, let's avoid the bad things. I even wrote about it – all the stakers together now have $60 billion worth of stake. To do what's better for eth is the right thing for them if they coordinate, but they don't, they do what's the right thing for them.

It feels off to choose and let them sandwich users or whatnot because you can say, "Oh, how about the relays throw out all the sandwiches too because it's bad?" This approach seems incompatible from my perspective. The entire idea of MEV boost and PBS, is that these are the incentives, these are what people are going to do, let's work around that, and putting relays as a policeman to say, "Don't do what you're supposed to do even though it's their incentive".

[bloXroute is] not playing any latency games, but since the days of proof of work, I would argue that they should wait as long as they can. They should be playing the latency games and adjust based on factors like the orphan fork rate and how much money it makes them. Choose the optimal one that's also very PBS and MEV boost-aligned. That, to me, is the right approach. Anyway, that's my take. Specifically, I don't see relays taking the policing role in any way. It's just off.

Yeah, I mean, generally, the more we can keep relays as neutral operators that are just doing a very minimal set of things, I think that's definitely for the better. Justin made this point that there's probably a lot of low-hanging fruit that might not even touch the relay. Once that's taken care of, there might be some stuff on the margin, but the complexity needed to profit from them is so advanced that it ultimately might not be an issue because so few people even try to go after it.

If anything, Alex, relay enforcement is simpler than relay timing games as a service. Asking relays to do this timing games as a service thing is a bigger lift for them, I guess.

No, certainly, but I mean, it sounds like it might not have to, right? I think that's kind of the point. If timing games as a service only captures this last 1%, then it just might not even be important.

Well, I guess timing games as a service is like... we could start by having MEV boost default call at, say, T equals 2 or something, and then timing games as a service is compressed. But going from what we have now to timing games as a service is potentially a large amount of MEV, right? The default behavior of calling at T equals zero versus timing games as a service, that delta is currently very big.

The suggestion is not to do timing games as a service; the suggestion is to make a few lines of code changes to MEV boost to pick up the low-hanging fruit. This way, the optimization opportunity is only 1%, and then maybe timing games as a service is not even required.

But to get to the point where, you know, that last 120 milliseconds matters, everyone on their local MEV boost has to make the decision about when they call, right? So, you do need to do that latency calculation at some point. Who's doing that? Are we having the relay do it, or are you suggesting having the validator configure it based on their local estimate?

I mean, there's going to be some amount of time to do the broadcasting to the validators, let's say 500 milliseconds. Then, the proposer can see that they're at most, let's say, 200 milliseconds away from every single relay. They can just pick the highest header 700 milliseconds before the end of the slot, and, you know, end of story. Sure, the 700 milliseconds can be compressed by a few tens of milliseconds if you want to be really, really sophisticated, but the low-hanging fruit can be picked just by making simple modifications to the MEV boost software.

I mean, even just adding one line of code, which is delay by 2 seconds before calling a header, that already reduces by half or more than half the low-hanging fruit.

What do you mean by that? What's the proposal that you call the low-hanging fruit here?

Right now, there's a 4-second window to work with, and 4 seconds is just unnecessarily long, so you just call "get header" two seconds in and now the play opportunity to just two seconds. Or you know, you could consider a delay of 2.5 seconds or something similar.

But sometimes proposers do require that time. Not long ago, some Lido operator took 3.6 seconds to process. It depends on their location, it depends on the machine, etc. So, it's not always the case, I would argue. If we cut it by two seconds, these operators are affected, and maybe that's okay, but we should be aware of it.

I think this also becomes a centralizing vector. To maximize your APY as a validator, you'd want to be as close as possible to relays. This would really fight decentralization if relays start doing these timing games as a service.

Right, I mean, we're trying not to do timing games as a service, that's the idea, right? So, I think Justin is just saying that there is a lot of low-hanging fruit where you could imagine that MEV boost is calling multiple times across this 4-second window, or even just waiting, you know. Assuming block rewards are monotonic, which generally I think they are, then you get to a point where, yeah, wait two seconds, two and a half. There's some natural back pressure because the more you wait, the more risky you run of missing your slot. So, in equilibrium, you might get to a point where a lot more of this timing game MEV is being extracted via the proposer, and then you just, you know, the return on investment you get from waiting longer and playing this game will just be so low beyond that point that we might have a nice equilibrium that is more compatible than, say, having relays do any policing, so to speak, on their end.

I'm not sure about that. Just calling "get header" as a standard at second 2 because we do see a lot of reorgs, especially in the first slots, and I guess this is not the big sophisticated validators; this might be already the small ones. So, I think it's just making their life harder.

Well, right. So, now you need to be aware of your proposal with respect to the slot in the epoch. That's also not a huge ask for the CL to be determining because ultimately this is all driven by the validator client, and something like that they should know. So, again, I don't think there are any silver bullets here, but we can probably do, you know, low-hanging fruit. There's probably a lot we can do to improve the situation quite drastically without putting more of these concerns at the relay, which I think everyone wants to avoid.

I would be afraid that if we delay the call by default, some validators will also delay their attestations by default.

Well, hopefully not. That would be a pretty advanced modification.

Not really. It's equally easy to change and possibly also rational, so that's the whole other side of the coin. Yes, certain things are not incentive-compatible, but there are some sort of negative externalities to timing games being played very aggressively. So, it's a very funny trade-off space. Timing games as a service is a very natural endpoint, almost like enabling proposers to stay, quote-unquote, naive and extract that MEV timing game. Arguably, even the relay might be better at updating the timing of their message than a home staker who now has to consider, "Oh, now we all of a sudden have blocks. Do I need to adjust my release time?" So, if you expect every home staker to be aware of this kind of thing, it's unclear if that's better. But then also, if you do timing games as a service, it has other drawbacks. So, it's a complex trade-off space that's very much not clear to me.

Yeah, I mean, that's true.

I just agree that giving solo stakers competitiveness should be a primary concern here. If we have large numbers of staking pools eventually playing these games themselves, it would feel, if you zoom out a bit, healthier for the economics of the space to provide a safe way of allowing solo stakers not to have to do a huge amount of work to keep their APY competitive.

Right. So, yeah, I mean, I think in the limit, it does look like timing games as a service. And this is what I was just going to say a second ago: let's say that we have some low-hanging fruit fixes we can deploy in the next few months that buy us time before we see the advent of these really advanced strategies in, say, 12 months. And maybe by that time, you know, we've bought more time for research; there are things we can do in protocol around incentivizing timeliness that might make these moot completely. So, yeah, I mean, I hear everyone, but we also need to keep in mind that there are things we can do that might have different horizons of effect. And to the extent that we can delay putting all this complexity and like, you know, latency optimization and geolocating proposers and all this stuff within the relay, I think the better.

One idea that I've been toying with is what I've been calling attester-proposer separation. So, what a validator could do in theory is have two nodes: one that does the proposing, which is colocated with the relay, and then the other one that does the attesting, which is much more decentralized. Because if the timing games really become sophisticated, we don't want the attesters to be geographically distributed since that's where the security ultimately comes from. But it is fine for the proposers to be geographically centralized, and that can be achieved in software by having two nodes in two different geographic positions. But this can also be done at the protocol layer. That's something we've been thinking about, and I think Mike and I will be releasing a write-up on that fairly shortly.

Justin, taking this further, have you considered the idea that, it's not PBS really at that point, but if you consider that it should be the attesters who require payment to attest. Basically, attesters capturing the MEV. If you pay me 50% of whatever you're taking to yourself, I will sign it, and if not, then I don't. And that becomes the end, because it always feels to me that the MEV supply chain stops at the proposer, which is one step too early. It's really the attester. So, if you're thinking about attester behavior and whether they sign it or not, then attesters should really start charging the proposer because they have power.

Yeah, so what you're describing is actually pretty much exactly what Francesco wrote on ethresearch called MEV Smoothing, where the MEV is smoothed equally across all the attesters. It doesn't go to the proposer, and then there was basically the same construction, but instead of distributing to the attesters, you burn it, and that was called MEV Burn.

The nice thing about the attester-proposer separation is that you have this auction mechanism where the chain itself sells the execution slots. So the end of the pipeline or the end of the chain is the protocol itself; it's no longer the attesters. So you can have the protocol capture the MEV.

I'm not too worried about that, and also, these things become a little different with attesters. The dynamics are a little different; we're talking about group dynamics versus individual dynamics. Also, what I call entropy, which is basically the different types of messages that make sense to sign, kind of changes quite dramatically. As a proposer, I can sign whatever block hash I want. On the other hand, as an attester, I can really only sign two messages: message number one being, you know, I saw the proposal on time, and message number two being I didn't see it on time. So things do change quite dramatically.

Yeah. That's actually the reason, and I was saying, like, proposer does keep half and pass half, and you could even think about passing some to the next proposer, but I agree proposer also has power. So anyway, we could jam on it some other day.

I mean, one thing I would note at this point is that attester-proposer separation is extremely exciting as a research direction, but it's also, I think, in terms of time scales, on a different order. In terms of timing games, they are just going to be played very quickly. If we see attested timing games, they will be found out much sooner than we will ever be able to ship APS, should it come to that. But yeah, there's a bunch of nice things that APS could get in terms of, you could basically treat proposers as sophisticated actors who you can then penalize extremely heavily for missed slots, and so that kind of prevents attester games and to the extent that it's not worth it to play timing games so aggressively. But yeah, different time scales, I would argue.

And in some weird sense, it might actually be good if attesters do start playing timing games because we'll have real-world data, and you know, Ethereum being anti-fragile can just learn from that and have ultimately a better long-term design.

Cool, yeah. APS is definitely an exciting direction to keep exploring, and I think on that note, we might go ahead and table the call. Are there any closing comments?

[silence]

Okay, great. Thanks, everyone, and yeah, I'll see you all in the new year.