Mev-boost community call #10 - 14 Aug 2024

The Flashbots Ship
3

Suggested Agenda Topics:

Privileged Relay Capability

The ‘Privileged Relay’ capability is a way of specifying a validators preferential choice in using one relay exclusively. The use case for this includes:

  • Relays that have a defined auction window bid time (i.e. relay does not participate in such ‘latency games’
  • Proxy Gateway that provides an additional layer for security / enabling certain testing scenarios

The Privileged Relay MUST provide a valid response by the defined window time. Validators SHOULD also listen and accept other relay bids as well. If the Privileged Relay does not provide a valid bid, or some other error code, the validator MUST then either accept other relay bids or use a locally built block.

There is a potential for the Privileged Relay to have a weight scoring applied to it, however we defer this point as there already validator configruation settings that are applied that alter valuation math, and are not done so in a clearly transparent manner.

Blob Inclusion Information

Expand Relay Specification to include blob information related to inclusion, e.g.

   "blob_inclusion": {
      "blobs_included": true,
      "blob_count": 5,
      "blob_inclusion_hash": "0xabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef",
      "total_blob_size": 5120
    }

Before we open up a PR on the relay specification repo, feedback must be solicited. Additionally, this MUST be a new endpoint for bid_trace.

Generating a Proof of Builder Payment Verification

Currently, generating such proofs without proposer fee recipient-related transactions distorting the number is not straightforward.

This is a draft proposal for an enhancement to the way builder bids are verified by the relay, expanding the block-based data used to calculate the true value received by proposer fee recipients.

This change aims to address the inaccuracies caused by current methods that only use simple pre- / post-balance checks or transaction value checks.

  • Block Data Extensions

    • Transfers In: Define as the sum of all incoming transfers to the proposer fee recipient within a block.
    • Transfers Out: Define as the sum of all outgoing transfers from the proposer fee recipient within the same block.
    • Costs: Define as the sum of all transaction fees burned by transactions that originate from the proposer, fee recipient.

  • Bid Calculation

    • The builder bid value for the proposer fee recipient is calculated using a defined formula

There are at 5 observed methods of payment for builders/searchers, see https://docs.xga.com/Developers/payment-methods/

If you have any questions, feel free to message me on Telegram - Telegram: Contact @sambacha or Twitter https://twitter.com/@blockrotator

1 Like