Consider running builder software through the Merge testing

[ralexstokes]

Remaining testnets before the Merge:

• Sepolia
• Goerli

@metachris and I would like to consider CL clients running version v0.1.0 of these specs during the upcoming Sepolia merge as a dress-rehearsal for later testnet merges and ultimately mainnet.

There is a trade-off here between shipping a safe merge with reduced code surface and deploying an untested software stack a few epochs into the finalized mainnet merge.

I'm raising this issue as a place for discussion of these various trade offs.

I'll open with the following extension to the builder-specs:

`MERGE_DELAY_EPOCHS` | `16` | `epoch`

Proposers **MUST** wait until `MERGE_DELAY_EPOCHS` epochs after the merge transition has been finalized before they can start querying the external builder network.

* NOTE: if the merge transition happens in epoch N and is finalized in epoch N+2, then proposers **MUST** not use the external builder network until epoch N + 2 + `MERGE_DELAY_EPOCHS`.

[metachris]

I'd like to suggest MERGE_DELAY_EPOCHS = 10 (so the external builder network is used about an hour after the merge is finalized).

[ralexstokes]

yeah I picked the closest power of 2 rounding up to target ~1hr

[tbenr]

Since time is shortening for sepolia, how should be setting this up? should we use https://github.com/flashbots/boost-geth-builder as local EL? Or are you planning to serve a relay for sepolia too?

[metachris]

We'll have a relay ready for sepolia!

[tbenr]

Thinking more about MERGE_DELAY_EPOCHS I realized that it isn't very CL friendly: most of the clients have the knowledge of the latest finalized state and tend to discard previous states. We could track it at runtime the first finalized payload but it wont survive a restart. The only way is, at startup, to scan backward canonical blocks searching for the first bellatrix block with non-default payload, which is increasingly heavy as time pass by. We could hardcode an upper bound slot\epoch (ie BELLATRIX activation epoch + something) after that we assume we are safe to start using MEV without checking. Other options?

[tbenr]

How bad is the option to leave the delay to the relays and signal it via status API? and CL simply start considering it after the first payload is finalized (no delay)?

[metachris]

We'll disable sending blocks from our relay as well until the agreed time has passed. Just realized that we might need to add a status code to the builder specs in case there's no header available, like 204 No Content 🤔

-> #34

[ralexstokes]

isn't very CL friendly

yeah, @tbenr is there anything else like this where you are tracking something just around the transition?

if not, then perhaps CLs just do best-effort combined w/ the same from the relay