-
Notifications
You must be signed in to change notification settings - Fork 20.3k
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
beacon/engine, eth/catalyst, miner: 4788 CL/EL protocol updates #27872
Conversation
the intent is to make sure that the root coming from the engine API is the one that matches the EL block header I think w/ the latest engine API updates, the EL block header will be constructed (if necessary) using the engine API data so it will be default be valid the other set of cases where the roots need to be checked is syncing |
14e9932
to
03a9b09
Compare
06b0626
to
445fce3
Compare
This is now ready for review, cc @lightclient @fjl |
I'll put #27993 in first, because it makes it easier to get the new parameter into the core of the miner. |
miner/worker.go
Outdated
@@ -935,6 +939,18 @@ func (w *worker) prepareWork(genParams *generateParams) (*environment, error) { | |||
log.Error("Failed to create sealing context", "err", err) | |||
return nil, err | |||
} | |||
if w.chainConfig.IsCancun(header.Number, header.Time) { | |||
if header.BeaconRoot == nil { |
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 we need to decide if this is the right place for this check. We could check it earlier, i.e. just require that the beaconRoot
be submitted. However, checking it here has the advantage that the consensus engine can override it. This will mostly be useful for downstream projects, who might want to set this there.
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.
So the options are ...
- Leave it as is,
- Remove the check (potentially getting a nil deref on
core.ProcessBeaconBlockRoot(*header.BeaconRoot,
- Change the check to use
common.Hash{}
if it is nil, - Change the check to not
ProcessBeaconBlockRoot
at all, if it is nil
But perhaps you were thinking of something else?
I mean, whatever we somewhere else, if we deref a pointer here, we should check it first, so IMO the only question is if we barge ahead or back out.
Out of the options I listed, I'd prefer 1
, possibly 4
for flexibility, but that's the kind of flexibility which can bite us later on.
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 decided to go with (4), for now.
@holiman PTAL! |
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
…i surface miner, beacon/engine: process systemtx, update json tag
…thereum#27872) This PR makes EIP-4788 work in the engine API and miner. It also fixes some bugs related to EIP-4844 block processing and mining. Changes in detail: - Header.BeaconRoot has been renamed to ParentBeaconRoot. - The engine API now implements forkchoiceUpdatedV3 - newPayloadV3 method has been updated with the parentBeaconBlockRoot parameter - beacon root is now applied to new blocks in miner - For EIP-4844, block creation now updates the blobGasUsed field of the header
…pdates (ethereum#27872)" This reverts commit 8398b70.
…pdates (ethereum#27872)" This reverts commit 8398b70.
… param checks (#28230) This PR introduces a few changes with respect to payload verification in fcu and new payload requests: * First of all, it undoes the `verifyPayloadAttributes(..)` simplification I attempted in #27872. * Adds timestamp validation to fcu payload attributes [as required](https://github.com/ethereum/execution-apis/blob/main/src/engine/cancun.md#specification-1) (section 2) by the Engine API spec. * For the new payload methods, I also update the verification of the executable data. For `newPayloadV2`, it does not currently ensure that cancun values are `nil`. Which could make it possible to submit cancun payloads through it. * On `newPayloadV3` the same types of checks are added. All shanghai and cancun related fields in the executable data must be non-nil, with the addition that the timestamp is _only_ with cancun. * Finally it updates a newly failing catalyst test to call the correct fcu and new payload methods depending on the fork.
… param checks (ethereum#28230) This PR introduces a few changes with respect to payload verification in fcu and new payload requests: * First of all, it undoes the `verifyPayloadAttributes(..)` simplification I attempted in ethereum#27872. * Adds timestamp validation to fcu payload attributes [as required](https://github.com/ethereum/execution-apis/blob/main/src/engine/cancun.md#specification-1) (section 2) by the Engine API spec. * For the new payload methods, I also update the verification of the executable data. For `newPayloadV2`, it does not currently ensure that cancun values are `nil`. Which could make it possible to submit cancun payloads through it. * On `newPayloadV3` the same types of checks are added. All shanghai and cancun related fields in the executable data must be non-nil, with the addition that the timestamp is _only_ with cancun. * Finally it updates a newly failing catalyst test to call the correct fcu and new payload methods depending on the fork.
beacon/engine, eth/catalyst, miner: EIP-4788 CL/EL protocol updates (ethereum#27872) Conflicts: eth/catalyst/api.go callSite to IsShanghai moved. New callsirte also calls IsCancun. I solved the conflict by assuming IsCancun will also accept ArbOS, without modifying IsCancun itself - this will be done in the next commit to keep things separate and easier to review. miner/worker.go callsite to ApplyTransaction moved, we have a change that adds a new (here ignored) value
This PR makes EIP-4788 work in the engine API and miner. It also fixes some bugs related to 4844 block processing and mining. Changes in detail:
This is a follow-up to #27849, adding the beaconroot to the messages passed between CL and EL. I split this up into a separate PR since it is backwards-incompatible, and will start rejecting cancun-updates from the CL which do not contain a beaconroot.
This also adds the beaconroot to the miner.
Note, there's one sentence in the 4788 eip which I do not fully understand (cc @ralexstokes
Exactly when should what be verified against what?