Skip to content
Permalink
Browse files

Merge pull request #1069 from sigp/bn-vc-api-rfc

Beacon Node API for Validator
  • Loading branch information...
djrtwo committed May 28, 2019
2 parents a994a5d + c32328f commit 4183d8440bc4e61e7bbc1766950905ab131df66b
Showing with 670 additions and 0 deletions.
  1. +1 −0 README.md
  2. +28 −0 specs/validator/0_beacon-node-validator-api.md
  3. +641 −0 specs/validator/beacon_node_oapi.yaml
@@ -28,6 +28,7 @@ Core specifications for Eth 2.0 client validation can be found in [specs/core](s
* [General test format](specs/test_formats/README.md)
* [Merkle proof formats](specs/light_client/merkle_proofs.md)
* [Light client syncing protocol](specs/light_client/sync_protocol.md)
* [Beacon node API for validator](specs/validator/0_beacon-node-validator-api.md)


## Design goals
@@ -0,0 +1,28 @@
# Ethereum 2.0 Phase 0 -- Beacon Node API for Validator

__NOTICE__: This document is a work-in-progress for researchers and implementers. This is an accompanying document to [Ethereum 2.0 Phase 0 -- Honest Validator](0_beacon-chain-validator.md) that describes an API exposed by the beacon node, which enables the validator client to participate in the Ethereum 2.0 protocol.

## Outline

This document outlines a minimal application programming interface (API) which is exposed by a beacon node for use by a validator client implementation which aims to facilitate [_phase 0_](../../README.md#phase-0) of Ethereum 2.0.

The API is a REST interface, accessed via HTTP, designed for use as a local communications protocol between binaries. The only supported return data type is currently JSON.

### Background
The beacon node maintains the state of the beacon chain by communicating with other beacon nodes in the Ethereum Serenity network. Conceptually, it does not maintain keypairs that participate with the beacon chain.

The validator client is a conceptually separate entity which utilizes private keys to perform validator related tasks on the beacon chain, which we call validator "duties". These duties include the production of beacon blocks and signing of attestations.

Since it is recommended to separate these concerns in the client implementations, we must clearly define the communication between them.

The goal of this specification is to promote interoperability between beacon nodes and validator clients derived from different projects and to encourage innovation in validator client implementations, independently from beacon node development. For example, the validator client from Lighthouse could communicate with a running instance of the beacon node from Prysm, or a staking pool might create a decentrally managed validator client which utilises the same API.

This specification is derived from a proposal and discussion on Issues [#1011](https://github.com/ethereum/eth2.0-specs/issues/1011) and [#1012](https://github.com/ethereum/eth2.0-specs/issues/1012)


## Specification

The API specification has been written in [OpenAPI 3.0](https://swagger.io/docs/specification/about/) and is provided in the [beacon_node_oapi.yaml](beacon_node_oapi.yaml) file alongside this document.

For convenience, this specification has been uploaded to [SwaggerHub](https://swagger.io/tools/swaggerhub/) at the following URL:
[https://app.swaggerhub.com/apis/spble/beacon_node_api_for_validator](https://app.swaggerhub.com/apis/spble/beacon_node_api_for_validator)

0 comments on commit 4183d84

Please sign in to comment.
You can’t perform that action at this time.