sambacha/Mev-relay-dos-vector.md Secret

## Mev-relay-dos-vector.md

      
    Raw
  

              Mev-relay-dos-vector.md
            
          
    Error in user YAML: (<unknown>): mapping values are not allowed in this context at line 2 column 129
---
title: Effective DoS of mev-boost-relay
description: it is possible to 'block' bids from other block builders on the relay by offering a block with only one transaction: transferring high reward (e.g. 1 ETH) to the reward address.
author: Dragan Milic
source: Manifold Finance
---


Effective DoS of mev-boost-relay

11/03/2022
Context

mev-boost-relay acts as a market place matching block builders with blocks proposers (validators).
Block proposers register with the mev-boost-relay by submitting their preferred gas limit and reward address.
Block builders fetch this information from the relay at the start of the slot and submit one or more blocks containing reward for the requested reward address of the block proposer.
Relay checks each block submission for

validity of the block by replaying all transaction and comparing states before and after
transactions involving OFAC blacklisted addresses
transaction containing reward to the reward address being present and matching the declared reward

Block proposer keeps polling the relay to get the latest best bid.
At every request only the current best bid out of all the submitted blocks is returned.
The bid itself is a 'blinded' block - containing just enough data to sign the block, but not enough to get the block's payload.
The best bid is determined solely by the amount of the reward to the block proposer's reward address.
When deadline for submitting the block has been reached, block proposer chooses the best bid seen and unblinds it by submit a block signature for it.
In return block proposer gets the complete signed block including the block payload to the block proposer.
Attack

Submitting a block containing only one transaction with a high bid to the reward address of the block proposer practically 'blocks' all other bids from being returned to the block proposer.
For some reason, (this needs further investigation; probably block gas used being extremely low) block proposers seem not to sign the proposed block and hence ignoring that relay as long as such a block is being offered.
Impact

We have tested this attack on Flashbot's Goerli relay and were successful at blocking any blocks being included in the Goerli testnet from Flashbot's relay for more than 30 minutes.
In theory, attacker would be risking loosing the reward, but can mitigate this by periodically submitting small transactions to increase the nonce of the sender of the reward.
Proposed mitigation

Validate the assumption that there is a lower limit of gas used on the block in validator clients, determine the lower gas limit and enforce this on the relay when accepting the blocks from the block builders.