nimbus-eth2/beacon_chain/spec/eth2_apis/rpc_validator_calls.nim

import
  options,
  rpc_types

# calls that return a bool are actually without a return type in the main REST API
# spec but nim-json-rpc requires that all RPC calls have a return type.

proc get_v1_validator_block(slot: Slot, graffiti: GraffitiBytes, randao_reveal: ValidatorSig): phase0.BeaconBlock

proc get_v1_validator_attestation_data(slot: Slot, committee_index: CommitteeIndex): AttestationData

proc get_v1_validator_aggregate_attestation(slot: Slot, attestation_data_root: Eth2Digest): Attestation

proc post_v1_validator_aggregate_and_proofs(payload: SignedAggregateAndProof): bool

# TODO epoch is part of the REST path
proc get_v1_validator_duties_attester(epoch: Epoch, public_keys: seq[ValidatorPubKey]): seq[RpcAttesterDuties]

# TODO epoch is part of the REST path
proc get_v1_validator_duties_proposer(epoch: Epoch): seq[RpcValidatorDuties]

proc post_v1_validator_beacon_committee_subscriptions(committee_index: CommitteeIndex,
                                                      slot: Slot,
                                                      aggregator: bool,
                                                      validator_pubkey: ValidatorPubKey,
                                                      slot_signature: ValidatorSig): bool
Initial implementation of a JSON-RPC service 2020-03-17 00:28:54 +02:00			`import`
			`options,`
