auction - should (header,bid) messages be publicly accessible during the message passing period?

[obadiaa]

Description:
In the current design of MEV-Boost, relays release (header,bid) pairs to all instances of mev-boost that pings it (please correct me if this is wrong). This means the pairs are public information that can be used as input for auction participants.

For example, a builder could watch the 'mempool' of (header,bid) pairs, see what the maximum bid and compare it to the maximum they're willing to bid. If they can bid higher than max_current_bid then they just add 1 wei to it.

If you assume this behaviour from multiple builders, we have a game where:

• the optimal bidding strategy is to bid by increments and always bid the smallest increment allowed more than the current 'winning' builder.
• the optimal bidding strategy is to wait until the last possible moment to bid as to not reveal the information to other bidders.

Questions:

1. Should we make the 'mempool' private only to the proposer of a slot? Technically this would require proposers to send an authenticated message to the relays, proving that they are the proposers of the current slot. How technically difficult is this?
2. Is this PGA behaviour problematic? Does it overwhelm the communication network or pollute its bandwidth with incremental bids from builders or burst of bids close to the deadline?
3. What does this non-sealed bid auction look like?
4. Is this a worry at all since in a repeated game, this should trend towards bidding max of the opportunity?

[metachris]

relays release (header,bid) pairs to all instances of mev-boost that pings it

In the current spec that is true. The getHeader request is unsigned and can be sent by anyone.

[thegostep]

Something important to keep in mind is that it's important for builders to find out if relays are prioritizing their payloads correctly. I expect relays to be incentivized to publish summaries of receive and publish timestamps as well as bid value for all requests.

The more standardized this data publishing is between relays, the better.

Other metrics which will be critical to track for mev-boost system health: relay reveal performance, relay latency, fraud proofs, bid value, builder rankings, relay rankings

[charlescharles]

I think public bids are the equilibrium - builders will bid up to their value for a given slot, and proposers are therefore incentivized to publish the current highest bid.

I'm a bit worried that this will cause a speed/bidding war: builders send their blocks to the relay at deadline - epsilon, and also try to learn about other bids from the relay as fast as possible (it seems best for relays to publish bids over some fair multicast feed as soon as they're received - if you can learn about bids faster by connecting to the relay over the mev-boost api, builders will just do that, which seems bad. If relays don't publish bids, then I think validators will end up running mev-boost mods which do that, which also seems bad)

[quintuskilbourn]

Agreed there are several issues which come to mind:

