-
Notifications
You must be signed in to change notification settings - Fork 30
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
feat(l1): implement implement forkchoiceupdatedv2, newpayloadv2 and getpayloadv2 as enum variants #1395
Conversation
This reverts commit 4256146.
ForkChoiceUpdatedVersion::V1 => 1u8, | ||
ForkChoiceUpdatedVersion::V2 => 2u8, | ||
ForkChoiceUpdatedVersion::V3 => 3u8, |
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.
You can assign this values in the enum
definition so you can return the conversion to u8
directly:
pub enum ForkChoiceUpdatedVersion {
V1 = 1,
V2 = 2,
V3 = 3,
}
fn version(&self) -> u8 {
self.version as u8
}
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.
nice
ForkChoiceUpdatedVersion::V1 => "engine_forkchoiceUpdatedV1".to_string(), | ||
ForkChoiceUpdatedVersion::V2 => "engine_forkchoiceUpdatedV2".to_string(), | ||
ForkChoiceUpdatedVersion::V3 => "engine_forkchoiceUpdatedV3".to_string(), |
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.
The same trick as below enables formatting:
ForkChoiceUpdatedVersion::V1 => "engine_forkchoiceUpdatedV1".to_string(), | |
ForkChoiceUpdatedVersion::V2 => "engine_forkchoiceUpdatedV2".to_string(), | |
ForkChoiceUpdatedVersion::V3 => "engine_forkchoiceUpdatedV3".to_string(), | |
format!("engine_forkchoiceUpdatedV{}", self.version as usize) |
if attributes.parent_beacon_block_root.is_some() { | ||
return Err(RpcErr::InvalidPayloadAttributes( | ||
"forkChoiceV2 with Beacon Root".to_string(), | ||
)); | ||
} | ||
if !chain_config.is_shanghai_activated(attributes.timestamp) { | ||
return Err(RpcErr::UnsuportedFork( | ||
"forkChoiceV2 used to build pre-Shanghai payload".to_string(), | ||
)); | ||
} | ||
if chain_config.is_cancun_activated(attributes.timestamp) { | ||
return Err(RpcErr::UnsuportedFork( | ||
"forkChoiceV2 used to build Cancun payload".to_string(), | ||
)); | ||
} |
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 these can be avoided by replacing the optionals with the same "base struct wrapped with specific struct" technique. Then there are no extraneous attributes by construction, and the others can simply count on them.
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 in this case I prefer to use Optionals
for a couple of reasons:
- It's easier for serde to parse the request into the struct. The hive test checks if we receive a v2 request with v3 parameters and the other way around, so we need to allow v2 rpc with v3 params to signal that specific error. If we used the "base struct wrapped with specific struct" scheme, we would otherwise return a generic
RpcErr::BadParams
error (because we wouldn't be able to parse v3 params in a v2 call), but the hive test expects aRpcErr::InvalidPayloadAttributes
error instead 🤦♂️ - The resulting structure (in this case a
BlockHeader
) also expectsOptionals
for the v3 params (ie.parent_beacon_block_root
). So it is easier to set it directly in the end, as optional. See here
} | ||
} | ||
|
||
// TODO(#853): Allow fork choice to be executed even if fork choice updated was not correctly parsed. |
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'm confused by this TODO. If the fork choice was not correctly parsed, how do you know which choice you should make?
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 about this either. It was already implemented for V3. Also #853 is already fixed. I need to dig a bit on this one to check if the comment still holds
**Motivation** We need to support post merge V1, V2 and V3 for `GetPayload`, `NewPayload` and `ForkChoiceUpdated` functions **Description** Moved @mpaulucci ideas from his [PR](#1406) into [my own PR](#1395) to get V2 code for `ForkChoiceUpdated` It includes the removal of payload_attributes being a result Closes #892, #1184, #1186
Included in #1411 |
Motivation
We need to support post merge
V1
,V2
andV3
forGetPayload
,NewPayload
andForkChoiceUpdated
functionsDescription
Implemented
V2
for those functionsCloses #892, #1184, #1186
Makes to pass about 19 new hive tests
This PR replaces #1297 as it is the same solution using composition instead of traits