Make API friendly to block explorers

[paulhauner]

Issue Addressed

• Resolves #694
• Resolves #713

Proposed Changes

Point-by-point addressing of @ppratscher's requests:

The blocks object should also include the block root hash alongside the state root hash and parent root hash

This has been done, see /beacon/block.

Currently I could not find any call that returns the current balance of a validator, it would be great if it is included in the get_beacon_validators response alongside the effective balance

The /beacon/validators endpoint now includes the balance.

The get_beacon_validators should include the validator index alongside the validator public key

The /beacon/validators endpoint now includes the validator index.

Add a get_beacon_validators_duties that returns the duties of all validators for a given epoch, otherwise we will have to call get_beacon_validator_duties with all public keys which might be not that performant (but I haven't tested this up to now)

The /beacon/validators/all endpoint serves this request. It's returning quite quickly on my end (40ms).

In order to de-aggregate attestations and associate an attestation with the included validators we will need the beacon committees for each epoch. I couldn't find any call that returns the committees by epoch

The /beacon/committees endpoint should fulfill this request.

In order to show participation statistics for each epoch add a call that shows the eligible ether, voted ether and the participation rate for each epoch

The consensus/global_votes endpoint should serve this request.

• eligible ether = previous_epoch_active_gwei
• voted ether = previous_epoch_attesting_gwei
• participation rate = voted ether / eligible ether (I didn't see the need to include this in the endpoint)

Notes

This is a work-in-progress.

[paulhauner]

@ppratscher, I have finished implementing the endpoints you were after and I have addressed each point in the top of this PR.

I will move onto unit testing next, however I have tested the endpoints by hand. If you are eager, feel free to start building off this branch. Otherwise, feel free to wait until it has been merged to master.

[ppratscher]

@paulhauner thanks a lot for your efforts! we will be starting next week on Monday to add a compatibility layer to beaconcha.in in order to support lighthouse. Will report back in case we run into any issues.

[pscott]

Just read the docs in this PR, everything looked good to me! Disappointed I couldn't find a single typo... :p

[michaelsproul]

Looks good overall, would just like to discuss some of the points raised about the /consensus end point.

[michaelsproul]

its ;)

[michaelsproul]

does not -> do not?

[michaelsproul]

I guess this should read "see current_epoch_head_attesting_gwei", and current_epoch_attesting_gwei should have a description above. Would be nice to arrange all the current_ fields into one block of bullet points, and follow them with all the "see above" previous_ fields.

[michaelsproul]

Gramatically awkward, maybe:

Requests one MultiAddr for each peer connected to the beacon node

[michaelsproul]

its

[pawanjay176]

This should be a POST method with query params None.

[pawanjay176]

I think this should be a RequestBody with epoch and pubkeys as parameters.

[ppratscher]

Thanks a lot for your efforts. Today we completed the integration of the lighthouse rpc api into our block explorer. Must of the calls work as expected, we just found 1 oddity:

For some states calling /beacon/validators/all returns Unable to read pubkey cache: PubkeyCacheIncomplete { cache_len: 0, registry_len: 16384 }

An example would be retrieving the validators with the state root of slot 192:
http://localhost:5052/beacon/validators/all?state_root=0xdf0b538dbf80d2a1d1933b80052a740e1a4f07297f83c8948650977ecf09d418

[paulhauner]

For some states calling /beacon/validators/all returns Unable to read pubkey cache: PubkeyCacheIncomplete { cache_len: 0, registry_len: 16384 }

Thanks @ppratscher, I know exactly what this is and will fix it.

[paulhauner]

All comments have been addressed :)

[michaelsproul]

Looks good!