Endpoint for state RANDAO mix

[michaelsproul]

Add an endpoint to fetch the RANDAO mix from a given state at some epoch.

The endpoint path is /eth/v1/beacon/states/{state_id}/randao.

With the merge the RANDAO mix has taken on increased significance, as it is embedded in execution payloads and available in the EVM.

Currently for tools that want to access the prev_randao from outside the beacon node for the purposes of payload construction or validation, they must load an entire beacon state using the debug endpoint. This is prohibitively slow for something that should be fast with the right API.

With this API, they can immediately get access to the correct prev_randao value using /eth/v1/beacon/states/head/randao prior to block construction (or can use the state_id corresponding to the parent block).

[djrtwo]

should there be a bound on state accessor or is it fine/easy to do for any depth?

[michaelsproul]

should there be a bound on state accessor or is it fine/easy to do for any depth?

Like the other state APIs it depends on the node's configuration & pruning settings. In Lighthouse's default config these queries will be fast close to the head, and unavailable for most historic states unless the user has opted into reconstructing and storing them (in which case they could be slow or fast).

[michaelsproul]

This is ready for review again

[riposteX]

Any chance you could also return the beacon node's current slot in the response?

Otherwise you may not be receiving the randao you're expecting.

[dapplion]

LGTM!

[michaelsproul]

@riposteX For consistency with the other state APIs I'd prefer to leave the slot out. If you want to be sure of the state from which you're drawing the RANDAO mix you can use the state_id to specify one. A good method for reliably getting the head's RANDAO mix is to listen for the head event on the SSE endpoint (https://ethereum.github.io/beacon-APIs/#/Events/eventstream), and then query for the RANDAO mix using the state root you get from there.

For block building there's also work to standardise a new event type with all the required information: #244.

[rolfyone]

LGTM