# mev-boost @ Blox Staking Overview of what we know so far about mev-boost and how ready is the ecosystem and us. :::info ⚠️ Warning: this guide is very technical. ![](https://i.imgur.com/9xu6WTI.png) ::: # What's changed mev-boost changes how blocks are produced and proposed. ## The non-MEV way ### Proposals Summary: Eth2 blocks are built by **BN**, Eth1 blocks are built by **EL**. 1. **VC** requests **BN** to produce a ==block== 1. **BN** requests ==**EL**== to build an ==execution payload==, which is basically an Eth1 block ==with transactions== 2. ==**EL** builds an execution payload with the recently suggested fee recipient (see [Fee recipients](#Fee-recipients))== 3. **BN** produces a ==block== with that ==execution payload== and returns it to **VC** 2. **VC** signs the ==block== 3. **VC** submits the ==signed block== to **BN** 4. **BN** publishes the signed block to the network ### Fee recipients 1. **VC** periodically updates **BN** with it's ==fee recipient preferences== via `/prepare_beacon_proposer` 2. ==**BN** suggests the fee recipient to **EL**, a third of a slot (4 seconds) before a registered validator is supposed to propose.== ## The MEV way ### Proposals Summary: Eth2 blocks are built by **BN**, Eth1 blocks are built by external builders via mev-boost. 1. **VC** requests **BN** to produce a ==blinded block== 1. **BN** requests ==mev-boost== to build an ==execution payload header==, which is basically an Eth1 block ==with only a hash of the transactions== 2. ==mev-boost retrieves the most profitable execution payload header from it's relay(s) and returns it to **BN**== 3. **BN** produces a ==blinded block== with that ==execution payload header== and returns it to **VC** 2. **VC** signs the ==blinded block== 3. **VC** submits the ==signed blinded block== to **BN** 4. ==**BN** reveals the signature to the builder (via mev-boost), and in return, the builder reveals the execution payload (with the complete list of transactions) to **BN**== 5. ==**BN** produces a signed block from the signed blinded block== *This is feasible because `execution_payload.hash_root() == execution_payload_header.hash_root()`, so the blinded signature is identical.* 6. **BN** publishes the signed block to the network ### Fee recipients 1. **VC** periodically updates **BN** with it's ==signed fee recipient preferences== via `/register_validator` 2. ==**BN** forwards it to mev-boost, which forwards it to it's relay(s).== 3. ==Builders are *supposed* to pick up on it and produce an execution payload header with the validator's prefered fee recipient, though this part is opaque at the moment.== --- ||| Examples | | -------- | -------- | -------- | | **EL** | Execution layer | *Geth* | | **VC** | Validator client | *Lighthouse VC, Vouch* | | **BN** | Beacon node | *Lighthouse BN* | # Readiness ## Ecosystem - [x] mev-boost -- supposedly ready, and [they want to audit before The Merge](https://github.com/flashbots/mev-boost/issues/224). - [ ] Prysm -- ready, except for validator registration which is available only via gRPC but not via Beacon API (which we specifically use) - [x] Lighthouse -- doesn't provide a Docker image for testing, but it's `builder-api` branch has been stable so far. ## Blox - [x] key-vault & eth2-key-manager can sign `BlindedBeaconBlock` and `ValidatorRegistration` - [x] key-vault refuses to sign `ValidatorRegistration` if the fee recipient doesn't match it's configuration - [x] validator-center schedules proposal preperation and validator registration tasks, at every slot, only for upcoming proposers - [x] ethereum2-validator proposes blinded blocks - [x] ethereum2-validator submits `ProposalPreparation` & `SignedValidatorRegistration` - [x] Everything works on Sepolia with Lighthouse@builder-api # Open issues 🌖 *On the bright side, it's worse today on PoW.* ## @ mev-boost ### Centralized Relay Relay is a middleman between validators (which run the mev-boost client) and builders. As of today, there's only one relay by Flashbots, and it's closed-source. Unfortunately, even after it open-sources and hosted by more entities, relays are still very powerful and can exert their power for profit. #### Solutions - 👀 [Relay Monitor](https://github.com/flashbots/mev-boost/issues/142) -- 3rd parties monitor relays and provide validators with relay rankings so their choices are better-informed. - ⭐ [proposer/builder separation (PBS)](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) -- basically a fully decentralized mev-boost in-protocol. Requires consensus layer changes and not expected anytime soon. ### Fake Bids Builders are supposed take a cut of the block's fee reward, so per-spec they're allowed to set the block's `fee_recipient` to their own, and are expected to pay the validator by including a transfer transaction with the value they promised in their bid. Validators sign a blinded block, whose `fee_recipient` is not their own, in expectation that it includes this transaction which pays them. Unfortunately, they can only verify this after revealing their signature to the builder (which should reveal the transactions in return), but this in itself commits them to the block (due to slashing rules), at which point they can only choose between publishing this block which doesn't pay them or nothing at all. Therefore, builders and relays can trick validators into signing their blinded blocks by claiming luxurious rewards in their bids without actually paying them. Acknowledging this, validators are only going to use relays they trust (such as Flashbots'), and there lies the issue --- *trust*. #### Solutions - ⭐ [Payment proofs](https://github.com/flashbots/mev-boost/issues/99#issuecomment-1130039956) -- builders provide validators with a cryptographic proof so they can verify that the blinded block they're signing includes the payment transaction they're promised. *This is only a proposal, so I wouldn't bet on it to happen before The Merge.* ### Block Withholding Since validators must reveal their block signature to the relay to receive the missing piece required to publish it (transactions), the relay can withhold it and paralyze the validator who risks slashing if it tries to publish another block, and so the slot ends up empty. If the relay does this repeatedly, we end up with the only validators who actually publish blocks being those who aren't running mev-boost. If most validators are running mev-bost (because it's very profitable to do so), then we have an outage. *h/t @Micah for explaining this on Eth R&D Discord* - 👀 [Relay Monitor](https://github.com/flashbots/mev-boost/issues/142) - ⭐ [proposer/builder separation (PBS)](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) ## @ Blox See https://hackmd.io/@OePu7i-9Q7u7cUH5oiCy9Q/SyybKLE29#Gaps --- | | Legend | | --- | ---------------------- | | ⭐ | it *really* solves it | | 👀 | it helps.. |