Mev-boost community call #12

ralexstokes · January 23, 2025, 6:38pm

Meeting Info

19 Feb 2025, 16:00 UTC
Duration: 90 minutes
Recording: https://youtu.be/Bpy_otcoimw
Zoom: Launch meeting

Agenda

Pectra
- mev-boost, mev-boost-relay, rbuilder updates
  - Release v1.9-rc2 · flashbots/mev-boost · GitHub
- timelines
Bid pricing: Standardize Bid Pricing Calculation for PBS Bids · Issue #708 · flashbots/mev-boost · GitHub
- example where the bid computation followed the rules, but is obviously incorrect: https://beaconcha.in/block/21846078
Spec update for header timestamp: add get header request sent timestamp by alextes · Pull Request #111 · ethereum/builder-specs · GitHub
BuilderNet v1.2: BuilderNet v1.2 | BuilderNet
PBS Foundation update

benjamin.hunter · January 24, 2025, 7:56pm

I’d love for us to be able to discuss this in a more official capacity to understand if we can get this standardized across all operators!

github.com/flashbots/mev-boost

Standardize Bid Pricing Calculation for PBS Bids

opened 07:55PM - 12 Dec 24 UTC

benhenryhunter

## Description There is currently an inconsistency in how bid prices are calc…ulated for blocks and how relays simulate bid accuracy. Specifically, the process of using a validator’s balance difference to determine the bid value can lead to inaccuracies. This issue aims to standardize how validator balance differences are applied, ensuring consistent and transparent calculation of bid values across all builders and relays. The goal isn't to force this proposal through, if there is a better method we can all agree on and point to moving forward then I will be content. After chatting with many teams it doesn't seem that any are bidding or verifying bids the exact same way. ## Background / Context Previously, it was proposed that bid values should consider only the positive balance change to the block’s coinbase, excluding any outgoing transfers and withdrawals. If the validator is the coinbase, using the validator’s balance difference (excluding withdrawals) is acceptable. However, when a builder is the coinbase, the correct method is to rely solely on the builder’s final transaction transfer. Below is an example where a validator balance difference was used while a block builder's address was set to the block coinbase. **Example:** In the [BTCS block at slot 10575868](https://beaconcha.in/slot/10575868#transactions), there was a payment of 0.18532 ETH to Lido and a builder payment of 0.02161 ETH. The intended bid should have been 0.02161 ETH, but due to the current logic, it was mistakenly interpreted as 0.20693 ETH. This occurred because the rbuilder simulation used the validator’s balance difference even though the coinbase was a builder address, not the validator. This kind of bidding can be misleading to validators believing they are accepting a block that pays them `0.20693` meanwhile it's using incoming funds of `0.18532` that they would have received either way. Furthermore this kind of bidding is incompatible with bloXroute relays currently and results in being demoted from optimistic submissions. ## Proposed Standardization To achieve consistency, I'm proposing the following: 1. **When the validator is the coinbase:** Use the positive balance difference (excluding withdrawals) as the bid price. - **Calculation:** Determine the validator’s balance before and after the block is built. Exclude incoming withdrawals from the balance increase and adjust for outgoing transfers, ensuring the final figure reflects the net positive gain. If the validator decides to give some money to his poor grandmother we ignore this tx since counting it would appear as negative profit. 2. **When the builder is the coinbase:** Use only the final transaction’s transfer value to determine the bid price. - **Calculation:** The last transaction’s transfer amount (e.g., from gas, MEV rewards, or subsidies) serves as the bid value. This is the simplest and most direct indicator of the builder’s intended payment. ## Impact / Implementation Details Implementing this standardization should involve minimal changes to both Go and Rust simulation code. Once adopted, validators, builders, and relays will have a unified and transparent method for determining bid values, reducing confusion and promoting fairness and consistency within the PBS ecosystem. As of time of posting I have gathered feedback and support from multiple teams and will ask them to provide their support or any discussions below to get everything finalized.

ralexstokes · February 5, 2025, 9:51pm

it seems i can’t edit the OP at the moment

in the mean time, ill add some things here:

Fred · February 7, 2025, 2:59pm

You should be able to edit the post now:)
lmk if not