Skip to content
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

Closed
wants to merge 23 commits into from

Conversation

ElFantasma
Copy link
Contributor

@ElFantasma ElFantasma commented Dec 3, 2024

Motivation

We need to support post merge V1, V2 and V3 for GetPayload, NewPayload and ForkChoiceUpdated functions

Description

Implemented V2 for those functions

Closes #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

@ElFantasma ElFantasma requested a review from a team as a code owner December 3, 2024 18:37
Comment on lines 45 to 47
ForkChoiceUpdatedVersion::V1 => 1u8,
ForkChoiceUpdatedVersion::V2 => 2u8,
ForkChoiceUpdatedVersion::V3 => 3u8,
Copy link
Contributor

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
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

Comment on lines 37 to 39
ForkChoiceUpdatedVersion::V1 => "engine_forkchoiceUpdatedV1".to_string(),
ForkChoiceUpdatedVersion::V2 => "engine_forkchoiceUpdatedV2".to_string(),
ForkChoiceUpdatedVersion::V3 => "engine_forkchoiceUpdatedV3".to_string(),
Copy link
Contributor

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:

Suggested change
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)

Comment on lines +63 to +77
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(),
));
}
Copy link
Contributor

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.

Copy link
Contributor Author

@ElFantasma ElFantasma Dec 4, 2024

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 a RpcErr::InvalidPayloadAttributes error instead 🤦‍♂️
  • The resulting structure (in this case a BlockHeader) also expects Optionals 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.
Copy link
Contributor

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?

Copy link
Contributor Author

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

github-merge-queue bot pushed a commit that referenced this pull request Dec 5, 2024
**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
@ElFantasma ElFantasma closed this Dec 5, 2024
@ElFantasma
Copy link
Contributor Author

Included in #1411

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement ForkChoiceUpdatedV2
3 participants