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

beacon/engine, eth/catalyst, miner: 4788 CL/EL protocol updates #27872

Merged
merged 15 commits into from
Aug 26, 2023

Conversation

holiman
Copy link
Contributor

@holiman holiman commented Aug 7, 2023

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:

  • Header.BeaconRoot has been renamed to ParentBeaconRoot.
  • The engine API now implements forkchoiceUpdatedV3
  • newPayloadV3 method has been updated with the parentBeaconBlockRoot parameter
  • the beacon root is now applied to new blocks in miner
  • For EIP-4844, block creation now updates the blobGasUsed field of the header

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

When verifying a block, execution clients MUST ensure the root value in the block header matches the one provided by the consensus client.

Exactly when should what be verified against what?

@holiman holiman changed the title 4788 part2 4788 CL/EL protocol updates Aug 7, 2023
@ralexstokes
Copy link
Member

Exactly when should what be verified against what?

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

@holiman holiman added the cancun label Aug 14, 2023
@holiman holiman force-pushed the 4788_part2 branch 3 times, most recently from 14e9932 to 03a9b09 Compare August 17, 2023 06:43
@holiman holiman force-pushed the 4788_part2 branch 2 times, most recently from 06b0626 to 445fce3 Compare August 22, 2023 12:44
@holiman holiman marked this pull request as ready for review August 22, 2023 12:54
@holiman holiman requested a review from gballet as a code owner August 22, 2023 12:54
@holiman holiman changed the title 4788 CL/EL protocol updates beacon/engine, miner: 4788 CL/EL protocol updates Aug 22, 2023
@holiman
Copy link
Contributor Author

holiman commented Aug 23, 2023

This is now ready for review, cc @lightclient @fjl

@fjl
Copy link
Contributor

fjl commented Aug 23, 2023

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 {
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 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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So the options are ...

  1. Leave it as is,
  2. Remove the check (potentially getting a nil deref on core.ProcessBeaconBlockRoot(*header.BeaconRoot,
  3. Change the check to use common.Hash{} if it is nil,
  4. 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.

Copy link
Contributor

@fjl fjl Aug 25, 2023

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.

@fjl
Copy link
Contributor

fjl commented Aug 25, 2023

@holiman PTAL!

Copy link
Contributor Author

@holiman holiman left a comment

Choose a reason for hiding this comment

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

LGTM

@fjl fjl changed the title beacon/engine, miner: 4788 CL/EL protocol updates beacon/engine, eth/catalyst, miner: 4788 CL/EL protocol updates Aug 26, 2023
@fjl fjl merged commit 6aa88cc into ethereum:master Aug 26, 2023
@fjl fjl added this to the 1.13.0 milestone Aug 26, 2023
@holiman holiman deleted the 4788_part2 branch October 11, 2023 07:26
devopsbo3 pushed a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
…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
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
holiman pushed a commit that referenced this pull request Jan 23, 2024
… 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.
Dergarcon pushed a commit to specialmechanisms/mev-geth-0x2mev that referenced this pull request Jan 31, 2024
… 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.
sduchesneau pushed a commit to streamingfast/go-ethereum that referenced this pull request Feb 26, 2024
 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants