API between the BeaconChain and Validators

[GregTheGreek]

I don't have access to the document that was made by @spble during the Sydney client meetup, but we were discussing a few topics related to the API:

1. The Serialization (JSON, Proto Buffers, etc...)
2. The methods
3. Data availability

Recap off the top of my head

1. During the discussion everyone seemed to be leaning towards not over engineering the system, and use RPC in Phase 0 (potentially change in the future Phases). This should be fine and clients should be encouraged to use other options for benchmarking reasons, as long as your client is built with an abstraction around the serialization it really shouldn't matter what you use.

2. We should flesh out a subset of core methods, for Phase0, keep it lean and iterate from there. The core methods should be labeled as such within a clients API and any additional methods an implementation team wishes to expose should be considered extended from the core. The core methods should allow for ANY client and ANY beacon node to interact with each-other, that being said, the handshake between the two clients should acknowledge their creator so your client can operate accordingly. That way the corresponding API's can be used and we can reduced errors. This will help with a decentralized infura so that a multitude of clients and validators can run without any potential errors.

3. I can't recall, but there were some serious discussions around what is useful for storage on the validator client.

cc: @jrhea @dangerousfood @wemeetagain @Mikerah

[protolambda]

@spble Can you link your notes?

[djrtwo]

I can't recall, but there were some serious discussions around what is useful for storage on the validator client.

I would say two things are crucial -- (1) data private to the validator and (2) data required to assess if a future message is safe to sign.

Private data includes -- public/private key and withdrawal key.

For phase 0, safe signing data includes signed beacon blocks and attestations. This data can be pruned to just signed beacon block epochs and attestation source/target epochs.

For phase 1, the validator will need to remember shard blocks signed/attested and shard block data that the validator signed a custody bit for. This data will need to be remembered through the custody challenge period. This amounts to a validator client storing a custody challenge period worth of shard chain data at all times (this data is split across many shards). Like remembering signed attestation epochs, remembering this data is crucial to the responsibilities of a validator and not doing so can result in loss of funds. By keeping this data in the validator client, the node can cleanly and safely sync and drop shards without the validator being concerned about loss of attested to data.

[spble]

Hey y'all,
I thought it would be best to break it out into separate issues, as we planned during Sydney chats.
As such:

1. BeaconNode <--> ValidatorClient API - Protocol #1012
2. BeaconNode <--> ValidatorClient API - Messages #1011
3. I think the data availability is really up to the individual validator client implementation.
   I imagine that at a minimum, it would need to persist:
   • BeaconBlock: To avoid slashing conditions
   • IndexedAnnotation: To avoid signing conflicting attestations
   • current_version: To make sure we are connected to the correct version of a BeaconNode, and if the BeaconNode does change forks, then the validator client agrees with this change. This is proposed in the response to get_duties in BeaconNode <--> ValidatorClient API - Messages #1011.

[GregTheGreek]

Closing in favour of #1011 & #1012