-
Notifications
You must be signed in to change notification settings - Fork 890
Use SSZ by default when calling /eth/v3/validator/blocks #7727
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
Changes from 1 commit
b602790
429884b
9a26794
b825482
3e4381e
4a3c268
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 |
---|---|---|
|
@@ -524,22 +524,50 @@ impl<S: ValidatorStore + 'static, T: SlotClock + 'static> BlockService<S, T> { | |
proposer_index: Option<u64>, | ||
builder_boost_factor: Option<u64>, | ||
) -> Result<UnsignedBlock<S::E>, BlockError> { | ||
let (block_response, _) = beacon_node | ||
.get_validator_blocks_v3::<S::E>( | ||
let block_response = match beacon_node | ||
.get_validator_blocks_v3_ssz::<S::E>( | ||
slot, | ||
randao_reveal_ref, | ||
graffiti.as_ref(), | ||
builder_boost_factor, | ||
) | ||
.await | ||
.map_err(|e| { | ||
BlockError::Recoverable(format!( | ||
"Error from beacon node when producing block: {:?}", | ||
e | ||
)) | ||
})?; | ||
{ | ||
Ok((ssz_block_response, _)) => { | ||
info!(slot = slot.as_u64(), "Received unsigned block in SSZ"); | ||
|
||
ssz_block_response | ||
} | ||
Err(e) => { | ||
warn!( | ||
slot = slot.as_u64(), | ||
error = %e, | ||
"Beacon node does not support SSZ in block production, falling back to JSON" | ||
Comment on lines
+537
to
+541
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. I'm wondering is there a way to disable attempting to use SSZ in cases where we know SSZ isn't supported? I don't think it matters too much as the overhead of the API instantly erroring should be quite small, but it's worth considering in cases where the BN -> VC latency is very high 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. What we do with the builder is we track the builder's SSZ support and turn it off after the first request fails. I don't think that additional complexity is worth it here however. |
||
); | ||
|
||
let (json_block_response, _) = beacon_node | ||
.get_validator_blocks_v3::<S::E>( | ||
slot, | ||
randao_reveal_ref, | ||
graffiti.as_ref(), | ||
builder_boost_factor, | ||
) | ||
.await | ||
.map_err(|e| { | ||
BlockError::Recoverable(format!( | ||
"Error from beacon node when producing block: {:?}", | ||
e | ||
)) | ||
})?; | ||
|
||
info!(slot = slot.as_u64(), "Received unsigned block in JSON"); | ||
|
||
// Extract ProduceBlockV3Response (data field of the struct ForkVersionedResponse) | ||
json_block_response.data | ||
} | ||
}; | ||
|
||
let (block_proposer, unsigned_block) = match block_response.data { | ||
let (block_proposer, unsigned_block) = match block_response { | ||
eth2::types::ProduceBlockV3Response::Full(block) => { | ||
(block.block().proposer_index(), UnsignedBlock::Full(block)) | ||
} | ||
|
@@ -548,7 +576,6 @@ impl<S: ValidatorStore + 'static, T: SlotClock + 'static> BlockService<S, T> { | |
} | ||
}; | ||
|
||
info!(slot = slot.as_u64(), "Received unsigned block"); | ||
if proposer_index != Some(block_proposer) { | ||
return Err(BlockError::Recoverable( | ||
"Proposer index does not match block proposer. Beacon chain re-orged".to_string(), | ||
|
Uh oh!
There was an error while loading. Please reload this page.
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.
Not sure if we need to log specifically as SSZ (and in JSON), or just leave it as the original log without
in SSZ
/in JSON
, moving this line below and just log it after thematch
.Logging
in SSZ/JSON
provides a bit more info but don't know if it will be helpful? Moving the log after thematch
and keeping it the same as current is simplerThere 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 don't mind either way, but I think it is redundant because of the
warn!
explaining the fallback to JSON.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.
Makes sense, simplify in 4a3c268 (i.e., use the current info log)