Ethereum MEV Extraction and Rewards - Discussion & Policy Groundwork

Department of Decentralisation
1

Note: this is a copy of a document on hackmd which can be found (and commented on, if preferred to writing in the forum) here.

Introduction

Following the adoption of the Lido Operator Set Strategy, and specifically the Strategy for Ethereum, Lido also needs to adopt a clear and public strategy with regards to MEV extraction on Ethereum. From a rewards perspective, Lido has already outlined a plan and technical approach on how both priority fees as well as possible MEV rewards can be (re)-distributed between stakers, node operators, and the protocol. What remains to be clarified is if and how Lido Node Operators (NOs) will participate in MEV extraction.

Should Lido Node Operators extract MEV?

Given market dynamics, the widespread adoption of MEV extraction in PoW Ethereum, the close alignment between the Ethereum Foundation and teams like Flashbots, and clear plans for Proposer Builder Separation in the Ethereum Endgame, it would be hard to argue that Lido Node Operators should not extract MEV and share rewards with Lido stakers. Concisely:

  • Stakers will generally go to the staking provider with best returns, and if Lido does not extract MEV rewards and share it with stakers, some other staking provider will;
  • Efforts should be made to minimize MEV at the application layer, and even at the base layer when possible, but the reality is that some MEV will always be available and thus a market for it will emerge;
  • By enforcing an open and democratic approach to MEV, Lido stands to be able to “set the tone” in terms of discouraging deleterious MEV (e.g. reorg-based MEV), and paving the way for in-protocol PBS by adopting the prevailing form of PBS-lite in the meantime.

If so, how should Lido Node Operators extract MEV?

MEV extracted by Lido Node Operators should be done as openly, transparently, and democratically as possible. Exploring the solution space around this is why Lido joined the Flashbots ETH2 Working Group. Given the potential share of total stake that could be running through Lido NOs, it would not make sense for Lido to use an MEV extraction and rewards mechanism that is opaque and not open to the rest of the ecosystem.

Therefore, the optimal possible solution would be:

  • Utilizing middleware/infrastructure that is open source, useable by any interested party, and transparently operated by Node Operators who run nodes & validators for Lido.
  • Outsourcing block building to the maximum extent possible. This means that Lido validators should only include blocks that come from public/open block builder markets, and not engage in building blocks “in-house” (referring to both Lido and/or Node Operators).

What might a possible solution look like?

The most likely solution until PBS comes to fruition looks something like the below:

  • Lido DAO and Lido Node Operators formulate an agreed-upon policy regarding the possible extraction of MEV and sharing of MEV rewards with Lido stakers;
    • We imagine the policy could take various forms and also evolve over time, with some examples being:
      • All NOs agree to participate in MEV using the same manner and usage of this infrastructure becomes obligatory for all NOs (present and future, with a possible escape hatch for those who do not wish to participate),
      • NOs agree to participate in MEV extraction, and others may abstain (apart from the MEV inherent to public mempool tx-ordering by priority fee),
      • NOs generally agree to participate in MEV, but some percentage of validators could be used to test MEV-minimizing block proposal approaches (e.g. shutterized beacon blocks)
  • This manner would adopt the most robust and open solution available on the market at the time (e.g. currently the solution with most product-fit and general acceptance is Flashbots’ MEV-boost, but solutions should be periodically re-evaluated);
  • Lido NOs would run MEV-boost as a part of the infrastructure that they run for Lido (along with Execution Layer nodes, Consensus Layer Nodes, Validator Clients);
  • Lido NOs would use a public set of possible relays to ensure inclusivity of prospective block builders, to be maintained by the Lido DAO (possibly in coordination with other staking solutions);
  • Blocks would only be accepted from the open block market via the chosen infrastructure (e.g. MEV-boost) or from the normal block-building process via the public mempool (fallback mode in case MEV-boost is not functioning properly), blocks should not be built in-house by Lido or by Lido Node Operators (NOs are free to build their own blocks for blocks proposed by other validators that they run, but not for Lido validators);
  • Node Operators who fail to uphold the policy would be subject to having stake de-allocated from them (post-withdrawals), their validators exited (post triggerable exists via 0x03 or something similar), and potentially become de-registered from operator registries across “Lido on X” protocols.

Next steps

The DAO should deliberate on the above and any additional considerations and establish a policy on MEV extraction and rewards distribution on Ethereum.

