gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-17 21:08:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge latest master in v0.2.0

Browse Source
This commit is contained in:
Age Manning
2020-04-08 16:46:37 +10:00
parent b23f19272d 869b0621d6
commit 1779aa6a8a
144 changed files with 2603 additions and 1308 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
book/src/SUMMARY.md
View File

@@ -22,3 +22,4 @@
* [Database Configuration](./advanced_database.md)
* [Contributing](./contributing.md)
* [Development Environment](./setup.md)
* [FAQs](./faq.md)

78
book/src/become-a-validator-docker.md
View File

@@ -12,18 +12,28 @@ binary yourself.
> experience with docker-compose to integrate your locally built docker image
> with the docker-compose environment.
### 1. Clone the repository
## 0. Install Docker Compose
Once you have docker-compose
[installed](https://docs.docker.com/compose/install/), clone the
[sigp/lighthouse-docker](https://github.com/sigp/lighthouse-docker) repository.
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
git clone https://github.com/sigp/lighthouse-docker
cd lighthouse-docker
```
### 2. Configure the docker environment
## 2. Configure the Docker environment
Then, create a file named `.env` with the following contents (these values are
documented
@@ -41,36 +51,58 @@ DEPOSIT_VALUE=3200000000
_This `.env` file should live in the `lighthouse-docker` directory alongside the
`docker-compose.yml` file_.
### 3. Start Lighthouse
## 3. Start Lighthouse
Start the docker-compose environment (you may need to use `sudo`):
Start the docker-compose environment (you may need to prefix the below command with `sudo`):
```bash
$ docker-compose up
docker-compose up
```
Watch the output of this command for the `Saved new validator to disk` log, as
the `voting_pubkey` is the primary identifier for your new validator. This is
useful for finding your validator in block explorers. Here's an example of the
log:
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 | Jan 10 12:06:05.632 INFO Saved new validator to disk voting_pubkey: 0x8fc28504448783b10b0a7f5a321505b07ad2ad8d6a8430b8868a0fcdedee43766bee725855506626085776e020dfa472
validator_client_1 | Jan 10 12:06:05.632 INFO Saved new validator to disk
voting_pubkey: 0x8fc28504448783b10b0a7f5a321505b07ad2ad8d6a8430b8868a0fcdedee43766bee725855506626085776e020dfa472
```
This is one of the first logs outputted, so you may have to scroll up or perform a search in your terminal to find it.
> Note: the docker-compose setup includes a fast-synced geth node. You can
> 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/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.
### Installation complete!
To find an estimate for how long your beacon node will take to finish syncing, look for logs that look like this:
In the next step you'll need to locate your `eth1_deposit_data.rlp` file from
your `.lighthouse/validators` directory.
```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
```
The `./lighthouse` directory is in the root of the `lighthouse-docker`
repository. For example, if you ran Step 1 in `/home/karlm/` then you can find
your validator directory in
`/home/karlm/lighthouse-docker/.lighthouse/validators/`.
You'll find the estimated time under `est_time`. In the example above, that's `47 mins`.
You can now go to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
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).

134
book/src/become-a-validator-source.md
View File

@@ -1,103 +1,106 @@
# Become an Validator: Building from Source
# 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.
> Note: if you're not familiar with Rust or you'd like more detailed instructions, see our [installation guide](./installation.md).
## 1. Download and install Lighthouse
If you already have Rust installed, you can install Lighthouse with the
following commands (don't forget to use the `testnet5` branch):
Once you have Rust installed, you can install Lighthouse with the 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. `git clone https://github.com/sigp/lighthouse.git`
2. `cd lighthouse`
3. `git checkout testnet5`
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.
> - If you're not familiar with Rust or you'd like more detailed instructions,
> see the [Installation Guide](./installation.md) which contains a
> [Troubleshooting](installation.html#troubleshooting) section.
## 2. Start an Eth1 client
As Eth2 relies upon the Eth1 chain for validator on-boarding and eventually
Eth1 may use the Eth2 chain as a finality gadget, all Eth2 validators must have
a connection to an Eth1 node.
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 (this is, by chance, what we ended up
testing with), but you could use any client that implements the JSON RPC via
HTTP. At least for Geth, a fast-synced node is sufficient.
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
[Install geth](https://github.com/ethereum/go-ethereum/wiki/Installing-Geth)
and then use this command (or equivalent) to start your Eth1 node:
Once you have geth installed, use this command to start your Eth1 node:
```bash
$ geth --goerli --rpc
geth --goerli --rpc
```
## 3. Start your Beacon Node
## 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.
the internet and maintains a view of the chain.
Start your beacon node with:
```bash
$ lighthouse beacon --eth1 --http
lighthouse beacon --eth1 --http
```
>Note: the `--http` flag enables the HTTP API for the validator client. And the `--eth1` flag tells the beacon node that it should sync with an Ethereum1 node (e.g. Geth). These flags are only required if you wish to run a validator.
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 ...
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.
It has finished syncing once you see the following (truncated) log:
You'll know it's finished syncing once you see the following (truncated) log:
```
Dec 09 12:27:06.010 INFO Synced slot: 16835, ...
Dec 09 12:27:06.010 INFO Synced
slot: 16835, ...
```
> - The `--http` flag enables the HTTP API for the validator client.
> - The `--eth1` flag tells the beacon node that it should sync with an Ethereum
> 1 node (e.g., Geth). This is only required if you wish to run a validator.
## 4. Generate your validator key
Generate new validator BLS keypairs using:
```shell
$ lighthouse account validator new random
```bash
lighthouse account validator new random
```
Take note of the `voting_pubkey` of the new validator. This will be the primary
identifier of the validator. This is how you can find your validator in block
explorers.
Take note of the `voting_pubkey` of the new validator:
You've completed this step when you see the equivalent line:
```
INFO Saved new validator to disk
voting_pubkey: 0xa1625249d80...
```
It's the validator's primary identifier, and will be used to find your validator in block explorers.
You've completed this step when you see something like the following line:
```
Dec 02 21:42:01.337 INFO Generated validator directories count: 1, base_path: "/home/karl/.lighthouse/validators"
```
> - This will generate a new _validator directory_ in the `.lighthouse/validators`
> directory. Your validator directory will be identified by it's public key,
> which looks something like `0xc483de...`. You'll need to find this directory
> for the next step.
> - These keys are good enough for the Lighthouse testnet, however they shouldn't
> be considered secure until we've undergone a security audit (planned Jan
> 2020).
This means 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 (`voting_pubkey`). And is used to store your validator's deposit data, along with its voting and withdrawal keys.
> Note: these keypairs are good enough for the Lighthouse testnet, however they shouldn't be considered secure until we've undergone a security audit (planned March/April).
## 5. Start your validator client
For security reasons, the validator client runs separately to the beacon node.
The validator client stores private keys and signs messages generated by the
beacon node.
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.
@@ -105,32 +108,45 @@ stake.
Start the validator client with:
```bash
$ lighthouse validator
lighthouse validator
```
The validator client is running and has found your validator keys from step 3
when you see the following log:
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 isn't synced yet. It is safest to wait for
your node to sync before moving onto the next step, otherwise your validator
may activate before you're able to produce blocks and attestations. However, it
generally takes 4-8+ hours after deposit for a validator to become active. If
your `est_time` is less than 4 hours, you _should_ be fine to just move to the
next step. After all, this is a testnet and you're only risking Goerli ETH.
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 you'll need to locate your `eth1_deposit_data.rlp` file from
your `.lighthouse/validators` directory.
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`.
The `./lighthouse` directory is in your `$HOME` directory. For example, if
you're in Linux and your user is `karlm`, you can find your validator directory
in `/home/karlm/.lighthouse/validators/`.
You'll find it in `/home/.lighthouse/validators` -- in the sub-directory that corresponds to your validator's public key (`voting_pubkey`).
You can now go to [Become a Validator: Step 2](become-a-validator.html#2-submit-your-deposit-to-goerli).
> 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).

31
book/src/become-a-validator.md
View File

@@ -1,30 +1,36 @@
# 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.
Running a Lighthouse validator is easy if you're familiar with the terminal.
Before you start, you'll need [Metamask](https://metamask.io/) and 3.2 gETH
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 3.2 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:
- [Using `docker-compose`](./become-a-validator-docker.md): this is the easiest method.
- [Building from source](./become-a-validator-source.md): this is a little more involved, however it
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 have completed **only one** of these steps, move onto the next step.
Once you've completed **either one** of these steps, you can move onto the next step.
## 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 Step 1) to submit your 3.2 Goerli-ETH
directory (created in the previous step) to submit your 3.2 Goerli-ETH
deposit using Metamask.</p>
<p>Hint: the method used in Step 1 will determine where this file is
<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"
@@ -32,7 +38,7 @@ Once you have completed **only one** of these steps, move onto the next step.
</div>
<div class="form-signin" id="waitingDiv" style="display: none">
<p>Your validator deposit was submitted and this step is complete.</p>
<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>
@@ -40,16 +46,17 @@ Once you have completed **only one** of these steps, move onto the next step.
<div class="form-signin" id="errorDiv" style="display: none">
<h4 class="h3 mb-3 font-weight-normal">Error</h4>
<p id="errorText">Unknown error.</p>
<p id="errorText" style="color: red">Unknown error.</p>
<p style="color: red">Please refresh to reupload.</p>
</div>
> This deposit is using gETH (Goerli ETH) which has no real value. Don't ever
> 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 keeps synced with the network and the validator client produces
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

6
book/src/docker.md
View File

@@ -49,7 +49,7 @@ $ docker run lighthouse:local lighthouse --help
You can run a Docker beacon node with the following command:
```bash
$ docker run -p 9000:9000 -p 5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse beacon --http
$ docker run -p 9000:9000 -p 127.0.0.1:5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse beacon --http --http-address 0.0.0.0
```
> The `-p` and `-v` and values are described below.
@@ -78,8 +78,8 @@ $ docker run -p 9000:9000 sigp/lighthouse lighthouse beacon
```
If you use the `--http` flag you may also want to expose the HTTP port with `-p
5052:5052`.
127.0.0.1:5052:5052`.
```bash
$ docker run -p 9000:9000 -p 5052:5052 sigp/lighthouse lighthouse beacon --http
$ docker run -p 9000:9000 -p 127.0.0.1:5052:5052 sigp/lighthouse lighthouse beacon --http --http-address 0.0.0.0
```

81
book/src/faq.md Normal file
View File

@@ -0,0 +1,81 @@
# Frequently Asked Questions
## Why does it take so long for a validator to be activated?
After validators create their Eth1 deposit transaction there are two waiting
periods before they can start producing blocks and attestations:
1. Waiting for the beacon chain to recognise the Eth1 block containing the
deposit (generally 4 to 7.4 hours).
1. Waiting in the queue for validator activation (generally 6.4 minutes for
every 4 validators in the queue).
Detailed answers below:
### 1. Waiting for the beacon chain to detect the Eth1 deposit
Since the beacon chain uses Eth1 for validator on-boarding, beacon chain
validators must listen to event logs from the deposit contract. Since the
latest blocks of the Eth1 chain are vulnerable to re-orgs due to minor network
partitions, beacon nodes follow the Eth1 chain at a distance of 1,024 blocks
(~4 hours) (see
[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/validator.md#misc)).
This follow distance protects the beacon chain from on-boarding validators that
are likely to be removed due to an Eth1 re-org.
Now we know there's a 4 hours delay before the beacon nodes even _consider_ an
Eth1 block. Once they _are_ considering these blocks, there's a voting period
where beacon validators vote on which Eth1 to include in the beacon chain. This
period is defined as 32 epochs (~3.4 hours, see
[`ETH1_VOTING_PERIOD`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#time-parameters)).
During this voting period, each beacon block producer includes an
[`Eth1Data`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#eth1data)
in their block which counts as a vote towards what that validator considers to
be the head of the Eth1 chain at the start of the voting period (with respect
to `ETH1_FOLLOW_DISTANCE`, of course). You can see the exact voting logic
[here](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/validator.md#eth1-data).
These two delays combined represent the time between an Eth1 deposit being
included in an Eth1 data vote and that validator appearing in the beacon chain.
The `ETH1_FOLLOW_DISTANCE` delay causes a minimum delay of ~4 hours and
`ETH1_VOTING_PERIOD` means that if a validator deposit happens just _before_
the start of a new voting period then they might not notice this delay at all.
However, if the validator deposit happens just _after_ the start of the new
voting period the validator might have to wait ~3.4 hours for next voting
period. In times of very, very severe network issues, the network may even fail
to vote in new Eth1 blocks, stopping all new validator deposits!
> Note: you can see the list of validators included in the beacon chain using
> our REST API: [/beacon/validators/all](./http_beacon.md#beaconvalidatorsall)
### 2. Waiting for a validator to be activated
If a validator has provided an invalid public key or signature, they will
_never_ be activated or even show up in
[/beacon/validators/all](https://lighthouse-book.sigmaprime.io/http_beacon.html#beaconvalidatorsall).
They will simply be forgotten by the beacon chain! But, if those parameters were
correct, once the Eth1 delays have elapsed and the validator appears in the
beacon chain, there's _another_ delay before the validator becomes "active"
(canonical definition
[here](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#is_active_validator)) and can start producing blocks and attestations.
Firstly, the validator won't become active until their beacon chain balance is
equal to or greater than
[`MAX_EFFECTIVE_BALANCE`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#gwei-values)
(32 ETH on mainnet, usually 3.2 ETH on testnets). Once this balance is reached,
the validator must wait until the start of the next epoch (up to 6.4 minutes)
for the
[`process_registry_updates`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#registry-updates)
routine to run. This routine activates validators with respect to a [churn
limit](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#get_validator_churn_limit);
it will only allow the number of validators to increase (churn) by a certain
amount. Up until there are about 330,000 validators this churn limit is set to
4 and it starts to very slowly increase as the number of validators increases
from there.
If a new validator isn't within the churn limit from the front of the queue,
they will need to wait another epoch (6.4 minutes) for their next chance. This
repeats until the queue is cleared.
Once a validator has been activated, there's no more waiting! It's time to
produce blocks and attestations!

8
book/src/http_beacon.md
View File

@@ -166,6 +166,7 @@ Returns an object containing a single [`SignedBeaconBlock`](https://github.com/e
"beacon_block": {
"message": {
"slot": 0,
"proposer_index": 14,
"parent_root": "0x0000000000000000000000000000000000000000000000000000000000000000",
"state_root": "0xf15690b6be4ed42ea1ee0741eb4bfd4619d37be8229b84b4ddd480fb028dcc8f",
"body": {
@@ -444,7 +445,7 @@ canonical chain.
### Returns
Returns an object containing a single
[`BeaconState`](https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/beacon-chain.md#beaconstate)
[`BeaconState`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#beaconstate)
and its tree hash root.
### Example Response
@@ -454,6 +455,7 @@ and its tree hash root.
"root": "0x528e54ca5d4c957729a73f40fc513ae312e054c7295775c4a2b21f423416a72b",
"beacon_state": {
"genesis_time": 1575652800,
"genesis_validators_root": "0xa8a9226edee1b2627fb4117d7dea4996e64dec2998f37f6e824f74f2ce39a538",
"slot": 18478
}
}
@@ -505,7 +507,7 @@ Typical Responses | 200
### Returns
Returns an object containing the genesis
[`BeaconState`](https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/beacon-chain.md#beaconstate).
[`BeaconState`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#beaconstate).
### Example Response
@@ -565,7 +567,7 @@ Typical Responses | 200
### Returns
Returns an object containing the [`Fork`](https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/beacon-chain.md#fork) of the current head.
Returns an object containing the [`Fork`](https://github.com/ethereum/eth2.0-specs/blob/v0.11.1/specs/phase0/beacon-chain.md#fork) of the current head.
### Example Response

2
book/src/http_validator.md
View File

@@ -272,7 +272,7 @@ Returns a `Attestation` object with a default signature. The `signature` field s
"root": "0xaefd23b384994dc0c1a6b77836bdb2f24f209ebfe6c4819324d9685f4a43b4e1"
}
},
"signature": "0xc00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
"signature": "0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
```