-
Notifications
You must be signed in to change notification settings - Fork 304
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
Introduce SSZ support in Builder API #8994
Conversation
public Response(final T payload) { | ||
this.payload = payload; | ||
this.errorMessage = null; | ||
public static <T> Response<T> fromPayloadReceivedAsJson(final T payload) { |
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.
maybe better just as fromJsonPayload
public Response(final T payload, final String errorMessage) { | ||
this.payload = payload; | ||
this.errorMessage = errorMessage; | ||
public static <T> Response<T> fromPayloadReceivedAsSsz(final T payload) { |
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.
maybe fromSszPayload
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.
but technically the payload has been already decoded at this stage. It indicates how you received the payload rather than the format of the payload passed here. I have mixed feelings
...gration-test/java/tech/pegasys/teku/ethereum/executionclient/rest/RestBuilderClientTest.java
Show resolved
Hide resolved
...onclient/src/main/java/tech/pegasys/teku/ethereum/executionclient/rest/OkHttpRestClient.java
Outdated
Show resolved
Hide resolved
we also need to test that we correctly "revert" back to JSON if the getHeader response changes to JSON (e.g. builder software gets downgraded or some config changes). |
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
Expands the Builder Rest client to handle ssz in
getHeader
andpostPayload
methods.The general idea is that in
getHeader
we signal viaAccept
header that we supportssz
andjson
(withssz
preference).If we receive the header in
ssz
, we remember this and on the upcomingpostPayload
we will post the signed blinded block inssz
format.possible additional things:
isUnsupportedMediaTypeError
inResponse
to try to fallback to json in postPayload (maybe not really important)ssz
too. At immediately fallback toJSON
(and remain inJSON
) if the first call fails for whatever reason (independently by 415, which could be not implemented on server side). If the first call succeed we could keep sendingssz
(not falling back on generic error). This assumes that the relay doesn't change in the mean time from one supportingssz
to another not supportingssz
. But this would be out of spec RN.Fixed Issue(s)
fixes #8746
Documentation
doc-change-required
label to this PR if updates are required.Changelog