I'm interested in researching dynamics of MEV in PoS Ethereum and effects of centralization pressure, among other things. I'm also interested in mitigations of risks as part of immediate efforts of out-of-protocol PBS built by Flashbots in mev-boost and ways to achieve resilient relays.

EPF Update #1

EPF Week 1 & 2

TLDR:

1. Deep-dive into MEV from the lens of Ethereum PoS security, ways mev-boost helps, ways mev-boost adds centralization and safety & liveness fault risks
2. Started exploration of exported bulk data from Flashbots MEV-Boost Relay.
3. Initial deep-dives into mev-boost repo and relay-monitor repo & design doc

---

I've spent the majority of week 1 reading about various ongoing core development efforts ranging from AA, EVM improvements, statelessness roadmap, and MEV. For MEV I've been mostly interested in the current roadmap for in-protocol work as well as open research questions around MEV in PoS Ethereum. I spent the rest of the week, weekend, as well as last week doing a deep dive into the history of MEV on Ethereum, current state of MEV as it pertains to the health of the Ethereum network, and open problems. Below are a set of notes I've been taking that are relevant to a few current development efforts, but I also am in-progress of organizing a lot of this deep dive into a structured book-like format that I'll type up in either here, or a separate repo, or perhaps on something like Notion / HackMD. I found that there is a lot of MEV research and MEV learning materials out there, but it's easy to get lost following trails of links from articles, to notes, to videos, and back to articles, so I'll be working on typing up a linear progression that has worked for me to understand why MEV is front and center when it pertains to PoS Ethereum and some very serious centralization risks that come with it that are closely related to guarantees of liveness & safety of the system.

Last week @metachris on Twitter has shared the bulk upload of Flashbots MEV-Boost Relay data. I started a repo here to play around with some of the data and will do some actual experiments this upcoming week. There is some interesting data on the builder submissions, even the ones that were not delivered, i.e. didn't land on chain. There are some obvious patterns like builders re-building and re-submitting the block within short time intervals to include more transactions but I think it's going to be interesting to dig a bit deeper and see what the submission games is like.

I've also done a few deep-dives into MEV visualization resources, the mev-boost repo, and the relay-monitor repo by @ralexstokes.

---

Upcoming Week:

1. Researching risks of builder centralization and technical pathways to decentralize, deeper dive into private order flow
2. Reach out and coordinate an OK for contributing to a few in-development repos
3. Play around with Flashbots Relay builder submission dataset and do some exploration into dynamics of block submissions
4. Start typing up scattered notes into a book-like format for easier reading / more of a report

Notes

Why MEV exists and the centralizing aspect of it

• Event ordering is fundamental
• Different local ordering of events will produce different results
• Maximizing MEV is the task of ordering events locally within a time window, given some current state, such that balance at end of time window is greatest compared to balance at the start of time window
• Maximizing MEV is a difficult and resource-intensive optimization problem
• From a protocol perspective, decentralization is something that we are not willing to give up. Why is MEV centralizing?
  • Suppose we tell all validators in PoS Ethereum to figure out how to extract MEV for themselves, i.e. when it comes to building blocks, each validator have to figure out how to do it themselves. We know that post-merge the rewards for validators when proposing blocks are less then what equivalent works pays the miners in PoW, so their earnings essentially are beginning to depend on how well they perform this task. What are the problems with this? First, MEV extraction is an extra computational "puzzle", so a validator is suddenly forced to invest 1) into more powerful hardware and 2) into "r&d" to figure out how to do this task (suppose for the sake of simplicity just transaction ordering) well. One could make an argument that making a validator run even one extra binary is already an unnecessary pressure. We can see that parties that have more upfront capital clearly have an edge here. If a single party can afford to control a significant number of validators, it can likely afford to develop algorithms for MEV extraction that then every single validator under it's control has access to when called upon to propose a block. This clearly is tending towards economies of scale and has the danger of disincentivizing solo validators that simply want to construct blocks according to some simple FIFO ordering and run the bare minimum software needed to help secure the network.
  • This should be obvious, but an important point to stress is that for Ethereum we really want to have non-advanced validators, like the one descibed at the end of above paragraph, be able to participate and thrive in securing the network. We really do not want a validator to have to choose between monetary reward, i.e. higher APR on the one hand and "values"/"selflessness" on the other. We want to make sure that validators are not incentivized to participate in MEV extraction and are not hurt by their withdrawal from that game.
  • This is one basic way that I have reasoned about "centralization pressure" during this deep dive

Why create PBS.

• Proposer builder separation arises from the realization that those willing to extract MEV in the blocks that they are able to propose to the network will necessarily be advanced entities willing to commit resources to excelling at this task. The solution then is to draw a line between the process of building a block and the process of proposing it.
• As Vitalik put it at some point "sweep nasty builder centralization into one side of the room"
• Block builders are in charge of aggregating transactions, validators take the block and propose when it's their turn. Issues?

Why an actor like Flashbots is needed and why something like mev-boost is built

• separating roles in the goal, but doing so in-protocol is not trivial. Additionally, any in-protocol changes just take time to finalize, audit, verify, model, test, deploy, etc.

• for now, need some out-of-protocol solution to not put pressure on validators to build MEV extracting blocks

• out-of-protocol solution should still separate the roles

• PBS separates roles, issues?

  • Block builders and proposers inherently do NOT trust each other
  • Each is a permissionless role, we can't assume actors are not performing both roles, i.e. both a builder and a validator
  • Proposers can steal MEV -> builders build the block, send to proposer. Proposer takes the block and is in no way forced to honor the fact that the builder built it
  • Builders are not forced to create valid blocks. A builder can build a block that contains garbage / invalid txs, and deliver it to a proposer when their time comes to propose a block, in a way griefing the proposer. Can imagine builders can become picky / choosy about this and do this deliberately to proposers they don't like / have an issue with.
    • Noting here that this intersects with the problem of proposers being publicly known and there is research in-progress to prevent issues around DoS / doxxing of validator, e.g. the known SSLE

• mev-boost is the techinical solution that facilitates the solution to the problem

mev-boost

• a role of a "relay" is introduced that acts as a party between the proposers and the builders.

• the issue of proposers stealing MEV is solved via not revealing the contents of the txs in the block, only the header.

  • Sidenote: I won't be jotting down all of the mev-boost architecture here, and instead think best reference is to read Flashbots docs, they're really good!

• the issue of builders "griefing" proposers by submitting invalid payloads is solved by the relay stepping in as a mediator.

  • relay can keep track of builder reputation
  • relay picks the most valuable block
  • builders / searchers are incentivized to build valuable and correct bundles, as there is now a competition for both 1) block space and 2) slot space
    • The second competition is interesting because it is possible now for there to be multiple relays, and the validator running mev-boost just picks the most valuable block from the set of relays it wants to connect to.

• Quick personal note here: I think this architecture is very elegant but it's interesting because one can already see some risks here.

  • The relay is a trusted third party. Even if we know and see from reputation that Flashbots runs a really solid and reliable (in terms of uptime) relay, this still veers off how decentralized the system is
  • The relay is now a hot path for activity, issues with relay might mean issues with liveness & correctness of the chain
    • For example, in the two-phase commit / reveal architecture of mev-boost, what if the call to get the full block payload gets dropped / errors for some reason?
      • Because the validator signs over the block header (recall just the header to prevent MEV stealing), it is commited to this hidden payload and cannot renege / sign over another block because it will get slashed. Therefore, if the relay for whatever reason fails to deliver the payload, slots become empty

• There are a few other interesting examples here, and this search has brought me to relay-monitor by @ralexstokes, repo here which is a piece of software that essentially acts as a watchtower over relays and monitors activity. The keys piece that makes a monitor like this possible is a modification to mev-boost that would in addition to sending an API call to the relay would also make an API call to the monitor. This way the monitor sort of gets a picture of 1) what block the relay forwarded to the proposer (i.e. what it found to be the most valuable / whatever) 2) proof that the proposer signed over it and 3) a request to receive the full payload (all txs revealed). the monitor can then do some checks and compute any errors that the relay has conceded. This is just a super high level set of notes after doing a read-through of the original mev-boost proposal into a monitor like this, the repo, and design doc, and so it doesn't really do it justice. I'm pretty interested in writing up a more detailed guide on what this is and how it works later, since it's an awesome piece of software that's in-development.

• mev-boost is the next gen of mev-geth. Why not longer just geth? In PoS ethereum the execution and consensus layers are unbundled, therefore as a participant in securing the nextwork (validator in PoS Ethereum) you now run multiple "binaries" instead of just geth. Moreso, the consensus clients allow a validator to interract with mev-boost in sidecar mode.

• because consensus clients run mev-boost in sidecar mode, they also should run their own execution node and in case of incorrect behavior observed, fall back to the local block building, i.e. take the txs from mempool and build blocks yourself.

Question: why have proposer payment? why would it be higher in some instances and not others?

Answer: builders compete for inclusion in a particular slot. So when a validator requests a payload header from the relay and the relay responds with the most profitable one it knows about, depending on the MEV opportunities extracted, the payment to proposer may be higher then usual.

Question: where does private order flow fit into mev-boost architecture?

Answer: the builder role can be modeled as taking input (1) bundles from searchers and input (2) transactions comprising the private order flow, thus building a block and forwarding to the relay, without the transactions in input (2) ever having to touch the public mempool. Of course, it's possible that a given agent/actor in a "builder" role is just a searcher themselves, but it's helpful to think of these as separate entities.

Builder centralization

• A challenging result of block building becoming centralized (due to some reasons mentioned in earlier section on PBS) is that certain parties will by definition get to build more blocks then others, meaning the contents of the blocks can be controlled.
  • The main issue that jumps out here is censorship
  • But even with safeguards against censorship like inclusion lists / whatever similar techniques, just the fact that once a builder or a collective of builders gets good at building, less people will be able to challenge them is not good.

Builder role innovation

• There's an interesting talk by @ralexstokes here that has a few suggestions for interesting utilities that builders can provide

Visualization Resources

Collecting useful resources for existing MEV <> PoS ETH visualization and things that can be hacked together to make work even better.

Flashbots MEV-Boost Relay and Builder Metrics – Metrics from the Flashbots Relay post-merge.
Flashbots MEV-Boost Relay – Data on delivered payloads by Flashbots Relay

Modelling Realised Extractable Value in Proof of Stake Ethereum – Modelling validator returns

https://www.mevboost.org – Tracking MEV-Boost relays and block builders
https://mevboost.pics – MEV-Boost relays and block builders but with more colorful charts