I propose the following:

  • The policy should be ratified by the DAO prior to the Merge.
  • The policy should include, at a minimum:
    • The goals and scope of the policy;
    • Whether blocks should be built by Node Operators (NOs) in the ideal flow, and in which cases deviation from this may be acceptable;
    • The infrastructure that Lido NOs can utilize in furtherance of execution of the policy;
    • The repercussions for NOs not adhering to the policy;
    • How often the policy should be reviewed & re-evaluated by the DAO.
  • Infrastructure identified in the policy should be appropriately tested to the satisfaction of Lido and its Node Operators before being put to use on Ethereum mainnet; in case this has not been achieved before the Merge then implementation of MEV rewards gathering and distribution should be delayed until the solution is performing satisfactorily.
  • The policy should be periodically reviewed (e.g. every 12 months at a minimum) in order to assess whether its implementation is accomplishing its stated purpose and to re-evaluate tools and infrastructure that could be utilized.

Proposed Deadlines

This set of deadlines assumes that the Merge could occur in late August at the earliest (we think that this scenario is optimistic and not very likely, therefore a safe timeline to work against).

Topic Date
Discussion Week of Jun 20 - Week of July 18th
Policy is drafted posted on forums for final comment Week of July 25th
Policy is ratified by DAO vote (Snapshot) Week of Aug 4th
Implementation is fully tested on testnets & status is reported to the DAO By late August
9 Likes
2

Thanks for laying the foundation for this discussion Izzy. IMO, this should be among the highest priority items for Lido. If we can assume that stakers act rationally and in their own best interest, then Lido must adopt MEV extraction. More importantly, Lido is uniquely positioned to drive the democratization of MEV, which is a systemic risk if unchecked.

Regarding infrastructure:

I agree that Flashbots is currently the best option and it seems logical to coordinate this infrastructure among NOs. However, I am unsure of the implications of allowing NO’s to adopt a competing infrastructure if we wish to provide them with autonomy.

Regarding repercussions:

Repercussions for not adhering to the policy, de-allocation seems like a good starting point. We should consider an explicit and progressively more severe program of repercussions. For example, do we de-allocate some % per offense? Subsequent offenses resulting in more punitive de-allocations.

I think its equally important to design a repercussions that is linked to the offense in absolute terms. While its hard to imagine today, as MEV grows, there may be a scenario where a NO mathematically concludes the benefit of deviating outweighs the repercussion of some % de-allocated. In consideration of this, a 2nd tier review or punishment may be warranted that uses a different calculation of the offense.

In conjunction with the latter punishment, we may also consider how to implement direct repercussions vs. some long dated punishment of DAO de-allocation. A deposit and slashing like mechanism would provide a means to accomplish this.

While these may seem excessively punitive, I think its important to consider the economic incentives.

2 Likes
3

I agree that Flashbots is currently the best option and it seems logical to coordinate this infrastructure among NOs. However, I am unsure of the implications of allowing NO’s to adopt a competing infrastructure if we wish to provide them with autonomy.

Candidly, I agree; the reason I’ve left some wiggle-room in the discussion document is concerns around enforcing only one solution even if multiple solutions “tick all the boxes”. The important thing here is to:

  • get blocks from an open marketplace to remove block building responsibilities from the block proposer (node operator)
  • ensure that the block marketplaces are openly + freely accessible and decentralized
  • ensure that node operators use the prescribed infra and only “fail over” to vanilla building in the case of tooling or infra failure

Forcing one solution helps in terms of making monitoring and adherence to policy easier to ascertain, but if the solution doesn’t do a great job of ensuring a decentralized block builder marketplace then we ultimately paint ourselves into a difficult corner. We should discuss these possible scenarios and how we would respond to them in order to come up with a properly robust policy.

Repercussions for not adhering to the policy, de-allocation seems like a good starting point. We should consider an explicit and progressively more severe program of repercussions. For example, do we de-allocate some % per offense? Subsequent offenses resulting in more punitive de-allocations.

Bearing in mind that stake-reallocation cannot easily happen until triggerable exits are implemented, the details are perhaps one of the few things that we could leave to the next iteration of the policy. The difficulty here is a root-cause analysis for the deviation from policy (i.e. was it a false positive or not?). I think depending on the approach that you take to this question you would come up with possibly different solutions with regards to penalization mechanisms. For example, if the approach is purely automated, then some sort of “X strikes” policy together with a “holiday”-like model as used in trading for compliance violations could make sense. If we’re doing a qualitative analysis of each deviation (or for certain categories/sizes of deviation), then perhaps it makes sense to have stricter penalties as you suggest. For example, if there’s serious indication that this was a “profit taking” move vs a mistake or operational error, then we should seriously consider removing all stake from the operator. However this raises the risk of a possible validator “ransom attack” – this may not be a sizeable risk currently with our curated set, but it is much more likely once there are permissionless elements in the validator set. On the other hand, technologies such as DVT may serve to reduce the risk of potential attacks, allowing us to be more stringent with regards to punitive measures.

