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

Implement ExecutionPayload processing #4592

Merged
merged 4 commits into from
Nov 9, 2021

Conversation

ajsutton
Copy link
Contributor

@ajsutton ajsutton commented Nov 9, 2021

PR Description

Implements the spec version of execution payload processing during block processing.

As per the spec, assumes the execution engine is available separately so while this is enough to get reference tests passing we will need an actual ExecutionEngineChannel implementation before it works in the real world. Currently everything is passing in ExecutionEngineChannel.NOOP.

Also hasn't implemented optimistic sync which will need to be done separately.

Documentation

  • I thought about documentation and added the documentation label to this PR if updates are required.

Changelog

  • I thought about adding a changelog entry, and added one if I deemed necessary.

As per the spec, assumes the execution engine is available separately so while this is enough to get reference tests passing we will need an actual ExecutionEngineChannel implementation before it works in the real world.

Also hasn't implemented optimistic sync which will need to be done separately.
final ExecutionPayload executionPayload,
final ExecutionEngineChannel executionEngine)
throws BlockProcessingException {
throw new UnsupportedOperationException("No ExecutionPayload in phase0");
Copy link
Contributor

Choose a reason for hiding this comment

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

"in Altair"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I knew I'd forget to change that....

Copy link
Contributor

@tbenr tbenr left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -40,4 +41,8 @@ public boolean isMergeBlock(final BeaconState genericState, final BeaconBlock bl
public boolean isExecutionEnabled(final BeaconState genericState, final BeaconBlock block) {
return isMergeBlock(genericState, block) || isMergeComplete(genericState);
}

public UInt64 computeTimestampAtSlot(final BeaconState state, final UInt64 slot) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: state -> genericState

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I left this as state matching the spec because we didn't need to have a BeaconStateMerge version and thus didn't need to differentiate the names.

@ajsutton ajsutton merged commit c896062 into Consensys:master Nov 9, 2021
@ajsutton ajsutton deleted the process-payload branch November 9, 2021 22:39
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.

2 participants