Testnet5 docs (#892)
* Merge in ethdever book changes * Remove ethdenver docs
This commit is contained in:
parent
7f6ae4c2f5
commit
64ec3bd671
@ -3,9 +3,10 @@
|
||||
## 1. Download and install Lighthouse
|
||||
|
||||
If you already have Rust installed, you can install Lighthouse with the
|
||||
following three commands:
|
||||
following commands (don't forget to use the `testnet5` branch):
|
||||
|
||||
- `$ git clone https://github.com/sigp/lighthouse.git`
|
||||
- `$ git checkout testnet5`
|
||||
- `$ cd lighthouse`
|
||||
- `$ make`
|
||||
|
||||
|
@ -1,12 +1,4 @@
|
||||
# Become an Ethereum 2.0 Validator*
|
||||
|
||||
_* Testnet validator_
|
||||
|
||||
---
|
||||
**The lighthouse testnet is currently down. We expect to bring it up again in
|
||||
late-January or early-February. Thanks to all who participated in the testnet,
|
||||
we look forward to having your input again in the future.**
|
||||
---
|
||||
# Become an Ethereum 2.0 Testnet Validator
|
||||
|
||||
Running Lighthouse validator is easy if you're familiar with the terminal. It
|
||||
runs on Linux, MacOS and Windows and we have a Docker work-flow.
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Lighthouse REST API: `/spec`
|
||||
# Lighthouse REST API: `/advanced`
|
||||
|
||||
The `/advanced` endpoints provide information Lighthouse specific data structures for advanced debugging.
|
||||
|
||||
@ -112,4 +112,4 @@ Typical Responses | 200
|
||||
"voluntary_exits": []
|
||||
}
|
||||
```
|
||||
_Truncated for brevity._
|
||||
_Truncated for brevity._
|
||||
|
@ -702,4 +702,4 @@ canonical head state will be used.
|
||||
|
||||
### Returns
|
||||
|
||||
The return format is identical to the [`/beacon/validators`](#beaconvalidators) response body.
|
||||
The return format is identical to the [`/beacon/validators`](#beaconvalidators) response body.
|
||||
|
@ -159,7 +159,12 @@ The return format is identical to the [Validator Duties](#validator-duties) resp
|
||||
|
||||
## `/validator/block`
|
||||
|
||||
Produces and returns a `BeaconBlock` object from the current state.
|
||||
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
|
||||
|
||||
@ -210,6 +215,15 @@ Returns a `BeaconBlock` object.
|
||||
|
||||
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 |
|
||||
@ -255,7 +269,12 @@ Returns a `Attestation` object with a default signature. The `signature` field s
|
||||
|
||||
## `/validator/block`
|
||||
|
||||
Publishes a `SignedBeaconBlock` object to the network.
|
||||
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
|
||||
|
||||
@ -318,7 +337,13 @@ Else, returns a processing error description.
|
||||
|
||||
## `/validator/attestation`
|
||||
|
||||
Publishes a `Attestation` object to the network.
|
||||
Accepts an `Attestation` for verification. If it is valid, it 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
|
||||
|
||||
@ -362,4 +387,4 @@ Else, returns a processing error description.
|
||||
},
|
||||
"signature": "0xb76a1768c18615b5ade91a92e7d2ed0294f7e088e56e30fbe7e3aa6799c443b11bccadd578ca2cbd95d395ab689b9e4d03c88a56641791ab38dfa95dc1f4d24d1b19b9d36c96c20147ad03$649bd3c6c7e8a39cf2ffb99e07b4964d52854559f"
|
||||
}
|
||||
```
|
||||
```
|
||||
|
@ -1,5 +1,8 @@
|
||||
# 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:
|
||||
|
Loading…
Reference in New Issue
Block a user