TL;DR

• MEV-Boost v1.4.0
• Proposal to Replacing Types
• Preparations for Capella & EIP-4844 Changes
• Block Builder Submissions Vulnerability
• Beacon API Endpoint Implementation
• Relay API specs in OpenAPI format
• Relayooor
• Relayscan
• Open Source Priority Load Balancer

In the latest Consensus Layer Call #98, Chris Hager gave a latest mev-boost summary and updates.

MEV-Boost v1.4.0

This release includes some minor improvements, and the most notable feature is that it allows setting a minimum bid value in ETH using the -min-bid flag. Here is the complete PR on the Min Bid issue.

Users can now set a minimum bid to accept a block from a relay. Using the -min-bid flag to set a minimum bid value will incur a small opportunity cost and increase the chance of building local mempool blocks. These are the chances per value of building a local block, i.e., based on median payload values during the past two weeks:

Proposal to Replacing Types

This proposal was created to replace types from go-boost-utils with those from Attestant. Chris Hager has proposed to switch to the attestant types and deprecate the go-boost-utils types.

Preparations for Capella & EIP-4844 Changes

Capella and EIP-4844 will require changes to mev-boost, builder-specs, relay, and builders. They have introduced new fields to BeaconBlockBody, ExecutionPayload, and ExecutionPayloadHeader. This will break previous SSZ encoding/decoding and needs a mev-boost update alongside EL+CL updates. In addition, MEV-Boost will need to know about multiple container versions and handle the forks correctly.

Block Builder Submissions Vulnerability

Block builder submissions with incorrect timestamp and prev_randao values were sent in bids to proposers, resulting in the beacon node rejecting the bid and falling back to local block production. By sending specially crafted payloads to exploit this, attackers could prevent any MEV-Boost block from landing on the chain, forcing proposers to fallback to local block production.

The Manifold team responsibly disclosed the issue with tests in Goerli. In close collaboration with EF security, consensus client, and relay operators teams, the mev-boost team identified the root cause of the issue, i.e., an incomplete builder submission validation. Then, they deployed a solution to all networks.

A malicious builder sent bids to the Flashbots Mainnet relay, leading to a drop in MEV-Boost blocks between 12:00 and 16:00 UTC on Nov 10. The team identified the builder as 0xab847b...91921b and blacklisted him at 15:30 UTC while implementing a solution and unblocked him again afterwards.

Beacon API Endpoint Implementation

Chris Hager asked Consensus Teams to implement getStateRandao Beacon API Endpoint. Here is a complete guide on Beacon APIs in ELI5 Manner by EW Team.

Relay API specs in OpenAPI format

Relay API specs are now officially documented in OpenAPI format.

Relayooor

Relayooor.wtf is proving to be a new tool discover recently delivered payloads.

Relayscan

Relayscan is providing last 24 hours data for:

(i) Top Relays by Payloads Delivered

(ii) Top Top Builders by Blocks Landed On-Chain

Open Source Priority Load Balancer

Flashbots team have open sourced the Priority Load Balancer. This will be useful for anyone running mev-boost relay and allows block builder submissions across multiple validation nodes.

For the Readers who have no idea about MEV, we will recommend them to start from EW's MEV Research Report.

Related Videos

• The Merge Transition
• Ethereum: The Great Renaming
• Proof of Work
• Proof of Stake
• How to Join Kintsugi testnet?
• Kintsugi Fuzzer Issue
• What is Kiln Testnet?
• How to Join Kiln Testnet?

Related Articles

• An overview of expected changes with the Ethereum Merge upgrade
• MEV in DeFi
• Ethereum Mainnet Shadow Forking: An Overview
• What do Bellatrix, Paris & TTD mean in Ethereum Merge Upgrade?
• Ethereum's roadmap for 2022 and beyond!