-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Conversation
e310978
to
c64c49a
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files
... and 8 files with indirect coverage changes
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
lgtm,
pending @joshieDo
payload: ExecutionPayload, | ||
/// The parent beacon block root, if any. | ||
parent_beacon_block_root: Option<H256>, |
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 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
lgtm! Only one bit left.. |
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 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
pub fn try_into_sealed_block( | ||
self, | ||
parent_beacon_block_root: Option<H256>, | ||
) -> Result<SealedBlock, PayloadError> { |
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.
meh - can we/should we capture this in executionpayload? i g not?
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 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:
executionPayload
:ExecutionPayloadV3
.expectedBlobVersionedHashes
:Array of DATA
, 32 Bytes - Array of expected blob versioned hashes to validate.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")] |
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.
are tehse renames needed? doesn't the serde name camel case cut it?
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.
they aren't needed, missed the camel case rename. the only one that needs the rename is the uncles hash
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 |
0d2fec4
to
ab0ee67
Compare
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.
good to go @Rjected ?
yep |
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
forHeaderFlags
on main:and here is the new output of
cargo expand
forHeaderFlags
:We used up one of our unused bits adding the optional field, so this shouldn't break the DB.