Update lodestar-eip-7732-builder.md#191
Conversation
| - Deeper write-up of builder bidding constraints under ePBS and follow-up issues for future adversarial builder work. | ||
| - Run a kurtosis devnet with lodestar builder and Buildoor, consistently out-bid Buildoor's bids and get selected. | ||
| - Do not blindly reveal envelope when there is a win. Optionally withhold the envelop when weak proposer's block is detected (this is research focused task, there is no danger of payload being stolen as Lodestar does not include mev or private txs). | ||
| - Do not blindly reveal envelope when there is a win. Optionally withhold the envelope when weak proposer's block is detected (this is research focused task, there is no danger of payload being stolen as Lodestar does not include mev or private txs). |
There was a problem hiding this comment.
Optionally withhold the envelope when weak proposer's block is detected
not suggesting any change to how this is documented, but to be clear, if the proposer's block ends up being canonical, then the trustless payment will force us (as in the builder) to pay the proposer while we would lose tx fee revenue from the payload itself, ie. causing us to lose money
payload withholding is a viable strategy and high value mev payloads with lots of private order flow at risk of being unbundled will have to do this one way or the other. the only viable strategy I believe exists right now is to subscribe to all attestation subnets so you get a good attester signal early in the slot, since the payload due deadline is at/before the aggregation deadline, so you cannot rely on aggregates to give you this signal
maybe @ensi321 has more ideas with respect to implementing this, I don't think it's entirely trivial to get right
but either way, if we add something like this, it should definitely be behind a feature flag
|
Small optional wording tweak for the envelope-withholding stretch goal, to capture Nico's feature-flag caveat without expanding the scope too much. Current bullet could become:
This is not blocking from my side, but it records the important caveat from Nico's comment directly in the proposal. |
Co-authored-by: Kris O'Shea <91485468+krisoshea-eth@users.noreply.github.com>
5 participants
Introduces changes based on the comments from @nflaig and @ensi321 in #161:
cc: @krisoshea-eth