Remove --xblock-v3-enabled and useBlindedBlock variable

[gfukushima]

PR Description

This PR removes the experimental flag that allows users to enable or disable block production using the produceBlockV3 API. V3 is now the default behaviour and V2 deprecated implementations have been removed.

Fixed Issue(s)

Fixes #7779

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

[StefanBratanov]

This whole if statement should be simplified. After this change, we have only one condition, if fallback data is present, we return unblinded executionPayload, otherwise we have the builderBid and return the blinded header.

Essentially, we can skip this, since it will never happen:

final ExecutionPayload executionPayload =builderBidOrFallbackData
    .getFallbackDataRequired()
    .getExecutionPayload();
 return schemaDefinitions
     .getExecutionPayloadHeaderSchema()
     .createFromExecutionPayload(executionPayload);

[gfukushima]

well that's interesting, I understand the logic behind this clean up but wouldn't that be somehow a weird enforcement we would do? Every CL must have a EL in order to be fully functional in the network as a proposer, no? If so the first condition will always be true and even if you configure a builderBid we will default to use the fallback always isn't that so?

[StefanBratanov]

So, the way it works is that either the builder bid is present or the fallback is present. The two won't be present at the same time.

[StefanBratanov]

We can create similar method to getFallbackDataRequired() like getBuilderBidRequired() to make it bit cleaner

[StefanBratanov]

Hmm why did we remove the if statement?

[gfukushima]

if executionPayloadContext is empty then shouldTryBuilderFlow will always be false

[StefanBratanov]

Oh yes, got it. In this case, we can just leave the .executionPayload

[StefanBratanov]

And move shouldTryBuilderFlow initialization afterwards

[gfukushima]

leaving just the .executionPayload break one of the bellatrix unit tests (shouldIncludeExecutionPayloadHeaderOfDefaultPayload). which in my opinion should probably be fine to be removed but I'd like a second opinion here.

[StefanBratanov]

Yeah, we can just remove that test, it is no longer applicable. We will always use the unblinded flow in that case.

[StefanBratanov]

I think leaving only .executionPayload() will fix the acceptance test failure

[greptile-apps]

PR Summary

This pull request removes the '--xblock-v3-enabled' flag and 'useBlindedBlock' variable from the Teku codebase, simplifying the block creation process. Key changes include:

• Removed 'requestedBlinded' parameter from block creation methods across multiple classes
• Simplified 'createUnsignedBlock' method signatures in various components
• Eliminated fallback mechanisms for blinded block production
• Updated test cases to reflect the removal of blinded block options
• Removed deprecated methods related to older block versions

These changes streamline the block production process, potentially improving code maintainability and reducing complexity in the Teku Ethereum client.

_{30 file(s) reviewed, 1 comment(s)
Edit PR Review Bot Settings}

[greptile-apps]

logic: The Optional.empty() parameter for isBlinded has been removed. Verify that this doesn't break any existing functionality.

[StefanBratanov]

LGTM with one comment

[StefanBratanov]

I think we should remove this in ProduceBlockRequest

.withHandler(SC_NOT_FOUND,
                (__, ___) -> {
                  throw new BlockProductionV3FailedException();
                });

So that endpoint call from VC correctly returns 404. We don't have any fallback, so better to return correct response code to VC.