Add support for produce block v3 endpoint #2749
Comments
obol-bulldozer bot
pushed a commit
that referenced
this issue
Feb 8, 2024
Returns 404 with message `endpoint not supported` for produce block v3 endpoint to signal VC it is not supported by charon yet. Otherwise charon will proxy this request to beacon node. category: feature ticket: #2749
gsora
pushed a commit
that referenced
this issue
Feb 8, 2024
Returns 404 with message `endpoint not supported` for produce block v3 endpoint to signal VC it is not supported by charon yet. Otherwise charon will proxy this request to beacon node. category: feature ticket: #2749
gsora
pushed a commit
that referenced
this issue
Feb 8, 2024
Returns 404 with message `endpoint not supported` for produce block v3 endpoint to signal VC it is not supported by charon yet. Otherwise charon will proxy this request to beacon node. category: feature ticket: #2749
obol-bulldozer bot
pushed a commit
that referenced
this issue
Feb 19, 2024
Initial implementation of `/eth/v3/validator/blocks/{slot}` endpoint in according with the design doc.
Introduced some refactoring to the existing v1/v2 endpoints to reduce code duplication.
category: feature
ticket: #2749
obol-bulldozer bot
pushed a commit
that referenced
this issue
Mar 1, 2024
Integrated the forked version of go-eth2-client that supporting UniversalProposal interface. The changes for go-eth2-client can be found here: attestantio/go-eth2-client#109 category: feature ticket: #2749
|
This work is not relevant anymore, new ticket: #2936 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
🎯 Problem to be solved
We need to add support for fallback mechanism to local beacon node in case of blinded block failures. This can be done by adding produceBlockV3 endpoint to charon node. This endpoint can return full block as well as blinded block which provides fallback to local block in case if builder fails to respond on time.
🛠️ Proposed solution
One possible solution can be to combine
DutyProposerandDutyBuilderProposerduties. The reason being our current consensus workflow does consensus round by duty type which separates consensus rounds of both of these duties. Our consensus workflow doesn't care what is the underlying type of signed data.🧪 Tests
The text was updated successfully, but these errors were encountered: