mirror of
https://github.com/sigp/lighthouse.git
synced 2026-03-15 19:02:42 +00:00
e961ff60b4
## Issue Addressed Implements the standard key manager API from https://ethereum.github.io/keymanager-APIs/, formerly https://github.com/ethereum/beacon-APIs/pull/151 Related to https://github.com/sigp/lighthouse/issues/2557 ## Proposed Changes - [x] Add all of the new endpoints from the standard API: GET, POST and DELETE. - [x] Add a `validators.enabled` column to the slashing protection database to support atomic disable + export. - [x] Add tests for all the common sequential accesses of the API - [x] Add tests for interactions with remote signer validators - [x] Add end-to-end tests for migration of validators from one VC to another - [x] Implement the authentication scheme from the standard (token bearer auth) ## Additional Info The `enabled` column in the validators SQL database is necessary to prevent a race condition when exporting slashing protection data. Without the slashing protection database having a way of knowing that a key has been disabled, a concurrent request to sign a message could insert a new record into the database. The `delete_concurrent_with_signing` test exercises this code path, and was indeed failing before the `enabled` column was added. The validator client authentication has been modified from basic auth to bearer auth, with basic auth preserved for backwards compatibility.
45 lines
2.1 KiB
Markdown
45 lines
2.1 KiB
Markdown
# Validator Client API
|
|
|
|
Lighthouse implements a JSON HTTP API for the validator client which enables programmatic management
|
|
of validators and keys.
|
|
|
|
The API includes all of the endpoints from the [standard keymanager
|
|
API](https://ethereum.github.io/keymanager-APIs/) that is implemented by other clients and remote
|
|
signers. It also includes some Lighthouse-specific endpoints which are described in
|
|
[Endpoints](./api-vc-endpoints.md).
|
|
|
|
> Note: All requests to the HTTP server must supply an
|
|
> [`Authorization`](./api-vc-auth-header.md) header. All responses contain a
|
|
> [`Signature`](./api-vc-sig-header.md) header for optional verification.
|
|
|
|
## Starting the server
|
|
|
|
A Lighthouse validator client can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `127.0.0.1:5062`.
|
|
|
|
The following CLI flags control the HTTP server:
|
|
|
|
- `--http`: enable the HTTP server (required even if the following flags are
|
|
provided).
|
|
- `--http-address`: specify the listen address of the server. It is almost always unsafe to use a non-default HTTP listen address. Use with caution. See the **Security** section below for more information.
|
|
- `--http-port`: specify the listen port of the server.
|
|
- `--http-allow-origin`: specify the value of the `Access-Control-Allow-Origin`
|
|
header. The default is to not supply a header.
|
|
|
|
## Security
|
|
|
|
The validator client HTTP server is **not encrypted** (i.e., it is **not HTTPS**). For
|
|
this reason, it will listen by default on `127.0.0.1`.
|
|
|
|
It is unsafe to expose the validator client to the public Internet without
|
|
additional transport layer security (e.g., HTTPS via nginx, SSH tunnels, etc.).
|
|
|
|
For custom setups, such as certain Docker configurations, a custom HTTP listen address can be used by passing the `--http-address` and `--unencrypted-http-transport` flags. The `--unencrypted-http-transport` flag is a safety flag which is required to ensure the user is aware of the potential risks when using a non-default listen address.
|
|
|
|
### CLI Example
|
|
|
|
Start the validator client with the HTTP server listening on [http://localhost:5062](http://localhost:5062):
|
|
|
|
```bash
|
|
lighthouse vc --http
|
|
```
|