Mev-boost community call #10 - 14 Aug 2024

Meeting Info

Agenda

2 Likes

If people think this is worth it, we could give a short overview of EIP-7732: Enshrined Proposer–Builder Separation and discuss which open items would be useful to consider from the MEV-Boost ecosystem perspective.

2 Likes

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

Would like to discuss adding SSZ support to builder api. Details can be found in Add SSZ support to builder api by nflaig · Pull Request #104 · ethereum/builder-specs · GitHub.

Would be interested to discuss TEE-Boost TEE-Boost

2 Likes

I would like to introduce the latest optimizations of Grandine consensus layer client related to MEV, such as faster block production, state transition etc.

My view on the privileged builders feature.

Starting a new relay and aiming to become a key player in the MEV space is challenging. Not all relays receive top bids because the best builders are often connected to established relays like Flashbots, Titan, and Ultrasound. This is why custom contracts between validators and new relays are crucial. Like other relays, new relays can have a custom contracts with new builders, potentially offering better MEV rewards for validators. However, during the testing phase, the relay might not always receive bids from the builder. In such cases, we still want to ensure validators get the best possible MEV rewards.

The privileged-builders configuration helps validators receive the best rewards while participating in the new relay’s testing phase.