-
Notifications
You must be signed in to change notification settings - Fork 742
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
Clean up blockv3 metadata and client #5015
Conversation
I ended up wanting to test v3 JSON in blockdreamer, so I overhauled the JSON API and made it return the same type as the SSZ one. This PR will now clash with #4813, however unifying the types has simplified things a bit, and could allow us to do nice things in the VC, like select between SSZ (default!) and JSON requests based on a CLI flag. |
Nice!
This was really smart! would be getting pretty hairy otherwise |
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.
Love this, so much cleaner. Just a small question
Proposed Changes
execution_payload_value
to the JSON response for blocks/v3. Previously we were not following the spec.ForkVersionedResponse
so that it can carry arbitrarymetadata
. This is used to smuggle the metadata without adding a new variant ofForkVersionedResponse
. This required some refactoring elsewhere, but on the whole I think it's an improvement.produce_block
v3 API. This ensures the headers are checked in the tests, and enables blockdreamer to make use of the header metadata (see: Enable block v3 blockprint-collective/blockdreamer#5).Additional Info
This PR conflicts slightly with #4813. I was thinking we could merge this PR first.
This PR does not include the
builder_comparison_factor
change (ethereum/beacon-APIs#386). That needs to happen in another PR.