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: add EIP-4788 parent_beacon_block_root to Header #4299

Merged
merged 2 commits into from
Aug 29, 2023

Conversation

Rjected
Copy link
Member

@Rjected Rjected commented Aug 21, 2023

Adds an optional parent beacon block root to the header, as well as the engine newPayload methods arguments. Consensus checks are also added, making sure that the field only exists past Cancun.

Because adding new header fields has the possibility of breaking the DB, here is the previous output of cargo expand for HeaderFlags on main:

use bytes::Buf;
use modular_bitfield::prelude::*;
///Fieldset that facilitates compacting the parent type. Used bytes: 4 | Unused bits: 2
#[allow(clippy::identity_op)]
pub struct HeaderFlags {
    bytes: [::core::primitive::u8; {
        ((({
            0usize + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B6 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B2 as ::modular_bitfield::Specifier>::BITS
        } - 1) / 8) + 1) * 8
    } / 8usize],
}

and here is the new output of cargo expand for HeaderFlags:

use bytes::Buf;
use modular_bitfield::prelude::*;
///Fieldset that facilitates compacting the parent type. Used bytes: 4 | Unused bits: 1
#[allow(clippy::identity_op)]
pub struct HeaderFlags {
    bytes: [::core::primitive::u8; {
        ((({
            0usize + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B6 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B4 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
                + <B1 as ::modular_bitfield::Specifier>::BITS
        } - 1) / 8) + 1) * 8
    } / 8usize],
}

We used up one of our unused bits adding the optional field, so this shouldn't break the DB.

@Rjected Rjected added C-enhancement New feature or request M-eip This change relates to the implementation of an EIP E-cancun Related to the Cancun network upgrade labels Aug 21, 2023
@codecov
Copy link

codecov bot commented Aug 21, 2023

Codecov Report

Attention: Patch coverage is 90.08264% with 12 lines in your changes missing coverage. Please review.

Project coverage is 68.38%. Comparing base (d8b1609) to head (ab0ee67).
Report is 5061 commits behind head on main.

Files with missing lines Patch % Lines
crates/consensus/common/src/validation.rs 28.57% 5 Missing ⚠️
crates/payload/basic/src/lib.rs 0.00% 2 Missing ⚠️
crates/rpc/rpc-types/src/eth/block.rs 50.00% 2 Missing ⚠️
crates/consensus/auto-seal/src/lib.rs 0.00% 1 Missing ⚠️
crates/rpc/rpc-engine-api/src/engine_api.rs 66.66% 1 Missing ⚠️
crates/rpc/rpc/src/eth/api/pending_block.rs 0.00% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

Files with missing lines Coverage Δ
crates/consensus/beacon/src/engine/handle.rs 89.79% <100.00%> (+1.15%) ⬆️
crates/consensus/beacon/src/engine/message.rs 38.46% <ø> (ø)
crates/consensus/beacon/src/engine/mod.rs 75.25% <100.00%> (+0.39%) ⬆️
crates/consensus/beacon/src/engine/test_utils.rs 77.40% <100.00%> (+0.16%) ⬆️
crates/interfaces/src/consensus.rs 93.33% <ø> (ø)
crates/net/eth-wire/src/types/blocks.rs 97.27% <100.00%> (+0.02%) ⬆️
crates/primitives/src/header.rs 95.79% <100.00%> (+0.21%) ⬆️
crates/rpc/rpc-types/src/eth/engine/payload.rs 85.34% <100.00%> (+0.05%) ⬆️
crates/consensus/auto-seal/src/lib.rs 0.00% <0.00%> (ø)
crates/rpc/rpc-engine-api/src/engine_api.rs 83.33% <66.66%> (ø)
... and 4 more

... and 8 files with indirect coverage changes

Flag Coverage Δ
integration-tests 16.70% <51.23%> (+0.01%) ⬆️
unit-tests 63.66% <86.77%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
reth binary 26.01% <ø> (ø)
blockchain tree 82.56% <ø> (ø)
pipeline 90.07% <ø> (ø)
storage (db) 74.72% <ø> (ø)
trie 94.88% <ø> (ø)
txpool 47.23% <ø> (ø)
networking 77.48% <100.00%> (-0.01%) ⬇️
rpc 57.95% <89.18%> (-0.02%) ⬇️
consensus 63.54% <81.81%> (+0.15%) ⬆️
revm 31.89% <ø> (ø)
payload builder 6.77% <0.00%> (-0.02%) ⬇️
primitives 86.34% <100.00%> (+0.03%) ⬆️

@mattsse mattsse requested a review from joshieDo August 21, 2023 20:23
Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

lgtm,
pending @joshieDo

Comment on lines 149 to +151
payload: ExecutionPayload,
/// The parent beacon block root, if any.
parent_beacon_block_root: Option<H256>,
Copy link
Collaborator

Choose a reason for hiding this comment

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

I thought that we could introduce a new wrapper type here, but I actually prefer having a Some|None argument in all the on_new_payload functions so it is evident when we're using it

@joshieDo
Copy link
Collaborator

lgtm! Only one bit left..

Copy link
Member

@gakonst gakonst left a comment

Choose a reason for hiding this comment

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

I wonder if this is something where we'd want feature flags, I don't love it but the potentially unintended DB breakage is a bit scary

Comment on lines +134 to +150
pub fn try_into_sealed_block(
self,
parent_beacon_block_root: Option<H256>,
) -> Result<SealedBlock, PayloadError> {
Copy link
Member

Choose a reason for hiding this comment

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

meh - can we/should we capture this in executionpayload? i g not?

Copy link
Member Author

Choose a reason for hiding this comment

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

The API defines it as a separate argument, so if we were to put it into the execution payload we'd have the field duplicated across the execution payload and RPC args, which isn't ideal:

  • method: engine_newPayloadV3
  • params:
    1. executionPayload: ExecutionPayloadV3.
    2. expectedBlobVersionedHashes: Array of DATA, 32 Bytes - Array of expected blob versioned hashes to validate.
    3. parentBeaconBlockRoot: DATA, 32 Bytes - Root of the parent beacon block.

@mattsse was referencing a wrapper type for this

I thought that we could introduce a new wrapper type here, but I actually prefer having a Some|None argument in all the on_new_payload functions so it is evident when we're using it

which would wrap the execution payload and be used as the type in the newpayload message, and arguments for new_payload, ensure_well_formed_payload, etc

@@ -131,6 +131,9 @@ pub struct Header {
/// Excess blob gas
#[serde(rename = "excessBlobGas", skip_serializing_if = "Option::is_none")]
pub excess_blob_gas: Option<U64>,
/// Parent beacon block root
#[serde(rename = "parentBeaconBlockRoot", skip_serializing_if = "Option::is_none")]
Copy link
Member

Choose a reason for hiding this comment

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

are tehse renames needed? doesn't the serde name camel case cut it?

Copy link
Member Author

Choose a reason for hiding this comment

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

they aren't needed, missed the camel case rename. the only one that needs the rename is the uncles hash

@Rjected
Copy link
Member Author

Rjected commented Aug 23, 2023

I wonder if this is something where we'd want feature flags, I don't love it but the potentially unintended DB breakage is a bit scary

If future forks add 2 or more fields, then we might want to have a feature flag while we're not activated, but once the fork is active it looks like DB breakage is unavoidable

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

good to go @Rjected ?

@Rjected
Copy link
Member Author

Rjected commented Aug 29, 2023

good to go @Rjected ?

yep

@Rjected Rjected added this pull request to the merge queue Aug 29, 2023
Merged via the queue into main with commit 0c7a937 Aug 29, 2023
24 checks passed
@Rjected Rjected deleted the dan/eip-4788-header-fields branch August 29, 2023 18:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement New feature or request E-cancun Related to the Cancun network upgrade M-eip This change relates to the implementation of an EIP
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants