Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

ref impl: Engine API client bindings #127

Merged
merged 1 commit into from
Jan 19, 2022
Merged

ref impl: Engine API client bindings #127

merged 1 commit into from
Jan 19, 2022

Conversation

protolambda
Copy link
Collaborator

Part of #119: staging -> main migration

This:

  • Defines some types like Bytes32 and Bytes256 for stricter API decoding
  • Implements client-bindings for the https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md
  • Implements the backwards-compatible API change that the optimism spec defines (transactions field in payload request attributes)
  • Logs extensively for debugging (note: staging branch was logging to the wrong logger, it now logs to the el.Log instead of global geth log)
  • Helper function to convert a block to an execution payload (for completeness, might remove this later)

Depends on #125

Review: any team. No spec changes required, implements existing engine API spec.

type ErrorCode int

const (
UnavailablePayload ErrorCode = -32001
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this value come from somewhere?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, it's defined in the execution APIs standard. Not my idea to use large seemingly random negative numbers.

Copy link
Contributor

Choose a reason for hiding this comment

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

Who comes up with these numbers? 😅 Also my bad, I realize I did a ctrl+F in the wrong document.

return hexutil.Encode(b[:])
}

type Uint64Quantity = hexutil.Uint64
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not use uint64 directly here?

I do understand that hexutil defines type Uint64 uint64 in order to be able to define methods on this new type (not allowed on primitive types), but shouldn't box this type inside the methods of this file, and expose the simpler uint64 in fields of ExecutionPayload?

Ditto for Data lower in this file.

Copy link
Collaborator Author

@protolambda protolambda Jan 18, 2022

Choose a reason for hiding this comment

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

This was an attempt to follow spec definitions with "quantity"/"data" type separation more closely. Since payload ID was uint64 but encoded as data instead of quantity. Once the upstream PR with payload-id type lands I can clean this up.

Base automatically changed from impl-eth-utils to main January 14, 2022 21:00

type Data = hexutil.Bytes

// TODO: implement neat 8 byte typed payload ID and upstream it to geth api definitions
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this is a significant effort, could we do it now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is part of what I already did in the PR to upstream geth (see PR status update in slack). Can merge this as-is and upgrade later.

Copy link
Collaborator

@maurelian maurelian left a comment

Choose a reason for hiding this comment

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

Are there existing engine API tests elsewhere that we could port into here?

@protolambda
Copy link
Collaborator Author

Are there existing engine API tests elsewhere that we could port into here?

Not yet, the execution apis repo has json schemas, but not for the engine API, yet. Maybe we can share testing with consensus-clients later on.

@codecov-commenter
Copy link

Codecov Report

Merging #127 (89a27f7) into main (d270fcb) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #127   +/-   ##
=======================================
  Coverage   77.20%   77.20%           
=======================================
  Files           1        1           
  Lines         136      136           
=======================================
  Hits          105      105           
  Misses         24       24           
  Partials        7        7           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d270fcb...89a27f7. Read the comment docs.

@protolambda
Copy link
Collaborator Author

Rebased on main to resolve merge conflicts (go.mod/sum file dependency changes)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants