# MEV notes

## General

### Notes on Proposer-Builder Separation (PBS)
> https://barnabe.substack.com/p/pbs

Suggestion to look at PBS from two separate lenses:

1. Market structure
2. Allocation mechanism

Market structure is what I think of as the protocol acting out a role of an "enforcer". The protocol ensures certain guarantees / protections for the proposers and for third-parties, i.e. builders. Example of protections can be "proposer is paid a bid no matter what" or "builder given guarantee of bid acceptance, via say, blind signed block header".

Allocation mechanism is the space of various agreements and cooperation that proposers and third-parties may enter in. Does the protocol allow whole-block auctions or is there space for partial block auctions with, say, proposer suffix / prefix transactions. Or block vs. slot auctions, I.e a proposer chooses a bid for a slot but not to a specific header, hence a builder is free to submit whichever block they want, provided they won the right with their bid.

Many questions around the role of in-protocol PBS. Here are some of my favorite:

- How much should the protocol should protect the proposers?
- Proposers seeking to maximize may engage in risky behavior, is it the protocol's role to make guarantees, as Barnabe calls it, to "make them whole"?
- At the same time, PBS is generally being considered with an understanding that exposure by the validators/proposers to third-party actors is the future, e.g. having to build massive danksharding blocks. It seems that the protocol should have some say in "enforcement" given that proposers essentially will deliberately be exposed to other actors and will be delegating certain tasks to these specialized actors.
- How do we come up with an accurate way to measure MEV value per block, i.e. get some sort of MEV oracle?
- Challenge dealing with out-of-band payments
- Attestations to max bid help here, in-protocol PBS serves as the enforcer
- What does PBS look like in the presence of a "censoring-best" builder?
- Essentially the problem is if there is a builder that is so good that they can censor AND still making the highest bid.
- This results in a situation where proposers are not incentivized to create a `crList`-like` structure and essentially force the builder to either (1) not relay the block (and proposer misses out) or (2) force to fill up block with garbage tx’s in order to fulfill some `crList` / block fill percentage requirement.
- Hence, we can look for forward `crLists` and generally the protocol enforcing some version of `crLists` so that the proposer essentially does not have this choice

### Running mev-boost-relay at scale
> https://flashbots.notion.site/Running-mev-boost-relay-at-scale-draft-4040ccd5186c425d9a860cbb29bbfe09

- Main components are the API to interact with both builders and proposers, validator cluster to check the submitted blocks + a load balancer / priority reputation scheduler, website, API to expose relay-specific functionality. Postgres for DB + Redis
- Flashbots runs a relay themselves, this doc provides some specific things to look out for if you want to do it too + specifics like latency/bandwidth recommendations, redundancy/replica recommended numbers and example machine types they use
- Relay API is mentioned and is one of the components when running a relay.
- API [has a spec](https://www.notion.so/Andrii-MEV-599a7c4903b84fdfaf08d1cc83488825) and contains two categories
- (1) endpoints for builders
- (2) endpoints to query data — registrations, builder bids, payloads, etc.
- Visual rendering is here — https://flashbots.github.io/relay-specs/
- Relay API Docs page by Flashbots is here — [https://flashbots.notion.site/Relay-API-Documentation-5fb0819366954962bc02e81cb33840f5](https://www.notion.so/5fb0819366954962bc02e81cb33840f5)
- Generally the same info can be found in GitHub repos & the visual rendering
- Relay needs to implement / follow the [Builder Specs](https://www.notion.so/Andrii-MEV-599a7c4903b84fdfaf08d1cc83488825) for interacting with the validators
- Doc mentions being able to export data from the relay. Example data export here — https://flashbots-boost-relay-public.s3.us-east-2.amazonaws.com/index.html. Note how a lot of this data is relay-specific, e.g. builder submissions & delivered payloads (actually landed on-chain)
- Example of a “website component” is one of the Flashbots relay sites, for instance the mainnet one is here — [https://boost-relay.flashbots.net](https://boost-relay.flashbots.net/)
- Monitoring mentioned, Flashbots status page here — [https://status.flashbots.net](https://status.flashbots.net/)

### The Cost Of Resilience
> https://writings.flashbots.net/the-cost-of-resilience/

- Censorship with OFAC-compliant blocks, for instance, means that transaction inclusion for certain addresses is a multiple of blocks, i.e. longer wait time to land on-chain
- For an OFAC-compliant relay, this means that validators that connect to this relay have a choice:
1. ask for a block, receive the (we assume in this case, censoring) block, and propose to the network
2. do not ask for a block, build a block locally, and potentially miss out on a higher value block that could have been relayed
- The goal of `min-bid` is that it allows a dynamic threshold for validators running MEV-boost to configure their willingness to effectively forfeit relayed block opportunities and build locally.
- Why build locally? Local building allows decisions about what to include (we assume all transactions). The censorship restriction is now alleviated since a block is not coming from a relay that might have to censor (for whatever reason)
- The article provides some specific data and empirical evidence to suggest that, since most blocks are low-MEV-value, setting the `min-bid` value between `0.01 ETH - 0.05 ETH` significantly improves inclusion likelihood (measured time in blocks from transaction origination) while modestly decreasing the APR for a validator (number given around `0.1%`)
- Specifically what this means, is that with `min-bid` value the validator’s `mev-boost` instance will filter out blocks with bid value lower than the specific `min-bid`, hence allowing the validator to build a block locally. But, if a block is relayed with values > `min-bid` , then the `mev-boost` binary proceeds with accepting a delivered bid (with max payment to proposer), signs the blinded beacon block, and so on and so forth.
- To summarize, `min-bid` essentially allows more blocks to “get through” to local building since data indicates that a reasonable fraction is low-MEV blocks, i.e. low-payment-to-proposer.

### Understanding liveness risks from mev-boost
> https://writings.flashbots.net/understanding-mev-boost-liveness-risks/

- Good overview of liveness risks in PoS Ethereum if running mev-boost. The key point is that most risks are mitigated by fallback to local block production, but the one failure case is a malicious relay forwarding a high bid but refusing to reveal the contents of the block (via getPayload() call) when the proposer commits to the bid and asks for the payload.
- A relay is needed in out-of-protocol PBS to act as a broker between proposers and builders
- Needs to be trusted
- Proposers are expected to connect (by configuring their `mev-boost` instance) to only the relays that they trust. The issue is that a trusted relay with no history of misbehaving may, at some point, become malicious. How do we protect proposers?
- Circuit Breaker
- Relay Monitor

### Why run mev-boost?
> https://writings.flashbots.net/why-run-mevboost/

- Running mev-boost is not a decision that comes without trade-offs. First, have to take on some risk. Second, have to be willing to participate in receiving MEV blocks.
- The key arguments made in this article focus on the way `mev-boost` mitigates some of the centralization risk that comes with MEV.
- Trusted relays are not a perfect solution, but this design opens up block building to more parties, hence increasing competition and leading to less risk of builder centralization
- Out-of-protocol PBS is temporary while work is happening to implement “enshrined” PBS in the Ethereum protocol.

### How much can we constrain builders without bringing back heavy burdens to proposers?
> https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808

- Overview of alternatives to whole-block auctions, i.e. “partial block actions”. Trade-offs when allowing proposers to specify a prefix that a builder has to build on top of, suffix where proposer can append some transactions to the end of a builder-built block, and in-between proposal where proposal commits to a set of transactions with a Merkle root or KZG and when adds transactions as a suffix, needs to provide a proof that those transactions were committed to.
- Topics discussed here are what Barnabe refers to as “allocation mechanism” in the article on “Notes on Proposer-Builder Separation (PBS)”.
- There are some other interesting things related to partial block auctions like crLists and forward crLists
- In the thread there is some discussion around crList-like structures with `mev-boost`, with a basic mechanism described by Bert Miller where proposers running `mev-boost` can submit requirements to the relay to include certain transactions (some list). Then when a proposer asks for a header from a relay, the relay delivers the header for the top bid as well as a Merkle proof that the transactions that the proposer sent as “requirement” are included in the block.
- One thing to consider here is that this is opt-in. For example, it may not be in the profit-maximizing proposers interest to submit any transactions. This is the same problem that comes up with crLists in in-protocol PBS and a bunch of this is discussed in the article by Barnabe which was linked earlier.
- Essentially, unless the protocol forces crList-like structure, validators cannot be assumed to submit any lists just out of goodwill

### Proposer/block builder separation-friendly fee market designs
> https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725

- The two solutions that the post proposes are both in-protocol and require consensus-level changes. One solution trades-off fork-choice complexity (i.e. consensus complexity) with simplicity from the perspective of proposer-builder interaction. The second solution trades-off a more simple process from the proposer side with potential risks from builder misbehaviors.

Proposal (1) TLDR

- Essentially out-of-protocol `mev-boost` like builder-bid / builder-released payload structure but in protocol.
- Builders build blocks, publish headers that commit to the contents of the block (without revealing the contents due to same reasons as in out-of-protocol PBS to prevent MEV stealing), and additionally include the payment to proposer (bid) and a signature
- Proposers listen for headers and select a highest-paying one. Once selected, publish a message committing to the header, at which point the builder sends a message revealing the contents (payload) of the block.
- Fork choice now needs to differentiate between
- No proposal
- Proposal but no payload
- Proposal and payload
- This is needed in case the builder does not release the payload
- The benefit on proposer side is that the payment is unconditional, i.e. if a builder fails to publish the payload, proposer gets paid the bid amount (that’s included in the header bid that they see and sign over) no matter what
- There is a subtle issue with proposers misbehaving here, specifically, proposers may delay posting their message committing to the header (proposal since then all they do is wait for the payload to be revealed) close up to the end of the slot. This means that the builder may not have enough time to release the payload, hence losing out and not getting their block on-chain.
- A suggested mitigation is an enforced timing requirement on the proposer or a rule that if a payload is not delivered then the proposer gets only half of the bid and the builder also pays only half. The goal of such a mechanism is to make it not optimal for the proposal to engage in such behavior since it would lead to strictly smaller expected payout.

Proposal (2) TLDR

- Similar to Proposal (1) in the sense that it’s also the same two-phase / two-step process of publishing the bid by builders, proposer providing some proof of seeing a bid, and the builder releasing the contents
- Builders builds blocks, publish headers that commit to the contents of the block (same as before). Proposers listen for bids, accumulate a list of bids that they see and sign over this list, i.e. a proposer makes a commitment to a set of bids. The proposer then broadcasts this message.
- Builders listen for the message from the proposer, and after seeing the signature release the contents of the blocks (payloads)
- Proposer now listens for messages from builders with the revealed block payloads and chooses one of them, then proposes the block to the network.
- This does mean that we need a slashing condition to prevent a proposer to choosing some random block with a header that a proposer did not pre-commit to
- One issue with this is that it’s possible for malicious builders to submit many high-paying bids with no intention to deliver the payload. This is due to the fact that bid payment is now not unconditional, i.e. a bid has to be selected by a proposer, so a builder can DDoS a proposer and if the proposer has limited capability to process bids, essentially also force-out honest builders that are trying to submit valid bids.
- There are some ideas here to mitigate this using a fee market for submitting bids or a rule to penalize a builder. For instance, if a builder submits a bid, but the bid and payload that actually gets proposed is a lower value bid then theirs, then that builder gets banned or penalized in some other way. Essentially the latter is just a way to detect if a builders bid was way too high and not intended on being a valid one.

### Relay Monitor Design Doc
> https://hackmd.io/A2uex3QFSfiaJJ9BKxw-XA?view#behavior-faults

- A relay is a trusted third-party in out-of-protocol PBS, hence the role of the Relay Monitor (RM) is to check it’s behavior
- The RM is a standalone binary that runs separate from `mev-boost` and any `mev-boost` relays
- Motivation is to protect honest validators from byzantine relays (again since a relay is a trusted party)
- Even though it is up to the validators to configure their `mev-boost` instance to connect to relays that they trust, it is not out of the realm of possibility that some relays may suddenly exhibit byzantine faults
- A validator would “opt-in” to use a RM by specifying some config information to it’s running instance of `mev-boost`
- This will allow `mev-boost` to send information about the interaction between the validator and the relay (and by way, the builders) to the RM
- The RM watches the chain for data & activity
- The RM connects to a relay that it is supposed to be monitoring and interacts with it’s API to get data about bids and delivered payloads
- Initial design suggests focus on 1) bid faults and 2) payload faults
- Difference is that invalid bids are likely to lead the validator to not use the relay & fall back to local building, while payload faults means safety & liveness issues on network

### mev-boost circuit breaker proposal
> https://hackmd.io/@ralexstokes/BJn9N6Thc

- This is a more “enforced” version of `mev-boost` relay functionality control. For instance, the Relay Monitor proposal is for a reputation based approach where validators connecting via `mev-boost` can make decisions about which relay to connect to based on the collected metrics & computed “reputation” of a relay.
- The difference with any circuit breaker is that it may mean a one-way switch where in order to reverse the “ban” of outsourced blocks delivered via a relay, one might need to restart the beacon client (suggested in the proposal) or something similar.

### Research direction: keeping mev-boost relays honest
> https://notes.ethereum.org/@yoav/BJeOQ8rI5

- One mechanism mentioned are relay bonds to “slash” relays for failing to deliver
- Data availability committee to receive messages from both relays and proposers and compute reputation based on message timing
- Improves the trust assumption with something like a relay monitor, since decentralized
- Essentially becomes a “watchtower” but decentralized
- Perhaps a way to implement this with EigenLayer-like mechanism?

### Quantifying MEV: Introducing MEV-Explore v0
> https://medium.com/flashbots/quantifying-mev-introducing-mev-explore-v0-5ccbee0f6d02

- One of first steps in the “Illuminate” direction
- Scrapes Ethereum, parses transactions, attempts to classify into “buckets”
- Rough estimation of about 4500 Ethereum blocks worth of wasted blockspace in one year

### Two-slot proposer/builder separation
> https://ethresear.ch/t/two-slot-proposer-builder-separation/10980

- Slots would now be 8 seconds, since execution payloads come in every two blocks. So effectively we go from 12s slot → 16s slot
- Essentially the idea is to use an “intermediary” block every other slot that carries a `BuilderBid` as opposed to the actual block contents. This basically moves the two-phase-commit-like structure of out-of-protocol PBS into the protocol
- This requires some modification to consensus like having different size committees. For instance, the committee that attests to the intermediary block is suggested to be size `1` while the committee for the following “payload” block is `N - 1`
- The two-slot approach provides some nice properties of safety for both builders and proposers
- Builders bid first, then a winning bid is selected and included in intermediary block, a single committee attests to the block. This means that the builder then either 1) publishes because the bid is “included” or 2) doesn’t publish and is not penalized
- One thing to look out for is the builder deliberately not publishing the payload

### Block builder centralization
> https://ethresear.ch/t/block-builder-centralization/12135

- One point is that there is an intuitive feedback loop that happens when a builder gets really good. Essentially there becomes little incentive to submit transactions to the public mempool
- Which brings up the question, is it possible that the public mempool effectively “dries up”?
- Another point is that a single builder is also a threat to liveness if it goes offline for whatever reason and there is no flow into the public mempool
- An interesting observation is also that a “best performer” builder is likely to have private flow, so perhaps it’s worth to look at the trends of fractions of included transactions in specialized builder-built blocks and whether those transactions have appeared in the public mempool.
- Additionally, a single centralized builder is clearly a problem for censorship, so there is likely some need for `crList`-like structures that force inclusion of transactions (and perhaps a mechanism that has to be enforced by the protocol, i.e. a proposer can’t opt-out of putting up a `crList` by making it empty)

### Committee-driven MEV smoothing
> https://ethresear.ch/t/committee-driven-mev-smoothing/10408

- This proposal aims to “smooth” MEV within a single slot / block proposal by making the proposer split the bid from a builder-built submitted block header with the committee making attestations for the slot
- This is done by first adding a new rule for attesters, which now have to vote based on a criteria of a highest-paying-bid-block that they’ve seen
- This requires a change to fork choice by having a (block, slot) ability to vote
- Specifically, this is needed to express the notion of voting for an “empty” block, i.e. attesters say “skip a block in this slot”
- In general, (block, slot) voting is problematic due to latency requirements that the mechanism enforces (there’s been a bunch of research into this). One effect is that honest blocks that are late will not be included in the chain.
- This also means that such scenarios would occur during during bad network conditions
- The high-level idea of having the committee vote based on the new criteria is to force the proposer to propose blocks that fit the rules. If a block doesn’t, the committee will essentially vote to not include the block because a proposer is effectively not sharing the payment / MEV.

### Single-slot PBS using attesters as distributed availability oracle
> https://ethresear.ch/t/single-slot-pbs-using-attesters-as-distributed-availability-oracle/11877

- Proposal for a single-slot in-protocol PBS using some more advanced cryptography to build a data availability mechanism
- Core idea is similar to other proposals like the two-slot PBS where we try to take separate block bids and payload into two separate messages and figure out a way for the protocol to enforce the market structure.
- In this case, we have builders erasure-code the payloads (this is essentially a DA mechanism for the network to be able to reconstruct the data from less chunks then total created). Then we also have them encrypt each chunk to a validator key in a set of some validators, set size is suggested to be 256. Finally this data is propagated via p2p
- Validators then decrypt the payload chunk verify proofs, and send messages attesting to the fact that they’ve seen a payload
- Given enough attestations, proposer selects the one that they see as maximum bid + has enough attestations and makes the proposal
- Finally, committee members release the payload chunks (since now a commitment exists from a proposer)

### Sreeram Kannan — EigenLayr: Permissionless Feature Addition to Ethereum (ETHconomics @ Devconnect)
> https://www.youtube.com/watch?v=01xDSwMO5U4

- Innovation vs. trust layer — the observation is that Ethereum already is “layered” with the reason that the innovation on Dapp layer is able to happen is due to the execution / consensus / security <> trust separation
- The idea of EigenLayr is to re-direct the Ethereum security (decentralized validator set) back into the protocol and allow for more opt-in validator duties
- I think of this as validators “signing up” for more tasks based on some risk vs. reward calculation or tolerance
- Interesting consideration to make sure that the validator load is not significantly increases, e.g. for EigenDA the bandwidth requirement should be reasonable
- Still opt-in, i.e. if validators don’t want to opt-in they don’t have to

### MEV after EIP-1559 - Alejo Salles & Kristof Gazso
> https://www.youtube.com/watch?v=15sxHVt0K94

- Largely EIP-1559 does not have an impact on MEV
- One question to think about is what behavior might look like if miner profits are affected by Ethereum upgrades. How much more MEV can miners be expected to extract to “offset”?
- Provides some notes on thinking about miner behavior after EIP-1559. Many things are “not new”, i.e. structure is just as prior to London fork
- Introduces an idea to model a situation where consecutive blocks are under-filled up to some percentage. Miners are leaving profit on the table short-term but is there an optimal condition to do this for an optimal number of consecutive blocks?

### Searching Post-Merge
> https://writings.flashbots.net/searching-post-merge/#proposerbuilder-separation-pbs

- From a searcher standpoint, the transition to PoS does not introduce significantly noticeable changes. Biggest change is the two-part auction
1. The blockspace auction
2. The slot auction (new in PoS)
- Essentially this means that in order to “land on-chain” searcher bundles need to 1) first land in a block built by a builder and 2) that built block needs to be selected by the validator (via the `mev-boost` running in sidecar), i.e. that built block needs to have the highest bid to the proposer
- Blockbuilding algorithm is changed post-merge
- Still guarantees bundle atomicity, but not ordering according to effective gas price and thus no guarantee of top-of-block execution
- Transactions can be interleaved between bundles

### MEV-SGX: A sealed bid MEV auction design
> https://ethresear.ch/t/mev-sgx-a-sealed-bid-mev-auction-design/9677

- Outlines a proposed design for a permissionless and privacy preserving MEV auction design using trusted hardware
- Key here is that this post generally assumes a PoW chain and it’s actually interesting because some of the elements of this design start to significantly weaken when you instead have PoS and a proposer that does not have a requirement to do any work
- The general idea is that searchers build full blocks, an SGX encrypts the block guaranteeing the validity, and the searcher forwards the contents along with a plaintext header to the miner
- The miner then takes the header and starts work to seal the block
- Once done and the a proof-of-work solution is given, the block is decrypted by the miner SGX and can now be delivered to the network
- What are the challenges?
- Obviously SGX is a debated topic
- Searcher breaking SGX is less of a problem then miner breaking SGX
- Miner / searcher need to do a handshake, there are also some other latency complications

## SBC 2022

### Phil Daian: A History of MEV & Open Research Challenges - SBC 2022
> https://www.youtube.com/watch?v=Y0HcX4uZnnc

- Some history overview of MEV, coming from Ordering, PGAs, Flash Boys 2.0
- Gathered a bunch of data on PGA
- Derived a bunch of properties and showed that this can de-stabilize consensus
- Ongoing line of work in “fairness” in transaction ordering
- MEV as the balance that a miner/proposer (actor in privileged position) can increase over a series of blocks
- MEV fundamental to decentralized blockchains
- Flashbots origins from the historic elements above
- Illuminate
- Democratize
- Distribute
- World going cross-chain, there are more complex centralizing threats that can incentivize validators to collude

### Alex Stokes: MEV-Boost, How Does it Work & What’s Missing? - SBC 2022
> https://www.youtube.com/watch?v=PS9SlHGJlrU

- 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 transactions in the block, only the header
- One way to do this is to have privileged access only to trusted validators, but we don’t want to do this since we want to allow any proposer to access this network
- Commit-reveal scheme helps implement this
- 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
- Lots of open questions
- Open bid vs. sealed bid auction
- Decentralizing builder role
- Since this is specific software, there are some relevant repos

### Vitalik Buterin: Decentralizing the Builder Role - SBC 2022
> https://www.youtube.com/watch?app=desktop&v=fAgrIdyWIqc

- PBS sweeps the “problems” into a single corner of the room, but here we look at issues that still may come up if such a separation is performed, i.e. it’s still bad that the builder role can be centralized
- Bad for Ethereum if we end up in a world with a single builder building > 50% of blocks delivered to the network. This is not entirely unfeasible due to economies of scale and all the MEV centralization risks that we are already aware of
- We can solve a bunch of censorship concerns with a centralized builder actor with inclusion lists
- The mechanism, assuming it’s in-protocol, effectively forces the builder to include transactions on these lists that proposers create, otherwise the block will not be valid w.r.t. consensus and hence will not be accepted by the network
- Turns a whole-block auction into a partial-block auction
- Still this would mean a single builder will create these blocks honoring the inclusion lists, so we ask how to decentralize the role itself?
- Some ideas
- Trusted hardware
- Merge disjoint bundles
- There’s an interesting distributed builder construction that can be built that can offer pre-confirmation services
- With high security deposits + EigenLayer-like mechanism of Ethereum validators joining in the service, users of the service have strong guarantees of inclusion, or else the service will have to burn an extremely high amount of staked ETH

### Justin Drake: Censorship Résistance & PBS - SBC 2022
> https://www.youtube.com/watch?v=XZJcZ05d-Wo

- Motivation of why we should care about censorship resistance: a chain that starts with censorship resistance linking to a credibly neutral platform to economic bandwidth
- Essentially we need Ethereum to remain credibly neutral and a situation where a significant chunk of Ethereum block builders censor make it seem as if Ethereum itself censors
- The simplest “solution” is altruistic block building, i.e. have the proposers build blocks in “vanilla” way by ordering transactions from the mempool in order of tip and construct naive blocks. This does mean proposers have to willingly give up some economic upside from the MEV opportunities that they would be entitled to if outsourcing block construction to an external builder network. Though an argument could be made that the “good vibes” that come with such altruistic block building actually contribute to a healthier ecosystem that benefits the participants
- MEV smoothing as it pertains to solving proposer censorship
- The idea is to force the proposer to accept the highest bid that they observe, so that even if the proposer may wish to censor by selecting lower-bid blocks that are compliant, they do not have this choice
- The way we implement this is why attesters, who only vote for blocks with attached bids that are maximal in their view
- Limits proposer “agency”
- Encrypted mempools as it pertains for builder censorship
- If transactions are encrypted when in the mempool, from the builder standpoint it is unknown if the transaction is one that they “can” or “should” censor
- A way to think about benefits of encrypted mempools is categorization from the perspective of censoring builder economics. Justin provides a diagram that splits up transactions, that are candidates for inclusion by a builder, into
- Edge (+ for builder)
- Passive (e.g. arb)
- Active (e.g. sandwich, since requires user action to counter / exploit)
- Neural (= for builder)
- Handicap (- for builder)
- Without encryption and with enough expertise the builder can tell which transaction is which. In other words, in practice the edge is much larger than the handicap (transactions that the builder might want to censor), so there is no incentive to force yourself to include them
- But with encryption, everything except for Passive Edge opportunities meshes into a single category (due to builders unable to know exactly what the contents of the transactions originating from users are). This means that builders, if they would choose to only extract MEV from Passive Arb and in this way ignore everything else, would be at extreme disadvantage of excluding all of the order flow under this new category. The cost of censorship is therefore extremely high, since a builder is essentially forced to exclude all kinds of transactions that before it could differentiate between
- Force into “all or nothing”, since can’t tell which encrypted transactions to censor
- Transaction inclusion lists as it pertains for builder censorship
- Enforced on-chain
- Needed in situation where 100% of builders are censoring

### Quintus Kilbourn: Order flow, Auctions & Centralisation - SBC 2022
> https://www.youtube.com/watch?v=ilc3EoSMMDg

- Thinking of / defining order flow as what encompasses user intent → easiest to think of this as transactions, i.e. user is communicating a desire to take action. With account abstraction this can be expressed in finer grain with signed messages, etc.
- Order flow in conjunction with PBS is relevant since block building is winner-take all and is inherently competitive. In order words, if one builder finds a way to receive more / better transactions than other builders, it will gain an edge and is likely to win a disproportionate amount of block auctions (i.e. will be able to keep providing the highest bid to the proposer)
- Exclusive order flow
- The idea is if a dominant wallet or app sells the order flow to a builder A, that builder will become instantly better at block building then the competition
- Builder B, a competitor, now will see the block inclusion rate drop, since they are not as likely to produce highest-bid blocks
- There are a few negative effects that creep in
- Builder A is likely to be extracting more MEV than the bid that it has to pay the proposer, since in order to have the block land on-chain it only needs to outbid the next-best builder, i.e. Builder B without less order flow
- New wallets (and existing wallets that send order flow to Builder A) now have no incentive to switch, since switching to a smaller builder B would mean less likelihood of winning block auctions, i.e. slower transaction inclusion time, i.e. degradation in UX for users
- Builder A now also has no incentive to compete on features offered or better service, since they already have access to the order flow and can win consistently
- Builder A also has no incentive to compensate the wallet for the order flow, since as mentioned before the wallet is effectively facing a choice of maintaining the relationship with the dominant builder vs. long wait times of transaction inclusion and bad UX
- Relation to censorship resistance
- If there is a dominant builder in the market, then if that builder decides to censor, the proposer will have to choose between complying with the builders requirements (and hence not giving up the monetary reward) and essentially taking the L on any extra MEV and going the altruistic route
- The great point made here is that we fundamentally do not want to make proposers make this choice
- Some interesting thoughts on potential causes
- No good way for wallets to monetize (yet) → payment for order flow
- Searcher trust → if there is no good way for searchers to be sure that their bundles will not be stolen or at least detect the theft, then the searchers will choose to build relationships with specific “trusted” builders and exclusively send their bundles to them
- Making every order go through the public mempool is probably not idea. A few thoughts are given
- Probably not feasible
- It’s useful to allow users to express preference / intent
- If a builder algorithm is dominant it still might be the case that only a few builders will get really good at ordering public mempool transactions. The idea is that if the order flow is “spread out” i.e. contains more randomness, there may be more space for multiple builders to be competitive and offer different services
- A rough goal is to have “all orders flow to all builders that support the features required in the order”

### Alex Stokes: Block-builder Innovation Post-Merge - SBC 2022
> https://www.youtube.com/watch?v=Yx20UUTmgfU

- Some interesting services that the builder can provide as a “privileged” actor in the MEV supply chain
- Sponsored transactions. Not new idea, been discussed in the context of Account Abstraction on Ethereum in various ways
- Pre-confirmations. Even faster guarantees of transaction inclusion. The builder takes a user intent and provides a guarantee of when it will land on-chain
- Transaction cancellations, i.e. a better UX then having to do the gas increase “replacement” of transaction as is currently the norm and is a bad UX for new users using something like MetaMask
- Generally there is room for exploration of so-called MEV UX

### Sreeram Kannan: Censorship Resistance Via Restaking - SBC 2022
> https://www.youtube.com/watch?v=ywJNXIUSqOw

- The idea is to use a “restaking” mechanism i.e. EigenLayer to 1) improve censorship-resistance properties with PBS by giving a proposer ability to sign over a block and still add own transactions before proposing the final block to the network and 2) improve the centralization of the relay as a block content escrow
- The core idea boils down to the fact that with re-staking we utilize validators as actors that can opt-in into other responsibilities by re-staking
- EigenLayer re-staking generally works by re-pointing a validator withdrawal address to an EigenLayer smart contract on mainnet. In a way, this delegates control over the stake
- Re-staking is quite interesting, since it allows for more flexible and “programmable” slashing conditions along with similarly flexible commitments
- Below are some more notes on each of the points that Sreeram spends time talking about

Censorship resistance

- The reason proposers can’t sign over a builder-delivered block header and an additional header with their transactions added on is because the protocol will slash the proposer if it sees such conflicting messages
- The idea is that with EigenLayer the proposer can opt-in via re-staking into a more fine-grained EigenLayer-enabled commitments.
- A proposer now could make commitments w.r.t builder-provided “part” header that they receive from a relay in addition to, perhaps, some backup block.
- The interesting thing here is that the builder receives a commitment from a proposer, and so since a proposer is staked in EigenLayer, the builder has the assurance that this commitment is binding and misbehavior by the proposer is slashable via EigenLayer. It’s like the proposer is saying that they promise to include the builder part in whatever block they eventually propose to the network. And because of the EigenLayer mechanism, they are at risk of being slashed if they misbehave and renege on this commitment
- This also means that once a proposer commits to a builder-built part and responds to the relay with the signed commitment message, they are still free to include a proposer part added onto the builder part. All that the builder should care about is whether or not the part that they delivered via the relay has actually ended up in the block proposed to the network, and with a signed message commitment from the proposer, they have this guarantee or a slashing opportunity

Decentralizing the relay

- The `mev-boost` like centralized relay as we know it today serves the role as an intermediary between the builders and the proposers
- One specific intermediary role is what Sreeram calls a block content “escrow”, i.e. the relay holds onto the contents of the builder block and only delivers the header to the proposer (for familiar reasons of preventing any MEV stealing)
- The question being asked here is how can we decentralize this block escrow
- The idea is to use an EigenLayer mechanism of validators re-staked and serving as a DA committee (EigenLayer-DA)
- Block builder erasure-codes and polynomial commits to chunks of the built “builder part” and each DA committee member only downloads a fraction of all chunk
- Block builder then gathers proofs from DA committee members that they have possession of the block chunks and aggregate the signatures. Then they provide this aggregate signature to the proposer along with the header of the “builder part”. This is basically the builder providing a “certificate” to the proposer that the DA layer has the data available
- The proposer is able to verify the signature and create a commitment by signing a message committing to this builder part. The proposer sends the message to the DA layer
- Upon receiving the commitment from the proposer, the DA layer can release the builder part block contents
- Proposer re-constructs the “builder part” block parts and can propose to the network. Also, just as before the proposer now is able to add a “proposer part” to the block before proposing, since a commitment exists to the “builder part” already, so the proposer cannot cheat the builder without getting slashed via the re-staking mechanism
- The interesting thing about the DA layer is that it is the Ethereum validators that are providing the DA quorum via being re-staked with EigenLayer
- The functioning DA layer still assumes some majority honest validators
- The re-staking mechanism idea allows for various “roles” that validators can opt-in based on a risk-reward tolerance, since it’s essentially validators signing up to do some tasks and be compensated in some way (again this is up to the specific mechanisms) for the work that they’re doing

### Elaine Hu: Modeling Realised Extractable Value in Proof-of-Stake Ethereum
> https://www.youtube.com/watch?v=THKbs5YBWpk

- Walkthrough of how to think about modeling returns and moving from a smooth model of “Average MEV” → a dynamic return model of “Dynamic MEV”
- Modeling validator returns by using the mean of MEV is not representative → gini index is high and MEV is very unequal
- Instead try to build a dynamic model that accounts for time (e.g. momentum or a mean-reverting loop) as well as network conditions that can be simulated to get a measure of expected block reward
- Allows to account for variables such as gas price, base fee, etc.

### Tarun Chitra, Kshitij Kulkarni: A Formal Model of Post-MEV-Boost Blockspace Market Dynamics - SBC 22
> https://www.youtube.com/watch?v=72G2t82ZkMg

- One really interesting take away here is that MEV smoothing (referred to as redistribution in this talk / paper) helps pull away from a situation (in the model / dynamic system in the talk this is the equilibrium point) where, in the staking / lending portfolio allocation / choice, staking goes to zero (0) and hence PoS security erodes
- See talk slides (https://people.eecs.berkeley.edu/~ksk/files/MEV-Redistribution.pdf) for the build up of the staking + lending model and the results shown of a bad equilibrium point
- The above poses a question of how to use redistribution / smoothing to avoid this equilibrium point
- One note in the talk is that in the absence of redistribution, assuming you rationally want to avoid this equilibrium, you need high fast growing rewards
- With smoothing, now require lower inflation rate. Can get to constant supply or even deflationary

### Mahimna Kelkar: Ordering Protocols - SBC 2022
> https://www.youtube.com/watch?v=vqEIz9bmZbs

- One take-away claim in this talk is that user preference is important. Argues that something like PBS, while designed to be incentive-compatible w.r.t builder and validator protocol actors, is not so for users, and argues that this is an issue
- Some discussion of “fair ordering”, e.g. some first-in-first-out type of ordering

### Jannik Luhn: Reducing Trust Assumptions in PBS Using Threshold Decryption - SBC 2022
> https://www.youtube.com/watch?v=acMfCjjX7O4

- The idea is that in the current PBS setup the relay is trusted in order to solve the issues of 1) MEV stealing by proposers and 2) block withholding by builders
- The core idea here is to replace the relay acting as an escrow with a different escrow-like mechanism, where we use a committee of actors that provide encryption / decryption keys to the protocol actors — builders on the ordering side and proposers on the block selection and proposal to network side
- The mechanism generally works by
- Having builders build blocks
- Send blocks to proposers, encrypted to an “identity” (suggested to use the block header) along with a header
- Proposer picks the most valuable block header, signs over it and asks the committee for a decryption key for that header
- The proposer then, upon receiving the key, decrypts the block body and proposes the block to the network
- Relies on some sort of `m` of `n` assumption of honest committee members
- Generally the trade-offs seems to be less trust vs. higher latency (due to assumption that we have to deal with a p2p gossip structure vs. a centralized relay)

## Devcon Bogotá

### Block building after the Merge by Alex Stokes
> https://www.youtube.com/watch?v=KP5ppCRH0iM

- There’s a nice introduction to block building that approaches the topic from the perspective of block space and the fact that block space is valuable. Builder role then fits into the model by being the actor that gets good at filling up the block space, i.e. including / not-including transactions and the order in which they are included and hence the order in which the block is built.
- Several builder roles are discussed in addition to ordering / MEV extraction. For instance
- Guaranteeing inclusion
- Sponsored transactions
- Other services for a fee

### Evaluating the PBS Experiment: Early insights from MEV-Boost and the Builder Market by Jolene Dunne
> https://www.youtube.com/watch?v=BFVSRSN5E_A

- Talk on insights gathered on the state of the proposer/builder interactions after the Merge so far and potential research directions going forward
- The goal is to get an idea of proposer interaction with the external builder network over `mev-boost` and any effects on the protocol
- A few key metrics that data was already collected for (after the Merge)
1. Validator participation rate (ratio of validators that outsource their block construction to the external builder network via `mev-boost`
1. Approaching ~50-60% and seems to be trending up
2. Public mempool size
1. *Seems* to have dipped a bit, but a very clear trend is not visible yet
2. The concern here is that with existence of exclusive order flow, certain builders can get extremely good at building and consistently win, in turn incentivizing users to send transactions to them instead of to the public mempool
3. Public mempool “drying up” means that block build the “naive” way becomes very hard or impossible, since low transaction counts mean low-value blocks for the actor that’s building the block
3. Builder share of blocks delivered via the Flashbots relay doesn’t seem to be very asymmetric. Specifically, the Flashbots builder is still the dominant builder but the percentage is not growing
- One interesting thing to look out for will be reliable ways to monitor the builder market to actually see what’s going on

### This is not MEV. by Alejo Salles | Devcon Bogotá
> https://www.youtube.com/watch?v=Lc5zxOonT0A

- Permissionless value → permissionless value on the blockchain → value extractable by a monopolistic coordinator
- Value extractable by a monopolistic coordinator $\subset$ MEV?

### This is MEV by sxysun | Devcon Bogotá
> https://www.youtube.com/watch?v=8qPpiMDz_hw

- Want to re-distribute Monarch
- How to achieve 0%, 0%, 100% distribution?
- Sink of value impacts source of value

### Cost of Feudalism: Towards a Theory of MEV | Devcon Bogotá
> https://www.youtube.com/watch?v=6JA4_5QWG0s

- Most important idea here is that not all MEV is bad. The interesting example is in optimal routing and Braess’s Paradox
- With MEV the idea is that the searchers almost as if regulate the flow of orders which results in more optimal executions
- With a sandwich, somebody by default is paying the price and is getting a worse execution, but the idea is that price impact for a series of user orders can be thought of as being optimized
- Replace “travel times” in classic routing problem with some price impact function

## GitHub Repos

### Builder Specs (Ethereum Builder API Specification)
> https://github.com/ethereum/builder-specs

- Based on the initial out-of-protocol PBS proposal
- Defines a registration + a two-step process
1. Validator creates a “registration” object, signs it, and sends it on the `[registerValidator](https://ethereum.github.io/beacon-APIs/#/Validator/registerValidator)` route. More on this in the spec repo. The validator then waits for it’s turn to propose a block to the network
1. Should do this well ahead of proposer “duties”, i.e. having to propose a block to network
2. When time comes, validator asks for bid, receives a header only (which a relay should verify and forward stripped of the payload), then signs this header only (”blinded”)
3. Once signed, builder reveals the body
1. The proposer shows that the header is signed via the `/eth/v1/builder/blinded_blocks` endpoint → proposer submits a signed blinded block and receives the “full” block back, i.e. the execution payload
2. The relay needs to verify the proposer signature in the above request, and then release the payload
3. Once the proposer receives the payload the proposer can actually “propose” the full signed beacon block to the network
- Why a two-step process? Validators make the initial commitment in order to guarantee the builder. The commitment is to a header in order to prevent the validator from stealing the block contents (transactions) and it’s MEV. The risk is that the builder (and so the relay in this out-of-protocol PBS implementation) is expected to deliver the full contents (payload) and for it to be correct
- The endpoints make the block outsourcing process by validators possible and define the specific fields of objects that are sent/received and signed
- The “network of builders” is made accessible by a relay. There are multiple reasons why, one being that a validator (proposer) and a builder do not trust each other
- In the event the external builder network is not reachable / fails to deliver a bid in time, etc. the validator is expected to fall back to local block construction. It actually is assumed that the construction is done in parallel in order to avoid missing the proposal, i.e. optimistically assume a relay will come through and fallback after some time. There are more details on this in the repo.

### MEV-Boost Relay Specs (Ethereum Relay API Specifications)
> https://github.com/flashbots/relay-specs

- Required API for when you’d like to run a relay
- For builders, the API presents a way to submit blocks to the relay and hence participate, i.e. try to have the block land on-chain
- For validators, can use `/relay/v1/data/validator_registration` to check registration
- For general use-cases, can use the a few of the routes to get data on the payloads that were delivered to proposers by this relay and the builder bid submissions that were submitted to this relay

### MEV-boost
> https://github.com/flashbots/mev-boost

- The repo has *the* source code for the binary that people talk about when they talk about `mev-boost`
- Initial implementation of [PBS](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725)
- Documentation for `mev-boost` is here — https://docs.flashbots.net/flashbots-mev-boost/introduction
- Good page for reference is the Flashbots “MEV-Boost in a Nutshell” page here — [https://boost.flashbots.net](https://boost.flashbots.net/). Contains:
- Relay list
- Consensus client compatibility (compatible with all consensus clients since implements the [Builder Spec](https://www.notion.so/Andrii-MEV-599a7c4903b84fdfaf08d1cc83488825))
- FAQ and other resources

### MEV-Boost Relay
> https://github.com/flashbots/mev-boost-relay

- `mev-boost` works by connecting to a network of builders via a relay, which is a trusted entity. This repo is a set of binaries that, when run together according to the design/architecture that is mentioned in the repo and in the practical doc linked below, is able to serve as the middleware between a validator running the `mev-boost` software and a builder who wants to submit blocks to be included on-chain
- A single `mev-boost` instance can connect to multiple relays. For instance, recently (Nov 2022) a few more relays were spun up & [announced](https://twitter.com/ultrasoundmoney/status/1597939734088908800) based on the Flashbots relay.
- A relay accepts a multiple of blocks / second from builders and delivers the headers (and subsequently the payload) of the block that pays the most to the validator (via a transaction that the builder includes to the validators `feeRecipient` address)

### Beacon Specs (Ethereum Beacon API Specification)
> https://github.com/ethereum/beacon-APIs

- `mev-boost` runs in sidecar mode next to a consensus client
- There is a `dev` version of a spec that includes a RANDAO endpoint (`/eth/v1/beacon/states/{state_id}/randao`), so for use cases where this endpoint is needed, one should make sure the consensus client supports it
- Some notes on my experience running into this on Sepolia — https://hackmd.io/EVlL6nYUQ1uJM_CGAxlQLQ

## GitHub Issues

### auction - should (header,bid) messages be publicly accessible during the message passing period?
> https://github.com/flashbots/mev-boost/issues/112

- Game theoretic discussion about relays, proposers, bribes, etc.
- Thinking about public bids as the equilibrium
- Generally seems to be agreement in that if some actors can see bids, then it’s best that all actors see those bids
- I think this is also related to the fact that actors don’t trust each other + anyone could in theory run a relay, especially parties like large validator operators

### Relay spam protection: require a small deposit to submit blocks as a builder
> https://github.com/flashbots/mev-boost/issues/219

- One possibility is use a staking mechanism for anyone wanting to be a builder. If there is “misbehavior” the builder can be slashed by Flashbots
- A different one is to build a basic two-part system with “trusted” vs. not trusted builder block submissions queues, i.e. something like what Flashbots did for PoW with mev-geth
- Another is to use a Rate Limiting Nullifier + zk proofs to create a reputation score system

### Safeguards and mitigations to preserve liveness
> https://github.com/flashbots/mev-boost/issues/222

- Various discussions of what could go wrong if some threshold of validators are connected to relays
- Relay Monitor + circuit breaker mitigations
- How to fallback to local block building effectively

## Visualization

1. Flashbots Transparency Dashboard
- https://transparency.flashbots.net
- Metrics from the Flashbots Relay post-merge
2. Flashbots MEV Explore Dashboard
- https://explore.flashbots.net
3. Flashbots MEV-Boost Relay
- https://boost-relay.flashbots.net
- Data on delivered payloads by Flashbots Relay
4. mevboost.org
- https://www.mevboost.org
- Tracking MEV-Boost relays and block builders
5. mevboost.pics
- https://mevboost.pics
- MEV-Boost relays and block builders but with more colorful charts
6. MEV Watch
- https://www.mevwatch.info/
- OFAC censorship block visualization