2 Likes
4

What I like about mev-boost is that it is an extremely simple proxy. It in turn points to one or more relays.

I’ll argue that it makes sense to have a list of DAO-vetted/approved relays. NOs may use one or multiple of these, but adding to the list or removing from it would require DAO involvement.

mev-boost itself is not much, I want to emphasize that. Which relays are chosen, and thus which builders and searchers, is everything.

1 Like
5

I can understand the reason (and I agree with it) to have a minimal mandated list of relays; but what’s the reason to disallow Node Operators to extend it however they want?

1 Like
6

Perhaps we can allow it; from my perspective It’s mostly about policy monitoring / adherence and security.

Monitoring
I don’t think there’s a way to guarantee that the minimal mandated list is at least included without actually proving that the blocks executed actually came from a relay within that list. @George can you please let me know if this is correct or not?

Basically in the monitoring system proposed, the Lido watchtower/monitoring system would (a) need to know which other relays these node operators are using, (b) be collecting data from those relays, (c) somehow confirm that in the case that a block came from from a relay not in the “minimum list” there were no blocks proposed by relays in the minimum list with block reward > processed block. If we could do this then I think it could work.

Security
In theory, part of the reason the reason for the searcher->builder->relay separation is that relays should be performing some kind of “checks and balances” on builders (e.g. if builders turn out to be bad / proposing bad blocks / not paying rewards, relays should blacklist them). And for our monitoring / security perspective, we rely on relays to be good actors or de-list them if not (even if their builders are at fault, since they are the proxy for builder-groups). If we have no control over the relays that an NO adds, then we cannot directly respond to possible attacks (we also introduce additional attack vectors because we can’t quality control the relays added).

Further, If you allow NOs to define their own relays, then we also have scenarios where NOs would potentially actually be running the relay(s) that they add. Doing so would allow the NO to peek into the contents of builder-proposed blocks, and therefore greatly increase the chance of cheating / taking some builder’s block. This would also allow an NO the possibility of running a builder + a relay which puts us back in the “NOs shouldn’t build+propose their own blocks” problem-space and introduces concerns around censorship resistance and side-channel payments for inclusion into blocks. Obviously this can still happen with a more controlled list of relays, but I would argue that the chances of it happening go down drastically given a good vetting process.

1 Like
7

I don’t think there’s a way to guarantee that the minimal mandated list is at least included without actually proving that the blocks executed actually came from a relay within that list. @George can you please let me know if this is correct or not?

I don’t see a direct way to check usage of relays from the list. In the monitoring, we are planning to check payloads in blocks against what the relays offered for that slot. If the tx roots matches, we can very likely say that a relay from the list was used to produce the block. (it can also be another source, but we assume it’s acceptable, since the same payload was also produced by the relay which we decided to trust)

(c) somehow confirm that in the case that a block came from from a relay not in the “minimum list” there were no blocks proposed by relays in the minimum list with block reward > processed block. If we could do this then I think it could work.

We are planning to analyze the block value and check if the payload with the maximum value has been used. To make sure that any NO does not give preference to certain relays from the list. So it shouldn’t be too hard to add a check that an unknown source with a higher value was used and consider it acceptable.

In case we use a whitelist and count that NOs use only relays from it, we can also monitor missed blocks and make a guess which of relays could have been used by the validator to propose a block. This can help identify malicious relays or detect configuration or availability errors with some relays. If NOs will use additional relays it might make it a bit more difficult to analyze such situations, but looks like it’s not a big issue.

2 Likes
8

Thank you, Izzy and all for the post and the interesting comments. I totally agree it makes sense for Lido NOs to extract MEV for the service. However, I am concerned that by stipulating a particular mechanism and provider for MEV, Lido is creating an unnecessarily homogeneous ecosystem upstream. Given its size, I think Lido needs to be careful creating such rigidity.

