Skip to main content

Relay Fundamentals

Relay Fundamentals​

What is a Relay?​

Relays are a doubly-trusted data-availability layer and communication interface between builders and validators. Relays are trusted by builders for fair payload routing, and trusted by proposers for block validity, accuracy, and data availability. They are often specialized in Denial of Service (DoS) protection and networking.

Relays can connect to one or many builders, and we expect that there will be both variants. A relay connecting to many builders will aggregate their bids (fun fact: in a previous iteration, we called them builder aggregators or builder pools). The relay can see all the blocks submitted by the builders to confirm their validity and how much they pay to the validator. The relay then only submits the highest valid bid to the validator to sign.

Before validators can receive any bids from relays, they need to set up mev-boost and add relays to their mev-boost config. mev-boost is effectively just a relay aggregator or a local relay of relays. It will serve the validator the winning bid from all relays. A validator can connect to a small number of relays that aggregate all the builders, and many will probably do that. Other validators might connect to many relays.

The Role of Relays​

A relay has several responsibilities:

  • They execute builder-spec and data transparency API functionality.
  • Handle validator registrations and block proposals in a scalable manner.
  • Provide block escrow and data availability.
  • Simulate and verify blocks sent by block-builders, and rate-limit as necessary. Relays simulate whether:
    • the correct amount of fees are paid to recent validator feeRecipient.
    • the correct block attributes and transactions exist.
    • the block gas is within the gasLimit requested by validator.

Relay API Specification​

The current specification for the open-source Flashbots relay. Diagram below displays the current architecture:

Relay Architecture

Proposer API​

Standard builder spec APIs

  • registerValidator: POST /eth/v1/builder/validators
  • getHeader: GET /eth/v1/builder/header/{slot}/{parent_hash}/{pubkey} - Get an execution payload header.
  • submitBlindedBlock: POST /eth/v1/builder/blinded_blocks - Submit a signed blinded block and get unblinded execution payload.
  • status: GET /eth/v1/builder/status

Block Builder API​

Get a list of validator registrations for the current and next epoch, submit a new block to the relay.

Data API​

Provides data about received blocks from builders, payloads delivered to proposers as well as insights into validator registrations.

Circuit Breaker​

The circuit breaker is implemented by client software teams to define “circuit breaking” conditions using globally available inputs (such as the chain) to determine whether clients should stop sourcing blocks from an external block builder network and fallback to local block production instead. Each consensus client implements different circuit breaker conditions and once the circuit breaker condition is met, clients have different behaviour regarding when to resume sourcing external blocks.

For the exact behavior and available configuration around circuit breaker conditions for a specific client, please refer to the documentation for the specific consensus client.

Relay Monitor​

While relays are trusted actors, the ability to run a relay is permissionless. To mitigate potential abuses of this role, Flashbots has suggested a “relay monitor,” which uses publicly available data to form a view on the behavior and performance of the set of relays it is monitoring. This is an ongoing proposal and more details can be found in the relay monitor design documentation, keeping MEV-Boost relays honest, and understanding liveness risks.