mirror of
https://github.com/sigp/lighthouse.git
synced 2026-04-18 13:28:33 +00:00
Merge branch 'v0.3.0-staging' into v3-master
This commit is contained in:
Paul Hauner
@@ -1,11 +1,11 @@
|
||||
# Summary
|
||||
|
||||
* [Introduction](./intro.md)
|
||||
* [Become a Validator](./become-a-validator.md)
|
||||
* [Using Docker](./become-a-validator-docker.md)
|
||||
* [Building from Source](./become-a-validator-source.md)
|
||||
* [Become a Testnet Validator](./testnet-validator.md)
|
||||
* [Installation](./installation.md)
|
||||
* [Pre-Built Binaries](./installation-binaries.md)
|
||||
* [Docker](./docker.md)
|
||||
* [Build from Source](./installation-source.md)
|
||||
* [Raspberry Pi 4](./pi.md)
|
||||
* [Cross-Compiling](./cross-compiling.md)
|
||||
* [Key Management](./key-management.md)
|
||||
@@ -14,20 +14,21 @@
|
||||
* [Key recovery](./key-recovery.md)
|
||||
* [Validator Management](./validator-management.md)
|
||||
* [Importing from the Eth2 Launchpad](./validator-import-launchpad.md)
|
||||
* [Local Testnets](./local-testnets.md)
|
||||
* [API](./api.md)
|
||||
* [HTTP (RESTful JSON)](./http.md)
|
||||
* [/node](./http/node.md)
|
||||
* [/beacon](./http/beacon.md)
|
||||
* [/validator](./http/validator.md)
|
||||
* [/consensus](./http/consensus.md)
|
||||
* [/network](./http/network.md)
|
||||
* [/spec](./http/spec.md)
|
||||
* [/advanced](./http/advanced.md)
|
||||
* [/lighthouse](./http/lighthouse.md)
|
||||
* [WebSocket](./websockets.md)
|
||||
* [APIs](./api.md)
|
||||
* [Beacon Node API](./api-bn.md)
|
||||
* [/lighthouse](./api-lighthouse.md)
|
||||
* [Validator Inclusion APIs](./validator-inclusion.md)
|
||||
* [Validator Client API](./api-vc.md)
|
||||
* [Endpoints](./api-vc-endpoints.md)
|
||||
* [Authorization Header](./api-vc-auth-header.md)
|
||||
* [Signature Header](./api-vc-sig-header.md)
|
||||
* [Prometheus Metrics](./advanced_metrics.md)
|
||||
* [Advanced Usage](./advanced.md)
|
||||
* [Database Configuration](./advanced_database.md)
|
||||
<<<<<<< HEAD
|
||||
=======
|
||||
* [Local Testnets](./local-testnets.md)
|
||||
>>>>>>> v0.3.0-staging
|
||||
* [Advanced Networking](./advanced_networking.md)
|
||||
* [Contributing](./contributing.md)
|
||||
* [Development Environment](./setup.md)
|
||||
|
||||
34
book/src/advanced_metrics.md
Normal file
34
book/src/advanced_metrics.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Prometheus Metrics
|
||||
|
||||
Lighthouse provides an extensive suite of metrics and monitoring in the
|
||||
[Prometheus](https://prometheus.io/docs/introduction/overview/) export format
|
||||
via a HTTP server built into Lighthouse.
|
||||
|
||||
These metrics are generally consumed by a Prometheus server and displayed via a
|
||||
Grafana dashboard. These components are available in a docker-compose format at
|
||||
[sigp/lighthouse-metrics](https://github.com/sigp/lighthouse-metrics).
|
||||
|
||||
## Beacon Node Metrics
|
||||
|
||||
By default, these metrics are disabled but can be enabled with the `--metrics`
|
||||
flag. Use the `--metrics-address`, `--metrics-port` and
|
||||
`--metrics-allow-origin` flags to customize the metrics server.
|
||||
|
||||
### Example
|
||||
|
||||
Start a beacon node with the metrics server enabled:
|
||||
|
||||
```bash
|
||||
lighthouse bn --metrics
|
||||
```
|
||||
|
||||
Check to ensure that the metrics are available on the default port:
|
||||
|
||||
```bash
|
||||
curl localhost:5054/metrics
|
||||
```
|
||||
|
||||
## Validator Client Metrics
|
||||
|
||||
The validator client does not *yet* expose metrics, however this functionality
|
||||
is expected to be implemented in late-September 2020.
|
||||
130
book/src/api-bn.md
Normal file
130
book/src/api-bn.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# Beacon Node API
|
||||
|
||||
Lighthouse implements the standard [Eth2 Beacon Node API
|
||||
specification][OpenAPI]. Please follow that link for a full description of each API endpoint.
|
||||
|
||||
> **Warning:** the standard API specification is still in flux and the Lighthouse implementation is partially incomplete. You can track the status of each endpoint at [#1434](https://github.com/sigp/lighthouse/issues/1434).
|
||||
|
||||
## Starting the server
|
||||
|
||||
A Lighthouse beacon node can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `127.0.0.1:5052`.
|
||||
|
||||
The following CLI flags control the HTTP server:
|
||||
|
||||
- `--http`: enable the HTTP server (required even if the following flags are
|
||||
provided).
|
||||
- `--http-port`: specify the listen port of the server.
|
||||
- `--http-address`: specify the listen address of the server.
|
||||
- `--http-allow-origin`: specify the value of the `Access-Control-Allow-Origin`
|
||||
header. The default is to not supply a header.
|
||||
|
||||
The schema of the API aligns with the standard Eth2 Beacon Node API as defined
|
||||
at [github.com/ethereum/eth2.0-APIs](https://github.com/ethereum/eth2.0-APIs).
|
||||
An interactive specification is available [here][OpenAPI].
|
||||
|
||||
### CLI Example
|
||||
|
||||
Start the beacon node with the HTTP server listening on [http://localhost:5052](http://localhost:5052):
|
||||
|
||||
```bash
|
||||
lighthouse bn --http
|
||||
```
|
||||
|
||||
## HTTP Request/Response Examples
|
||||
|
||||
This section contains some simple examples of using the HTTP API via `curl`.
|
||||
All endpoints are documented in the [Eth2 Beacon Node API
|
||||
specification][OpenAPI].
|
||||
|
||||
### View the head of the beacon chain
|
||||
|
||||
Returns the block header at the head of the canonical chain.
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/eth/v1/beacon/headers/head" -H "accept:
|
||||
application/json"
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"root": "0x4381454174fc28c7095077e959dcab407ae5717b5dca447e74c340c1b743d7b2",
|
||||
"canonical": true,
|
||||
"header": {
|
||||
"message": {
|
||||
"slot": 3199,
|
||||
"proposer_index": "19077",
|
||||
"parent_root": "0xf1934973041c5896d0d608e52847c3cd9a5f809c59c64e76f6020e3d7cd0c7cd",
|
||||
"state_root": "0xe8e468f9f5961655dde91968f66480868dab8d4147de9498111df2b7e4e6fe60",
|
||||
"body_root": "0x6f183abc6c4e97f832900b00d4e08d4373bfdc819055d76b0f4ff850f559b883"
|
||||
},
|
||||
"signature": "0x988064a2f9cf13fe3aae051a3d85f6a4bca5a8ff6196f2f504e32f1203b549d5f86a39c6509f7113678880701b1881b50925a0417c1c88a750c8da7cd302dda5aabae4b941e3104d0cf19f5043c4f22a7d75d0d50dad5dbdaf6991381dc159ab"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### View the status of a validator
|
||||
|
||||
Shows the status of validator at index `1` at the `head` state.
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H "accept: application/json"
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"index": "1",
|
||||
"balance": "63985937939",
|
||||
"status": "Active",
|
||||
"validator": {
|
||||
"pubkey": "0x873e73ee8b3e4fcf1d2fb0f1036ba996ac9910b5b348f6438b5f8ef50857d4da9075d0218a9d1b99a9eae235a39703e1",
|
||||
"withdrawal_credentials": "0x00b8cdcf79ba7e74300a07e9d8f8121dd0d8dd11dcfd6d3f2807c45b426ac968",
|
||||
"effective_balance": 32000000000,
|
||||
"slashed": false,
|
||||
"activation_eligibility_epoch": 0,
|
||||
"activation_epoch": 0,
|
||||
"exit_epoch": 18446744073709552000,
|
||||
"withdrawable_epoch": 18446744073709552000
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### HTTP API is unavailable or refusing connections
|
||||
|
||||
Ensure the `--http` flag has been supplied at the CLI.
|
||||
|
||||
You can quickly check that the HTTP endpoint is up using `curl`:
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/eth/v1/node/version" -H "accept: application/json"
|
||||
```
|
||||
|
||||
The beacon node should respond with its version:
|
||||
|
||||
```json
|
||||
{"data":{"version":"Lighthouse/v0.2.9-6f7b4768a/x86_64-linux"}}
|
||||
```
|
||||
|
||||
If this doesn't work, the server might not be started or there might be a
|
||||
network connection error.
|
||||
|
||||
### I cannot query my node from a web browser (e.g., Swagger)
|
||||
|
||||
By default, the API does not provide an `Access-Control-Allow-Origin` header,
|
||||
which causes browsers to reject responses with a CORS error.
|
||||
|
||||
The `--http-allow-origin` flag can be used to add a wild-card CORS header:
|
||||
|
||||
```bash
|
||||
lighthouse bn --http --http-allow-origin "*"
|
||||
```
|
||||
|
||||
> **Warning:** Adding the wild-card allow-origin flag can pose a security risk.
|
||||
> Only use it in production if you understand the risks of a loose CORS policy.
|
||||
|
||||
[OpenAPI]: https://ethereum.github.io/eth2.0-APIs/#/
|
||||
179
book/src/api-lighthouse.md
Normal file
179
book/src/api-lighthouse.md
Normal file
@@ -0,0 +1,179 @@
|
||||
# Lighthouse Non-Standard APIs
|
||||
|
||||
Lighthouse fully supports the standardization efforts at
|
||||
[github.com/ethereum/eth2.0-APIs](https://github.com/ethereum/eth2.0-APIs),
|
||||
however sometimes development requires additional endpoints that shouldn't
|
||||
necessarily be defined as a broad-reaching standard. Such endpoints are placed
|
||||
behind the `/lighthouse` path.
|
||||
|
||||
The endpoints behind the `/lighthouse` path are:
|
||||
|
||||
- Not intended to be stable.
|
||||
- Not guaranteed to be safe.
|
||||
- For testing and debugging purposes only.
|
||||
|
||||
Although we don't recommend that users rely on these endpoints, we
|
||||
document them briefly so they can be utilized by developers and
|
||||
researchers.
|
||||
|
||||
### `/lighthouse/health`
|
||||
|
||||
*Presently only available on Linux.*
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/health" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"pid": 1728254,
|
||||
"pid_num_threads": 47,
|
||||
"pid_mem_resident_set_size": 510054400,
|
||||
"pid_mem_virtual_memory_size": 3963158528,
|
||||
"sys_virt_mem_total": 16715530240,
|
||||
"sys_virt_mem_available": 4065374208,
|
||||
"sys_virt_mem_used": 11383402496,
|
||||
"sys_virt_mem_free": 1368662016,
|
||||
"sys_virt_mem_percent": 75.67906,
|
||||
"sys_loadavg_1": 4.92,
|
||||
"sys_loadavg_5": 5.53,
|
||||
"sys_loadavg_15": 5.58
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### `/lighthouse/syncing`
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/syncing" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"SyncingFinalized": {
|
||||
"start_slot": 3104,
|
||||
"head_slot": 343744,
|
||||
"head_root": "0x1b434b5ed702338df53eb5e3e24336a90373bb51f74b83af42840be7421dd2bf"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### `/lighthouse/peers`
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/peers" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"peer_id": "16Uiu2HAmA9xa11dtNv2z5fFbgF9hER3yq35qYNTPvN7TdAmvjqqv",
|
||||
"peer_info": {
|
||||
"_status": "Healthy",
|
||||
"score": {
|
||||
"score": 0
|
||||
},
|
||||
"client": {
|
||||
"kind": "Lighthouse",
|
||||
"version": "v0.2.9-1c9a055c",
|
||||
"os_version": "aarch64-linux",
|
||||
"protocol_version": "lighthouse/libp2p",
|
||||
"agent_string": "Lighthouse/v0.2.9-1c9a055c/aarch64-linux"
|
||||
},
|
||||
"connection_status": {
|
||||
"status": "disconnected",
|
||||
"connections_in": 0,
|
||||
"connections_out": 0,
|
||||
"last_seen": 1082,
|
||||
"banned_ips": []
|
||||
},
|
||||
"listening_addresses": [
|
||||
"/ip4/80.109.35.174/tcp/9000",
|
||||
"/ip4/127.0.0.1/tcp/9000",
|
||||
"/ip4/192.168.0.73/tcp/9000",
|
||||
"/ip4/172.17.0.1/tcp/9000",
|
||||
"/ip6/::1/tcp/9000"
|
||||
],
|
||||
"sync_status": {
|
||||
"Advanced": {
|
||||
"info": {
|
||||
"status_head_slot": 343829,
|
||||
"status_head_root": "0xe34e43efc2bb462d9f364bc90e1f7f0094e74310fd172af698b5a94193498871",
|
||||
"status_finalized_epoch": 10742,
|
||||
"status_finalized_root": "0x1b434b5ed702338df53eb5e3e24336a90373bb51f74b83af42840be7421dd2bf"
|
||||
}
|
||||
}
|
||||
},
|
||||
"meta_data": {
|
||||
"seq_number": 160,
|
||||
"attnets": "0x0000000800000080"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### `/lighthouse/peers/connected`
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/peers/connected" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"peer_id": "16Uiu2HAkzJC5TqDSKuLgVUsV4dWat9Hr8EjNZUb6nzFb61mrfqBv",
|
||||
"peer_info": {
|
||||
"_status": "Healthy",
|
||||
"score": {
|
||||
"score": 0
|
||||
},
|
||||
"client": {
|
||||
"kind": "Lighthouse",
|
||||
"version": "v0.2.8-87181204+",
|
||||
"os_version": "x86_64-linux",
|
||||
"protocol_version": "lighthouse/libp2p",
|
||||
"agent_string": "Lighthouse/v0.2.8-87181204+/x86_64-linux"
|
||||
},
|
||||
"connection_status": {
|
||||
"status": "connected",
|
||||
"connections_in": 1,
|
||||
"connections_out": 0,
|
||||
"last_seen": 0,
|
||||
"banned_ips": []
|
||||
},
|
||||
"listening_addresses": [
|
||||
"/ip4/34.204.178.218/tcp/9000",
|
||||
"/ip4/127.0.0.1/tcp/9000",
|
||||
"/ip4/172.31.67.58/tcp/9000",
|
||||
"/ip4/172.17.0.1/tcp/9000",
|
||||
"/ip6/::1/tcp/9000"
|
||||
],
|
||||
"sync_status": "Unknown",
|
||||
"meta_data": {
|
||||
"seq_number": 1819,
|
||||
"attnets": "0xffffffffffffffff"
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### `/lighthouse/proto_array`
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/proto_array" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
*Example omitted for brevity.*
|
||||
|
||||
### `/lighthouse/validator_inclusion/{epoch}/{validator_id}`
|
||||
|
||||
See [Validator Inclusion APIs](./validator-inclusion.md).
|
||||
|
||||
### `/lighthouse/validator_inclusion/{epoch}/global`
|
||||
|
||||
See [Validator Inclusion APIs](./validator-inclusion.md).
|
||||
55
book/src/api-vc-auth-header.md
Normal file
55
book/src/api-vc-auth-header.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Validator Client API: Authorization Header
|
||||
|
||||
## Overview
|
||||
|
||||
The validator client HTTP server requires that all requests have the following
|
||||
HTTP header:
|
||||
|
||||
- Name: `Authorization`
|
||||
- Value: `Basic <api-token>`
|
||||
|
||||
Where `<api-token>` is a string that can be obtained from the validator client
|
||||
host. Here is an example `Authorization` header:
|
||||
|
||||
```
|
||||
Authorization Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
|
||||
```
|
||||
|
||||
## Obtaining the API token
|
||||
|
||||
The API token can be obtained via two methods:
|
||||
|
||||
### Method 1: Reading from a file
|
||||
|
||||
The API token is stored as a file in the `validators` directory. For most users
|
||||
this is `~/.lighthouse/{testnet}/validators/api-token.txt`. Here's an
|
||||
example using the `cat` command to print the token to the terminal, but any
|
||||
text editor will suffice:
|
||||
|
||||
```
|
||||
$ cat api-token.txt
|
||||
api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
|
||||
```
|
||||
|
||||
### Method 2: Reading from logs
|
||||
|
||||
When starting the validator client it will output a log message containing an
|
||||
`api-token` field:
|
||||
|
||||
```
|
||||
Sep 28 19:17:52.615 INFO HTTP API started api_token: api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123, listen_address: 127.0.0.1:5062
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
Here is an example `curl` command using the API token in the `Authorization` header:
|
||||
|
||||
```bash
|
||||
curl localhost:5062/lighthouse/version -H "Authorization: Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123"
|
||||
```
|
||||
|
||||
The server should respond with its version:
|
||||
|
||||
```json
|
||||
{"data":{"version":"Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux"}}
|
||||
```
|
||||
363
book/src/api-vc-endpoints.md
Normal file
363
book/src/api-vc-endpoints.md
Normal file
@@ -0,0 +1,363 @@
|
||||
# Validator Client API: Endpoints
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`GET /lighthouse/version`](#get-lighthouseversion) | Get the Lighthouse software version
|
||||
[`GET /lighthouse/health`](#get-lighthousehealth) | Get information about the host machine
|
||||
[`GET /lighthouse/spec`](#get-lighthousespec) | Get the Eth2 specification used by the validator
|
||||
[`GET /lighthouse/validators`](#get-lighthousevalidators) | List all validators
|
||||
[`GET /lighthouse/validators/:voting_pubkey`](#get-lighthousevalidatorsvoting_pubkey) | Get a specific validator
|
||||
[`PATCH /lighthouse/validators/:voting_pubkey`](#patch-lighthousevalidatorsvoting_pubkey) | Update a specific validator
|
||||
[`POST /lighthouse/validators`](#post-lighthousevalidators) | Create a new validator and mnemonic.
|
||||
[`POST /lighthouse/validators/mnemonic`](#post-lighthousevalidatorsmnemonic) | Create a new validator from an existing mnemonic.
|
||||
|
||||
## `GET /lighthouse/version`
|
||||
|
||||
Returns the software version and `git` commit hash for the Lighthouse binary.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/version`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"version": "Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `GET /lighthouse/health`
|
||||
|
||||
Returns information regarding the health of the host machine.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/health`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
|
||||
*Note: this endpoint is presently only available on Linux.*
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"pid": 1476293,
|
||||
"pid_num_threads": 19,
|
||||
"pid_mem_resident_set_size": 4009984,
|
||||
"pid_mem_virtual_memory_size": 1306775552,
|
||||
"sys_virt_mem_total": 33596100608,
|
||||
"sys_virt_mem_available": 23073017856,
|
||||
"sys_virt_mem_used": 9346957312,
|
||||
"sys_virt_mem_free": 22410510336,
|
||||
"sys_virt_mem_percent": 31.322334,
|
||||
"sys_loadavg_1": 0.98,
|
||||
"sys_loadavg_5": 0.98,
|
||||
"sys_loadavg_15": 1.01
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `GET /lighthouse/spec`
|
||||
|
||||
Returns the Eth2 specification loaded for this validator.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/spec`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"CONFIG_NAME": "mainnet",
|
||||
"MAX_COMMITTEES_PER_SLOT": "64",
|
||||
"TARGET_COMMITTEE_SIZE": "128",
|
||||
"MIN_PER_EPOCH_CHURN_LIMIT": "4",
|
||||
"CHURN_LIMIT_QUOTIENT": "65536",
|
||||
"SHUFFLE_ROUND_COUNT": "90",
|
||||
"MIN_GENESIS_ACTIVE_VALIDATOR_COUNT": "1024",
|
||||
"MIN_GENESIS_TIME": "1601380800",
|
||||
"GENESIS_DELAY": "172800",
|
||||
"MIN_DEPOSIT_AMOUNT": "1000000000",
|
||||
"MAX_EFFECTIVE_BALANCE": "32000000000",
|
||||
"EJECTION_BALANCE": "16000000000",
|
||||
"EFFECTIVE_BALANCE_INCREMENT": "1000000000",
|
||||
"HYSTERESIS_QUOTIENT": "4",
|
||||
"HYSTERESIS_DOWNWARD_MULTIPLIER": "1",
|
||||
"HYSTERESIS_UPWARD_MULTIPLIER": "5",
|
||||
"PROPORTIONAL_SLASHING_MULTIPLIER": "3",
|
||||
"GENESIS_FORK_VERSION": "0x00000002",
|
||||
"BLS_WITHDRAWAL_PREFIX": "0x00",
|
||||
"SECONDS_PER_SLOT": "12",
|
||||
"MIN_ATTESTATION_INCLUSION_DELAY": "1",
|
||||
"MIN_SEED_LOOKAHEAD": "1",
|
||||
"MAX_SEED_LOOKAHEAD": "4",
|
||||
"MIN_EPOCHS_TO_INACTIVITY_PENALTY": "4",
|
||||
"MIN_VALIDATOR_WITHDRAWABILITY_DELAY": "256",
|
||||
"SHARD_COMMITTEE_PERIOD": "256",
|
||||
"BASE_REWARD_FACTOR": "64",
|
||||
"WHISTLEBLOWER_REWARD_QUOTIENT": "512",
|
||||
"PROPOSER_REWARD_QUOTIENT": "8",
|
||||
"INACTIVITY_PENALTY_QUOTIENT": "16777216",
|
||||
"MIN_SLASHING_PENALTY_QUOTIENT": "32",
|
||||
"SAFE_SLOTS_TO_UPDATE_JUSTIFIED": "8",
|
||||
"DOMAIN_BEACON_PROPOSER": "0x00000000",
|
||||
"DOMAIN_BEACON_ATTESTER": "0x01000000",
|
||||
"DOMAIN_RANDAO": "0x02000000",
|
||||
"DOMAIN_DEPOSIT": "0x03000000",
|
||||
"DOMAIN_VOLUNTARY_EXIT": "0x04000000",
|
||||
"DOMAIN_SELECTION_PROOF": "0x05000000",
|
||||
"DOMAIN_AGGREGATE_AND_PROOF": "0x06000000",
|
||||
"MAX_VALIDATORS_PER_COMMITTEE": "2048",
|
||||
"SLOTS_PER_EPOCH": "32",
|
||||
"EPOCHS_PER_ETH1_VOTING_PERIOD": "32",
|
||||
"SLOTS_PER_HISTORICAL_ROOT": "8192",
|
||||
"EPOCHS_PER_HISTORICAL_VECTOR": "65536",
|
||||
"EPOCHS_PER_SLASHINGS_VECTOR": "8192",
|
||||
"HISTORICAL_ROOTS_LIMIT": "16777216",
|
||||
"VALIDATOR_REGISTRY_LIMIT": "1099511627776",
|
||||
"MAX_PROPOSER_SLASHINGS": "16",
|
||||
"MAX_ATTESTER_SLASHINGS": "2",
|
||||
"MAX_ATTESTATIONS": "128",
|
||||
"MAX_DEPOSITS": "16",
|
||||
"MAX_VOLUNTARY_EXITS": "16",
|
||||
"ETH1_FOLLOW_DISTANCE": "1024",
|
||||
"TARGET_AGGREGATORS_PER_COMMITTEE": "16",
|
||||
"RANDOM_SUBNETS_PER_VALIDATOR": "1",
|
||||
"EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION": "256",
|
||||
"SECONDS_PER_ETH1_BLOCK": "14",
|
||||
"DEPOSIT_CONTRACT_ADDRESS": "0x48b597f4b53c21b48ad95c7256b49d1779bd5890"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `GET /lighthouse/validators`
|
||||
|
||||
Lists all validators managed by this validator client.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": [
|
||||
{
|
||||
"enabled": true,
|
||||
"voting_pubkey": "0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde"
|
||||
},
|
||||
{
|
||||
"enabled": true,
|
||||
"voting_pubkey": "0xb0441246ed813af54c0a11efd53019f63dd454a1fa2a9939ce3c228419fbe113fb02b443ceeb38736ef97877eb88d43a"
|
||||
},
|
||||
{
|
||||
"enabled": true,
|
||||
"voting_pubkey": "0xad77e388d745f24e13890353031dd8137432ee4225752642aad0a2ab003c86620357d91973b6675932ff51f817088f38"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## `GET /lighthouse/validators/:voting_pubkey`
|
||||
|
||||
Get a validator by their `voting_pubkey`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/:voting_pubkey`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 400
|
||||
|
||||
### Example Path
|
||||
|
||||
```
|
||||
localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde
|
||||
```
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"enabled": true,
|
||||
"voting_pubkey": "0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `PATCH /lighthouse/validators/:voting_pubkey`
|
||||
|
||||
Update some values for the validator with `voting_pubkey`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/:voting_pubkey`
|
||||
Method | PATCH
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 400
|
||||
|
||||
### Example Path
|
||||
|
||||
```
|
||||
localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde
|
||||
```
|
||||
|
||||
### Example Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"enabled": false
|
||||
}
|
||||
```
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
null
|
||||
```
|
||||
|
||||
## `POST /lighthouse/validators/`
|
||||
|
||||
Create any number of new validators, all of which will share a common mnemonic
|
||||
generated by the server.
|
||||
|
||||
A BIP-39 mnemonic will be randomly generated and returned with the response.
|
||||
This mnemonic can be used to recover all keys returned in the response.
|
||||
Validators are generated from the mnemonic according to
|
||||
[EIP-2334](https://eips.ethereum.org/EIPS/eip-2334), starting at index `0`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Request Body
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"enable": true,
|
||||
"description": "validator_one",
|
||||
"deposit_gwei": "32000000000"
|
||||
},
|
||||
{
|
||||
"enable": false,
|
||||
"description": "validator two",
|
||||
"deposit_gwei": "34000000000"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": {
|
||||
"mnemonic": "marine orchard scout label trim only narrow taste art belt betray soda deal diagram glare hero scare shadow ramp blur junior behave resource tourist",
|
||||
"validators": [
|
||||
{
|
||||
"enabled": true,
|
||||
"description": "validator_one",
|
||||
"voting_pubkey": "0x8ffbc881fb60841a4546b4b385ec5e9b5090fd1c4395e568d98b74b94b41a912c6101113da39d43c101369eeb9b48e50",
|
||||
"eth1_deposit_tx_data": "0x22895118000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000001206c68675776d418bfd63468789e7c68a6788c4dd45a3a911fe3d642668220bbf200000000000000000000000000000000000000000000000000000000000000308ffbc881fb60841a4546b4b385ec5e9b5090fd1c4395e568d98b74b94b41a912c6101113da39d43c101369eeb9b48e5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000cf8b3abbf0ecd91f3b0affcc3a11e9c5f8066efb8982d354ee9a812219b17000000000000000000000000000000000000000000000000000000000000000608fbe2cc0e17a98d4a58bd7a65f0475a58850d3c048da7b718f8809d8943fee1dbd5677c04b5fa08a9c44d271d009edcd15caa56387dc217159b300aad66c2cf8040696d383d0bff37b2892a7fe9ba78b2220158f3dc1b9cd6357bdcaee3eb9f2",
|
||||
"deposit_gwei": "32000000000"
|
||||
},
|
||||
{
|
||||
"enabled": false,
|
||||
"description": "validator two",
|
||||
"voting_pubkey": "0xa9fadd620dc68e9fe0d6e1a69f6c54a0271ad65ab5a509e645e45c6e60ff8f4fc538f301781193a08b55821444801502",
|
||||
"eth1_deposit_tx_data": "0x22895118000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000120b1911954c1b8d23233e0e2bf8c4878c8f56d25a4f790ec09a94520ec88af30490000000000000000000000000000000000000000000000000000000000000030a9fadd620dc68e9fe0d6e1a69f6c54a0271ad65ab5a509e645e45c6e60ff8f4fc538f301781193a08b5582144480150200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000a96df8b95c3ba749265e48a101f2ed974fffd7487487ed55f8dded99b617ad000000000000000000000000000000000000000000000000000000000000006090421299179824950e2f5a592ab1fdefe5349faea1e8126146a006b64777b74cce3cfc5b39d35b370e8f844e99c2dc1b19a1ebd38c7605f28e9c4540aea48f0bc48e853ae5f477fa81a9fc599d1732968c772730e1e47aaf5c5117bd045b788e",
|
||||
"deposit_gwei": "34000000000"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `POST /lighthouse/validators/mnemonic`
|
||||
|
||||
Create any number of new validators, all of which will share a common mnemonic.
|
||||
|
||||
The supplied BIP-39 mnemonic will be used to generate the validator keys
|
||||
according to [EIP-2334](https://eips.ethereum.org/EIPS/eip-2334), starting at
|
||||
the supplied `key_derivation_path_offset`. For example, if
|
||||
`key_derivation_path_offset = 42`, then the first validator voting key will be
|
||||
generated with the path `m/12381/3600/i/42`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/mnemonic`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"mnemonic": "theme onion deal plastic claim silver fancy youth lock ordinary hotel elegant balance ridge web skill burger survey demand distance legal fish salad cloth",
|
||||
"key_derivation_path_offset": 0,
|
||||
"validators": [
|
||||
{
|
||||
"enable": true,
|
||||
"description": "validator_one",
|
||||
"deposit_gwei": "32000000000"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Example Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"data": [
|
||||
{
|
||||
"enabled": true,
|
||||
"description": "validator_one",
|
||||
"voting_pubkey": "0xa062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db380",
|
||||
"eth1_deposit_tx_data": "0x22895118000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000000000120a57324d95ae9c7abfb5cc9bd4db253ed0605dc8a19f84810bcf3f3874d0e703a0000000000000000000000000000000000000000000000000000000000000030a062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db3800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200046e4199f18102b5d4e8842d0eeafaa1268ee2c21340c63f9c2cd5b03ff19320000000000000000000000000000000000000000000000000000000000000060b2a897b4ba4f3910e9090abc4c22f81f13e8923ea61c0043506950b6ae174aa643540554037b465670d28fa7b7d716a301e9b172297122acc56be1131621c072f7c0a73ea7b8c5a90ecd5da06d79d90afaea17cdeeef8ed323912c70ad62c04b",
|
||||
"deposit_gwei": "32000000000"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
108
book/src/api-vc-sig-header.md
Normal file
108
book/src/api-vc-sig-header.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# Validator Client API: Signature Header
|
||||
|
||||
## Overview
|
||||
|
||||
The validator client HTTP server adds the following header to all responses:
|
||||
|
||||
- Name: `Signature`
|
||||
- Value: a secp256k1 signature across the SHA256 of the response body.
|
||||
|
||||
Example `Signature` header:
|
||||
|
||||
```
|
||||
Signature: 0x304402205b114366444112580bf455d919401e9c869f5af067cd496016ab70d428b5a99d0220067aede1eb5819eecfd5dd7a2b57c5ac2b98f25a7be214b05684b04523aef873
|
||||
```
|
||||
|
||||
## Verifying the Signature
|
||||
|
||||
Below is a browser-ready example of signature verification.
|
||||
|
||||
### HTML
|
||||
|
||||
```html
|
||||
<script src="https://rawgit.com/emn178/js-sha256/master/src/sha256.js" type="text/javascript"></script>
|
||||
<script src="https://rawgit.com/indutny/elliptic/master/dist/elliptic.min.js" type="text/javascript"></script>
|
||||
```
|
||||
|
||||
### Javascript
|
||||
|
||||
```javascript
|
||||
// Helper function to turn a hex-string into bytes.
|
||||
function hexStringToByte(str) {
|
||||
if (!str) {
|
||||
return new Uint8Array();
|
||||
}
|
||||
|
||||
var a = [];
|
||||
for (var i = 0, len = str.length; i < len; i+=2) {
|
||||
a.push(parseInt(str.substr(i,2),16));
|
||||
}
|
||||
|
||||
return new Uint8Array(a);
|
||||
}
|
||||
|
||||
// This example uses the secp256k1 curve from the "elliptic" library:
|
||||
//
|
||||
// https://github.com/indutny/elliptic
|
||||
var ec = new elliptic.ec('secp256k1');
|
||||
|
||||
// The public key is contained in the API token:
|
||||
//
|
||||
// Authorization: Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
|
||||
var pk_bytes = hexStringToByte('03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123');
|
||||
|
||||
// The signature is in the `Signature` header of the response:
|
||||
//
|
||||
// Signature: 0x304402205b114366444112580bf455d919401e9c869f5af067cd496016ab70d428b5a99d0220067aede1eb5819eecfd5dd7a2b57c5ac2b98f25a7be214b05684b04523aef873
|
||||
var sig_bytes = hexStringToByte('304402205b114366444112580bf455d919401e9c869f5af067cd496016ab70d428b5a99d0220067aede1eb5819eecfd5dd7a2b57c5ac2b98f25a7be214b05684b04523aef873');
|
||||
|
||||
// The HTTP response body.
|
||||
var response_body = "{\"data\":{\"version\":\"Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux\"}}";
|
||||
|
||||
// The HTTP response body is hashed (SHA256) to determine the 32-byte message.
|
||||
let hash = sha256.create();
|
||||
hash.update(response_body);
|
||||
let message = hash.array();
|
||||
|
||||
// The 32-byte message hash, the signature and the public key are verified.
|
||||
if (ec.verify(message, sig_bytes, pk_bytes)) {
|
||||
console.log("The signature is valid")
|
||||
} else {
|
||||
console.log("The signature is invalid")
|
||||
}
|
||||
```
|
||||
|
||||
*This example is also available as a [JSFiddle](https://jsfiddle.net/wnqd74Lz/).*
|
||||
|
||||
## Example
|
||||
|
||||
The previous Javascript example was written using the output from the following
|
||||
`curl` command:
|
||||
|
||||
```bash
|
||||
curl -v localhost:5062/lighthouse/version -H "Authorization: Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123"
|
||||
```
|
||||
|
||||
```
|
||||
* Trying ::1:5062...
|
||||
* connect to ::1 port 5062 failed: Connection refused
|
||||
* Trying 127.0.0.1:5062...
|
||||
* Connected to localhost (127.0.0.1) port 5062 (#0)
|
||||
> GET /lighthouse/version HTTP/1.1
|
||||
> Host: localhost:5062
|
||||
> User-Agent: curl/7.72.0
|
||||
> Accept: */*
|
||||
> Authorization: Basic api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
|
||||
>
|
||||
* Mark bundle as not supporting multiuse
|
||||
< HTTP/1.1 200 OK
|
||||
< content-type: application/json
|
||||
< signature: 0x304402205b114366444112580bf455d919401e9c869f5af067cd496016ab70d428b5a99d0220067aede1eb5819eecfd5dd7a2b57c5ac2b98f25a7be214b05684b04523aef873
|
||||
< server: Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux
|
||||
< access-control-allow-origin:
|
||||
< content-length: 65
|
||||
< date: Tue, 29 Sep 2020 04:23:46 GMT
|
||||
<
|
||||
* Connection #0 to host localhost left intact
|
||||
{"data":{"version":"Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux"}}
|
||||
```
|
||||
38
book/src/api-vc.md
Normal file
38
book/src/api-vc.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Validator Client API
|
||||
|
||||
Lighthouse implements a HTTP/JSON API for the validator client. Since there is
|
||||
no Eth2 standard validator client API, Lighthouse has defined its own.
|
||||
|
||||
A full list of endpoints can be found 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-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 is **not encrypted** (i.e., it is **not HTTPS**). For
|
||||
this reason, it will only listen 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.).
|
||||
|
||||
### CLI Example
|
||||
|
||||
Start the validator client with the HTTP server listening on [http://localhost:5062](http://localhost:5062):
|
||||
|
||||
```bash
|
||||
lighthouse vc --http
|
||||
```
|
||||
@@ -1,13 +1,9 @@
|
||||
# APIs
|
||||
|
||||
The Lighthouse `beacon_node` provides two APIs for local consumption:
|
||||
Lighthouse allows users to query the state of Eth2.0 using web-standard,
|
||||
RESTful HTTP/JSON APIs.
|
||||
|
||||
- A [RESTful JSON HTTP API](http.html) which provides beacon chain, node and network
|
||||
information.
|
||||
- A read-only [WebSocket API](websockets.html) providing beacon chain events, as they occur.
|
||||
There are two APIs served by Lighthouse:
|
||||
|
||||
|
||||
## Security
|
||||
|
||||
These endpoints are not designed to be exposed to the public Internet or
|
||||
untrusted users. They may pose a considerable DoS attack vector when used improperly.
|
||||
- [Beacon Node API](./api-bn.md)
|
||||
- [Validator Client API](./api-vc.md) (not yet released).
|
||||
|
||||
@@ -1,121 +0,0 @@
|
||||
# Become a Validator: Using Docker
|
||||
|
||||
Sigma Prime maintains the
|
||||
[sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repository
|
||||
which provides an easy way to run Lighthouse without building the Lighthouse
|
||||
binary yourself.
|
||||
|
||||
> Note: when you're running the Docker Hub image you're relying upon a
|
||||
> pre-built binary instead of building from source. If you want the highest
|
||||
> assurance you're running the _real_ Lighthouse,
|
||||
> [build the docker image yourself](./docker.md) instead. You'll need some
|
||||
> experience with docker-compose to integrate your locally built docker image
|
||||
> with the docker-compose environment.
|
||||
|
||||
## 0. Install Docker Compose
|
||||
|
||||
Docker Compose relies on Docker Engine for any meaningful work, so make sure you have Docker Engine installed either locally or remote, depending on your setup.
|
||||
|
||||
- On desktop systems like [Docker Desktop for Mac](https://docs.docker.com/docker-for-mac/install/) and [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/install/), Docker Compose is included as part of those desktop installs, so the desktop install is all you need.
|
||||
|
||||
- On Linux systems, you'll need to first [install the Docker for your OS](https://docs.docker.com/install/#server) and then [follow the instuctions here](https://docs.docker.com/compose/install/#install-compose-on-linux-systems).
|
||||
|
||||
> For more on installing Compose, see [here](https://docs.docker.com/compose/install/).
|
||||
|
||||
|
||||
## 1. Clone the repository
|
||||
|
||||
Once you have Docker Compose installed, clone the
|
||||
[sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repository:
|
||||
|
||||
```bash
|
||||
git clone https://github.com/sigp/lighthouse-docker
|
||||
cd lighthouse-docker
|
||||
```
|
||||
|
||||
## 2. Configure the Docker environment
|
||||
|
||||
Then, create a file named `.env` with the following contents (these values are
|
||||
documented
|
||||
[here](https://github.com/sigp/lighthouse-docker/blob/master/default.env)):
|
||||
|
||||
```bash
|
||||
DEBUG_LEVEL=info
|
||||
START_GETH=true
|
||||
START_VALIDATOR=true
|
||||
VALIDATOR_COUNT=1
|
||||
VOTING_ETH1_NODE=http://geth:8545
|
||||
```
|
||||
|
||||
> To specify a non-default testnet add `TESTNET=<testnet>` to the above file. <testnet> can be `altona` or `medalla`.
|
||||
|
||||
_This `.env` file should live in the `lighthouse-docker` directory alongside the
|
||||
`docker-compose.yml` file_.
|
||||
|
||||
## 3. Start Lighthouse
|
||||
|
||||
Start the docker-compose environment (you may need to prefix the below command with `sudo`):
|
||||
|
||||
```bash
|
||||
docker-compose up
|
||||
```
|
||||
|
||||
Watch the output of this command for the `Decrypted validator keystore pubkey`
|
||||
log, as it contains your `voting_pubkey` -- the primary identifier for your new
|
||||
validator. This key is useful for finding your validator in block explorers.
|
||||
Here's an example of the log:
|
||||
|
||||
```bash
|
||||
validator_client_1 | Jun 01 00:29:24.418 INFO Decrypted validator keystore voting_pubkey: 0x9986ade7a974d2fe2d0fc84a8c04153873337d533d43a83439cab8ec276410686dd69aa808605a7324f34e52497a3f41
|
||||
```
|
||||
This is one of the earlier logs outputted, so you may have to scroll up or perform a search in your terminal to find it.
|
||||
|
||||
> Note: `docker-compose up` generates a new sub-directory -- to store your validator's deposit data, along with its voting and withdrawal keys -- in the `lighthouse-data/validators` directory. This sub-directory is identified by your validator's `voting_pubkey` (the same `voting_pubkey` you see in the logs). So this is another way you can find it.
|
||||
|
||||
> Note: the docker-compose setup includes a fast-synced geth node. So you can
|
||||
> expect the `beacon_node` to log some eth1-related errors whilst the geth node
|
||||
> boots and becomes synced. This will only happen on the first start of the
|
||||
> compose environment or if geth loses sync.
|
||||
|
||||
> Note: If you are participating in the genesis of a network (the network has
|
||||
> not launched yet) you will notice errors in the validator client. This is
|
||||
> because the beacon node not expose its HTTP API until
|
||||
> the genesis of the network is known (approx 2 days before the network
|
||||
> launches).
|
||||
|
||||
> Note: Docker exposes ports TCP 9000 and UDP 9000 by default. Although not
|
||||
> strictly required, we recommend setting up port forwards to expose these
|
||||
> ports publicly. For more information see the FAQ or the [Advanced Networking](advanced_networking.html)
|
||||
> section
|
||||
|
||||
To find an estimate for how long your beacon node will take to finish syncing, look for logs that look like this:
|
||||
|
||||
```bash
|
||||
beacon_node_1 | Mar 16 11:33:53.979 INFO Syncing
|
||||
est_time: 47 mins, speed: 16.67 slots/sec, distance: 47296 slots (7 days 14 hrs), peers: 3, service: slot_notifier
|
||||
```
|
||||
|
||||
You'll find the estimated time under `est_time`. In the example above, that's `47 mins`.
|
||||
|
||||
If your beacon node hasn't finished syncing yet, you'll see some ERRO messages indicating that your node hasn't synced yet:
|
||||
|
||||
```bash
|
||||
validator_client_1 | Mar 16 11:34:36.086 ERRO Beacon node is not synced current_epoch: 6999, node_head_epoch: 5531, service: duties
|
||||
```
|
||||
|
||||
It's safest to wait for your node to sync before moving on to the next step, otherwise your validator may activate before you're able to produce blocks and attestations (and you may be penalized as a result).
|
||||
|
||||
However, since it generally takes somewhere between [4 and 8 hours](./faq.md) after depositing for a validator to become active, if your `est_time` is less than 4 hours, you _should_ be fine to just move on to the next step. After all, this is a testnet and you're only risking Goerli ETH!
|
||||
|
||||
## Installation complete!
|
||||
|
||||
In the [next step](become-a-validator.html#2-submit-your-deposit-to-goerli) you'll need to upload your validator's deposit data. This data is stored in a file called `eth1_deposit_data.rlp`.
|
||||
|
||||
You'll find it in `lighthouse-docker/.lighthouse/validators/` -- in the sub-directory that corresponds to your validator's public key (`voting_pubkey`).
|
||||
|
||||
|
||||
> For example, if you ran [step 1](become-a-validator-docker.html#1-clone-the-repository) in `/home/karlm/`, and your validator's `voting_pubkey` is `0x8592c7..`, then you'll find your `eth1_deposit_data.rlp` file in the following directory:
|
||||
>
|
||||
>`/home/karlm/lighthouse-docker/.lighthouse/validators/0x8592c7../`
|
||||
|
||||
Once you've located `eth1_deposit_data.rlp`, you're ready to move on to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
|
||||
@@ -1,219 +0,0 @@
|
||||
# Become a Validator: Building from Source
|
||||
|
||||
## 0. Install Rust
|
||||
If you don't have Rust installed already, visit [rustup.rs](https://rustup.rs/) to install it.
|
||||
|
||||
> Notes:
|
||||
> - If you're not familiar with Rust or you'd like more detailed instructions, see our [installation guide](./installation.md).
|
||||
> - Windows is presently only supported via [WSL](https://docs.microsoft.com/en-us/windows/wsl/about).
|
||||
|
||||
|
||||
## 1. Download and install Lighthouse
|
||||
|
||||
Once you have Rust installed, you can install Lighthouse with the following commands:
|
||||
|
||||
1. `git clone https://github.com/sigp/lighthouse.git`
|
||||
2. `cd lighthouse`
|
||||
4. `make`
|
||||
|
||||
You may need to open a new terminal window before running `make`.
|
||||
|
||||
You've completed this step when you can run `$ lighthouse --help` and see the
|
||||
help menu.
|
||||
|
||||
|
||||
## 2. Start an Eth1 client
|
||||
|
||||
Since Eth2 relies upon the Eth1 chain for validator on-boarding, all Eth2 validators must have a connection to an Eth1 node.
|
||||
|
||||
We provide instructions for using Geth (the Eth1 client that, by chance, we ended up testing with), but you could use any client that implements the JSON RPC via HTTP. A fast-synced node should be sufficient.
|
||||
|
||||
### Installing Geth
|
||||
If you're using a Mac, follow the instructions [listed here](https://github.com/ethereum/go-ethereum/wiki/Installation-Instructions-for-Mac) to install geth. Otherwise [see here](https://github.com/ethereum/go-ethereum/wiki/Installing-Geth).
|
||||
|
||||
### Starting Geth
|
||||
|
||||
Once you have geth installed, use this command to start your Eth1 node:
|
||||
|
||||
```bash
|
||||
geth --goerli --http
|
||||
```
|
||||
|
||||
## 3. Start your beacon node
|
||||
|
||||
The beacon node is the core component of Eth2, it connects to other peers over
|
||||
the internet and maintains a view of the chain.
|
||||
|
||||
Start your beacon node with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla beacon --staking
|
||||
```
|
||||
|
||||
> The `--testnet` parameter is optional. Omitting it will default to the
|
||||
> current public testnet. Set the value to the testnet you wish to run on.
|
||||
> Current values are either `altona` or `medalla`. This is true for all the
|
||||
> following commands in this document.
|
||||
|
||||
> Note: Lighthouse, by default, opens port 9000 over TCP and UDP. Although not
|
||||
> strictly required, we recommend setting up port forwards to expose these
|
||||
> ports publicly. For more information see the FAQ or the [Advanced Networking](advanced_networking.html)
|
||||
> section
|
||||
|
||||
|
||||
You can also pass an external http endpoint (e.g. Infura) for the Eth1 node using the `--eth1-endpoint` flag:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla beacon --staking --eth1-endpoint <ETH1-SERVER>
|
||||
```
|
||||
|
||||
Your beacon node has started syncing when you see the following (truncated)
|
||||
log:
|
||||
|
||||
```
|
||||
Dec 09 12:57:18.026 INFO Syncing
|
||||
est_time: 2 hrs ...
|
||||
```
|
||||
|
||||
The `distance` value reports the time since eth2 genesis, whilst the `est_time`
|
||||
reports an estimate of how long it will take your node to become synced.
|
||||
|
||||
You'll know it's finished syncing once you see the following (truncated) log:
|
||||
|
||||
```
|
||||
Dec 09 12:27:06.010 INFO Synced
|
||||
slot: 16835, ...
|
||||
```
|
||||
|
||||
|
||||
## 4. Generate your validator key
|
||||
|
||||
First, [create a wallet](./wallet-create.md) that can be used to generate
|
||||
validator keys. Then, from that wallet [create a
|
||||
validator](./validator-create.md). A two-step example follows:
|
||||
|
||||
### 4.1 Create a Wallet
|
||||
|
||||
Create a wallet with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla account wallet create
|
||||
```
|
||||
|
||||
You will be prompted for a wallet name and a password. The output will look like this:
|
||||
|
||||
```
|
||||
Your wallet's 24-word BIP-39 mnemonic is:
|
||||
|
||||
glad marble art pelican nurse large guilt response brave affair kite essence welcome gauge peace once picnic debris devote ticket blood bike solar junk
|
||||
|
||||
This mnemonic can be used to fully restore your wallet, should
|
||||
you lose the JSON file or your password.
|
||||
|
||||
It is very important that you DO NOT SHARE this mnemonic as it will
|
||||
reveal the private keys of all validators and keys generated with
|
||||
this wallet. That would be catastrophic.
|
||||
|
||||
It is also important to store a backup of this mnemonic so you can
|
||||
recover your private keys in the case of data loss. Writing it on
|
||||
a piece of paper and storing it in a safe place would be prudent.
|
||||
|
||||
Your wallet's UUID is:
|
||||
|
||||
1c8c13d5-d065-4ef7-bad3-14e9d8146140
|
||||
|
||||
You do not need to backup your UUID or keep it secret.
|
||||
```
|
||||
|
||||
**Don't forget to make a backup** of the 24-word BIP-39 mnemonic. It can be
|
||||
used to restore your validator if there is a data loss.
|
||||
|
||||
### 4.2 Create a Validator from the Wallet
|
||||
|
||||
Create a validator from the wallet with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla account validator create --count 1
|
||||
```
|
||||
|
||||
Enter your wallet's name and password when prompted. The output will look like this:
|
||||
|
||||
```bash
|
||||
1/1 0x80f3dce8d6745a725d8442c9bc3ca0852e772394b898c95c134b94979ebb0af6f898d5c5f65b71be6889185c486918a7
|
||||
```
|
||||
|
||||
Take note of the _validator public key_ (the `0x` and 64 characters following
|
||||
it). It's the validator's primary identifier, and will be used to find your
|
||||
validator in block explorers. (The `1/1` at the start is saying it's one-of-one
|
||||
keys generated).
|
||||
|
||||
Once you've observed the validator public key, you've successfully generated a
|
||||
new sub-directory for your validator in the `.lighthouse/validators` directory.
|
||||
The sub-directory is identified by your validator's public key . And is used to
|
||||
store your validator's deposit data, along with its voting keys and other
|
||||
information.
|
||||
|
||||
|
||||
## 5. Start your validator client
|
||||
|
||||
> Note: If you are participating in the genesis of a network (the network has
|
||||
> not launched yet) you should skip this step and re-run this step two days before
|
||||
> the launch of the network. The beacon node does not expose its HTTP API until
|
||||
> the genesis of the network is known (approx 2 days before the network
|
||||
> launches).
|
||||
|
||||
Since the validator client stores private keys and signs messages generated by the beacon node, for security reasons it runs separately from it.
|
||||
|
||||
You'll need both your beacon node _and_ validator client running if you want to
|
||||
stake.
|
||||
|
||||
Start the validator client with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet medalla validator --auto-register
|
||||
```
|
||||
|
||||
The `--auto-register` flag registers your signing key with the slashing protection database, which
|
||||
keeps track of all the messages your validator signs. This flag should be used sparingly,
|
||||
as reusing the same key on multiple nodes can lead to your validator getting slashed. On subsequent
|
||||
runs you should leave off the `--auto-register` flag.
|
||||
|
||||
You know that your validator client is running and has found your validator keys from [step 3](become-a-validator-source.html#3-start-your-beacon-node) when you see the following logs:
|
||||
|
||||
```
|
||||
Dec 09 13:08:59.171 INFO Loaded validator keypair store voting_validators: 1
|
||||
Dec 09 13:09:09.000 INFO Awaiting activation slot: 17787, ...
|
||||
```
|
||||
|
||||
|
||||
To find an estimate for how long your beacon node will take to finish syncing, lookout for the following logs:
|
||||
|
||||
```bash
|
||||
beacon_node_1 | Mar 16 11:33:53.979 INFO Syncing
|
||||
est_time: 47 mins, speed: 16.67 slots/sec, distance: 47296 slots (7 days 14 hrs), peers: 3, service: slot_notifier
|
||||
```
|
||||
|
||||
You'll find the estimated time under `est_time`. In the example log above, that's `47 mins`.
|
||||
|
||||
If your beacon node hasn't finished syncing yet, you'll see some `ERRO`
|
||||
messages indicating that your node hasn't synced yet:
|
||||
|
||||
```bash
|
||||
validator_client_1 | Mar 16 11:34:36.086 ERRO Beacon node is not synced current_epoch: 6999, node_head_epoch: 5531, service: duties
|
||||
```
|
||||
|
||||
It's safest to wait for your node to sync before moving on to the next step, otherwise your validator may activate before you're able to produce blocks and attestations (and you may be penalized as a result).
|
||||
|
||||
However, since it generally takes somewhere between [4 and 8 hours](./faq.md) after depositing for a validator to become active, if your `est_time` is less than 4 hours, you _should_ be fine to just move on to the next step. After all, this is a testnet and you're only risking Goerli ETH!
|
||||
|
||||
## Installation complete!
|
||||
|
||||
In the [next step](become-a-validator.html#2-submit-your-deposit-to-goerli) you'll need to upload your validator's deposit data. This data is stored in a file called `eth1_deposit_data.rlp`.
|
||||
|
||||
You'll find it in `/home/.lighthouse/validators` -- in the sub-directory that corresponds to your validator's public key.
|
||||
|
||||
> For example, if your username is `karlm`, and your validator's public key (aka `voting_pubkey`) is `0x8592c7..`, then you'll find your `eth1_deposit_data.rlp` file in the following directory:
|
||||
>
|
||||
>`/home/karlm/.lighthouse/validators/0x8592c7../`
|
||||
|
||||
Once you've located your `eth1_deposit_data.rlp` file, you're ready to move on to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
|
||||
@@ -1,96 +0,0 @@
|
||||
# Become an Ethereum 2.0 Validator
|
||||
|
||||
There are two public testnets currently available. [Medalla](https://github.com/goerli/medalla/tree/master/medalla) and [Altona](https://github.com/goerli/medalla/tree/master/altona). Lighthouse supports both out of the box and joining these multi-client testnets is easy if you're familiar with the terminal.
|
||||
|
||||
Lighthouse runs on Linux, MacOS and Windows and has a Docker work-flow to make
|
||||
things as simple as possible.
|
||||
|
||||
## 0. Acquire Goerli ETH
|
||||
Before you install Lighthouse, you'll need [Metamask](https://metamask.io/) and 32 gETH
|
||||
(Goerli ETH). We recommend the [mudit.blog
|
||||
faucet](https://faucet.goerli.mudit.blog/) for those familiar with Goerli, or
|
||||
[goerli.net](https://goerli.net/) for an overview of the testnet.
|
||||
|
||||
> If this is your first time using Metamask and/or interacting with an Ethereum test network, we recommend going through the beginning of [this guide](https://hack.aragon.org/docs/guides-use-metamask) first (up to the *Signing your first transaction with MetaMask* section).
|
||||
|
||||
## 1. Install and start Lighthouse
|
||||
|
||||
There are two, different ways to install and start a Lighthouse validator:
|
||||
|
||||
1. [Using `docker-compose`](./become-a-validator-docker.md): this is the easiest method.
|
||||
|
||||
2. [Building from source](./become-a-validator-source.md): this is a little more involved, however it
|
||||
gives a more hands-on experience.
|
||||
|
||||
Once you've completed **either one** of these steps, you can move onto the next step.
|
||||
|
||||
> Take note when running Lighthouse. Use the --testnet parameter to specify the testnet you whish to participate in. Medalla is currently the default, so make sure to use --testnet altona to join the Altona testnet.
|
||||
|
||||
## 2. Submit your deposit to Goerli
|
||||
|
||||
<div class="form-signin" id="uploadDiv">
|
||||
<p>Upload the <code>eth1_deposit_data.rlp</code> file from your validator
|
||||
directory (created in the previous step) to submit your 32 Goerli-ETH
|
||||
deposit using Metamask.</p>
|
||||
<p>Note that the method you used in step 1 will determine where this file is
|
||||
located.</p>
|
||||
<input id="fileInput" type="file" style="display: none">
|
||||
<button id="uploadButton" class="btn btn-lg btn-primary btn-block"
|
||||
type="submit">Upload and Submit Deposit</button>
|
||||
</div>
|
||||
|
||||
<div class="form-signin" id="waitingDiv" style="display: none">
|
||||
<p style="color: green">Your validator deposit was submitted and this step is complete.</p>
|
||||
<p>See the transaction on <a id="txLink" target="_blank"
|
||||
href="https://etherscan.io">Etherscan</a>
|
||||
or <a href="">reload</a> to perform another deposit.</p>
|
||||
</div>
|
||||
|
||||
<div class="form-signin" id="errorDiv" style="display: none">
|
||||
<h4 class="h3 mb-3 font-weight-normal">Error</h4>
|
||||
<p id="errorText" style="color: red">Unknown error.</p>
|
||||
<p style="color: red">Please refresh to reupload.</p>
|
||||
</div>
|
||||
|
||||
> This deposit is made using gETH (Goerli ETH) which has no real value. Please don't ever
|
||||
> send _real_ ETH to our deposit contract!
|
||||
|
||||
## 3. Leave Lighthouse running
|
||||
|
||||
Leave your beacon node and validator client running and you'll see logs as the
|
||||
beacon node stays synced with the network while the validator client produces
|
||||
blocks and attestations.
|
||||
|
||||
It will take 4-8+ hours for the beacon chain to process and activate your
|
||||
validator, however you'll know you're active when the validator client starts
|
||||
successfully publishing attestations each slot:
|
||||
|
||||
```
|
||||
Dec 03 08:49:40.053 INFO Successfully published attestation slot: 98, committee_index: 0, head_block: 0xa208…7fd5,
|
||||
```
|
||||
|
||||
Although you'll produce an attestation each slot, it's less common to produce a
|
||||
block. Watch for the block production logs too:
|
||||
|
||||
```
|
||||
Dec 03 08:49:36.225 INFO Successfully published block slot: 98, attestations: 2, deposits: 0, service: block
|
||||
```
|
||||
|
||||
If you see any `ERRO` (error) logs, please reach out on
|
||||
[Discord](https://discord.gg/cyAszAh) or [create an
|
||||
issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
Don't forget to checkout the open-source block explorer for the Lighthouse
|
||||
testnet at
|
||||
[lighthouse-testnet3.beaconcha.in](https://lighthouse-testnet3.beaconcha.in/).
|
||||
|
||||
Happy staking!
|
||||
|
||||
|
||||
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
|
||||
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
|
||||
<script charset="utf-8"
|
||||
src="https://cdn.ethers.io/scripts/ethers-v4.min.js"
|
||||
type="text/javascript">
|
||||
</script>
|
||||
<script src="js/deposit.js"></script>
|
||||
@@ -1,11 +1,7 @@
|
||||
# Docker Guide
|
||||
|
||||
This repository has a `Dockerfile` in the root which builds an image with the
|
||||
`lighthouse` binary installed.
|
||||
|
||||
A pre-built image is available on Docker Hub and the
|
||||
[sigp/lighthouse](https://github.com/sigp/lighthouse-docker) repository
|
||||
contains a full-featured `docker-compose` environment.
|
||||
`lighthouse` binary installed. A pre-built image is available on Docker Hub.
|
||||
|
||||
## Obtaining the Docker image
|
||||
|
||||
@@ -20,10 +16,28 @@ Lighthouse maintains the
|
||||
Docker Hub repository which provides an easy way to run Lighthouse without
|
||||
building the image yourself.
|
||||
|
||||
Obtain the latest image with:
|
||||
|
||||
```bash
|
||||
$ docker pull sigp/lighthouse
|
||||
```
|
||||
|
||||
Download and test the image with:
|
||||
|
||||
```bash
|
||||
$ docker run sigp/lighthouse lighthouse --help
|
||||
$ docker run sigp/lighthouse lighthouse --version
|
||||
```
|
||||
|
||||
If you can see the latest [Lighthouse
|
||||
release](https://github.com/sigp/lighthouse/releases) version (see example
|
||||
below), then you've
|
||||
successfully installed Lighthouse via Docker.
|
||||
|
||||
#### Example Version Output
|
||||
|
||||
```
|
||||
Lighthouse vx.x.xx-xxxxxxxxx
|
||||
BLS Library: xxxx-xxxxxxx
|
||||
```
|
||||
|
||||
> Note: when you're running the Docker Hub image you're relying upon a
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
# HTTP API
|
||||
|
||||
[OpenAPI Specification](https://ethereum.github.io/eth2.0-APIs/#/)
|
||||
|
||||
## Beacon Node
|
||||
|
||||
A Lighthouse beacon node can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `localhost:5052`.
|
||||
|
||||
The following CLI flags control the HTTP server:
|
||||
@@ -9,24 +13,10 @@ The following CLI flags control the HTTP server:
|
||||
- `--http-port`: specify the listen port of the server.
|
||||
- `--http-address`: specify the listen address of the server.
|
||||
|
||||
The API is logically divided into several core endpoints, each documented in
|
||||
detail:
|
||||
|
||||
Endpoint | Description |
|
||||
| --- | -- |
|
||||
[`/node`](./http/node.md) | General information about the beacon node.
|
||||
[`/beacon`](./http/beacon.md) | General information about the beacon chain.
|
||||
[`/validator`](./http/validator.md) | Provides functionality to validator clients.
|
||||
[`/consensus`](./http/consensus.md) | Proof-of-stake voting statistics.
|
||||
[`/network`](./http/network.md) | Information about the p2p network.
|
||||
[`/spec`](./http/spec.md) | Information about the specs that the client is running.
|
||||
[`/advanced`](./http/advanced.md) | Provides endpoints for advanced inspection of Lighthouse specific objects.
|
||||
[`/lighthouse`](./http/lighthouse.md) | Provides lighthouse specific endpoints.
|
||||
|
||||
_Please note: The OpenAPI format at
|
||||
[SwaggerHub: Lighthouse REST
|
||||
API](https://app.swaggerhub.com/apis-docs/spble/lighthouse_rest_api/0.2.0) has
|
||||
been **deprecated**. This documentation is now the source of truth for the REST API._
|
||||
The schema of the API aligns with the standard Eth2 Beacon Node API as defined
|
||||
at [github.com/ethereum/eth2.0-APIs](https://github.com/ethereum/eth2.0-APIs).
|
||||
It is an easy-to-use RESTful HTTP/JSON API. An interactive specification is
|
||||
available [here](https://ethereum.github.io/eth2.0-APIs/#/).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
||||
@@ -1,115 +0,0 @@
|
||||
# Lighthouse REST API: `/advanced`
|
||||
|
||||
The `/advanced` endpoints provide information Lighthouse specific data structures for advanced debugging.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/advanced/fork_choice`](#advancedfork_choice) | Get the `proto_array` fork choice object.
|
||||
[`/advanced/operation_pool`](#advancedoperation_pool) | Get the Lighthouse `PersistedOperationPool` object.
|
||||
|
||||
|
||||
## `/advanced/fork_choice`
|
||||
|
||||
Requests the `proto_array` fork choice object as represented in Lighthouse.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/advanced/fork_choice`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"prune_threshold": 256,
|
||||
"justified_epoch": 25,
|
||||
"finalized_epoch": 24,
|
||||
"nodes": [
|
||||
{
|
||||
"slot": 544,
|
||||
"root": "0x27103c56d4427cb4309dd202920ead6381d54d43277c29cf0572ddf0d528e6ea",
|
||||
"parent": null,
|
||||
"justified_epoch": 16,
|
||||
"finalized_epoch": 15,
|
||||
"weight": 256000000000,
|
||||
"best_child": 1,
|
||||
"best_descendant": 296
|
||||
},
|
||||
{
|
||||
"slot": 545,
|
||||
"root": "0x09af0e8d4e781ea4280c9c969d168839c564fab3a03942e7db0bfbede7d4c745",
|
||||
"parent": 0,
|
||||
"justified_epoch": 16,
|
||||
"finalized_epoch": 15,
|
||||
"weight": 256000000000,
|
||||
"best_child": 2,
|
||||
"best_descendant": 296
|
||||
},
|
||||
],
|
||||
"indices": {
|
||||
"0xb935bb3651eeddcb2d2961bf307156850de982021087062033f02576d5df00a3": 59,
|
||||
"0x8f4ec47a34c6c1d69ede64d27165d195f7e2a97c711808ce51f1071a6e12d5b9": 189,
|
||||
"0xf675eba701ef77ee2803a130dda89c3c5673a604d2782c9e25ea2be300d7d2da": 173,
|
||||
"0x488a483c8d5083faaf5f9535c051b9f373ba60d5a16e77ddb1775f248245b281": 37
|
||||
}
|
||||
}
|
||||
```
|
||||
_Truncated for brevity._
|
||||
|
||||
## `/advanced/operation_pool`
|
||||
|
||||
Requests the `PersistedOperationPool` object as represented in Lighthouse.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/advanced/operation_pool`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"attestations": [
|
||||
[
|
||||
{
|
||||
"v": [39, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 112, 118, 215, 252, 51, 186, 76, 156, 157, 99, 91, 4, 137, 195, 209, 224, 26, 233, 233, 184, 38, 89, 215, 177, 247, 97, 243, 119, 229, 69, 50, 90, 24, 0, 0, 0, 0, 0, 0, 0, 79, 37, 38, 210, 96, 235, 121, 142, 129, 136, 206, 214, 179, 132, 22, 19, 222, 213, 203, 46, 112, 192, 26, 5, 254, 26, 103, 170, 158, 205, 72, 3, 25, 0, 0, 0, 0, 0, 0, 0, 164, 50, 214, 67, 98, 13, 50, 180, 108, 232, 248, 109, 128, 45, 177, 23, 221, 24, 218, 211, 8, 152, 172, 120, 24, 86, 198, 103, 68, 164, 67, 202, 1, 0, 0, 0, 0, 0, 0, 0]
|
||||
},
|
||||
[
|
||||
{
|
||||
"aggregation_bits": "0x03",
|
||||
"data": {
|
||||
"slot": 807,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0x7076d7fc33ba4c9c9d635b0489c3d1e01ae9e9b82659d7b1f761f377e545325a",
|
||||
"source": {
|
||||
"epoch": 24,
|
||||
"root": "0x4f2526d260eb798e8188ced6b3841613ded5cb2e70c01a05fe1a67aa9ecd4803"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 25,
|
||||
"root": "0xa432d643620d32b46ce8f86d802db117dd18dad30898ac781856c66744a443ca"
|
||||
}
|
||||
},
|
||||
"signature": "0x8b1d624b0cd5a7a0e13944e90826878a230e3901db34ea87dbef5b145ade2fedbc830b6752a38a0937a1594211ab85b615d65f9eef0baccd270acca945786036695f4db969d9ff1693c505c0fe568b2fe9831ea78a74cbf7c945122231f04026"
|
||||
}
|
||||
]
|
||||
]
|
||||
],
|
||||
"attester_slashings": [],
|
||||
"proposer_slashings": [],
|
||||
"voluntary_exits": []
|
||||
}
|
||||
```
|
||||
_Truncated for brevity._
|
||||
@@ -1,784 +0,0 @@
|
||||
# Lighthouse REST API: `/beacon`
|
||||
|
||||
The `/beacon` endpoints provide information about the canonical head of the
|
||||
beacon chain and also historical information about beacon blocks and states.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/beacon/head`](#beaconhead) | Info about the block at the head of the chain.
|
||||
[`/beacon/heads`](#beaconheads) | Returns a list of all known chain heads.
|
||||
[`/beacon/block`](#beaconblock) | Get a `BeaconBlock` by slot or root.
|
||||
[`/beacon/block_root`](#beaconblock_root) | Resolve a slot to a block root.
|
||||
[`/beacon/fork`](#beaconfork) | Get the fork of the head of the chain.
|
||||
[`/beacon/genesis_time`](#beacongenesis_time) | Get the genesis time from the beacon state.
|
||||
[`/beacon/genesis_validators_root`](#beacongenesis_validators_root) | Get the genesis validators root.
|
||||
[`/beacon/validators`](#beaconvalidators) | Query for one or more validators.
|
||||
[`/beacon/validators/all`](#beaconvalidatorsall) | Get all validators.
|
||||
[`/beacon/validators/active`](#beaconvalidatorsactive) | Get all active validators.
|
||||
[`/beacon/state`](#beaconstate) | Get a `BeaconState` by slot or root.
|
||||
[`/beacon/state_root`](#beaconstate_root) | Resolve a slot to a state root.
|
||||
[`/beacon/state/genesis`](#beaconstategenesis) | Get a `BeaconState` at genesis.
|
||||
[`/beacon/committees`](#beaconcommittees) | Get the shuffling for an epoch.
|
||||
[`/beacon/proposer_slashing`](#beaconproposer_slashing) | Insert a proposer slashing
|
||||
[`/beacon/attester_slashing`](#beaconattester_slashing) | Insert an attester slashing
|
||||
|
||||
## `/beacon/head`
|
||||
|
||||
Requests information about the head of the beacon chain, from the node's
|
||||
perspective.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/head`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"slot": 37923,
|
||||
"block_root": "0xe865d4805395a0776b8abe46d714a9e64914ab8dc5ff66624e5a1776bcc1684b",
|
||||
"state_root": "0xe500e3567ab273c9a6f8a057440deff476ab236f0983da27f201ee9494a879f0",
|
||||
"finalized_slot": 37856,
|
||||
"finalized_block_root": "0xbdae152b62acef1e5c332697567d2b89e358628790b8273729096da670b23e86",
|
||||
"justified_slot": 37888,
|
||||
"justified_block_root": "0x01c2f516a407d8fdda23cad4ed4381e4ab8913d638f935a2fe9bd00d6ced5ec4",
|
||||
"previous_justified_slot": 37856,
|
||||
"previous_justified_block_root": "0xbdae152b62acef1e5c332697567d2b89e358628790b8273729096da670b23e86"
|
||||
}
|
||||
```
|
||||
|
||||
## `/beacon/heads`
|
||||
|
||||
Returns the roots of all known head blocks. Only one of these roots is the
|
||||
canonical head and that is decided by the fork choice algorithm. See [`/beacon/head`](#beaconhead) for the canonical head.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/heads`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"beacon_block_root": "0x226b2fd7c5f3d31dbb21444b96dfafe715f0017cd16545ecc4ffa87229496a69",
|
||||
"beacon_block_slot": 38373
|
||||
},
|
||||
{
|
||||
"beacon_block_root": "0x41ed5b253c4fc841cba8a6d44acbe101866bc674c3cfa3c4e9f7388f465aa15b",
|
||||
"beacon_block_slot": 38375
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## `/beacon/block`
|
||||
|
||||
Request that the node return a beacon chain block that matches the provided
|
||||
criteria (a block `root` or beacon chain `slot`). Only one of the parameters
|
||||
should be provided as a criteria.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/block`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `slot`, `root`
|
||||
Typical Responses | 200, 404
|
||||
|
||||
### Parameters
|
||||
|
||||
Accepts **only one** of the following parameters:
|
||||
|
||||
- `slot` (`Slot`): Query by slot number. Any block returned must be in the canonical chain (i.e.,
|
||||
either the head or an ancestor of the head).
|
||||
- `root` (`Bytes32`): Query by tree hash root. A returned block is not required to be in the
|
||||
canonical chain.
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing a single [`SignedBeaconBlock`](https://github.com/ethereum/eth2.0-specs/blob/v0.10.0/specs/phase0/beacon-chain.md#signedbeaconblock) and the block root of the inner [`BeaconBlock`](https://github.com/ethereum/eth2.0-specs/blob/v0.10.0/specs/phase0/beacon-chain.md#beaconblock).
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"root": "0xc35ddf4e71c31774e0594bd7eb32dfe50b54dbc40abd594944254b4ec8895196",
|
||||
"beacon_block": {
|
||||
"message": {
|
||||
"slot": 0,
|
||||
"proposer_index": 14,
|
||||
"parent_root": "0x0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"state_root": "0xf15690b6be4ed42ea1ee0741eb4bfd4619d37be8229b84b4ddd480fb028dcc8f",
|
||||
"body": {
|
||||
"randao_reveal": "0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
|
||||
"eth1_data": {
|
||||
"deposit_root": "0x0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"deposit_count": 0,
|
||||
"block_hash": "0x0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"graffiti": "0x0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"proposer_slashings": [],
|
||||
"attester_slashings": [],
|
||||
"attestations": [],
|
||||
"deposits": [],
|
||||
"voluntary_exits": []
|
||||
}
|
||||
},
|
||||
"signature": "0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `/beacon/block_root`
|
||||
|
||||
Returns the block root for the given slot in the canonical chain. If there
|
||||
is a re-org, the same slot may return a different root.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/block_root`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `slot`
|
||||
Typical Responses | 200, 404
|
||||
|
||||
## Parameters
|
||||
|
||||
- `slot` (`Slot`): the slot to be resolved to a root.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
"0xc35ddf4e71c31774e0594bd7eb32dfe50b54dbc40abd594944254b4ec8895196"
|
||||
```
|
||||
|
||||
## `/beacon/committees`
|
||||
|
||||
Request the committees (a.k.a. "shuffling") for all slots and committee indices
|
||||
in a given `epoch`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/committees`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `epoch`
|
||||
Typical Responses | 200/500
|
||||
|
||||
### Parameters
|
||||
|
||||
The `epoch` (`Epoch`) query parameter is required and defines the epoch for
|
||||
which the committees will be returned. All slots contained within the response will
|
||||
be inside this epoch.
|
||||
|
||||
### Returns
|
||||
|
||||
A list of beacon committees.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"slot": 4768,
|
||||
"index": 0,
|
||||
"committee": [
|
||||
1154,
|
||||
492,
|
||||
9667,
|
||||
3089,
|
||||
8987,
|
||||
1421,
|
||||
224,
|
||||
11243,
|
||||
2127,
|
||||
2329,
|
||||
188,
|
||||
482,
|
||||
486
|
||||
]
|
||||
},
|
||||
{
|
||||
"slot": 4768,
|
||||
"index": 1,
|
||||
"committee": [
|
||||
5929,
|
||||
8482,
|
||||
5528,
|
||||
6130,
|
||||
14343,
|
||||
9777,
|
||||
10808,
|
||||
12739,
|
||||
15234,
|
||||
12819,
|
||||
5423,
|
||||
6320,
|
||||
9991
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
_Truncated for brevity._
|
||||
|
||||
## `/beacon/fork`
|
||||
|
||||
Request that the node return the `fork` of the current head.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/fork`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing the [`Fork`](https://github.com/ethereum/eth2.0-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#fork) of the current head.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"previous_version": "0x00000000",
|
||||
"current_version": "0x00000000",
|
||||
"epoch": 0
|
||||
}
|
||||
```
|
||||
|
||||
## `/beacon/genesis_time`
|
||||
|
||||
Request that the node return the genesis time from the beacon state.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/genesis_time`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing the genesis time.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
1581576353
|
||||
```
|
||||
|
||||
## `/beacon/genesis_validators_root`
|
||||
|
||||
Request that the node return the genesis validators root from the beacon state.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/genesis_validators_root`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing the genesis validators root.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
0x4fbf23439a7a9b9dd91650e64e8124012dde5e2ea2940c552b86f04eb47f95de
|
||||
```
|
||||
|
||||
## `/beacon/validators`
|
||||
|
||||
Request that the node returns information about one or more validator public
|
||||
keys. This request takes the form of a `POST` request to allow sending a large
|
||||
number of pubkeys in the request.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/validators`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects the following object in the POST request body:
|
||||
|
||||
```
|
||||
{
|
||||
state_root: Bytes32,
|
||||
pubkeys: [PublicKey]
|
||||
}
|
||||
```
|
||||
|
||||
The `state_root` field indicates which `BeaconState` should be used to collect
|
||||
the information. The `state_root` is optional and omitting it will result in
|
||||
the canonical head state being used.
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object describing several aspects of the given validator.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"pubkeys": [
|
||||
"0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"0x42f87bc7c8fa10408425bbeeeb3dc3874242b4bd92f57775b60b39142426f9ec80b273a64269332d97bdb7d93ae05a42"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
_Note: for demonstration purposes the second pubkey is some unknown pubkey._
|
||||
|
||||
### Response Body
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"pubkey": "0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"validator_index": 14935,
|
||||
"balance": 3228885987,
|
||||
"validator": {
|
||||
"pubkey": "0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"withdrawal_credentials": "0x00b7bec22d5bda6b2cca1343d4f640d0e9ccc204a06a73703605c590d4c0d28e",
|
||||
"effective_balance": 3200000000,
|
||||
"slashed": false,
|
||||
"activation_eligibility_epoch": 0,
|
||||
"activation_epoch": 0,
|
||||
"exit_epoch": 18446744073709551615,
|
||||
"withdrawable_epoch": 18446744073709551615
|
||||
}
|
||||
},
|
||||
{
|
||||
"pubkey": "0x42f87bc7c8fa10408425bbeeeb3dc3874242b4bd92f57775b60b39142426f9ec80b273a64269332d97bdb7d93ae05a42",
|
||||
"validator_index": null,
|
||||
"balance": null,
|
||||
"validator": null
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## `/beacon/validators/all`
|
||||
|
||||
Returns all validators.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/validators/all`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `state_root` (optional)
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
The optional `state_root` (`Bytes32`) query parameter indicates which
|
||||
`BeaconState` should be used to collect the information. When omitted, the
|
||||
canonical head state will be used.
|
||||
|
||||
### Returns
|
||||
|
||||
The return format is identical to the [`/beacon/validators`](#beaconvalidators) response body.
|
||||
|
||||
|
||||
## `/beacon/validators/active`
|
||||
|
||||
Returns all validators that are active in the state defined by `state_root`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/validators/active`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `state_root` (optional)
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
The optional `state_root` (`Bytes32`) query parameter indicates which
|
||||
`BeaconState` should be used to collect the information. When omitted, the
|
||||
canonical head state will be used.
|
||||
|
||||
### Returns
|
||||
|
||||
The return format is identical to the [`/beacon/validators`](#beaconvalidators) response body.
|
||||
|
||||
|
||||
## `/beacon/state`
|
||||
|
||||
Request that the node return a beacon chain state that matches the provided
|
||||
criteria (a state `root` or beacon chain `slot`). Only one of the parameters
|
||||
should be provided as a criteria.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/state`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `slot`, `root`
|
||||
Typical Responses | 200, 404
|
||||
|
||||
### Parameters
|
||||
|
||||
Accepts **only one** of the following parameters:
|
||||
|
||||
- `slot` (`Slot`): Query by slot number. Any state returned must be in the canonical chain (i.e.,
|
||||
either the head or an ancestor of the head).
|
||||
- `root` (`Bytes32`): Query by tree hash root. A returned state is not required to be in the
|
||||
canonical chain.
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing a single
|
||||
[`BeaconState`](https://github.com/ethereum/eth2.0-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#beaconstate)
|
||||
and its tree hash root.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"root": "0x528e54ca5d4c957729a73f40fc513ae312e054c7295775c4a2b21f423416a72b",
|
||||
"beacon_state": {
|
||||
"genesis_time": 1575652800,
|
||||
"genesis_validators_root": "0xa8a9226edee1b2627fb4117d7dea4996e64dec2998f37f6e824f74f2ce39a538",
|
||||
"slot": 18478
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
_Truncated for brevity._
|
||||
|
||||
## `/beacon/state_root`
|
||||
|
||||
Returns the state root for the given slot in the canonical chain. If there
|
||||
is a re-org, the same slot may return a different root.
|
||||
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/state_root`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `slot`
|
||||
Typical Responses | 200, 404
|
||||
|
||||
## Parameters
|
||||
|
||||
- `slot` (`Slot`): the slot to be resolved to a root.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
"0xf15690b6be4ed42ea1ee0741eb4bfd4619d37be8229b84b4ddd480fb028dcc8f"
|
||||
```
|
||||
|
||||
## `/beacon/state/genesis`
|
||||
|
||||
Request that the node return a beacon chain state at genesis (slot 0).
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/state/genesis`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing the genesis
|
||||
[`BeaconState`](https://github.com/ethereum/eth2.0-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#beaconstate).
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"genesis_time": 1581576353,
|
||||
"slot": 0,
|
||||
"fork": {
|
||||
"previous_version": "0x00000000",
|
||||
"current_version": "0x00000000",
|
||||
"epoch": 0
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
_Truncated for brevity._
|
||||
|
||||
|
||||
## `/beacon/state/committees`
|
||||
|
||||
Request that the node return a beacon chain state at genesis (slot 0).
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/state/genesis`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `epoch`
|
||||
Typical Responses | 200
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns an object containing the committees for a given epoch.
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
{"slot":64,"index":0,"committee":[]},
|
||||
{"slot":65,"index":0,"committee":[3]},
|
||||
{"slot":66,"index":0,"committee":[]},
|
||||
{"slot":67,"index":0,"committee":[14]},
|
||||
{"slot":68,"index":0,"committee":[]},
|
||||
{"slot":69,"index":0,"committee":[9]},
|
||||
{"slot":70,"index":0,"committee":[]},
|
||||
{"slot":71,"index":0,"committee":[11]},
|
||||
{"slot":72,"index":0,"committee":[]},
|
||||
{"slot":73,"index":0,"committee":[5]},
|
||||
{"slot":74,"index":0,"committee":[]},
|
||||
{"slot":75,"index":0,"committee":[15]},
|
||||
{"slot":76,"index":0,"committee":[]},
|
||||
{"slot":77,"index":0,"committee":[0]}
|
||||
]
|
||||
```
|
||||
|
||||
_Truncated for brevity._
|
||||
|
||||
|
||||
## `/beacon/attester_slashing`
|
||||
|
||||
Accepts an `attester_slashing` and verifies it. If it is valid, it is added to the operations pool for potential inclusion in a future block. Returns a 400 error if the `attester_slashing` is invalid.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/attester_slashing`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200/400
|
||||
|
||||
### Parameters
|
||||
|
||||
Expects the following object in the POST request body:
|
||||
|
||||
```
|
||||
{
|
||||
attestation_1: {
|
||||
attesting_indices: [u64],
|
||||
data: {
|
||||
slot: Slot,
|
||||
index: u64,
|
||||
beacon_block_root: Bytes32,
|
||||
source: {
|
||||
epoch: Epoch,
|
||||
root: Bytes32
|
||||
},
|
||||
target: {
|
||||
epoch: Epoch,
|
||||
root: Bytes32
|
||||
}
|
||||
}
|
||||
signature: Bytes32
|
||||
},
|
||||
attestation_2: {
|
||||
attesting_indices: [u64],
|
||||
data: {
|
||||
slot: Slot,
|
||||
index: u64,
|
||||
beacon_block_root: Bytes32,
|
||||
source: {
|
||||
epoch: Epoch,
|
||||
root: Bytes32
|
||||
},
|
||||
target: {
|
||||
epoch: Epoch,
|
||||
root: Bytes32
|
||||
}
|
||||
}
|
||||
signature: Bytes32
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Returns
|
||||
|
||||
Returns `true` if the attester slashing was inserted successfully, or the corresponding error if it failed.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"attestation_1": {
|
||||
"attesting_indices": [0],
|
||||
"data": {
|
||||
"slot": 1,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0x0000000000000000000000000000000000000000000000000100000000000000",
|
||||
"source": {
|
||||
"epoch": 1,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000100000000000000"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 1,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000100000000000000"
|
||||
}
|
||||
},
|
||||
"signature": "0xb47f7397cd944b8d5856a13352166bbe74c85625a45b14b7347fc2c9f6f6f82acee674c65bc9ceb576fcf78387a6731c0b0eb3f8371c70db2da4e7f5dfbc451730c159d67263d3db56b6d0e009e4287a8ba3efcacac30b3ae3447e89dc71b5b9"
|
||||
},
|
||||
"attestation_2": {
|
||||
"attesting_indices": [0],
|
||||
"data": {
|
||||
"slot": 1,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0x0000000000000000000000000000000000000000000000000100000000000000",
|
||||
"source": {
|
||||
"epoch": 1,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000100000000000000"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 1,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000200000000000000"
|
||||
}
|
||||
},
|
||||
"signature": "0x93fef587a63acf72aaf8df627718fd43cb268035764071f802ffb4370a2969d226595cc650f4c0bf2291ae0c0a41fcac1700f318603d75d34bcb4b9f4a8368f61eeea0e1f5d969d92d5073ba5fbadec102b45ec87d418d25168d2e3c74b9fcbb"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
_Note: data sent here is for demonstration purposes only_
|
||||
|
||||
|
||||
|
||||
## `/beacon/proposer_slashing`
|
||||
|
||||
Accepts a `proposer_slashing` and verifies it. If it is valid, it is added to the operations pool for potential inclusion in a future block. Returns an 400 error if the `proposer_slashing` is invalid.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/beacon/proposer_slashing`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200/400
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects the following object in the POST request body:
|
||||
|
||||
```
|
||||
{
|
||||
proposer_index: u64,
|
||||
header_1: {
|
||||
slot: Slot,
|
||||
parent_root: Bytes32,
|
||||
state_root: Bytes32,
|
||||
body_root: Bytes32,
|
||||
signature: Bytes32
|
||||
},
|
||||
header_2: {
|
||||
slot: Slot,
|
||||
parent_root: Bytes32,
|
||||
state_root: Bytes32,
|
||||
body_root: Bytes32,
|
||||
signature: Bytes32
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Returns
|
||||
|
||||
Returns `true` if the proposer slashing was inserted successfully, or the corresponding error if it failed.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"proposer_index": 0,
|
||||
"header_1": {
|
||||
"slot": 0,
|
||||
"parent_root": "0x0101010101010101010101010101010101010101010101010101010101010101",
|
||||
"state_root": "0x0101010101010101010101010101010101010101010101010101010101010101",
|
||||
"body_root": "0x0101010101010101010101010101010101010101010101010101010101010101",
|
||||
"signature": "0xb8970d1342c6d5779c700ec366efd0ca819937ca330960db3ca5a55eb370a3edd83f4cbb2f74d06e82f934fcbd4bb80609a19c2254cc8b3532a4efff9e80edf312ac735757c059d77126851e377f875593e64ba50d1dffe69a809a409202dd12"
|
||||
},
|
||||
"header_2": {
|
||||
"slot": 0,
|
||||
"parent_root": "0x0202020202020202020202020202020202020202020202020202020202020202",
|
||||
"state_root": "0x0101010101010101010101010101010101010101010101010101010101010101",
|
||||
"body_root": "0x0101010101010101010101010101010101010101010101010101010101010101",
|
||||
"signature": "0xb60e6b348698a34e59b22e0af96f8809f977f00f95d52375383ade8d22e9102270a66c6d52b0434214897e11ca4896871510c01b3fd74d62108a855658d5705fcfc4ced5136264a1c6496f05918576926aa191b1ad311b7e27f5aa2167aba294"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
_Note: data sent here is for demonstration purposes only_
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,182 +0,0 @@
|
||||
# Lighthouse REST API: `/lighthouse`
|
||||
|
||||
The `/lighthouse` endpoints provide lighthouse-specific information about the beacon node.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/lighthouse/syncing`](#lighthousesyncing) | Get the node's syncing status
|
||||
[`/lighthouse/peers`](#lighthousepeers) | Get the peers info known by the beacon node
|
||||
[`/lighthouse/connected_peers`](#lighthousepeers) | Get the connected_peers known by the beacon node
|
||||
|
||||
## `/lighthouse/syncing`
|
||||
|
||||
Requests the syncing state of a Lighthouse beacon node. Lighthouse as a
|
||||
custom sync protocol, this request gets Lighthouse-specific sync information.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/syncing`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
If the node is undergoing a finalization sync:
|
||||
```json
|
||||
{
|
||||
"SyncingFinalized": {
|
||||
"start_slot": 10,
|
||||
"head_slot": 20,
|
||||
"head_root":"0x74020d0e3c3c02d2ea6279d5760f7d0dd376c4924beaaec4d5c0cefd1c0c4465"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If the node is undergoing a head chain sync:
|
||||
```json
|
||||
{
|
||||
"SyncingHead": {
|
||||
"start_slot":0,
|
||||
"head_slot":1195
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If the node is synced
|
||||
```json
|
||||
{
|
||||
"Synced"
|
||||
}
|
||||
```
|
||||
|
||||
## `/lighthouse/peers`
|
||||
|
||||
Get all known peers info from the beacon node.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/peers`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"peer_id" : "16Uiu2HAmTEinipUS3haxqucrn7d7SmCKx5XzAVbAZCiNW54ncynG",
|
||||
"peer_info" : {
|
||||
"_status" : "Healthy",
|
||||
"client" : {
|
||||
"agent_string" : "github.com/libp2p/go-libp2p",
|
||||
"kind" : "Prysm",
|
||||
"os_version" : "unknown",
|
||||
"protocol_version" : "ipfs/0.1.0",
|
||||
"version" : "unknown"
|
||||
},
|
||||
"connection_status" : {
|
||||
"Disconnected" : {
|
||||
"since" : 3
|
||||
}
|
||||
},
|
||||
"listening_addresses" : [
|
||||
"/ip4/10.3.58.241/tcp/9001",
|
||||
"/ip4/35.172.14.146/tcp/9001",
|
||||
"/ip4/35.172.14.146/tcp/9001"
|
||||
],
|
||||
"meta_data" : {
|
||||
"attnets" : "0x0000000000000000",
|
||||
"seq_number" : 0
|
||||
},
|
||||
"reputation" : 20,
|
||||
"sync_status" : {
|
||||
"Synced" : {
|
||||
"status_head_slot" : 18146
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
{
|
||||
"peer_id" : "16Uiu2HAm8XZfPv3YjktCjitSRtfS7UfHfEvpiUyHrdiX6uAD55xZ",
|
||||
"peer_info" : {
|
||||
"_status" : "Healthy",
|
||||
"client" : {
|
||||
"agent_string" : null,
|
||||
"kind" : "Unknown",
|
||||
"os_version" : "unknown",
|
||||
"protocol_version" : "unknown",
|
||||
"version" : "unknown"
|
||||
},
|
||||
"connection_status" : {
|
||||
"Disconnected" : {
|
||||
"since" : 5
|
||||
}
|
||||
},
|
||||
"listening_addresses" : [],
|
||||
"meta_data" : {
|
||||
"attnets" : "0x0900000000000000",
|
||||
"seq_number" : 0
|
||||
},
|
||||
"reputation" : 20,
|
||||
"sync_status" : "Unknown"
|
||||
}
|
||||
},
|
||||
]
|
||||
```
|
||||
|
||||
## `/lighthouse/connected_peers`
|
||||
|
||||
Get all known peers info from the beacon node.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/connected_peers`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"peer_id" : "16Uiu2HAm8XZfPv3YjktCjitSRtfS7UfHfEvpiUyHrdiX6uAD55xZ",
|
||||
"peer_info" : {
|
||||
"_status" : "Healthy",
|
||||
"client" : {
|
||||
"agent_string" : null,
|
||||
"kind" : "Unknown",
|
||||
"os_version" : "unknown",
|
||||
"protocol_version" : "unknown",
|
||||
"version" : "unknown"
|
||||
},
|
||||
"connection_status" : {
|
||||
"Connected" : {
|
||||
"in" : 5,
|
||||
"out" : 2
|
||||
}
|
||||
},
|
||||
"listening_addresses" : [],
|
||||
"meta_data" : {
|
||||
"attnets" : "0x0900000000000000",
|
||||
"seq_number" : 0
|
||||
},
|
||||
"reputation" : 20,
|
||||
"sync_status" : "Unknown"
|
||||
}
|
||||
},
|
||||
]
|
||||
```
|
||||
@@ -1,148 +0,0 @@
|
||||
# Lighthouse REST API: `/network`
|
||||
|
||||
The `/network` endpoints provide information about the p2p network that
|
||||
Lighthouse uses to communicate with other beacon nodes.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/network/enr`](#networkenr) | Get the local node's `ENR` as base64 .
|
||||
[`/network/peer_count`](#networkpeer_count) | Get the count of connected peers.
|
||||
[`/network/peer_id`](#networkpeer_id) | Get a node's libp2p `PeerId`.
|
||||
[`/network/peers`](#networkpeers) | List a node's connected peers (as `PeerIds`).
|
||||
[`/network/listen_port`](#networklisten_port) | Get a node's libp2p listening port.
|
||||
[`/network/listen_addresses`](#networklisten_addresses) | Get a list of libp2p multiaddr the node is listening on.
|
||||
|
||||
## `network/enr`
|
||||
|
||||
Requests the beacon node for its listening `ENR` address.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/network/enr`
|
||||
Method | GET
|
||||
JSON Encoding | String (base64)
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
"-IW4QPYyGkXJSuJ2Eji8b-m4PTNrW4YMdBsNOBrYAdCk8NLMJcddAiQlpcv6G_hdNjiLACOPTkqTBhUjnC0wtIIhyQkEgmlwhKwqAPqDdGNwgiMog3VkcIIjKIlzZWNwMjU2azGhA1sBKo0yCfw4Z_jbggwflNfftjwKACu-a-CoFAQHJnrm"
|
||||
```
|
||||
|
||||
## `/network/peer_count`
|
||||
|
||||
Requests the count of peers connected to the client.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/network/peer_count`
|
||||
Method | GET
|
||||
JSON Encoding | Number
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
5
|
||||
```
|
||||
## `/network/peer_id`
|
||||
|
||||
Requests the beacon node's local `PeerId`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/network/peer_id`
|
||||
Method | GET
|
||||
JSON Encoding | String (base58)
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
"QmVFcULBYZecPdCKgGmpEYDqJLqvMecfhJadVBtB371Avd"
|
||||
```
|
||||
|
||||
## `/network/peers`
|
||||
|
||||
Requests one `MultiAddr` for each peer connected to the beacon node.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/network/peers`
|
||||
Method | GET
|
||||
JSON Encoding | [String] (base58)
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
"QmaPGeXcfKFMU13d8VgbnnpeTxcvoFoD9bUpnRGMUJ1L9w",
|
||||
"QmZt47cP8V96MgiS35WzHKpPbKVBMqr1eoBNTLhQPqpP3m"
|
||||
]
|
||||
```
|
||||
|
||||
|
||||
## `/network/listen_port`
|
||||
|
||||
Requests the TCP port that the client's libp2p service is listening on.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/network/listen_port`
|
||||
Method | GET
|
||||
JSON Encoding | Number
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
9000
|
||||
```
|
||||
|
||||
## `/network/listen_addresses`
|
||||
|
||||
Requests the list of multiaddr that the client's libp2p service is listening on.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/network/listen_addresses`
|
||||
Method | GET
|
||||
JSON Encoding | Array
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
[
|
||||
"/ip4/127.0.0.1/tcp/9000",
|
||||
"/ip4/192.168.31.115/tcp/9000",
|
||||
"/ip4/172.24.0.1/tcp/9000",
|
||||
"/ip4/172.21.0.1/tcp/9000",
|
||||
"/ip4/172.17.0.1/tcp/9000",
|
||||
"/ip4/172.18.0.1/tcp/9000",
|
||||
"/ip4/172.19.0.1/tcp/9000",
|
||||
"/ip4/172.42.0.1/tcp/9000",
|
||||
"/ip6/::1/tcp/9000"
|
||||
]
|
||||
```
|
||||
@@ -1,91 +0,0 @@
|
||||
# Lighthouse REST API: `/node`
|
||||
|
||||
The `/node` endpoints provide information about the lighthouse beacon node.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/node/version`](#nodeversion) | Get the node's version.
|
||||
[`/node/syncing`](#nodesyncing) | Get the node's syncing status.
|
||||
[`/node/health`](#nodehealth) | Get the node's health.
|
||||
|
||||
## `/node/version`
|
||||
|
||||
Requests the beacon node's version.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/node/version`
|
||||
Method | GET
|
||||
JSON Encoding | String
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
"Lighthouse-0.2.0-unstable"
|
||||
```
|
||||
|
||||
## `/node/syncing`
|
||||
|
||||
Requests the syncing status of the beacon node.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/node/syncing`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
is_syncing: true,
|
||||
sync_status: {
|
||||
starting_slot: 0,
|
||||
current_slot: 100,
|
||||
highest_slot: 200,
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `/node/health`
|
||||
|
||||
Requests information about the health of the beacon node.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/node/health`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"pid": 96160,
|
||||
"pid_num_threads": 30,
|
||||
"pid_mem_resident_set_size": 55476224,
|
||||
"pid_mem_virtual_memory_size": 2081382400,
|
||||
"sys_virt_mem_total": 16721076224,
|
||||
"sys_virt_mem_available": 7423197184,
|
||||
"sys_virt_mem_used": 8450183168,
|
||||
"sys_virt_mem_free": 3496345600,
|
||||
"sys_virt_mem_percent": 55.605743,
|
||||
"sys_loadavg_1": 1.56,
|
||||
"sys_loadavg_5": 2.61,
|
||||
"sys_loadavg_15": 2.43
|
||||
}
|
||||
```
|
||||
@@ -1,154 +0,0 @@
|
||||
# Lighthouse REST API: `/spec`
|
||||
|
||||
The `/spec` endpoints provide information about Eth2.0 specifications that the node is running.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/spec`](#spec) | Get the full spec object that a node's running.
|
||||
[`/spec/slots_per_epoch`](#specslots_per_epoch) | Get the number of slots per epoch.
|
||||
[`/spec/eth2_config`](#specseth2_config) | Get the full Eth2 config object.
|
||||
|
||||
## `/spec`
|
||||
|
||||
Requests the full spec object that a node's running.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/spec`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"genesis_slot": 0,
|
||||
"base_rewards_per_epoch": 4,
|
||||
"deposit_contract_tree_depth": 32,
|
||||
"max_committees_per_slot": 64,
|
||||
"target_committee_size": 128,
|
||||
"min_per_epoch_churn_limit": 4,
|
||||
"churn_limit_quotient": 65536,
|
||||
"shuffle_round_count": 90,
|
||||
"min_genesis_active_validator_count": 16384,
|
||||
"min_genesis_time": 1578009600,
|
||||
"min_deposit_amount": 1000000000,
|
||||
"max_effective_balance": 32000000000,
|
||||
"ejection_balance": 16000000000,
|
||||
"effective_balance_increment": 1000000000,
|
||||
"genesis_fork_version": "0x00000000",
|
||||
"bls_withdrawal_prefix_byte": "0x00",
|
||||
"genesis_delay": 172800,
|
||||
"milliseconds_per_slot": 12000,
|
||||
"min_attestation_inclusion_delay": 1,
|
||||
"min_seed_lookahead": 1,
|
||||
"max_seed_lookahead": 4,
|
||||
"min_epochs_to_inactivity_penalty": 4,
|
||||
"min_validator_withdrawability_delay": 256,
|
||||
"shard_committee_period": 2048,
|
||||
"base_reward_factor": 64,
|
||||
"whistleblower_reward_quotient": 512,
|
||||
"proposer_reward_quotient": 8,
|
||||
"inactivity_penalty_quotient": 33554432,
|
||||
"min_slashing_penalty_quotient": 32,
|
||||
"domain_beacon_proposer": 0,
|
||||
"domain_beacon_attester": 1,
|
||||
"domain_randao": 2,
|
||||
"domain_deposit": 3,
|
||||
"domain_voluntary_exit": 4,
|
||||
"safe_slots_to_update_justified": 8,
|
||||
"eth1_follow_distance": 1024,
|
||||
"seconds_per_eth1_block": 14,
|
||||
"boot_nodes": [],
|
||||
"network_id": 1
|
||||
}
|
||||
```
|
||||
|
||||
## `/spec/eth2_config`
|
||||
|
||||
Requests the full `Eth2Config` object.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/spec/eth2_config`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
{
|
||||
"spec_constants": "mainnet",
|
||||
"spec": {
|
||||
"genesis_slot": 0,
|
||||
"base_rewards_per_epoch": 4,
|
||||
"deposit_contract_tree_depth": 32,
|
||||
"max_committees_per_slot": 64,
|
||||
"target_committee_size": 128,
|
||||
"min_per_epoch_churn_limit": 4,
|
||||
"churn_limit_quotient": 65536,
|
||||
"shuffle_round_count": 90,
|
||||
"min_genesis_active_validator_count": 16384,
|
||||
"min_genesis_time": 1578009600,
|
||||
"min_deposit_amount": 1000000000,
|
||||
"max_effective_balance": 32000000000,
|
||||
"ejection_balance": 16000000000,
|
||||
"effective_balance_increment": 1000000000,
|
||||
"genesis_fork_version": "0x00000000",
|
||||
"bls_withdrawal_prefix_byte": "0x00",
|
||||
"genesis_delay": 172800,
|
||||
"milliseconds_per_slot": 12000,
|
||||
"min_attestation_inclusion_delay": 1,
|
||||
"min_seed_lookahead": 1,
|
||||
"max_seed_lookahead": 4,
|
||||
"min_epochs_to_inactivity_penalty": 4,
|
||||
"min_validator_withdrawability_delay": 256,
|
||||
"shard_committee_period": 2048,
|
||||
"base_reward_factor": 64,
|
||||
"whistleblower_reward_quotient": 512,
|
||||
"proposer_reward_quotient": 8,
|
||||
"inactivity_penalty_quotient": 33554432,
|
||||
"min_slashing_penalty_quotient": 32,
|
||||
"domain_beacon_proposer": 0,
|
||||
"domain_beacon_attester": 1,
|
||||
"domain_randao": 2,
|
||||
"domain_deposit": 3,
|
||||
"domain_voluntary_exit": 4,
|
||||
"safe_slots_to_update_justified": 8,
|
||||
"eth1_follow_distance": 1024,
|
||||
"seconds_per_eth1_block": 14,
|
||||
"boot_nodes": [],
|
||||
"network_id": 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `/spec/slots_per_epoch`
|
||||
|
||||
Requests the `SLOTS_PER_EPOCH` parameter from the specs that the node is running.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/spec/slots_per_epoch`
|
||||
Method | GET
|
||||
JSON Encoding | Number
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Example Response
|
||||
|
||||
```json
|
||||
32
|
||||
```
|
||||
@@ -1,545 +0,0 @@
|
||||
# Lighthouse REST API: `/validator`
|
||||
|
||||
The `/validator` endpoints provide the minimum functionality required for a validator
|
||||
client to connect to the beacon node and produce blocks and attestations.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | HTTP Method | Description |
|
||||
| - | - | ---- |
|
||||
[`/validator/duties`](#validatorduties) | POST | Provides block and attestation production information for validators.
|
||||
[`/validator/subscribe`](#validatorsubscribe) | POST | Subscribes a list of validators to the beacon node for a particular duty/slot.
|
||||
[`/validator/duties/all`](#validatordutiesall) | GET |Provides block and attestation production information for all validators.
|
||||
[`/validator/duties/active`](#validatordutiesactive) | GET | Provides block and attestation production information for all active validators.
|
||||
[`/validator/block`](#validatorblock-get) | GET | Retrieves the current beacon block for the validator to publish.
|
||||
[`/validator/block`](#validatorblock-post) | POST | Publishes a signed block to the network.
|
||||
[`/validator/attestation`](#validatorattestation) | GET | Retrieves the current best attestation for a validator to publish.
|
||||
[`/validator/aggregate_attestation`](#validatoraggregate_attestation) | GET | Gets an aggregate attestation for validators to sign and publish.
|
||||
[`/validator/attestations`](#validatorattestations) | POST | Publishes a list of raw unaggregated attestations to their appropriate subnets.
|
||||
[`/validator/aggregate_and_proofs`](#validatoraggregate_and_proofs) | POST | Publishes a list of Signed aggregate and proofs for validators who are aggregators.
|
||||
|
||||
## `/validator/duties`
|
||||
|
||||
Request information about when a validator must produce blocks and attestations
|
||||
at some given `epoch`. The information returned always refers to the canonical
|
||||
chain and the same input parameters may yield different results after a re-org.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/duties`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects the following object in the POST request body:
|
||||
|
||||
```
|
||||
{
|
||||
epoch: Epoch,
|
||||
pubkeys: [PublicKey]
|
||||
}
|
||||
```
|
||||
|
||||
Duties are assigned on a per-epoch basis, all duties returned will contain
|
||||
slots that are inside the given `epoch`. A set of duties will be returned for
|
||||
each of the `pubkeys`.
|
||||
|
||||
Validators who are not known to the beacon chain (e.g., have not yet deposited)
|
||||
will have `null` values for most fields.
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
A set of duties for each given pubkey.
|
||||
|
||||
### Example
|
||||
|
||||
#### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"epoch": 1203,
|
||||
"pubkeys": [
|
||||
"0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"0x42f87bc7c8fa10408425bbeeeb3dc3874242b4bd92f57775b60b39142426f9ec80b273a64269332d97bdb7d93ae05a42"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
_Note: for demonstration purposes the second pubkey is some unknown pubkey._
|
||||
|
||||
#### Response Body
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"validator_pubkey": "0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"validator_index": 14935,
|
||||
"attestation_slot": 38511,
|
||||
"attestation_committee_index": 3,
|
||||
"attestation_committee_position": 39,
|
||||
"block_proposal_slots": [],
|
||||
"aggregator_modulo": 5,
|
||||
},
|
||||
{
|
||||
"validator_pubkey": "0x42f87bc7c8fa10408425bbeeeb3dc3874242b4bd92f57775b60b39142426f9ec80b273a64269332d97bdb7d93ae05a42",
|
||||
"validator_index": null,
|
||||
"attestation_slot": null,
|
||||
"attestation_committee_index": null,
|
||||
"attestation_committee_position": null,
|
||||
"block_proposal_slots": []
|
||||
"aggregator_modulo": null,
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## `/validator/duties/all`
|
||||
|
||||
Returns the duties for all validators, equivalent to calling [Validator
|
||||
Duties](#validator-duties) while providing all known validator public keys.
|
||||
|
||||
Considering that duties for non-active validators will just be `null`, it is
|
||||
generally more efficient to query using [Active Validator
|
||||
Duties](#active-validator-duties).
|
||||
|
||||
This endpoint will only return validators that were in the beacon state
|
||||
in the given epoch. For example, if the query epoch is 10 and some validator
|
||||
deposit was included in epoch 11, that validator will not be included in the
|
||||
result.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/duties/all`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `epoch`
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
The duties returned will all be inside the given `epoch` (`Epoch`) query
|
||||
parameter. This parameter is required.
|
||||
|
||||
### Returns
|
||||
|
||||
The return format is identical to the [Validator Duties](#validator-duties) response body.
|
||||
|
||||
## `/validator/duties/active`
|
||||
|
||||
Returns the duties for all active validators, equivalent to calling [Validator
|
||||
Duties](#validator-duties) while providing all known validator public keys that
|
||||
are active in the given epoch.
|
||||
|
||||
This endpoint will only return validators that were in the beacon state
|
||||
in the given epoch. For example, if the query epoch is 10 and some validator
|
||||
deposit was included in epoch 11, that validator will not be included in the
|
||||
result.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/duties/active`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `epoch`
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
The duties returned will all be inside the given `epoch` (`Epoch`) query
|
||||
parameter. This parameter is required.
|
||||
|
||||
### Returns
|
||||
|
||||
The return format is identical to the [Validator Duties](#validator-duties) response body.
|
||||
|
||||
## `/validator/subscribe`
|
||||
|
||||
Posts a list of `ValidatorSubscription` to subscribe validators to
|
||||
particular slots to perform attestation duties.
|
||||
|
||||
This informs the beacon node to search for peers and subscribe to
|
||||
required attestation subnets to perform the attestation duties required.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/subscribe`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects the following object in the POST request body:
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
validator_index: 10,
|
||||
attestation_committee_index: 12,
|
||||
slot: 3,
|
||||
is_aggregator: true
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
The `is_aggregator` informs the beacon node if the validator is an aggregator
|
||||
for this slot/committee.
|
||||
|
||||
### Returns
|
||||
|
||||
A null object on success and an error indicating any failures.
|
||||
|
||||
## `/validator/block` GET
|
||||
|
||||
|
||||
Produces and returns an unsigned `BeaconBlock` object.
|
||||
|
||||
The block will be produced with the given `slot` and the parent block will be the
|
||||
highest block in the canonical chain that has a slot less than `slot`. The
|
||||
block will still be produced if some other block is also known to be at `slot`
|
||||
(i.e., it may produce a block that would be slashable if signed).
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/block`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `slot`, `randao_reveal`
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
|
||||
- `slot` (`Slot`): The slot number for which the block is to be produced.
|
||||
- `randao_reveal` (`Signature`): 96 bytes `Signature` for the randomness.
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns a `BeaconBlock` object.
|
||||
|
||||
#### Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"slot": 33,
|
||||
"parent_root": "0xf54de54bd33e33aee4706cffff4bd991bcbf522f2551ab007180479c63f4fe912",
|
||||
"state_root": "0x615c887bad27bc05754d627d941e1730e1b4c77b2eb4378c195ac8a8203bbf26",
|
||||
"body": {
|
||||
"randao_reveal": "0x8d7b2a32b026e9c79aae6ec6b83eabae89d60cacd65ac41ed7d2f4be9dd8c89c1bf7cd3d700374e18d03d12f6a054c23006f64f0e4e8b7cf37d6ac9a4c7d815c858120c54673b7d3cb2bb1550a4d659eaf46e34515677c678b70d6f62dbf89f",
|
||||
"eth1_data": {
|
||||
"deposit_root": "0x66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925",
|
||||
"deposit_count": 8,
|
||||
"block_hash": "0x2b32db6c2c0a6235fb1397e8225ea85e0f0e6e8c7b126d0016ccbde0e667151e"
|
||||
},
|
||||
"graffiti": "0x736967702f6c69676874686f7573652d302e312e312d7076572656c65617365",
|
||||
"proposer_slashings": [],
|
||||
"attester_slashings": [],
|
||||
"attestations": [],
|
||||
"deposits": [],
|
||||
"voluntary_exits": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `/validator/block` POST
|
||||
|
||||
Accepts a `SignedBeaconBlock` for verification. If it is valid, it will be
|
||||
imported into the local database and published on the network. Invalid blocks
|
||||
will not be published to the network.
|
||||
|
||||
A block may be considered invalid because it is fundamentally incorrect, or its
|
||||
parent has not yet been imported.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/block`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200/202
|
||||
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects a JSON encoded `SignedBeaconBlock` in the POST request body:
|
||||
|
||||
### Returns
|
||||
|
||||
Returns a null object if the block passed all block validation and is published to the network.
|
||||
Else, returns a processing error description.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"message": {
|
||||
"slot": 33,
|
||||
"parent_root": "0xf54de54bd33e33aee4706cffff4bd991bcbf522f2551ab007180479c63f4fe912",
|
||||
"state_root": "0x615c887bad27bc05754d627d941e1730e1b4c77b2eb4378c195ac8a8203bbf26",
|
||||
"body": {
|
||||
"randao_reveal": "0x8d7b2a32b026e9c79aae6ec6b83eabae89d60cacd65ac41ed7d2f4be9dd8c89c1bf7cd3d700374e18d03d12f6a054c23006f64f0e4e8b7cf37d6ac9a4c7d815c858120c54673b7d3cb2bb1550a4d659eaf46e34515677c678b70d6f62dbf89f",
|
||||
"eth1_data": {
|
||||
"deposit_root": "0x66687aadf862bd776c8fc18b8e9f8e20089714856ee233b3902a591d0d5f2925",
|
||||
"deposit_count": 8,
|
||||
"block_hash": "0x2b32db6c2c0a6235fb1397e8225ea85e0f0e6e8c7b126d0016ccbde0e667151e"
|
||||
},
|
||||
"graffiti": "0x736967702f6c69676874686f7573652d302e312e312d7076572656c65617365",
|
||||
"proposer_slashings": [
|
||||
|
||||
],
|
||||
"attester_slashings": [
|
||||
|
||||
],
|
||||
"attestations": [
|
||||
|
||||
],
|
||||
"deposits": [
|
||||
|
||||
],
|
||||
"voluntary_exits": [
|
||||
|
||||
]
|
||||
}
|
||||
},
|
||||
"signature": "0x965ced900dbabd0a78b81a0abb5d03407be0d38762104316416347f2ea6f82652b5759396f402e85df8ee18ba2c60145037c73b1c335f4272f1751a1cd89862b7b4937c035e350d0108554bd4a8930437ec3311c801a65fe8e5ba022689b5c24"
|
||||
}
|
||||
```
|
||||
|
||||
## `/validator/attestation`
|
||||
|
||||
Produces and returns an unsigned `Attestation` from the current state.
|
||||
|
||||
The attestation will reference the `beacon_block_root` of the highest block in
|
||||
the canonical chain with a slot equal to or less than the given `slot`.
|
||||
|
||||
An error will be returned if the given slot is more than
|
||||
`SLOTS_PER_HISTORICAL_VECTOR` slots behind the current head block.
|
||||
|
||||
This endpoint is not protected against slashing. Signing the returned
|
||||
attestation may result in a slashable offence.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/attestation`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `slot`, `committee_index`
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
|
||||
- `slot` (`Slot`): The slot number for which the attestation is to be produced.
|
||||
- `committee_index` (`CommitteeIndex`): The index of the committee that makes the attestation.
|
||||
|
||||
|
||||
### Returns
|
||||
|
||||
Returns a `Attestation` object with a default signature. The `signature` field should be replaced by the valid signature.
|
||||
|
||||
#### Response Body
|
||||
|
||||
```json
|
||||
{
|
||||
"aggregation_bits": "0x01",
|
||||
"data": {
|
||||
"slot": 100,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0xf22e4ec281136d119eabcd4d9d248aeacd042eb63d8d7642f73ad3e71f1c9283",
|
||||
"source": {
|
||||
"epoch": 2,
|
||||
"root": "0x34c1244535c923f08e7f83170d41a076e4f1ec61013846b3a615a1d109d3c329"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 3,
|
||||
"root": "0xaefd23b384994dc0c1a6b77836bdb2f24f209ebfe6c4819324d9685f4a43b4e1"
|
||||
}
|
||||
},
|
||||
"signature": "0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## `/validator/aggregate_attestation`
|
||||
|
||||
Requests an `AggregateAttestation` from the beacon node that has a
|
||||
specific `attestation.data`. If no aggregate attestation is known this will
|
||||
return a null object.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/aggregate_attestation`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `attestation_data`
|
||||
Typical Responses | 200
|
||||
|
||||
### Returns
|
||||
|
||||
Returns a null object if the attestation data passed is not known to the beacon
|
||||
node.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"aggregation_bits": "0x03",
|
||||
"data": {
|
||||
"slot": 3,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0x0b6a1f7a9baa38d00ef079ba861b7587662565ca2502fb9901741c1feb8bb3c9",
|
||||
"source": {
|
||||
"epoch": 0,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 0,
|
||||
"root": "0xad2c360ab8c8523db278a7d7ced22f3810800f2fdc282defb6db216689d376bd"
|
||||
}
|
||||
},
|
||||
"signature": "0xb76a1768c18615b5ade91a92e7d2ed0294f7e088e56e30fbe7e3aa6799c443b11bccadd578ca2cbd95d395ab689b9e4d03c88a56641791ab38dfa95dc1f4d24d1b19b9d36c96c20147ad03$649bd3c6c7e8a39cf2ffb99e07b4964d52854559f"
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## `/validator/attestations`
|
||||
|
||||
Accepts a list of `Attestation` for verification. If they are valid, they will be imported
|
||||
into the local database and published to the network. Invalid attestations will
|
||||
not be published to the network.
|
||||
|
||||
An attestation may be considered invalid because it is fundamentally incorrect
|
||||
or because the beacon node has not imported the relevant blocks required to
|
||||
verify it.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/attestations`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200/202
|
||||
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects a JSON encoded list of signed `Attestation` objects in the POST request body. In
|
||||
accordance with the naive aggregation scheme, the attestation _must_ have
|
||||
exactly one of the `attestation.aggregation_bits` fields set.
|
||||
|
||||
### Returns
|
||||
|
||||
Returns a null object if the attestation passed all validation and is published to the network.
|
||||
Else, returns a processing error description.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"aggregation_bits": "0x03",
|
||||
"data": {
|
||||
"slot": 3,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0x0b6a1f7a9baa38d00ef079ba861b7587662565ca2502fb9901741c1feb8bb3c9",
|
||||
"source": {
|
||||
"epoch": 0,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 0,
|
||||
"root": "0xad2c360ab8c8523db278a7d7ced22f3810800f2fdc282defb6db216689d376bd"
|
||||
}
|
||||
},
|
||||
"signature": "0xb76a1768c18615b5ade91a92e7d2ed0294f7e088e56e30fbe7e3aa6799c443b11bccadd578ca2cbd95d395ab689b9e4d03c88a56641791ab38dfa95dc1f4d24d1b19b9d36c96c20147ad03$649bd3c6c7e8a39cf2ffb99e07b4964d52854559f"
|
||||
}
|
||||
```
|
||||
|
||||
## `/validator/aggregate_and_proofs`
|
||||
|
||||
Accepts a list of `SignedAggregateAndProof` for publication. If they are valid
|
||||
(the validator is an aggregator and the signatures can be verified) these
|
||||
are published to the network on the global aggregate gossip topic.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/validator/aggregate_and_proofs`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200/202
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects a JSON encoded list of `SignedAggregateAndProof` objects in the POST request body.
|
||||
|
||||
### Returns
|
||||
|
||||
Returns a null object if the attestation passed all validation and is published to the network.
|
||||
Else, returns a processing error description.
|
||||
|
||||
### Example
|
||||
|
||||
### Request Body
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"message": {
|
||||
"aggregator_index": 12,
|
||||
"aggregate": {
|
||||
"aggregation_bits": "0x03",
|
||||
"data": {
|
||||
"slot": 3,
|
||||
"index": 0,
|
||||
"beacon_block_root": "0x0b6a1f7a9baa38d00ef079ba861b7587662565ca2502fb9901741c1feb8bb3c9",
|
||||
"source": {
|
||||
"epoch": 0,
|
||||
"root": "0x0000000000000000000000000000000000000000000000000000000000000000"
|
||||
},
|
||||
"target": {
|
||||
"epoch": 0,
|
||||
"root": "0xad2c360ab8c8523db278a7d7ced22f3810800f2fdc282defb6db216689d376bd"
|
||||
}
|
||||
},
|
||||
"signature": "0xb76a1768c18615b5ade91a92e7d2ed0294f7e088e56e30fbe7e3aa6799c443b11bccadd578ca2cbd95d395ab689b9e4d03c88a56641791ab38dfa95dc1f4d24d1b19b9d36c96c20147ad03649bd3c6c7e8a39cf2ffb99e07b4964d52854559f"
|
||||
},
|
||||
"selection_proof": "0xb76a1768c18615b5ade91a92e7d2ed0294f7e088e56e30fbe7e3aa6799c443b11bccadd578ca2cbd95d395ab689b9e4d03c88a56641791ab38dfa95dc1f4d24d1b19b9d36c96c20147ad03649bd3c6c7e8a39cf2ffb99e07b4964d52854559f"
|
||||
}
|
||||
signature: "0xb76a1768c18615b5ade91a92e7d2ed0294f7e088e56e30fbe7e3aa6799c443b11bccadd578ca2cbd95d395ab689b9e4d03c88a56641791ab38dfa95dc1f4d24d1b19b9d36c96c20147ad03649bd3c6c7e8a39cf2ffb99e07b4964d52854559f"
|
||||
}
|
||||
]
|
||||
```
|
||||
_Note: The data in this request is for demonstrating types and does not
|
||||
contain real data_
|
||||
38
book/src/installation-binaries.md
Normal file
38
book/src/installation-binaries.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Pre-built Binaries
|
||||
|
||||
Each Lighthouse release contains several downloadable binaries in the "Assets"
|
||||
section of the release. You can find the [releases
|
||||
on Github](https://github.com/sigp/lighthouse/releases).
|
||||
|
||||
> Note: binaries are not yet provided for MacOS or Windows native.
|
||||
|
||||
## Platforms
|
||||
|
||||
Binaries are supplied for two platforms:
|
||||
|
||||
- `x86_64-unknown-linux-gnu`: AMD/Intel 64-bit processors (most desktops, laptops, servers)
|
||||
- `aarch64-unknown-linux-gnu`: 64-bit ARM processors (Raspberry Pi 4)
|
||||
|
||||
Additionally there is also a `-portable` suffix which indicates if the `portable` feature is used:
|
||||
|
||||
- Without `portable`: uses modern CPU instructions to provide the fastest signature verification times (may cause `Illegal instruction` error on older CPUs)
|
||||
- With `portable`: approx. 20% slower, but should work on all modern 64-bit processors.
|
||||
|
||||
## Usage
|
||||
|
||||
Each binary is contained in a `.tar.gz` archive. For this example, lets use the
|
||||
`v0.2.13` release and assume the user needs a portable `x86_64` binary.
|
||||
|
||||
> Whilst this example uses `v0.2.13` we recommend always using the latest release.
|
||||
|
||||
### Steps
|
||||
|
||||
1. Go to the [Releases](https://github.com/sigp/lighthouse/releases) page and
|
||||
select the latest release.
|
||||
1. Download the `lighthouse-${VERSION}-x86_64-unknown-linux-gnu-portable.tar.gz` binary.
|
||||
1. Extract the archive:
|
||||
1. `cd Downloads`
|
||||
1. `tar -xvf lighthouse-${VERSION}-x86_64-unknown-linux-gnu.tar.gz`
|
||||
1. Test the binary with `./lighthouse --version` (it should print the version).
|
||||
1. (Optional) Move the `lighthouse` binary to a location in your `PATH`, so the `lighthouse` command can be called from anywhere.
|
||||
- E.g., `cp lighthouse /usr/bin`
|
||||
82
book/src/installation-source.md
Normal file
82
book/src/installation-source.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# Installation: Build from Source
|
||||
|
||||
Lighthouse builds on Linux, macOS, and Windows (via [WSL][] only).
|
||||
|
||||
Compilation should be easy. In fact, if you already have Rust installed all you
|
||||
need is:
|
||||
|
||||
- `git clone https://github.com/sigp/lighthouse.git`
|
||||
- `cd lighthouse`
|
||||
- `make`
|
||||
|
||||
If this doesn't work or is not clear enough, see the [Detailed
|
||||
Instructions](#detailed-instructions) below. If you have further issues, see
|
||||
[Troubleshooting](#troubleshooting). If you'd prefer to use Docker, see the
|
||||
[Docker Guide](./docker.md).
|
||||
|
||||
## Detailed Instructions
|
||||
|
||||
1. Install Rust and Cargo with [rustup](https://rustup.rs/).
|
||||
- Use the `stable` toolchain (it's the default).
|
||||
- Check the [Troubleshooting](#troubleshooting) section for additional
|
||||
dependencies (e.g., `cmake`).
|
||||
1. Clone the Lighthouse repository.
|
||||
- Run `$ git clone https://github.com/sigp/lighthouse.git`
|
||||
- Change into the newly created directory with `$ cd lighthouse`
|
||||
1. Build Lighthouse with `$ make`.
|
||||
1. Installation was successful if `$ lighthouse --help` displays the
|
||||
command-line documentation.
|
||||
|
||||
> First time compilation may take several minutes. If you experience any
|
||||
> failures, please reach out on [discord](https://discord.gg/cyAszAh) or
|
||||
> [create an issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
## Windows Support
|
||||
|
||||
Compiling or running Lighthouse natively on Windows is not currently supported. However,
|
||||
Lighthouse can run successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using
|
||||
Ubuntu under WSL, you can should install the Ubuntu dependencies listed in the [Dependencies
|
||||
(Ubuntu)](#dependencies-ubuntu) section.
|
||||
|
||||
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Dependencies
|
||||
|
||||
#### Ubuntu
|
||||
|
||||
Several dependencies may be required to compile Lighthouse. The following
|
||||
packages may be required in addition a base Ubuntu Server installation:
|
||||
|
||||
```bash
|
||||
sudo apt install -y git gcc g++ make cmake pkg-config libssl-dev
|
||||
```
|
||||
|
||||
#### macOS
|
||||
|
||||
You will need `cmake`. You can install via homebrew:
|
||||
|
||||
brew install openssl cmake
|
||||
|
||||
### Command is not found
|
||||
|
||||
Lighthouse will be installed to `CARGO_HOME` or `$HOME/.cargo`. This directory
|
||||
needs to be on your `PATH` before you can run `$ lighthouse`.
|
||||
|
||||
See ["Configuring the `PATH` environment variable"
|
||||
(rust-lang.org)](https://www.rust-lang.org/tools/install) for more information.
|
||||
|
||||
### Compilation error
|
||||
|
||||
Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply type `$ rustup update`.
|
||||
|
||||
### OpenSSL
|
||||
|
||||
If you get a build failure relating to OpenSSL, try installing `openssl-dev` or
|
||||
`libssl-dev` using your OS package manager.
|
||||
|
||||
- Ubuntu: `$ apt-get install libssl-dev`.
|
||||
- Amazon Linux: `$ yum install openssl-devel`.
|
||||
|
||||
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
|
||||
@@ -1,73 +1,16 @@
|
||||
# 📦 Installation
|
||||
|
||||
Lighthouse runs on Linux, macOS, and Windows via [WSL][].
|
||||
Installation should be easy. In fact, if you already have Rust installed all you need is:
|
||||
Lighthouse runs on Linux, macOS, and Windows (via [WSL][] only).
|
||||
|
||||
- `git clone https://github.com/sigp/lighthouse.git`
|
||||
- `cd lighthouse`
|
||||
- `make`
|
||||
There are three core methods to obtain the Lighthouse application:
|
||||
|
||||
If this doesn't work or is not clear enough, see the [Detailed Instructions](#detailed-instructions). If you have further issues, see [Troubleshooting](#troubleshooting). If you'd prefer to use Docker, see the [Docker Guide](./docker.md).
|
||||
- [Pre-built binaries](./installation-binaries.md).
|
||||
- [Docker images](./docker.md).
|
||||
- [Building from source](./installation-source.md).
|
||||
|
||||
## Detailed Instructions
|
||||
Additionally, there are two extra guides for specific uses:
|
||||
|
||||
1. Install Rust and Cargo with [rustup](https://rustup.rs/).
|
||||
- Use the `stable` toolchain (it's the default).
|
||||
1. Clone the Lighthouse repository.
|
||||
- Run `$ git clone https://github.com/sigp/lighthouse.git`
|
||||
- Change into the newly created directory with `$ cd lighthouse`
|
||||
1. Build Lighthouse with `$ make`.
|
||||
1. Installation was successful if `$ lighthouse --help` displays the
|
||||
command-line documentation.
|
||||
|
||||
> First time compilation may take several minutes. If you experience any
|
||||
> failures, please reach out on [discord](https://discord.gg/cyAszAh) or
|
||||
> [create an issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
## Windows Support
|
||||
|
||||
Compiling or running Lighthouse natively on Windows is not currently supported. However,
|
||||
Lighthouse can run successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using
|
||||
Ubuntu under WSL, you can should install the Ubuntu dependencies listed in the [Dependencies
|
||||
(Ubuntu)](#dependencies-ubuntu) section.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Dependencies
|
||||
|
||||
#### Ubuntu
|
||||
|
||||
Several dependencies may be required to compile Lighthouse. The following
|
||||
packages may be required in addition a base Ubuntu Server installation:
|
||||
|
||||
```bash
|
||||
sudo apt install -y git gcc g++ make cmake pkg-config libssl-dev
|
||||
```
|
||||
|
||||
#### macOS
|
||||
|
||||
You will need `cmake`. You can install via homebrew:
|
||||
|
||||
brew install cmake
|
||||
|
||||
### Command is not found
|
||||
|
||||
Lighthouse will be installed to `CARGO_HOME` or `$HOME/.cargo`. This directory
|
||||
needs to be on your `PATH` before you can run `$ lighthouse`.
|
||||
|
||||
See ["Configuring the `PATH` environment variable"
|
||||
(rust-lang.org)](https://www.rust-lang.org/tools/install) for more information.
|
||||
|
||||
### Compilation error
|
||||
|
||||
Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply type `$ rustup update`.
|
||||
|
||||
### OpenSSL
|
||||
|
||||
If you get a build failure relating to OpenSSL, try installing `openssl-dev` or
|
||||
`libssl-dev` using your OS package manager.
|
||||
|
||||
- Ubuntu: `$ apt-get install libssl-dev`.
|
||||
- Amazon Linux: `$ yum install openssl-devel`.
|
||||
- [Rapsberry Pi 4 guide](./pi.md).
|
||||
- [Cross-compiling guide for developers](./cross-compiling.md).
|
||||
|
||||
[WSL]: https://docs.microsoft.com/en-us/windows/wsl/about
|
||||
|
||||
@@ -42,12 +42,12 @@ keypairs. Creating a single validator looks like this:
|
||||
- `lighthouse account validator create --wallet-name wally --wallet-password wally.pass --count 1`
|
||||
|
||||
|
||||
In step (1), we created a wallet in `~/.lighthouse/wallets` with the name
|
||||
In step (1), we created a wallet in `~/.lighthouse/{testnet}/wallets` with the name
|
||||
`wally`. We encrypted this using a pre-defined password in the
|
||||
`wally.pass` file. Then, in step (2), we created one new validator in the
|
||||
`~/.lighthouse/validators` directory using `wally` (unlocking it with
|
||||
`~/.lighthouse/{testnet}/validators` directory using `wally` (unlocking it with
|
||||
`wally.pass`) and storing the passwords to the validators voting key in
|
||||
`~/.lighthouse/secrets`.
|
||||
`~/.lighthouse/{testnet}/secrets`.
|
||||
|
||||
Thanks to the hierarchical key derivation scheme, we can delete all of the
|
||||
aforementioned directories and then regenerate them as long as we remembered
|
||||
@@ -65,14 +65,16 @@ There are three important directories in Lighthouse validator key management:
|
||||
|
||||
- `wallets/`: contains encrypted wallets which are used for hierarchical
|
||||
key derivation.
|
||||
- Defaults to `~/.lighthouse/wallets`
|
||||
- Defaults to `~/.lighthouse/{testnet}/wallets`
|
||||
- `validators/`: contains a directory for each validator containing
|
||||
encrypted keystores and other validator-specific data.
|
||||
- Defaults to `~/.lighthouse/validators`
|
||||
- Defaults to `~/.lighthouse/{testnet}/validators`
|
||||
- `secrets/`: since the validator signing keys are "hot", the validator process
|
||||
needs access to the passwords to decrypt the keystores in the validators
|
||||
dir. These passwords are stored here.
|
||||
- Defaults to `~/.lighthouse/secrets`
|
||||
- Defaults to `~/.lighthouse/{testnet}/secrets`
|
||||
|
||||
where `testnet` is the name of the testnet passed in the `--testnet` parameter (default is `medalla`).
|
||||
|
||||
When the validator client boots, it searches the `validators/` for directories
|
||||
containing voting keystores. When it discovers a keystore, it searches the
|
||||
|
||||
162
book/src/testnet-validator.md
Normal file
162
book/src/testnet-validator.md
Normal file
@@ -0,0 +1,162 @@
|
||||
# Become a Testnet Validator
|
||||
|
||||
Joining an Eth2 testnet is a great way to get familiar with staking in Phase 0.
|
||||
All users should experiment with a testnet prior to staking mainnet ETH.
|
||||
|
||||
## Supported Testnets
|
||||
|
||||
Lighthouse supports four testnets:
|
||||
|
||||
- [Medalla](https://github.com/goerli/medalla/tree/master/medalla) (default)
|
||||
- [Zinken](https://github.com/goerli/medalla/tree/master/zinken)
|
||||
- [Spadina](https://github.com/goerli/medalla/tree/master/spadina) (deprecated)
|
||||
- [Altona](https://github.com/goerli/medalla/tree/master/altona) (deprecated)
|
||||
|
||||
When using Lighthouse, the `--testnet` flag selects a testnet. E.g.,
|
||||
|
||||
- `lighthouse` (no flag): Medalla.
|
||||
- `lighthouse --testnet medalla`: Medalla.
|
||||
- `lighthouse --testnet zinken`: Zinken.
|
||||
|
||||
Using the correct `--testnet` flag is very important; using the wrong flag can
|
||||
result in penalties, slashings or lost deposits. As a rule of thumb, always
|
||||
provide a `--testnet` flag instead of relying on the default.
|
||||
|
||||
> Note: In these documents we use `--testnet MY_TESTNET` for demonstration. You
|
||||
> must replace `MY_TESTNET` with a valid testnet name.
|
||||
|
||||
## Joining a Testnet
|
||||
|
||||
There are five primary steps to become a testnet validator:
|
||||
|
||||
1. Create validator keys and submit deposits.
|
||||
1. Start an Eth1 client.
|
||||
1. Install Lighthouse.
|
||||
1. Import the validator keys into Lighthouse.
|
||||
1. Start Lighthouse.
|
||||
1. Leave Lighthouse running.
|
||||
|
||||
Each of these primary steps has several intermediate steps, so we recommend
|
||||
setting aside one or two hours for this process.
|
||||
|
||||
### Step 1. Create validator keys
|
||||
|
||||
The Ethereum Foundation provides an "Eth2 launch pad" for each active testnet:
|
||||
|
||||
- [Medalla launchpad](https://medalla.launchpad.ethereum.org/)
|
||||
- [Zinken launchpad](https://zinken.launchpad.ethereum.org/)
|
||||
|
||||
Please follow the steps on the appropriate launch pad site to generate
|
||||
validator keys and submit deposits. Make sure you select "Lighthouse" as your
|
||||
client.
|
||||
|
||||
Move to the next step once you have completed the steps on the launch pad,
|
||||
including generating keys via the Python CLI and submitting gETH/ETH deposits.
|
||||
|
||||
### Step 2. Start an Eth1 client
|
||||
|
||||
Since Eth2 relies upon the Eth1 chain for validator on-boarding, all Eth2 validators must have a connection to an Eth1 node.
|
||||
|
||||
We provide instructions for using Geth (the Eth1 client that, by chance, we ended up testing with), but you could use any client that implements the JSON RPC via HTTP. A fast-synced node should be sufficient.
|
||||
|
||||
#### Installing Geth
|
||||
|
||||
If you're using a Mac, follow the instructions [listed here](https://github.com/ethereum/go-ethereum/wiki/Installation-Instructions-for-Mac) to install geth. Otherwise [see here](https://github.com/ethereum/go-ethereum/wiki/Installing-Geth).
|
||||
|
||||
#### Starting Geth
|
||||
|
||||
Once you have geth installed, use this command to start your Eth1 node:
|
||||
|
||||
```bash
|
||||
geth --goerli --http
|
||||
```
|
||||
|
||||
### Step 3. Install Lighthouse
|
||||
|
||||
*Note: Lighthouse only supports Windows via WSL.*
|
||||
|
||||
Follow the [Lighthouse Installation Instructions](./installation.md) to install
|
||||
Lighthouse from one of the available options.
|
||||
|
||||
Proceed to the next step once you've successfully installed Lighthouse and view
|
||||
its `--version` info.
|
||||
|
||||
> Note: Some of the instructions vary when using Docker, ensure you follow the
|
||||
> appropriate sections later in this guide.
|
||||
|
||||
### Step 4. Import validator keys to Lighthouse
|
||||
|
||||
When Lighthouse is installed, follow the [Importing from the Ethereum 2.0 Launch
|
||||
pad](./validator-import-launchpad.md) instructions so the validator client can
|
||||
perform your validator duties.
|
||||
|
||||
Proceed to the next step once you've successfully imported all validators.
|
||||
|
||||
### Step 5. Start Lighthouse
|
||||
|
||||
For staking, one needs to run two Lighthouse processes:
|
||||
|
||||
- `lighthouse bn`: the "beacon node" which connects to the P2P network and
|
||||
verifies blocks.
|
||||
- `lighthouse vc`: the "validator client" which manages validators, using data
|
||||
obtained from the beacon node via a HTTP API.
|
||||
|
||||
Starting these processes is different for binary and docker users:
|
||||
|
||||
#### Binary users
|
||||
|
||||
Those using the pre- or custom-built binaries can start the two processes with:
|
||||
|
||||
```bash
|
||||
lighthouse --testnet MY_TESTNET bn --staking
|
||||
```
|
||||
|
||||
```bash
|
||||
lighthouse --testnet MY_TESTNET vc
|
||||
```
|
||||
|
||||
#### Docker users
|
||||
|
||||
Those using Docker images can start the processes with:
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse \
|
||||
lighthouse --testnet MY_TESTNET bn --staking --http-address 0.0.0.0
|
||||
```
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
--network host \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse \
|
||||
sigp/lighthouse \
|
||||
lighthouse --testnet MY_TESTNET vc
|
||||
```
|
||||
|
||||
### Step 6. Leave Lighthouse running
|
||||
|
||||
Leave your beacon node and validator client running and you'll see logs as the
|
||||
beacon node stays synced with the network while the validator client produces
|
||||
blocks and attestations.
|
||||
|
||||
It will take 4-8+ hours for the beacon chain to process and activate your
|
||||
validator, however you'll know you're active when the validator client starts
|
||||
successfully publishing attestations each epoch:
|
||||
|
||||
```
|
||||
Dec 03 08:49:40.053 INFO Successfully published attestation slot: 98, committee_index: 0, head_block: 0xa208…7fd5,
|
||||
```
|
||||
|
||||
Although you'll produce an attestation each epoch, it's less common to produce a
|
||||
block. Watch for the block production logs too:
|
||||
|
||||
```
|
||||
Dec 03 08:49:36.225 INFO Successfully published block slot: 98, attestations: 2, deposits: 0, service: block
|
||||
```
|
||||
|
||||
If you see any `ERRO` (error) logs, please reach out on
|
||||
[Discord](https://discord.gg/cyAszAh) or [create an
|
||||
issue](https://github.com/sigp/lighthouse/issues/new).
|
||||
|
||||
Happy staking!
|
||||
@@ -41,7 +41,7 @@ OPTIONS:
|
||||
The GWEI value of the deposit amount. Defaults to the minimum amount required for an active validator
|
||||
(MAX_EFFECTIVE_BALANCE)
|
||||
--secrets-dir <SECRETS_DIR>
|
||||
The path where the validator keystore passwords will be stored. Defaults to ~/.lighthouse/secrets
|
||||
The path where the validator keystore passwords will be stored. Defaults to ~/.lighthouse/{testnet}/secrets
|
||||
|
||||
-s, --spec <TITLE>
|
||||
Specifies the default eth2 spec type. [default: mainnet] [possible values: mainnet, minimal, interop]
|
||||
@@ -53,7 +53,7 @@ OPTIONS:
|
||||
Path to directory containing eth2_testnet specs. Defaults to a hard-coded Lighthouse testnet. Only effective
|
||||
if there is no existing database.
|
||||
--validator-dir <VALIDATOR_DIRECTORY>
|
||||
The path where the validator directories will be created. Defaults to ~/.lighthouse/validators
|
||||
The path where the validator directories will be created. Defaults to ~/.lighthouse/{testnet}/validators
|
||||
|
||||
--wallet-name <WALLET_NAME> Use the wallet identified by this name
|
||||
--wallet-password <WALLET_PASSWORD_PATH>
|
||||
@@ -73,10 +73,12 @@ This command will:
|
||||
|
||||
- Derive a single new BLS keypair from `wally`, updating it so that it generates a
|
||||
new key next time.
|
||||
- Create a new directory in `~/.lighthouse/validators` containing:
|
||||
- Create a new directory in `~/.lighthouse/{testnet}/validators` containing:
|
||||
- An encrypted keystore containing the validators voting keypair.
|
||||
- An `eth1_deposit_data.rlp` assuming the default deposit amount (`32 ETH`
|
||||
for most testnets and mainnet) which can be submitted to the deposit
|
||||
contract for the medalla testnet. Other testnets can be set via the
|
||||
`--testnet` CLI param.
|
||||
- Store a password to the validators voting keypair in `~/.lighthouse/secrets`.
|
||||
- Store a password to the validators voting keypair in `~/.lighthouse/{testnet}/secrets`.
|
||||
|
||||
where `testnet` is the name of the testnet passed in the `--testnet` parameter (default is `medalla`).
|
||||
@@ -1,4 +1,4 @@
|
||||
# Importing from the Ethereum 2.0 Launchpad
|
||||
# Importing from the Ethereum 2.0 Launch pad
|
||||
|
||||
The [Eth2 Lauchpad](https://github.com/ethereum/eth2.0-deposit) is a website
|
||||
from the Ethereum Foundation which guides users how to use the
|
||||
@@ -20,7 +20,7 @@ Whilst following the steps on the website, users are instructed to download the
|
||||
repository. This `eth2-deposit-cli` script will generate the validator BLS keys
|
||||
into a `validator_keys` directory. We assume that the user's
|
||||
present-working-directory is the `eth2-deposit-cli` repository (this is where
|
||||
you will be if you just ran the `./deposit.sh` script from the Eth2 Launchpad
|
||||
you will be if you just ran the `./deposit.sh` script from the Eth2 Launch pad
|
||||
website). If this is not the case, simply change the `--directory` to point to
|
||||
the `validator_keys` directory.
|
||||
|
||||
@@ -30,6 +30,9 @@ using the standard `validators` directory (specify a different one using
|
||||
|
||||
### 1. Run the `lighthouse account validator import` command.
|
||||
|
||||
Docker users should use the command from the [Docker](#docker)
|
||||
section, all other users can use:
|
||||
|
||||
|
||||
```bash
|
||||
lighthouse account validator import --directory validator_keys
|
||||
@@ -85,3 +88,22 @@ INFO Enabled validator voting_pubkey: 0xa5e8702533f6d66422e042a0bf3471ab9b
|
||||
Once this log appears (and there are no errors) the `lighthouse vc` application
|
||||
will ensure that the validator starts performing its duties and being rewarded
|
||||
by the protocol. There is no more input required from the user.
|
||||
|
||||
## Docker
|
||||
|
||||
The `import` command is a little more complex for Docker users, but the example
|
||||
in this document can be substituted with:
|
||||
|
||||
```bash
|
||||
docker run -it \
|
||||
-v $HOME/.lighthouse:/root/.lighthouse \
|
||||
-v $(pwd)/validator_keys:/root/validator_keys \
|
||||
sigp/lighthouse \
|
||||
lighthouse --testnet medalla account validator import --directory /root/validator_keys
|
||||
```
|
||||
|
||||
Here we use two `-v` volumes to attach:
|
||||
|
||||
- `~/.lighthouse` on the host to `/root/.lighthouse` in the Docker container.
|
||||
- The `validator_keys` directory in the present working directory of the host
|
||||
to the `/root/validator_keys` directory of the Docker container.
|
||||
|
||||
@@ -1,16 +1,21 @@
|
||||
# Lighthouse REST API: `/consensus`
|
||||
# Validator Inclusion APIs
|
||||
|
||||
The `/consensus` endpoints provide information on results of the proof-of-stake
|
||||
voting process used for finality/justification under Casper FFG.
|
||||
The `/lighthouse/validator_inclusion` API endpoints provide information on
|
||||
results of the proof-of-stake voting process used for finality/justification
|
||||
under Casper FFG.
|
||||
|
||||
These endpoints are not stable or included in the Eth2 standard API. As such,
|
||||
they are subject to change or removal without a change in major release
|
||||
version.
|
||||
|
||||
## Endpoints
|
||||
|
||||
HTTP Path | Description |
|
||||
| --- | -- |
|
||||
[`/consensus/global_votes`](#consensusglobal_votes) | A global vote count for a given epoch.
|
||||
[`/consensus/individual_votes`](#consensusindividual_votes) | A per-validator breakdown of votes in a given epoch.
|
||||
[`/lighthouse/validator_inclusion/{epoch}/global`](#global) | A global vote count for a given epoch.
|
||||
[`/lighthouse/validator_inclusion/{epoch}/{validator_id}`](#individual) | A per-validator breakdown of votes in a given epoch.
|
||||
|
||||
## `/consensus/global_votes`
|
||||
## Global
|
||||
|
||||
Returns a global count of votes for some given `epoch`. The results are included
|
||||
both for the current and previous (`epoch - 1`) epochs since both are required
|
||||
@@ -75,40 +80,27 @@ voting upon the previous epoch included in a block.
|
||||
When this value is greater than or equal to `2/3` it is possible that the
|
||||
beacon chain may justify and/or finalize the epoch.
|
||||
|
||||
### HTTP Specification
|
||||
### HTTP Example
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/consensus/global_votes`
|
||||
Method | GET
|
||||
JSON Encoding | Object
|
||||
Query Parameters | `epoch`
|
||||
Typical Responses | 200
|
||||
|
||||
### Parameters
|
||||
|
||||
Requires the `epoch` (`Epoch`) query parameter to determine which epoch will be
|
||||
considered the current epoch.
|
||||
|
||||
### Returns
|
||||
|
||||
A report on global validator voting participation.
|
||||
|
||||
### Example
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/validator_inclusion/0/global" -H "accept: application/json" | jq
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"current_epoch_active_gwei": 52377600000000,
|
||||
"previous_epoch_active_gwei": 52377600000000,
|
||||
"current_epoch_attesting_gwei": 50740900000000,
|
||||
"current_epoch_target_attesting_gwei": 49526000000000,
|
||||
"previous_epoch_attesting_gwei": 52377600000000,
|
||||
"previous_epoch_target_attesting_gwei": 51063400000000,
|
||||
"previous_epoch_head_attesting_gwei": 9248600000000
|
||||
"data": {
|
||||
"current_epoch_active_gwei": 642688000000000,
|
||||
"previous_epoch_active_gwei": 642688000000000,
|
||||
"current_epoch_attesting_gwei": 366208000000000,
|
||||
"current_epoch_target_attesting_gwei": 366208000000000,
|
||||
"previous_epoch_attesting_gwei": 1000000000,
|
||||
"previous_epoch_target_attesting_gwei": 1000000000,
|
||||
"previous_epoch_head_attesting_gwei": 1000000000
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## `/consensus/individual_votes`
|
||||
## Individual
|
||||
|
||||
Returns a per-validator summary of how that validator performed during the
|
||||
current epoch.
|
||||
@@ -117,73 +109,26 @@ The [Global Votes](#consensusglobal_votes) endpoint is the summation of all of t
|
||||
individual values, please see it for definitions of terms like "current_epoch",
|
||||
"previous_epoch" and "target_attester".
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/consensus/individual_votes`
|
||||
Method | POST
|
||||
JSON Encoding | Object
|
||||
Query Parameters | None
|
||||
Typical Responses | 200
|
||||
|
||||
### Request Body
|
||||
|
||||
Expects the following object in the POST request body:
|
||||
### HTTP Example
|
||||
|
||||
```bash
|
||||
curl -X GET "http://localhost:5052/lighthouse/validator_inclusion/0/42" -H "accept: application/json" | jq
|
||||
```
|
||||
{
|
||||
epoch: Epoch,
|
||||
pubkeys: [PublicKey]
|
||||
}
|
||||
```
|
||||
|
||||
### Returns
|
||||
|
||||
A report on the validators voting participation.
|
||||
|
||||
### Example
|
||||
|
||||
#### Request Body
|
||||
|
||||
```json
|
||||
{
|
||||
"epoch": 1203,
|
||||
"pubkeys": [
|
||||
"0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"0x42f87bc7c8fa10408425bbeeeb3dc3874242b4bd92f57775b60b39142426f9ec80b273a64269332d97bdb7d93ae05a42"
|
||||
]
|
||||
"data": {
|
||||
"is_slashed": false,
|
||||
"is_withdrawable_in_current_epoch": false,
|
||||
"is_active_in_current_epoch": true,
|
||||
"is_active_in_previous_epoch": true,
|
||||
"current_epoch_effective_balance_gwei": 32000000000,
|
||||
"is_current_epoch_attester": false,
|
||||
"is_current_epoch_target_attester": false,
|
||||
"is_previous_epoch_attester": false,
|
||||
"is_previous_epoch_target_attester": false,
|
||||
"is_previous_epoch_head_attester": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
_Note: for demonstration purposes the second pubkey is some unknown pubkey._
|
||||
|
||||
#### Response Body
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"epoch": 1203,
|
||||
"pubkey": "0x98f87bc7c8fa10408425bbeeeb3dc387e3e0b4bd92f57775b60b39156a16f9ec80b273a64269332d97bdb7d93ae05a16",
|
||||
"validator_index": 14935,
|
||||
"vote": {
|
||||
"is_slashed": false,
|
||||
"is_withdrawable_in_current_epoch": false,
|
||||
"is_active_in_current_epoch": true,
|
||||
"is_active_in_previous_epoch": true,
|
||||
"current_epoch_effective_balance_gwei": 3200000000,
|
||||
"is_current_epoch_attester": true,
|
||||
"is_current_epoch_target_attester": true,
|
||||
"is_previous_epoch_attester": true,
|
||||
"is_previous_epoch_target_attester": true,
|
||||
"is_previous_epoch_head_attester": false
|
||||
}
|
||||
},
|
||||
{
|
||||
"epoch": 1203,
|
||||
"pubkey": "0x42f87bc7c8fa10408425bbeeeb3dc3874242b4bd92f57775b60b39142426f9ec80b273a64269332d97bdb7d93ae05a42",
|
||||
"validator_index": null,
|
||||
"vote": null
|
||||
}
|
||||
]
|
||||
```
|
||||
@@ -16,7 +16,7 @@ useful.
|
||||
## Introducing the `validator_definitions.yml` file
|
||||
|
||||
The `validator_definitions.yml` file is located in the `validator-dir`, which
|
||||
defaults to `~/.lighthouse/validators`. It is a
|
||||
defaults to `~/.lighthouse/{testnet}/validators`. It is a
|
||||
[YAML](https://en.wikipedia.org/wiki/YAML) encoded file defining exactly which
|
||||
validators the validator client will (and won't) act for.
|
||||
|
||||
@@ -92,7 +92,7 @@ name identical to the `voting_public_key` value.
|
||||
Lets assume the following directory structure:
|
||||
|
||||
```
|
||||
~/.lighthouse/validators
|
||||
~/.lighthouse/{testnet}/validators
|
||||
├── john
|
||||
│ └── voting-keystore.json
|
||||
├── sally
|
||||
@@ -135,7 +135,7 @@ In order for the validator client to decrypt the validators, they will need to
|
||||
ensure their `secrets-dir` is organised as below:
|
||||
|
||||
```
|
||||
~/.lighthouse/secrets
|
||||
~/.lighthouse/{testnet}/secrets
|
||||
├── 0xa5566f9ec3c6e1fdf362634ebec9ef7aceb0e460e5079714808388e5d48f4ae1e12897fed1bea951c17fa389d511e477
|
||||
├── 0xaa440c566fcf34dedf233baf56cf5fb05bb420d9663b4208272545608c27c13d5b08174518c758ecd814f158f2b4a337
|
||||
└── 0x87a580d31d7bc69069b55f5a01995a610dd391a26dc9e36e81057a17211983a79266800ab8531f21f1083d7d84085007
|
||||
|
||||
@@ -1,111 +0,0 @@
|
||||
# Websocket API
|
||||
|
||||
**Note: the WebSocket server _only_ emits events. It does not accept any
|
||||
requests. Use the [HTTP API](./http.md) for requests.**
|
||||
|
||||
By default, a Lighthouse `beacon_node` exposes a websocket server on `localhost:5053`.
|
||||
|
||||
The following CLI flags control the websocket server:
|
||||
|
||||
- `--no-ws`: disable the websocket server.
|
||||
- `--ws-port`: specify the listen port of the server.
|
||||
- `--ws-address`: specify the listen address of the server.
|
||||
|
||||
All clients connected to the websocket server will receive the same stream of events, all triggered
|
||||
by the `BeaconChain`. Each event is a JSON object with the following schema:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "string",
|
||||
"data": "object"
|
||||
}
|
||||
```
|
||||
|
||||
## Events
|
||||
|
||||
The following events may be emitted:
|
||||
|
||||
### Beacon Head Changed
|
||||
|
||||
Occurs whenever the canonical head of the beacon chain changes.
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "beacon_head_changed",
|
||||
"data": {
|
||||
"reorg": "boolean",
|
||||
"current_head_beacon_block_root": "string",
|
||||
"previous_head_beacon_block_root": "string"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Beacon Finalization
|
||||
|
||||
Occurs whenever the finalized checkpoint of the canonical head changes.
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "beacon_finalization",
|
||||
"data": {
|
||||
"epoch": "number",
|
||||
"root": "string"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Beacon Block Imported
|
||||
|
||||
Occurs whenever the beacon node imports a valid block.
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "beacon_block_imported",
|
||||
"data": {
|
||||
"block": "object"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Beacon Block Rejected
|
||||
|
||||
Occurs whenever the beacon node rejects a block because it is invalid or an
|
||||
error occurred during validation.
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "beacon_block_rejected",
|
||||
"data": {
|
||||
"reason": "string",
|
||||
"block": "object"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Beacon Attestation Imported
|
||||
|
||||
Occurs whenever the beacon node imports a valid attestation.
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "beacon_attestation_imported",
|
||||
"data": {
|
||||
"attestation": "object"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Beacon Attestation Rejected
|
||||
|
||||
Occurs whenever the beacon node rejects an attestation because it is invalid or
|
||||
an error occurred during validation.
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "beacon_attestation_rejected",
|
||||
"data": {
|
||||
"reason": "string",
|
||||
"attestation": "object"
|
||||
}
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user