REST API client, JSON-RPC cleanups (#2756) This refactoring puts the JSON-RPC and REST APIs on more equal footing by renaming and moving things around, creating a separation between client and server, and documenting what they are - the aim is to have a simple-to-use base to start from when developing API clients, as well as make it easier to navigate the code when looking for the legacy JSON-RPC interface vs the new REST API. * move REST client, serialization and supporting types to spec/eth2_apis * REST stuff now starts with `rest_`, JSON-RPC stuff starts with `rpc_`, more or less * simplify imports such that there's a simple module to import for both server and client * map REST type and proc names to yaml spec more closely - in particular, reuse operation and type names in `rest_types` to make comparisons against spec more easy * cleaner separation between client and server modules - modules common between server and client such as `rest_types` and serialization move to the spec folder - this allows the client to be built with less knowledge about server internals 2021-08-03 17:17:11 +02:00			`rpc_types`
Initial implementation of a JSON-RPC service 2020-03-17 00:28:54 +02:00
- updated the validator shell script after the keystore changes - better logging & retrying requests on the VC side if the BN fails for some reason - VC now fetches the attestation duties 1 epoch in advance - in the future it will tell the BN to subscribe to the appropriate attestation topics in advance based on that info - a bunch of other code cleanup & fixes such as better naming for consoles when using multitail, etc. reviewed in PR #1184 - proper review of the API & VC are pending 2020-06-19 12:21:17 +03:00			`# calls that return a bool are actually without a return type in the main REST API`
			`# spec but nim-json-rpc requires that all RPC calls have a return type.`
more work on the BN/VC split - fixed comments from the last review - getting more data VIA RPC, moved some code back into the BN only - attestation duties being requested as well 2020-05-27 20:06:28 +03:00
rework spec imports (#2779) The spec imports are a mess to work with, so this branch cleans them up a bit to ensure that we avoid generic sandwitches and that importing stuff generally becomes easier. * reexport crypto/digest/presets because these are part of the public symbol set of the rest of the spec types * don't export `merge` types from `base` - this causes circular deps * fix circular deps in `ssz/spec_types` - this is the first step in disentangling ssz from spec * be explicit about phase0 vs altair - longer term, `altair` will become the "natural" type set, then merge and so on, so no point in giving `phase0` special preferential treatment 2021-08-12 15:08:20 +02:00			`proc get_v1_validator_block(slot: Slot, graffiti: GraffitiBytes, randao_reveal: ValidatorSig): phase0.BeaconBlock`
- extracted the commands to run a VC into a separate run_validator.sh script - each BN gets half of its previous validators as inProcess and the other half goes to the respective VC for that BN - using separate data dirs where the keys are copied - also removed a few command line options which are no longer necessary - block proposals originating from a VC are propagated from one BN to the rest properly - other cleanup & moving code back to since it is no longer used elsewhere 2020-06-05 12:57:40 +03:00
Documentation for Validators API. (#2147) * Recover proper validator API call and remove incorrect one. Add more examples to API documentation. 2020-12-07 14:51:14 +02:00			`proc get_v1_validator_attestation_data(slot: Slot, committee_index: CommitteeIndex): AttestationData`
Initial implementation of a JSON-RPC service 2020-03-17 00:28:54 +02:00
initial implementation of attestation aggregation for the validator API 2020-09-14 14:13:30 +03:00			`proc get_v1_validator_aggregate_attestation(slot: Slot, attestation_data_root: Eth2Digest): Attestation`
Initial implementation of a JSON-RPC service 2020-03-17 00:28:54 +02:00
initial implementation of attestation aggregation for the validator API 2020-09-14 14:13:30 +03:00			`proc post_v1_validator_aggregate_and_proofs(payload: SignedAggregateAndProof): bool`
Initial implementation of a JSON-RPC service 2020-03-17 00:28:54 +02:00
- updated the validator shell script after the keystore changes - better logging & retrying requests on the VC side if the BN fails for some reason - VC now fetches the attestation duties 1 epoch in advance - in the future it will tell the BN to subscribe to the appropriate attestation topics in advance based on that info - a bunch of other code cleanup & fixes such as better naming for consoles when using multitail, etc. reviewed in PR #1184 - proper review of the API & VC are pending 2020-06-19 12:21:17 +03:00			`# TODO epoch is part of the REST path`
REST API client, JSON-RPC cleanups (#2756) This refactoring puts the JSON-RPC and REST APIs on more equal footing by renaming and moving things around, creating a separation between client and server, and documenting what they are - the aim is to have a simple-to-use base to start from when developing API clients, as well as make it easier to navigate the code when looking for the legacy JSON-RPC interface vs the new REST API. * move REST client, serialization and supporting types to spec/eth2_apis * REST stuff now starts with `rest_`, JSON-RPC stuff starts with `rpc_`, more or less * simplify imports such that there's a simple module to import for both server and client * map REST type and proc names to yaml spec more closely - in particular, reuse operation and type names in `rest_types` to make comparisons against spec more easy * cleaner separation between client and server modules - modules common between server and client such as `rest_types` and serialization move to the spec folder - this allows the client to be built with less knowledge about server internals 2021-08-03 17:17:11 +02:00			`proc get_v1_validator_duties_attester(epoch: Epoch, public_keys: seq[ValidatorPubKey]): seq[RpcAttesterDuties]`
Initial implementation of a JSON-RPC service 2020-03-17 00:28:54 +02:00
- updated the validator shell script after the keystore changes - better logging & retrying requests on the VC side if the BN fails for some reason - VC now fetches the attestation duties 1 epoch in advance - in the future it will tell the BN to subscribe to the appropriate attestation topics in advance based on that info - a bunch of other code cleanup & fixes such as better naming for consoles when using multitail, etc. reviewed in PR #1184 - proper review of the API & VC are pending 2020-06-19 12:21:17 +03:00			`# TODO epoch is part of the REST path`
REST API client, JSON-RPC cleanups (#2756) This refactoring puts the JSON-RPC and REST APIs on more equal footing by renaming and moving things around, creating a separation between client and server, and documenting what they are - the aim is to have a simple-to-use base to start from when developing API clients, as well as make it easier to navigate the code when looking for the legacy JSON-RPC interface vs the new REST API. * move REST client, serialization and supporting types to spec/eth2_apis * REST stuff now starts with `rest_`, JSON-RPC stuff starts with `rpc_`, more or less * simplify imports such that there's a simple module to import for both server and client * map REST type and proc names to yaml spec more closely - in particular, reuse operation and type names in `rest_types` to make comparisons against spec more easy * cleaner separation between client and server modules - modules common between server and client such as `rest_types` and serialization move to the spec folder - this allows the client to be built with less knowledge about server internals 2021-08-03 17:17:11 +02:00			`proc get_v1_validator_duties_proposer(epoch: Epoch): seq[RpcValidatorDuties]`
first batch of work towards the VC/BN split: - we have a new binary which connects via RPC to the respective BN and has an internal clock - waking it up on every slot - the BN has a new option called --external-validators and currently in order to have the VC binaries to run we need to pass EXTERNAL_VALIDATORS=yes to make - factored some code out of beacon_node.nim for easier reuse in validator_api.nim and validator_client.nim - the VC loads its associated private keys from the datadir for its BN - most of the validator API calls have been implemented as a stub. - the VC polls its BN at the start of each epoch - getting a list of all active validators for the current epoch - and then continues to request blocks and sign them with its appropriate validators when necessary 2020-05-22 20:04:52 +03:00
- updated the validator shell script after the keystore changes - better logging & retrying requests on the VC side if the BN fails for some reason - VC now fetches the attestation duties 1 epoch in advance - in the future it will tell the BN to subscribe to the appropriate attestation topics in advance based on that info - a bunch of other code cleanup & fixes such as better naming for consoles when using multitail, etc. reviewed in PR #1184 - proper review of the API & VC are pending 2020-06-19 12:21:17 +03:00			`proc post_v1_validator_beacon_committee_subscriptions(committee_index: CommitteeIndex,`
			`slot: Slot,`
			`aggregator: bool,`
			`validator_pubkey: ValidatorPubKey,`
			`slot_signature: ValidatorSig): bool`