Skip to content

Commit

Permalink
Merge branch 'master' of https://github.com/ethereum/beacon-APIs into…
Browse files Browse the repository at this point in the history
… add-blob-signing-endpoints
  • Loading branch information
realbigsean committed May 12, 2023
2 parents 2627727 + 6ed3820 commit 1b08ee4
Show file tree
Hide file tree
Showing 41 changed files with 316 additions and 110 deletions.
41 changes: 10 additions & 31 deletions CHANGES.md

Large diffs are not rendered by default.

13 changes: 6 additions & 7 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,22 +8,21 @@ API browser: [https://ethereum.github.io/beacon-APIs/](https://ethereum.github.i

## Outline

This document outlines an application programming interface (API) which is exposed by a beacon node implementation
which aims to facilitate [Phase 0](https://github.com/ethereum/consensus-specs#phase-0) of the Ethereum consensus layer.
This document outlines an application programming interface (API) which is exposed by a beacon node implementation of the Ethereum [consensus layer specifications](https://github.com/ethereum/consensus-specs).

The API is a REST interface, accessed via HTTP. The API should not, unless protected by additional security layers, be exposed to the public Internet as the API includes multiple endpoints which could open your node to denial-of-service (DoS) attacks through endpoints triggering heavy processing.
Currently, the only supported return data type is JSON.

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

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

The goal of this specification is to promote interoperability between various beacon node implementations.

## Render
## Render
To render spec in browser you will need any http server to load `index.html` file
in root of the repo.

Expand All @@ -49,10 +48,10 @@ And api spec will render on [http://localhost:8000](http://localhost:8000).

Local changes will be observable if "dev" is selected in the "Select a definition" drop-down in the web UI.

Users may need to tick the "Disable Cache" box in their browser's developer tools to see changes after modifying the source.
Users may need to tick the "Disable Cache" box in their browser's developer tools to see changes after modifying the source.

## Contributing
Api spec is checked for lint errors before merge.
Api spec is checked for lint errors before merge.

To run lint locally, install linter with
```
Expand All @@ -64,7 +63,7 @@ yarn global add @redocly/cli
```
and run lint with
```
redocly lint beacon-node-oapi.yaml
redocly lint beacon-node-oapi.yaml
```

## Implementations
Expand Down
80 changes: 80 additions & 0 deletions apis/beacon/blocks/blinded_blocks.v2.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
post:
tags:
- Beacon
- ValidatorRequiredApi
summary: "Publish a signed block."
operationId: "publishBlindedBlockV2"
description: |
Instructs the beacon node to use the components of the `SignedBlindedBeaconBlock` to construct and publish a
`SignedBeaconBlock` by swapping out the `transactions_root` for the corresponding full list of `transactions`.
The beacon node should broadcast a newly constructed `SignedBeaconBlock` to the beacon network,
to be included in the beacon chain. The beacon node is not required to validate the signed
`BeaconBlock`, and a successful response (20X) only indicates that the broadcast has been
successful. The beacon node is expected to integrate the new block into its state, and
therefore validate the block internally, however blocks which fail the validation are still
broadcast but a different status code is returned (202). Pre-Bellatrix, this endpoint will accept
a `SignedBeaconBlock`. The broadcast behaviour may be adjusted via the `broadcast_validation`
query parameter.
parameters:
- name: broadcast_validation
in: query
required: false
description: |
Level of validation that must be applied to a block before it is broadcast.
Possible values:
- **`gossip`** (default): lightweight gossip checks only
- **`consensus`**: full consensus checks, including validation of all signatures and
blocks fields _except_ for the execution payload transactions.
- **`consensus_and_equivocation`**: the same as `consensus`, with an extra equivocation
check immediately before the block is broadcast. If the block is found to be an
equivocation it fails validation.
If the block fails the requested level of a validation a 400 status MUST be returned
immediately and the block MUST NOT be broadcast to the network.
If validation succeeds, the block must still be fully verified before it is
incorporated into the state and a 20x status is returned to the caller.
schema:
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/BroadcastValidation'
- in: header
schema:
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/ConsensusVersion'
required: false
name: Eth-Consensus-Version
description: "Version of the block being submitted, if using SSZ encoding."
requestBody:
description: "The `SignedBlindedBeaconBlock` object composed of `BlindedBeaconBlock` object (produced by beacon node) and validator signature."
required: true
content:
application/json:
schema:
oneOf:
- $ref: '../../../beacon-node-oapi.yaml#/components/schemas/SignedBeaconBlock'
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Altair.SignedBeaconBlock"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Bellatrix.SignedBlindedBeaconBlock"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Capella.SignedBlindedBeaconBlock"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Deneb.SignedBlindedBeaconBlock"
application/octet-stream:
schema:
description: "SSZ serialized block bytes. Use content type header to indicate that SSZ data is contained in the request body."
responses:
"200":
description: "The block was validated successfully and has been broadcast. It has also been integrated into the beacon node's database."
"202":
description: "The block failed validation, but was successfully broadcast anyway. It was not integrated into the beacon node's database."
"400":
description: "The `SignedBlindedBeaconBlock` object is invalid"
content:
application/json:
schema:
$ref: "../../../beacon-node-oapi.yaml#/components/schemas/ErrorMessage"
example:
code: 400
message: "Invalid block: missing signature"
"415":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/UnsupportedMediaType'
"500":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/InternalError'
"503":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/CurrentlySyncing'
79 changes: 79 additions & 0 deletions apis/beacon/blocks/blocks.v2.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
post:
tags:
- Beacon
- ValidatorRequiredApi
summary: "Publish a signed block."
operationId: "publishBlockV2"
description: |
Instructs the beacon node to broadcast a newly signed beacon block to the beacon network,
to be included in the beacon chain. A success response (20x) indicates that the block
passed gossip validation and was successfully broadcast onto the network.
The beacon node is also expected to integrate the block into the state, but may broadcast it
before doing so, so as to aid timely delivery of the block. Should the block fail full
validation, a separate success response code (202) is used to indicate that the block was
successfully broadcast but failed integration. The broadcast behaviour may be adjusted via the
`broadcast_validation` query parameter.
parameters:
- name: broadcast_validation
in: query
required: false
description: |
Level of validation that must be applied to a block before it is broadcast.
Possible values:
- **`gossip`** (default): lightweight gossip checks only
- **`consensus`**: full consensus checks, including validation of all signatures and
blocks fields _except_ for the execution payload transactions.
- **`consensus_and_equivocation`**: the same as `consensus`, with an extra equivocation
check immediately before the block is broadcast. If the block is found to be an
equivocation it fails validation.
If the block fails the requested level of a validation a 400 status MUST be returned
immediately and the block MUST NOT be broadcast to the network.
If validation succeeds, the block must still be fully verified before it is
incorporated into the state and a 20x status is returned to the caller.
schema:
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/BroadcastValidation'
- in: header
schema:
$ref: '../../../beacon-node-oapi.yaml#/components/schemas/ConsensusVersion'
required: false
name: Eth-Consensus-Version
description: "Version of the block being submitted, if using SSZ encoding."
requestBody:
description: "The `SignedBeaconBlock` object composed of `BeaconBlock` object (produced by beacon node) and validator signature."
required: true
content:
application/json:
schema:
oneOf:
- $ref: '../../../beacon-node-oapi.yaml#/components/schemas/SignedBeaconBlock'
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Altair.SignedBeaconBlock"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Bellatrix.SignedBeaconBlock"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Capella.SignedBeaconBlock"
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/Deneb.SignedBeaconBlock"
application/octet-stream:
schema:
description: "SSZ serialized block bytes. Use content type header to indicate that SSZ data is contained in the request body."
responses:
"200":
description: "The block was validated successfully and has been broadcast. It has also been integrated into the beacon node's database."
"202":
description: "The block could not be integrated into the beacon node's database as it failed validation, but was successfully broadcast."
"400":
description: "The `SignedBeaconBlock` object is invalid and could not be broadcast"
content:
application/json:
schema:
allOf:
- $ref: "../../../beacon-node-oapi.yaml#/components/schemas/ErrorMessage"
- example:
code: 400
message: "Invalid block: missing signature"
"415":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/UnsupportedMediaType'
"500":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/InternalError'
"503":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/CurrentlySyncing'
4 changes: 2 additions & 2 deletions apis/beacon/light_client/bootstrap.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,10 @@ get:
operationId: getLightClientBootstrap
summary: Get `LightClientBootstrap` structure for a requested block root
description: |
Requests the [`LightClientBootstrap`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/sync-protocol.md#lightclientbootstrap) structure corresponding to a given post-Altair beacon block root.
Requests the [`LightClientBootstrap`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/sync-protocol.md#lightclientbootstrap) structure corresponding to a given post-Altair beacon block root.
Depending on the `Accept` header it can be returned either as JSON or SSZ-serialized bytes.
Servers SHOULD provide results as defined in [`create_light_client_bootstrap`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/full-node.md#create_light_client_bootstrap). To fulfill a request, the requested block's post state needs to be known.
Servers SHOULD provide results as defined in [`create_light_client_bootstrap`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/full-node.md#create_light_client_bootstrap). To fulfill a request, the requested block's post state needs to be known.
tags:
- Beacon
parameters:
Expand Down
4 changes: 2 additions & 2 deletions apis/beacon/light_client/finality_update.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,10 @@ get:
operationId: getLightClientFinalityUpdate
summary: Get the latest known `LightClientFinalityUpdate`
description: |
Requests the latest [`LightClientFinalityUpdate`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/sync-protocol.md#lightclientfinalityupdate) known by the server.
Requests the latest [`LightClientFinalityUpdate`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/sync-protocol.md#lightclientfinalityupdate) known by the server.
Depending on the `Accept` header it can be returned either as JSON or SSZ-serialized bytes.
Servers SHOULD provide results as defined in [`create_light_client_finality_update`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/full-node.md#create_light_client_finality_update).
Servers SHOULD provide results as defined in [`create_light_client_finality_update`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/full-node.md#create_light_client_finality_update).
tags:
- Beacon
responses:
Expand Down
4 changes: 2 additions & 2 deletions apis/beacon/light_client/optimistic_update.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,10 @@ get:
operationId: getLightClientOptimisticUpdate
summary: Get the latest known `LightClientOptimisticUpdate`
description: |
Requests the latest [`LightClientOptimisticUpdate`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/sync-protocol.md#lightclientoptimisticupdate) known by the server.
Requests the latest [`LightClientOptimisticUpdate`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/sync-protocol.md#lightclientoptimisticupdate) known by the server.
Depending on the `Accept` header it can be returned either as JSON or SSZ-serialized bytes.
Servers SHOULD provide results as defined in [`create_light_client_optimistic_update`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/full-node.md#create_light_client_optimistic_update).
Servers SHOULD provide results as defined in [`create_light_client_optimistic_update`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/full-node.md#create_light_client_optimistic_update).
tags:
- Beacon
responses:
Expand Down
4 changes: 2 additions & 2 deletions apis/beacon/light_client/updates.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,10 @@ get:
operationId: getLightClientUpdatesByRange
summary: Get `LightClientUpdate` instances in a requested sync committee period range
description: |
Requests the [`LightClientUpdate`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/sync-protocol.md#lightclientupdate) instances in the sync committee period range `[start_period, start_period + count)`, leading up to the current head sync committee period as selected by fork choice.
Requests the [`LightClientUpdate`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/sync-protocol.md#lightclientupdate) instances in the sync committee period range `[start_period, start_period + count)`, leading up to the current head sync committee period as selected by fork choice.
Depending on the `Accept` header they can be returned either as JSON or SSZ-serialized bytes.
Servers SHOULD provide results as defined in [`create_light_client_update`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/full-node.md#create_light_client_update). They MUST respond with at least the earliest known result within the requested range, and MUST send results in consecutive order (by period). The response MUST NOT contain more than [`min(MAX_REQUEST_LIGHT_CLIENT_UPDATES, count)`](https://github.com/ethereum/consensus-specs/blob/v1.3.0-rc.2/specs/altair/light-client/p2p-interface.md#configuration) results.
Servers SHOULD provide results as defined in [`create_light_client_update`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/full-node.md#create_light_client_update). They MUST respond with at least the earliest known result within the requested range, and MUST send results in consecutive order (by period). The response MUST NOT contain more than [`min(MAX_REQUEST_LIGHT_CLIENT_UPDATES, count)`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/light-client/p2p-interface.md#configuration) results.
tags:
- Beacon
parameters:
Expand Down
3 changes: 1 addition & 2 deletions apis/beacon/states/fork.yaml
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
get:
operationId: "getStateFork"
summary: "Get Fork object for requested state"
description: "Returns [Fork](https://github.com/ethereum/consensus-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#fork) object for state with given 'stateId'."
description: "Returns [Fork](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#fork) object for state with given 'stateId'."
tags:
- Beacon
- ValidatorRequiredApi
Expand Down Expand Up @@ -45,4 +45,3 @@ get:
message: "State not found"
"500":
$ref: '../../../beacon-node-oapi.yaml#/components/responses/InternalError'

6 changes: 3 additions & 3 deletions apis/config/spec.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@ get:
summary: Get spec params.
description: |
Retrieve specification configuration used on this node. The configuration should include:
- Constants for all hard forks known by the beacon node, for example the [phase 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#constants) and [altair](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md#constants) values
- Presets for all hard forks supplied to the beacon node, for example the [phase 0](https://github.com/ethereum/consensus-specs/blob/dev/presets/mainnet/phase0.yaml) and [altair](https://github.com/ethereum/consensus-specs/blob/dev/presets/mainnet/altair.yaml) values
- Configuration for the beacon node, for example the [mainnet](https://github.com/ethereum/consensus-specs/blob/dev/configs/mainnet.yaml) values
- Constants for all hard forks known by the beacon node, for example the [phase 0](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#constants) and [altair](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/altair/beacon-chain.md#constants) values
- Presets for all hard forks supplied to the beacon node, for example the [phase 0](https://github.com/ethereum/consensus-specs/blob/v1.3.0/presets/mainnet/phase0.yaml) and [altair](https://github.com/ethereum/consensus-specs/blob/v1.3.0/presets/mainnet/altair.yaml) values
- Configuration for the beacon node, for example the [mainnet](https://github.com/ethereum/consensus-specs/blob/v1.3.0/configs/mainnet.yaml) values
Values are returned with following format:
- any value starting with 0x in the spec is returned as a hex string
Expand Down
2 changes: 2 additions & 0 deletions apis/validator/sync_committee_selections.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -37,5 +37,7 @@ post:
$ref: '../../beacon-node-oapi.yaml#/components/responses/InvalidRequest'
"500":
$ref: '../../beacon-node-oapi.yaml#/components/responses/InternalError'
"501":
$ref: '../../beacon-node-oapi.yaml#/components/responses/NotImplementedError'
"503":
$ref: '../../beacon-node-oapi.yaml#/components/responses/CurrentlySyncing'
Loading

0 comments on commit 1b08ee4

Please sign in to comment.