Use blocks v3 endpoint in the VC

[eserilev]

Issue Addressed

#4812

Proposed Changes

Use the blocks v3 endpoint in the vc if post deneb or if enabled via a config flag

Additional Info

This also includes changes from #4629. It'll probably be tough to review this without merging #4629 to unstable first

• add block_v3 logic to the vc
• enable block_v3 logic by default post deneb
• enable block_v3 logic in vc via config (pre deneb)

[realbigsean]

At a bare minimum I think we need to add a new VC flag --builder-boost-factor

Agree!

There might also be some additional flags we could add to improve UX

--builder-always sets builder_boost_factor to u64::MAX, ignoring local payloads as long as the builder payload is valid.
--local-always sets builder_boost_factor to 0, ignoring builder payloads as long as the local payload is valid

We have a BN flag --always-prefer-builder-payload, so re-using the name in the VC could be good? and --always-prefer-local-payload as an alias for 0? But maybe we leave these for a follow up PR

I asked other teams about whether they plan to switch endpoints at the fork or start using V3 right away or stick with V2 through the fork. Teku is still using V2 by default and has a flag for V3, so seems like we're ok to move forward with the same.

The Goerli fork for Deneb is gonna be on Jan 17, so if we're able to get this in by early next week (no pressure though @eserilev , we can bump it this is too tight a timeline), we'd be able to include it in our pre-release for that fork. That would give us a good opportunity to start getting people prepared for the deprecation of --builder-proposal. I've reviewed #5035 and it looks good to go apart from one small change.

[jimmygchen]

At a bare minimum I think we need to add a new VC flag --builder-boost-factor

It would be a good feature, but I see this as a new and separate feature, i.e. we don't need a new flag to make our VC compatible with block v3. I think we also want to think about potentially removing some of the logic in the BN before we add these new flags, as we have the same flags in the BN, and it's already quite complex.

We need to do a pre-release next week for the Goerli Deneb fork and it would be great to have block V3 support (builder-boost-factor) included in the release, so we should probably consider making it work before adding additional features.

EDIT: ^ probably applies more to the beacon node PR (#5035), this one is probably lower priority. If we were to remove some of the BN flags in the future, I think we should bundle those changes together with the new VC flags in the same release, so users still have the ability to maintain the same Lighthouse behaviour without a workaround.

[jimmygchen]

btw with the new --builder-boost-factor, we will be able to keep the --builder-proposal flag, and support per validator configuration, so we shouldn't need to deprecate the flag.

[realbigsean]

btw with the new --builder-boost-factor, we will be able to keep the --builder-proposal flag, and support per validator configuration, so we shouldn't need to deprecate the flag.

Oh right! nice

[paulhauner]

I pushed this to v4.6.0 based on a DM from @realbigsean in another channel. Please feel free to push it back if you didn't intend it for v4.6.0.

[michaelsproul]

I've updated this branch to build on #5035. I would like someone to double-check my translation of builder_proposals (see commit a9304c0).

I've also removed the automatic activation at Deneb, as that's what I understood Sean desired from this comment: #4813 (comment).

I also removed some TODOs from the code and opened #5039 and #5040 to track the remaining tasks.

[michaelsproul]

Just some other small changes I noticed

[michaelsproul]

Looks good!

[jimmygchen]

Other changes also look good to me!