-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove --xblock-v3-enabled and useBlindedBlock variable #8511
Changes from 19 commits
5c0fad7
30854e4
8fdd44d
52d6c38
ae20b68
73974e4
3534683
0e2c4ae
d18b280
f47afa5
996085c
a59953e
46356e2
6a6a685
1853058
2ec44e8
8ab3f75
fbe3836
d389a88
713f7e0
c469051
c98b937
f7b999f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -115,7 +115,6 @@ public Function<BeaconBlockBodyBuilder, SafeFuture<Void>> createSelector( | |
final BeaconState blockSlotState, | ||
final BLSSignature randaoReveal, | ||
final Optional<Bytes32> optionalGraffiti, | ||
final Optional<Boolean> requestedBlinded, | ||
final Optional<UInt64> requestedBuilderBoostFactor, | ||
final BlockProductionPerformance blockProductionPerformance) { | ||
|
||
|
@@ -190,7 +189,6 @@ public Function<BeaconBlockBodyBuilder, SafeFuture<Void>> createSelector( | |
setExecutionData( | ||
executionPayloadContext, | ||
bodyBuilder, | ||
requestedBlinded, | ||
requestedBuilderBoostFactor, | ||
SchemaDefinitionsBellatrix.required(schemaDefinitions), | ||
blockSlotState, | ||
|
@@ -208,7 +206,6 @@ public Function<BeaconBlockBodyBuilder, SafeFuture<Void>> createSelector( | |
private SafeFuture<Void> setExecutionData( | ||
final Optional<ExecutionPayloadContext> executionPayloadContext, | ||
final BeaconBlockBodyBuilder bodyBuilder, | ||
final Optional<Boolean> requestedBlinded, | ||
final Optional<UInt64> requestedBuilderBoostFactor, | ||
final SchemaDefinitionsBellatrix schemaDefinitions, | ||
final BeaconState blockSlotState, | ||
|
@@ -221,26 +218,23 @@ private SafeFuture<Void> setExecutionData( | |
blockSlotState.getSlot())); | ||
} | ||
|
||
// if requestedBlinded has been specified, we strictly follow it, otherwise we should run | ||
// Builder flow (blinded) only if we have a validator registration | ||
final boolean shouldTryBuilderFlow = | ||
requestedBlinded.orElseGet( | ||
() -> | ||
executionPayloadContext | ||
.map(ExecutionPayloadContext::isValidatorRegistrationPresent) | ||
.orElse(false)); | ||
|
||
// pre-Merge Execution Payload / Execution Payload Header | ||
if (executionPayloadContext.isEmpty()) { | ||
if (shouldTryBuilderFlow) { | ||
bodyBuilder.executionPayloadHeader( | ||
schemaDefinitions.getExecutionPayloadHeaderSchema().getHeaderOfDefaultPayload()); | ||
} else { | ||
bodyBuilder.executionPayload(schemaDefinitions.getExecutionPayloadSchema().getDefault()); | ||
} | ||
|
||
bodyBuilder.executionPayloadHeader( | ||
schemaDefinitions.getExecutionPayloadHeaderSchema().getHeaderOfDefaultPayload()); | ||
|
||
bodyBuilder.executionPayload(schemaDefinitions.getExecutionPayloadSchema().getDefault()); | ||
|
||
return SafeFuture.COMPLETE; | ||
} | ||
|
||
// We should run Builder flow (blinded) only if we have a validator registration | ||
final boolean shouldTryBuilderFlow = | ||
executionPayloadContext | ||
.map(ExecutionPayloadContext::isValidatorRegistrationPresent) | ||
.orElse(false); | ||
|
||
final ExecutionPayloadResult executionPayloadResult = | ||
executionLayerBlockProductionManager.initiateBlockProduction( | ||
executionPayloadContext.orElseThrow(), | ||
|
@@ -251,8 +245,7 @@ private SafeFuture<Void> setExecutionData( | |
|
||
return SafeFuture.allOf( | ||
cacheExecutionPayloadValue(executionPayloadResult, blockSlotState), | ||
setPayloadOrPayloadHeader( | ||
bodyBuilder, schemaDefinitions, requestedBlinded, executionPayloadResult), | ||
setPayloadOrPayloadHeader(bodyBuilder, executionPayloadResult), | ||
setKzgCommitments(bodyBuilder, schemaDefinitions, executionPayloadResult)); | ||
} | ||
|
||
|
@@ -268,8 +261,6 @@ private SafeFuture<Void> cacheExecutionPayloadValue( | |
|
||
private SafeFuture<Void> setPayloadOrPayloadHeader( | ||
final BeaconBlockBodyBuilder bodyBuilder, | ||
final SchemaDefinitionsBellatrix schemaDefinitions, | ||
final Optional<Boolean> requestedBlinded, | ||
final ExecutionPayloadResult executionPayloadResult) { | ||
|
||
if (executionPayloadResult.isFromLocalFlow()) { | ||
|
@@ -287,8 +278,7 @@ private SafeFuture<Void> setPayloadOrPayloadHeader( | |
builderBidOrFallbackData -> { | ||
// we should try to return unblinded content only if no explicit "blindness" has been | ||
// requested and builder flow fallbacks to local | ||
if (requestedBlinded.isEmpty() | ||
&& builderBidOrFallbackData.getFallbackData().isPresent()) { | ||
if (builderBidOrFallbackData.getFallbackData().isPresent()) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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); There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
bodyBuilder.executionPayload( | ||
builderBidOrFallbackData.getFallbackDataRequired().getExecutionPayload()); | ||
} else { | ||
|
@@ -298,16 +288,7 @@ private SafeFuture<Void> setPayloadOrPayloadHeader( | |
// from the builder bid | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can create similar method to |
||
.map(BuilderBid::getHeader) | ||
// from the local fallback | ||
.orElseGet( | ||
() -> { | ||
final ExecutionPayload executionPayload = | ||
builderBidOrFallbackData | ||
.getFallbackDataRequired() | ||
.getExecutionPayload(); | ||
return schemaDefinitions | ||
.getExecutionPayloadHeaderSchema() | ||
.createFromExecutionPayload(executionPayload); | ||
}); | ||
.orElseThrow(); | ||
bodyBuilder.executionPayloadHeader(executionPayloadHeader); | ||
} | ||
}); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm why did we remove the if statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if
executionPayloadContext
is empty thenshouldTryBuilderFlow
will always be falseThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes, got it. In this case, we can just leave the
.executionPayload
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And move shouldTryBuilderFlow initialization afterwards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we can just remove that test, it is no longer applicable. We will always use the unblinded flow in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think leaving only .executionPayload() will fix the acceptance test failure