I’d rather see Lido focus on the rewards and fees it receives and that they’re appropriate versus market mean, rather laying down rules for NOs. After all, the whole basis of Lido’s model is that it has all these diverse NOs, all doing it differently but all attesting and producing blocks at a reasonable rate. Why can’t that approach be adopted here? Outcome not method.

4 Likes
9

However, I am concerned that by stipulating a particular mechanism and provider for MEV, Lido is creating an unnecessarily homogeneous ecosystem upstream. Given its size, I think Lido needs to be careful creating such rigidity.

I’m not sure I agree that the proposed approach is stipulating a particular mechanism and provider for MEV. Can you expand here? If the policy is “examine available MEV extraction mechanisms and pick the one(s) that ensure that NOs do not build their own blocks and obtain blocks from an open market”, where is the provider lock in? For example, MEV-boost is not a provider for MEV, it is a communication platform through which many MEV providers (block producers) can interact with block proposers (validators). If it fails at doing this performantly and robustly then the DAO should not use it.

Could you elaborate on the possible rigidity that you foresee being created here?

I’d rather see Lido focus on the rewards and fees it receives and that they’re appropriate versus market mean, rather laying down rules for NOs.

The only real rule here I think we should seriously consider working towards is “don’t build your own blocks” (n.b. there’s serious questions/concerns around builder centralization here which I understand and share, but Lido can’t solve for everything). For me building blocks is something that node operators should actively try to avoid to begin with given (a) this will be the post-PBS reality anyway, and (b) block building may engender serious risks for potentially onerous or unsustainable compliance requirements and regulatory capture.

After all, the whole basis of Lido’s model is that it has all these diverse NOs, all doing it differently but all attesting and producing blocks at a reasonable rate. Why can’t that approach be adopted here? Outcome not method.

This may be picking at words, but I don’t agree that Lido is about “outcome not method”. Method is important to Lido – this is why we allocate stake across numerous operators, this is why we consider geographic distribution, this is why we promote client and infrastructure diversity. Outcome not method leads to competition on returns alone, and competition on returns alone leads to centralization. Sustainable outcome with sustainable method is what Lido is about.

Specifically about MEV, I think that allowing NOs to do whatever they want from an MEV perspective has the potential to have deleterious outcomes both for Lido as well as the underlying network (e.g. unchecked multiblock MEV, reorgs, etc). Setting those examples aside, let’s say that Operator ABC who is running thousands of validators via Lido is running a private RPC, selling access to this RPC (via a side-channel), keeping the majority of the profits and only adding as much profit to the on-chain block to share with stakers as necessary to make these blocks perform close to the avg extractable value. Basically they would be selling access to the increased likelihood of proposing a block which comes from the stake delegated to them via Lido, and not properly sharing the benefits from it. Why should Lido enable this behavior?

10

Maybe I misread but I thought the idea was for everyone to use MEV-Boost? Which then ties you into the relay-builder mechanism being proposed. Furthermore, Lido wishes to determine the relay set that validators connect to. Both of these, in my eyes, leads to an awful lot of the network using the same thing whereas wouldn’t the ecosystem be healthier if we all used different approaches?

Fair enough on the methods - of course Lido does go to the effort of ensuring diversity here… which makes me even more curious why we’re not going for diversity with MEV.

The risks around value extraction by others along the supply chain, leveraging the weight or strength that Lido’s staking has provided them exist in every market since forever. Supermarkets, for example, dictate to farmers what to grow, how it should be grown and how much it costs to ensure that they capture as much of the vertical value as possible. Lido chose to operate in a particular way (and has been amazingly successful!) but now wants to extend its control outside of its initial remit. I think it’s about the roles we play in a successful market or process.

Just to be clear - I’m not against MEV-Boost. I think it will indeed be the only game in town for the Merge and we’ll run it. I’m just conscious of the power of Lido in the staking arena and that there’s as much diversity and resilience in every dimension that we can manage.

1 Like
11

re: the policy of “node operators do whatever they want but share most of the profits with Lido”, I have two issues with it:

  • it’s very hard to check if node operators are indeed doing just that. It’s very easy to hide a sidechannel payment. We won’t be able to check if node operators follow the policy.
  • there are ways to extract MEV that I would be at odds with, e.g. hostile reorgs.

There are also potential second-order effects of block building centralization which I won’t dwell on because they are relatively less important because I think they are reversible.

