status-im
/
nimbus-eth2
mirror of https://github.com/status-im/nimbus-eth2.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
nimbus-eth2/beacon_chain/spec/eth2_apis/rpc_validator_calls.nim

27 lines
1.2 KiB
Nim
Raw Normal View History

Initial implementation of a JSON-RPC service
2020-03-16 22:28:54 +00: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 15:17:11 +00:00
rpc_types
Initial implementation of a JSON-RPC service
2020-03-16 22:28:54 +00: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 09:21:17 +00: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 17:06:28 +00: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 13:08:20 +00: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 09:57:40 +00:00
Documentation for Validators API. (#2147) * Recover proper validator API call and remove incorrect one. Add more examples to API documentation.
2020-12-07 12:51:14 +00:00
proc get_v1_validator_attestation_data(slot: Slot, committee_index: CommitteeIndex): AttestationData
Initial implementation of a JSON-RPC service
2020-03-16 22:28:54 +00:00
initial implementation of attestation aggregation for the validator API
2020-09-14 11:13:30 +00:00
proc get_v1_validator_aggregate_attestation(slot: Slot, attestation_data_root: Eth2Digest): Attestation
Initial implementation of a JSON-RPC service
2020-03-16 22:28:54 +00:00
initial implementation of attestation aggregation for the validator API
2020-09-14 11:13:30 +00:00
proc post_v1_validator_aggregate_and_proofs(payload: SignedAggregateAndProof): bool
Initial implementation of a JSON-RPC service
2020-03-16 22:28:54 +00: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 09:21:17 +00: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 15:17:11 +00:00
proc get_v1_validator_duties_attester(epoch: Epoch, public_keys: seq[ValidatorPubKey]): seq[RpcAttesterDuties]
Initial implementation of a JSON-RPC service
2020-03-16 22:28:54 +00: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 09:21:17 +00: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 15:17:11 +00: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 17:04:52 +00: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 09:21:17 +00:00
proc post_v1_validator_beacon_committee_subscriptions(committee_index: CommitteeIndex,
slot: Slot,
aggregator: bool,
validator_pubkey: ValidatorPubKey,
slot_signature: ValidatorSig): bool