Endpoint for expected withdrawals for a slot #301
Comments
|
We could do this to a limited amount, we need the pre-state to compute it and the starting point. Curious why we want this? Basically the EL is told precisely the withdrawals to include before building a block, so it should get that information up front before it starts... Is there value in an api being provided to show the information? |
|
It's useful for external block builders who want to synthesise their own payload attributes without being prompted by the CL. It's part of the reason why we added an API for fetching the randao mix at the head state (#242). For the expected withdrawals API I think it's essential to provide a |
|
If this is required then perhaps it makes more sense to have a single API call that can provide all of the information required by the builder, rather than having separate calls for each element? |
|
yeah, this is something we could combine w/ #244 so that if configured the beacon node just spits out "builder events" for each head it is tracking |
|
For reference, this is the implementation in the Flashbots Prysm fork: |
|
Does that imply we're not going to integrate it into the events, and an endpoint off a state is sufficient? |
|
@rolfyone I think current plan is to have both |
Added into a new route, `/eth/v1/builder`, as it's different to the existing beacon state fetch paradigm, and a new Tag for builders seems appropriate. This endpoint is probably suited to allowing for returning SSZ via octet-stream also, so added that in. The idea would be similar to blocks, it would just return the data object as the SSZ result. It would be possible to add withdrawals_root, but it'd be at the same level as finalized, so it'd be a little less clean. I've left that out for now. Fixes ethereum#301.
…304) Added into a new route, `/eth/v1/builder`, as it's different to the existing beacon state fetch paradigm, and a new Tag for builders seems appropriate. This endpoint is probably suited to allowing for returning SSZ via octet-stream also, so added that in. The idea would be similar to blocks, it would just return the data object as the SSZ result. It would be possible to add withdrawals_root, but it'd be at the same level as finalized, so it'd be a little less clean. I've left that out for now. Fixes #301.
Add an endpoint to fetch the expected withdrawals for some slot.
The endpoint path proposed is /eth/v1/beacon/states/{state_id}/withdrawals.
With the capella upgrade withdrawals are embedded in the payload attributes and currently there is no way to access the withdrawals outside the beacon node for validation.
With this API, withdrawals in the payload of externally built blocks can be compared with the expected withdrawals to ensure that the two match.
The text was updated successfully, but these errors were encountered: