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 DutyProposer and DutyBuilderProposer duties. 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
[ ] Tested by new automated unit/integration/smoke tests
[ ] Manually tested on core team/canary/test clusters
🎯 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
DutyProposer
andDutyBuilderProposer
duties. 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