A Beacon Chain Light Client Proposal
A beacon chain light client could be built in many different ways. A light client could be classified by its API functionalities. A light client could use different networking layers as its input data sources.
Any proposed light client implementation needs to define both of these components at a minimum. The supported APIs is the output of the client, and the networking environment is its input data.
Here, I am proposing a light client implementation that goes a step further than the minimum light client described in the altair consensus-spec. The proposed client aims to allow queries into the beacon state. The input data sources uses p2p networks that follow the specifications of portal-network.
Supported APIs
Here is a representative subset of APIs the client intends to support.
/eth/v1/beacon/headers
/eth/v1/beacon/states/{state_id}/root
/eth/v1/beacon/states/{state_id}/finality_checkpoints
/eth/v1/beacon/states/{state_id}/validators
/eth/v1/beacon/states/{state_id}/validators/{validator_id}
/eth/v1/beacon/states/{state_id}/validator_balances
/eth/v1/beacon/states/{state_id}/committees
/eth/v1/beacon/states/{state_id}/sync_committees
P2P Portal Networks
The input data could be put into two categories. The first category is the information required to move the block headers forward. The second category is the information required to build out part of the beacon state.
Note: We should write these networks as part of the portal-network specs.
Updating Headers
- gossip network:
bc-light-client-snapshot- Data type:
LightClientSnapshot
- Data type:
- gossip network:
bc-light-client-update- Data type:
LightClientUpdate
- Data type:
Beacon State
- dht network:
beacon-statecontent_id: sha256(root | leaves_general_indices)content: root, leaves_general_indices, leaves, proof