I’m not a fan of mandating a single solution, but:

  • mev-boost is an open enough system to allow for a lot of freedom and competition within it
  • there’s no credible alternative atm
  • it’s basically PBS on the cheap, so it’s likely we’ll come to something similar in the next few years anyway
  • it’s observable enough for Lido to monitor the node operators and make sure they don’t shortchange our stakers
  • it doesn’t allow the forms of MEV I would draw the line at
2 Likes
12

Maybe I misread but I thought the idea was for everyone to use MEV-Boost? Which then ties you into the relay-builder mechanism being proposed.

The idea is for all NOs to agree to using infra that promotes sourcing blocks from open and as decentralized as possible builder market(s). If the only available infra right now is MEV-boost, then it’s MEV-boost, but if other viable solutions become available then of course they should be evaluated and if they are useful should be tested and, if they work well, used.

What are the downsides of the relay-builder mechanism in MEV-boost that you find disagreeable, and how would NOs being enabled to freely build their own blocks remedy these shortcomings (and is the value that this diverse set of approaches enough to offset the risk of things like regulatory capture) ?

wouldn’t the ecosystem be healthier if we all used different approaches?

I’m not sure, there’s definitely a subset of approaches which are most definitely terrible and should not be used, so “Lido NOs should do whatever they want” is not a really good avenue to go down. E.g. Hostile reorgs.

Lido chose to operate in a particular way (and has been amazingly successful!) but now wants to extend its control outside of its initial remit. I think it’s about the roles we play in a successful market or process.

What’s the initial remit here? Because perhaps we disagree on that. This discussion boils down to finding policy and set of mechanisms to avoid scenarios where Lido’s position in the market is utilized by its constituent NOs to make the network worse off overall. I don’t think that’s an extension of our remit, but a core part of it.

1 Like
13

Okay. This is great. I agree with this. And perhaps then we can work from this point and leave the rest for the time being. Thank you for engaging in the discussion. :pray:

1 Like
14

According to the principles laid out in this thread (outsourcing block building to an open and as-decentralized-as-possible block market), I went ahead and created a concrete MEV policy proposal for Lido.
Happy to discuss further in the thread!

3 Likes
15

One important business in MEV extraction is dark pool transactions, where (and many other types of MEV transactions) require participating verifying nodes to keep incoming transactions confidential.
How can the confidentiality of MEV transactions be guaranteed with the verifier operating in a distributed fashion?

16

This is one of the benefits of only sourcing blocks from open builder markets, the Node Operator would never be involved in actually receiving transactions (dark pool or not), but just fully formed and encrypted blocks.

1 Like
17

Following up on the topic of relay management specific to MEV-boost, we have clarified with Flashbots that currently:

  • The block proposer and MEV-boost software in general is not able to evaluate and assess (e.g. via simulation) whether the reward in the block received from the block builder is correct, so cannot drop “bad” or “underpaid” blocks
  • As an immediate practical solution, Relays will basically need to be trusted to do this, which is in part why FB aims to build a monitoring + reputation system for relays (Relay monitoring & preventing continued relay errors · Issue #142 · flashbots/mev-boost · GitHub)

Given the above, I think the allow-list proposal for relays continues to make the most sense, but I want to clarify that at least in my mind the allow-list should not be static. I would propose:

  • All relays utilized by Lido NOs should be public (so that builders are aware of them and may send blocks to them)
  • Relays utilized by Lido NOs should be based on an allow list maintain by the DAO, but allow for NOs (and other parties) to request additions / removals from the list, via a to-be-determined governance process (something via Easy Track may make sense).

I foresee the possibility of various types of relays being created (e.g. even “vanilla” relays that just expect their builders to select from tx pool(s) and order by gas price), and I don’t see any reason that these builders and relays should not be able to accessible to Lido validators.

2 Likes
18

I would add that an allow-list itself is not enough. We also need a must-include list. If Lido’s allow-list included a vanilla relay, and NOs had the option to connect only to this relay, then goals 1-3 from the optimal policy analysis (maximize APR, maximize Eth security, minimize hiding risk) would no longer be satisfied. So we can always add more relays that pass a certain quality threshold, but these have to be purely additive.

3 Likes
19

Yep, agreed, allow list was probably the wrong terminology for this. I’m not sure if it makes sense for there to be separate must-include lists and then an additional set of “optional” relays or whether the list itself must be “must-include” in its entirety.

2 Likes
20

Agree - we should have must-include list, and maybe a larger allowlist. Don’t see much value in having allowlist larger than must-include at this time, but think it’s not impossible we’ll setlle on this for reasons we don’t understand yet.

2 Likes