1. Latency advantage for builders close to the relay, because of information asymmetry and just-in-time bidding.
2. This adds further incentive for validators to wait as long as possible before signing a block header (related thread: how does pos ethereum prevent bribery for late block proposal? #111 (comment))
3. Relayers incurring additional overhead (spam), although I am not sure how significant this will be relative to a relay's capacity. (please weigh in if you have a better idea).

A sealed-bid auction (assuming highest bidder wins) in a competitive market, should see the highest bidder bidding close to their true value (how much value the extracted) so the final bid shouldn't be any worse than the public case, but with none of the downsides listed above.

On the point of the value of transparency: relays can offer a service in which information about block bids is made public after a slight delay. This can ensure that e.g. Lido validators are truly accepting the highest bid and not taking payments through side channels.

[ralexstokes]

Relayers incurring additional overhead (spam),

some low-hanging fruit here is to only allow 1 bid per builder per slot, which seems like it would go a long way to prevent any type of PGA-style behavior. if we have some cancellation mechanism then that would be 0 or 1 bids per slot

further incentive for validators to wait

honest validators are already enforcing a timeout on the availability of headers, cf. the BUILDER_PROPOSAL_DELAY_TOLERANCE constant and its usage here: https://github.com/ethereum/builder-specs/blob/main/specs/validator.md#relation-to-local-block-building; validators are free to deviate of course, but in practice defaults do go a long way

even if we only allow 1 bid per builder per slot, we still have the "first mover disadvantage" if the "mempool" is public...

the only immediate issue I see with making the "mempool" private is that it harms validator privacy as in expectation only the proposer will be making a request in a given slot -- if you can pull off any sort of correlation attacks, then you can start mapping proposers to their IPs. there are mitigations here and you have this problem to a lesser extent (up to the size of the "anonymity set") w/ the public "mempool" so it may not be worth worrying about here.

[barnabemonnot]

We discussed it briefly during an earlier call, but it may be worth thinking about incentive-compatibility of the different parties. Broadly:

• Builders want their bids to win, and they want to pay as little as possible to get in. They can choose which relays to send their bids to.
• Relays want as many successful builder bids to be included, it signals higher relay quality to builders and so more traffic towards a specific relay. They can choose to publish or not the bids they receive.
• Proposers want the best possible bid to win, so they earn a greater profit from the builder.

I describe a strawman auction first:

• Builders send their bids to relays privately
• Relays commit to sending one bid only to proposers, using a second-price auction: they charge the best builder the bid of the second-best builder. Bids are sent publicly to proposers to avoid the issues associated with private mempools
• Proposers choose the highest received bid before publishing

This auction has nice properties:

• Builders don't need to engage in sniping wars: they privately declare their willingness-to-pay to the relay and know they will only pay the second highest bid, which would be the natural result of a PGA style open bidding process. They can even declare their bid (privately) to as many relays as they want.
• The onus is on relays to gauge how much risk they are willing to take with respect to when they should publish their "best bid". Relays who consistently publish too late never get blocks included and so builders defect to more timely relays. Relays who publish too early have the same issue.
• Proposers can have a very passive strategy that guarantees them the current highest revealed bid: set a deadline for publishing their blocks and listen to the bids, picking the highest received bid when they publish.

Some issues:

• The second-price needs to be implementable. A builder signs its own bid, so how can the relay charge the second-price? Do they ask the builder to resubmit their bid at the second-price, with the guarantee that the relay will publish the resubmitted bid? If the relay doesn't provide good quality of service or deviates in any way, the builder would choose a different relay that is more reliable => good to note here that the builder-relay relationship is essentially a repeated game.
• Incentive-compatibility for proposers: This is the more serious problem of the auction. A proposer has an incentive to accept bids from relays who deviate from the "honest" specification of "one bid only per relay". For instance, if the relay obtains a better second-best bid after they communicated an initial bid to the proposer, they could communicate the better bid to the proposer, and it's in the proposer's interest to accept this new bid. If this is true, then the relay's best strategy is to always offer the proposer its current second-best bid, and update it based on the bids it receives. On the other hand, if a strong enough social norm forms around relays, the constraint of one bid per relay can hold. If it doesn't hold, it just ends up being the same as the timing game where all players publish as late as they possibly can in the case of "one-bid-per-builder", or spam with insignificant increments otherwise. The constraint can also be relaxed by allowing for "up to two bids per relay" in case the norm seems untenable. I am not aware of any other mechanism to force relays to respect the constraint.

Anyways, I mainly wanted to present this strawman as a way to explore a different point in the design space, but I realise it may be impractical (and there are possibly flaws I haven't thought about).

[charlescharles]

@barnabemonnot here are a couple things that may or may not be issues with your strawman setup; I'd be curious to hear your thoughts.

• what prevents a builder-relay from connecting to a second-price relay, waiting to see its bid, and then itself bidding +epsilon to proposers? even if the relay validates that the proposer is a legitimate validator scheduled for this slot, isn't there a more general problem that the proposer is incentivized to publish all the (header, bid)s it has received as an invitation for improving bids?
• there are many ways for relays to undetectably defect (lying about the second price in return for some payment from the proposer, colluding with a subset of builders to raise the second price, etc)

[barnabemonnot]

Thanks @charlescharles !

• I was under the assumption that relays were somewhat limited in number and identifiable, as in a builder couldn't become a relay at the same time, this came up while I was writing but I don't remember where exactly now, it does break something else if builders can just "spawn as relays" too. Regarding the bids, I believe they should be publicly visible once the relay publishes them. But indeed public bids means there is a waiting game for relays as well, who can observe currently published bids and if their current highest bid is higher than the publicly published bid, bid an increment above (they can do that only once however, if they are honest about not publishing multiple bids for the same slot).
• Good point on the undetectable deviations... I don't know why I had in mind that this would be potentially detected by builders. Now I wonder if it's enforceable.

[charlescharles]

Yeah, I have been conflating builders and relays because relays kind of seem irrelevant in a game theoretic analysis (or something) - if a mechanism is incentive-compatible for neither builders nor proposers then I think we should expect new relays to emerge that don't follow the rules. I agree that social norms + only writing software that follows the rules might suffice for some time (maybe indefinitely?), but it seems preferable to design a mechanism which is more game-theoretically robust, if possible :)

[barnabemonnot]

Can you expand on what relays look like then, in a MEV-boost landscape? I thought of them as a handful, like Infura, Metamask, Flashbots, well-known names, for which validators using MEV-boost connect to directly (like add their addresses in a config file)

[metachris]

Yes, validators need to configure mev-boost with each relay to connect to specifically (using the relay address and pubkey, as cli arg or a config file).

[charlescharles]

Can you expand on what relays look like then, in a MEV-boost landscape? I thought of them as a handful, like Infura, Metamask, Flashbots, well-known names, for which validators using MEV-boost connect to directly (like add their addresses in a config file)

Well, if the world is such that it's possible for proposers to make more money by bypassing the existing relays and connecting directly to builders, I think we should assume that this will happen. It's not hard to imagine someone starting a relay and saying "if you add us to your relay list and run this mev-boost patch which publishes (header, bid)s, you'll be able to make x% more" - behind the scenes, they're a builder who's actually one of the flashbots builders (or something), and just bidding epsilon more than the existing bid whenever their value exceeds the bid.

[thegostep]

How the relay landscape evolves over time is difficult to predict. We believe the ideal will have relays as independent 3rd parties who are not actively profiting from the private information they have access to.

However, I still expect all three of these to occur:

1. Independent relays will be operated by trusted entities like Infura, Flashbots, Alchemy, Bloxroute, and others. These are likely to attract the most validators and therefore the highest quality builders. Some of them will be corrupted and sell or otherwise make use of preferential access to the information they hold.
2. Some validators (particularly the large ones) will want to run their own relays. This will allow them to reduce the risk of proposing an invalid block or for their block proposal to be withheld.
3. Some builders will want to run their own relays. They will want to do this to avoid needing to trust a 3rd party relay or to minimize their latency.

I tend to agree with @charlescharles claim that if any actor can see the bid, then it's best for every actor to see it. Anything else creates an opportunity for bribery.

We've previously discussed exploring a system where no actor outside the builder sees the bid. Not even the validator. This might be possible to achieve using some mpc or sgx committee for selecting the winning bid. This is pretty green field exploration.

[metachris]

This topic was discussed in today's Consensus-layer call, see also notes from Ben and the recording (excuse my bumbling ^^).

[barnabemonnot]

The more I think about it the more it seems like few rules can be enforced and perhaps it's best to let relays operate their favoured trade-offs. Relays have two constraints:

• They want to give block producers their most up-to-date bids and they want to receive the most up-to-date bids from builders
• They don't want to crumble under spam/DoS

Any rule regarding their behaviour typically reduces to a race to the bottom, e.g. imposing builders to resubmit with a 5% extra value rule means builders will move to a relay that imposes 4% instead. Even setting such a rule as a social norm seems tricky, as indeed builders could become their own relays to bypass any norm.

I am not clear however how the trust model works for validators running their own relay, as per @thegostep suggestion. Isn't the point of the relay to shield the block payload from the validator? Is this supposed to work in a case where the builders trust large validator entities to not steal their blocks? That doesn't seem unrealistic, but it does reintroduce a small element of economic centralisation (assuming the latency difference is significant for validator-run relays)

[charlescharles]

The more I think about it the more it seems like few rules can be enforced and perhaps it's best to let relays operate their favoured trade-offs.

Yeah, I totally agree with this

I am not clear however how the trust model works for validators running their own relay, as per @thegostep suggestion. Isn't the point of the relay to shield the block payload from the validator? Is this supposed to work in a case where the builders trust large validator entities to not steal their blocks? That doesn't seem unrealistic, but it does reintroduce a small element of economic centralisation (assuming the latency difference is significant for validator-run relays)

Yeah, this is why I feel like relays disappear in any kind of formal analysis. If some large validator entity connects to all the big relays, but also runs their own relay, then as a builder you may want to connect to that validator's relay to skip 100ms (or something) worth of network hops. Even if a validator-run relay steals your trades with some probability, if the probability isn't too large and the validator is sufficiently big you may still want to send blocks to them.

[barnabemonnot]

Right, so assuming this eventually happens, perhaps a strong norm around relays sharing the bids they receive should be enforced. If big validators do run their own relays, they could close them off to being "pinged" by observers. While it's not inherently bad that a validator would collude with a builder, it feels like relevant information to the network as a whole. By keeping private the bids the relay receives, maybe it's not clear if such a collusion is happening?

[quintuskilbourn]

In my view the key focus should be preventing proposer centralisation - after all, this was the original motivation for PBS implementation - and this is best done by examining the behaviour of proposers. In order to avoid centralisation of proposers, we would like sophisticated proposers to have little to no advantage over “naive” proposers exhibiting default behaviour or other proposers deviating in a less sophisticated manner. Ideally, there would be a clear dominant strategy for proposers which we could set as the default. Unfortunately, this seems unrealistic (at least until more data is gathered), but we could still strive for setting a default with a payoff close to what a sophisticated proposer can achieve.

A rough way of looking at the builder-relayer-proposer dynamic is that there are two parties determining the mechanism at play - the relays and the proposer, with the proposer having the last move and therefore most important role. If relays have one default behaviour (e.g. sealed bids) the proposer could flip the mechanism and change the game (e.g. to open bids).

Some examples of what I mean:

• If naive proposers do not sign getHeader requests, relayers expose bids by default since it is hard to distinguish the true proposer from those pretending to be the proposer. Builders would want access to other builders’ bids without exposing their own so a builder may choose to run its own relayer to accomplish this. If proposers feel that private bids may increase their profit or they receive payment according to some side agreement then they can allow this by changing to a version of mev-boost that allows for signed messages or sharing their IP.
  • One reason private bids may increase their profit is if builders given access to private bids agree to always increase the max bid by some minimum amount if they increase it all, which may be worthwhile for proposers if the sealed bid always comes right before block selection. Other reasons could be a pre-agreed payment (validators may prefer consistent income in dollars vs. inconsistent ETH and MEV payments).
  • As a side note: if relays are able to tell which requests are from the proposer for the current slot, they could hide bids of partnered builders from everyone else calling getHeader in order to give those builders an advantage.
• If naive proposers sign getHeader requests to run sealed-bid as default then proposers could change the auction to open-bid if they believe open-bid to be more profitable or are being payed.
  • There is nuance here as well since proposers could only open bids to a subset of builders/relays.
  • Proposers could expose bids in two ways
    • Propagating bids (so latency becomes important). This could happen in exchange for some pre-agreed payment perhaps.
    • Refusing to sign getHeader messages. If validators are big enough this could force relayers to expose their bids to everyone since they cannot distinguish proposers from those behaving as proposers.

Wat do
Ideally we choose a setup in which proposers have no incentive to switch and no sophisticated techniques for improving their revenue. The literature is not particularly decisive on this point as different assumptions predict different proposer revenues at equilibrium:

• Symmetric, independent, private values for builders should lead to the same revenue for sealed-bid first-price and English auctions (Revenue Equivalence Theorem)
• Symmetric, affiliated values should lead to a higher payoff under an English auction
• Under other sets of assumptions like asymmetry, collusion or risk-aversion there are equilibria with a higher payoff for sealed-bid auctions

See this paper for a good overview and pointer to other results.

Unfortunately, it is unclear which assumptions will hold for several reasons (e.g. how OF will be divided/shared between builders). These results also don’t cover cases where some agents are operating in an open environment and other agents are operating in a private environment.

(It is worth noting (as pointed out in flashboys 2.0 paper) that if the block-selection time is highly predictable as being at time T, then an open auction defaults into sealed bid where “sealed-bids” are submitted at T-d where d is the time taken for a bid to reach the proposer. However, T and d may not be known to a sufficient accuracy and vary across agents such that it is not the case that all auctions end up being sealed-bid.)

This leaves us the question: will there be stronger centralisation forces among proposers who facilitate sealed-bid or open auctions?

There are several factors to consider outside of the advantage gained from deviation and deviating better than other deviating proposers. For instance, if a certain deviation becomes very widespread (e.g. most proposers provide private channels) then relays may start doing this themselves as a service. Alternatively, if certain deviations by large validators affect the market such that some builders shade their bids lower or drop out suspecting misbehaviour, deviations may cease to occur.

One last thing to note on the practicality of enforcement: if proposers allow private channels, relays which do not expose bids are likely to become the norm. All things being equal between relays, no builders gains by sending their bids via open relays.

If proposers don’t allow private channels, the gains of a relay that doesn’t expose bids may be negligible (and perhaps infeasible if proposers don’t implement signed messages).

If we put aside proposer centralisation, it seems intuitive that a default-open system is better for competition. For example if 90% of the builder-relay world operates in the open and 10% manage to keep their info private. The maximum difference between the default and the "cheating" parties is 10% information.
If the builder-relay world is private by default then most parties have only their private info but some parties have close to 100% more info in absolute terms.

[come-maiz]

Wow, this is a lot 🤯. I appreciate all of your comments and how you make it as easy as possible to follow <3

I would like to see more people interested in running relays to participate here. I think we only succeed at this part if the network of builders collaborate to design it. My immediate proposal to not explode is to insist a lot that anybody wanting to be a relay should start by running a builder. That way they get in touch with the complexities of MEV and start participating on these discussions, so when we have multiple relays we have good mitigations in place and a plan for exploring permissionlessness.