cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Rename Eth1/Eth2 in documents (#3021)

Browse Source 
## Issue Addressed

Resolves https://github.com/sigp/lighthouse/issues/3019

## Proposed Changes

- Eth2 Eth2.0 Ethereum 2.0 -> Ethereum consensus
- Eth2 network -> consensus layer
- Ethereum 2.0 specification -> Ethereum proof-of-stake consensus specification
- Eth2 deposit contract -> Staking deposit contract
- Eth1 -> execution client

## Additional Info

The description needs to be updated by someone who has permission to do. 📝 

<img width="487" alt="image" src="https://user-images.githubusercontent.com/1885716/153995211-816d9561-751e-4810-abb9-83d979379783.png">
This commit is contained in:
Akihito Nakano 2022-03-02 01:05:08 +00:00
parent e34524be75
commit 668115a4b8
25 changed files with 100 additions and 100 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
README.md
View File

@ -1,6 +1,6 @@
# Lighthouse: Ethereum 2.0
# Lighthouse: Ethereum consensus client
An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime.
An open-source Ethereum consensus client, written in Rust and maintained by Sigma Prime.
[![Build Status]][Build Link] [![Book Status]][Book Link] [![Chat Badge]][Chat Link]
@ -22,7 +22,7 @@ An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prim
Lighthouse is:
- Ready for use on Eth2 mainnet.
- Ready for use on Ethereum consensus mainnet.
- Fully open-source, licensed under Apache 2.0.
- Security-focused. Fuzzing techniques have been continuously applied and several external security reviews have been performed.
- Built in [Rust](https://www.rust-lang.org), a modern language providing unique safety guarantees and
@ -30,13 +30,13 @@ Lighthouse is:
- Funded by various organisations, including Sigma Prime, the
Ethereum Foundation, ConsenSys, the Decentralization Foundation and private individuals.
- Actively involved in the specification and security analysis of the
Ethereum 2.0 specification.
Ethereum proof-of-stake consensus specification.
## Eth2 Deposit Contract
## Staking Deposit Contract
The Lighthouse team acknowledges
[`0x00000000219ab540356cBB839Cbe05303d7705Fa`](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa)
as the canonical Eth2 deposit contract address.
as the canonical staking deposit contract address.
## Documentation
@ -66,7 +66,7 @@ of the Lighthouse book.
## Contact
The best place for discussion is the [Lighthouse Discord
server](https://discord.gg/cyAszAh).
server](https://discord.gg/cyAszAh).
Sign up to the [Lighthouse Development Updates](http://eepurl.com/dh9Lvb) mailing list for email
notifications about releases, network status and other important information.

2
book/src/SUMMARY.md
View File

@ -17,7 +17,7 @@
* [Create a validator](./validator-create.md)
* [Key recovery](./key-recovery.md)
* [Validator Management](./validator-management.md)
* [Importing from the Eth2 Launchpad](./validator-import-launchpad.md)
* [Importing from the Staking Launchpad](./validator-import-launchpad.md)
* [Slashing Protection](./slashing-protection.md)
* [Voluntary Exits](./voluntary-exit.md)
* [Validator Monitoring](./validator-monitoring.md)

4
book/src/advanced_networking.md
View File

@ -46,7 +46,7 @@ still function if it is behind a NAT without any port mappings. Although
Lighthouse still functions, we recommend that some mechanism is used to ensure
that your Lighthouse node is publicly accessible. This will typically improve
your peer count, allow the scoring system to find the best/most favourable
peers for your node and overall improve the eth2 network.
peers for your node and overall improve the Ethereum consensus network.
Lighthouse currently supports UPnP. If UPnP is enabled on your router,
Lighthouse will automatically establish the port mappings for you (the beacon
@ -63,7 +63,7 @@ settings allow you construct your initial ENR. Their primary intention is for
setting up boot-like nodes and having a contactable ENR on boot. On normal
operation of a Lighthouse node, none of these flags need to be set. Setting
these flags incorrectly can lead to your node being incorrectly added to the
global DHT which will degrades the discovery process for all Eth2 peers.
global DHT which will degrades the discovery process for all Ethereum consensus peers.
The ENR of a Lighthouse node is initially set to be non-contactable. The
in-built discovery mechanism can determine if you node is publicly accessible,

6
book/src/api-bn.md
View File

@ -1,6 +1,6 @@
# Beacon Node API
Lighthouse implements the standard [Eth2 Beacon Node API
Lighthouse implements the standard [Beacon Node API
specification][OpenAPI]. Please follow that link for a full description of each API endpoint.
## Starting the server
@ -22,7 +22,7 @@ The following CLI flags control the HTTP server:
- `--http-tls-cert`: specify the path to the certificate file for Lighthouse to use.
- `--http-tls-key`: specify the path to the private key file for Lighthouse to use.
The schema of the API aligns with the standard Eth2 Beacon Node API as defined
The schema of the API aligns with the standard Beacon Node API as defined
at [github.com/ethereum/beacon-APIs](https://github.com/ethereum/beacon-APIs).
An interactive specification is available [here][OpenAPI].
@ -64,7 +64,7 @@ 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
All endpoints are documented in the [Beacon Node API
specification][OpenAPI].
### View the head of the beacon chain

22
book/src/api-lighthouse.md
View File

@ -199,23 +199,23 @@ See [Validator Inclusion APIs](./validator-inclusion.md).
### `/lighthouse/eth1/syncing`
Returns information regarding the Eth1 network, as it is required for use in
Eth2
Returns information regarding execution layer, as it is required for use in
consensus layer
#### Fields
- `head_block_number`, `head_block_timestamp`: the block number and timestamp
from the very head of the Eth1 chain. Useful for understanding the immediate
health of the Eth1 node that the beacon node is connected to.
from the very head of the execution chain. Useful for understanding the immediate
health of the execution node that the beacon node is connected to.
- `latest_cached_block_number` & `latest_cached_block_timestamp`: the block
number and timestamp of the latest block we have in our block cache.
- For correct Eth1 voting this timestamp should be later than the
- For correct execution client voting this timestamp should be later than the
`voting_period_start_timestamp`.
- `voting_target_timestamp`: The latest timestamp allowed for an eth1 block in this voting period.
- `voting_target_timestamp`: The latest timestamp allowed for an execution layer block in this voting period.
- `eth1_node_sync_status_percentage` (float): An estimate of how far the head of the
Eth1 node is from the head of the Eth1 chain.
- `100.0` indicates a fully synced Eth1 node.
- `0.0` indicates an Eth1 node that has not verified any blocks past the
execution node is from the head of the execution chain.
- `100.0` indicates a fully synced execution node.
- `0.0` indicates an execution node that has not verified any blocks past the
genesis block.
- `lighthouse_is_cached_and_ready`: Is set to `true` if the caches in the
beacon node are ready for block production.
@ -248,7 +248,7 @@ curl -X GET "http://localhost:5052/lighthouse/eth1/syncing" -H "accept: applica
### `/lighthouse/eth1/block_cache`
Returns a list of all the Eth1 blocks in the Eth1 voting cache.
Returns a list of all the execution layer blocks in the execution client voting cache.
#### Example
@ -320,7 +320,7 @@ curl -X GET "http://localhost:5052/lighthouse/eth1/deposit_cache" -H "accept: a
Obtains a `BeaconState` in SSZ bytes. Useful for obtaining a genesis state.
The `state_id` parameter is identical to that used in the [Standard Eth2.0 Beacon Node API
The `state_id` parameter is identical to that used in the [Standard Beacon Node API
`beacon/state`
routes](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot).

4
book/src/api-vc-endpoints.md
View File

@ -6,7 +6,7 @@ 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/spec`](#get-lighthousespec) | Get the Ethereum proof-of-stake consensus specification used by the validator.
[`GET /lighthouse/auth`](#get-lighthouseauth) | Get the location of the authorization token.
[`GET /lighthouse/validators`](#get-lighthousevalidators) | List all validators.
[`GET /lighthouse/validators/:voting_pubkey`](#get-lighthousevalidatorsvoting_pubkey) | Get a specific validator.
@ -79,7 +79,7 @@ Typical Responses | 200
## `GET /lighthouse/spec`
Returns the Eth2 specification loaded for this validator.
Returns the Ethereum proof-of-stake consensus specification loaded for this validator.
### HTTP Specification

2
book/src/api.md
View File

@ -1,6 +1,6 @@
# APIs
Lighthouse allows users to query the state of Eth2.0 using web-standard,
Lighthouse allows users to query the state of Ethereum consensus using web-standard,
RESTful HTTP/JSON APIs.
There are two APIs served by Lighthouse:

4
book/src/cli.md
View File

@ -1,6 +1,6 @@
# Command-Line Interface (CLI)
The `lighthouse` binary provides all necessary Ethereum 2.0 functionality. It
The `lighthouse` binary provides all necessary Ethereum consensus client functionality. It
has two primary sub-commands:
- `$ lighthouse beacon_node`: the largest and most fundamental component which connects to
@ -48,7 +48,7 @@ maintained by Sigma Prime.
However, for developers, testnets can be created by following the instructions
outlined in [testnets](./testnets.md). The steps listed here will create a
local database specified to a new testnet.
local database specified to a new testnet.
## Resuming from an existing database

6
book/src/contributing.md
View File

@ -35,10 +35,10 @@ Lighthouse maintains two permanent branches:
- [`unstable`][unstable]: Used for development, contains the latest PRs.
- Developers should base thier PRs on this branch.
## Ethereum 2.0
## Ethereum consensus client
Lighthouse is an implementation of the Ethereum 2.0 specification, as defined
in the [ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs)
Lighthouse is an implementation of the Ethereum proof-of-stake consensus specification, as defined
in the [ethereum/consensus-specs](https://github.com/ethereum/consensus-specs)
repository.
We recommend reading Danny Ryan's (incomplete) [Phase 0 for

48
book/src/faq.md
View File

@ -12,68 +12,68 @@
### Why does it take so long for a validator to be activated?
After validators create their Eth1 deposit transaction there are two waiting
After validators create their execution layer 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
1. Waiting for the beacon chain to recognise the execution layer 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
#### 1. Waiting for the beacon chain to detect the execution layer deposit
Since the beacon chain uses Eth1 for validator on-boarding, beacon chain
Since the beacon chain uses the execution layer 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
latest blocks of the execution chain are vulnerable to re-orgs due to minor network
partitions, beacon nodes follow the execution chain at a distance of 1,024 blocks
(~4 hours) (see
[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/eth2.0-specs/blob/v0.12.1/specs/phase0/validator.md#misc)).
[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/consensus-specs/blob/v0.12.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.
are likely to be removed due to an execution chain 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
execution layer block. Once they _are_ considering these blocks, there's a voting period
where beacon validators vote on which execution block hash 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.12.1/specs/phase0/beacon-chain.md#time-parameters)).
[`ETH1_VOTING_PERIOD`](https://github.com/ethereum/consensus-specs/blob/v0.12.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.12.1/specs/phase0/beacon-chain.md#eth1data)
[`Eth1Data`](https://github.com/ethereum/consensus-specs/blob/v0.12.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
be the head of the execution 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.12.1/specs/phase0/validator.md#eth1-data).
[here](https://github.com/ethereum/consensus-specs/blob/v0.12.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.
These two delays combined represent the time between an execution layer deposit being
included in an execution 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!
to vote in new execution layer blocks, stopping all new validator deposits!
#### 2. Waiting for a validator to be activated
If a validator has provided an invalid public key or signature, they will
_never_ be activated.
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
correct, once the execution layer 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.12.1/specs/phase0/beacon-chain.md#is_active_validator)) and can start producing blocks and attestations.
[here](https://github.com/ethereum/consensus-specs/blob/v0.12.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.12.1/specs/phase0/beacon-chain.md#gwei-values)
[`MAX_EFFECTIVE_BALANCE`](https://github.com/ethereum/consensus-specs/blob/v0.12.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.12.1/specs/phase0/beacon-chain.md#registry-updates)
[`process_registry_updates`](https://github.com/ethereum/consensus-specs/blob/v0.12.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.12.1/specs/phase0/beacon-chain.md#get_validator_churn_limit);
limit](https://github.com/ethereum/consensus-specs/blob/v0.12.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
@ -161,7 +161,7 @@ Nov 30 21:04:28.268 WARN Syncing eth1 block cache est_blocks_remaining: initia
```
This log indicates that your beacon node is downloading blocks and deposits
from your eth1 node. When the `est_blocks_remaining` is
from your execution node. When the `est_blocks_remaining` is
`initializing_deposits`, your node is downloading deposit logs. It may stay in
this stage for several minutes. Once the deposits logs are finished
downloading, the `est_blocks_remaining` value will start decreasing.
@ -170,7 +170,7 @@ It is perfectly normal to see this log when starting a node for the first time
or after being off for more than several minutes.
If this log continues appearing sporadically during operation, there may be an
issue with your eth1 endpoint.
issue with your execution client endpoint.
### Can I use redundancy in my staking setup?

2
book/src/http.md
View File

@ -13,7 +13,7 @@ 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 schema of the API aligns with the standard Eth2 Beacon Node API as defined
The schema of the API aligns with the standard Ethereum Beacon Node API as defined
at [github.com/ethereum/beacon-APIs](https://github.com/ethereum/beacon-APIs).
It is an easy-to-use RESTful HTTP/JSON API. An interactive specification is
available [here](https://ethereum.github.io/beacon-APIs/).

4
book/src/intro.md
View File

@ -7,11 +7,11 @@ _Documentation for Lighthouse users and developers._
[Chat Badge]: https://img.shields.io/badge/chat-discord-%237289da
[Chat Link]: https://discord.gg/cyAszAh
Lighthouse is an **Ethereum 2.0 client** that connects to other Ethereum 2.0
Lighthouse is an **Ethereum consensus client** that connects to other Ethereum consensus
clients to form a resilient and decentralized proof-of-stake blockchain.
We implement the specification as defined in the
[ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs) repository.
[ethereum/consensus-specs](https://github.com/ethereum/consensus-specs) repository.
## Topics

4
book/src/key-management.md
View File

@ -3,7 +3,7 @@
[launchpad]: https://launchpad.ethereum.org/
>
> **Note: we recommend using the [Eth2 launchpad][launchpad] to create validators.**
> **Note: we recommend using the [Staking launchpad][launchpad] to create validators.**
Lighthouse uses a _hierarchical_ key management system for producing validator
keys. It is hierarchical because each validator key can be _derived_ from a
@ -92,7 +92,7 @@ leaking private key data.
### Withdrawal Keypairs
In Eth2 Phase 0, withdrawal keypairs do not serve any immediate purpose.
In Ethereum consensus Phase 0, withdrawal keypairs do not serve any immediate purpose.
However, they become very important _after_ Phase 0: they will provide the
ultimate control of the ETH of withdrawn validators.

2
book/src/key-recovery.md
View File

@ -48,7 +48,7 @@ which contains all the information necessary to run a validator using the
`lighthouse vc` command. The password to this new keystore will be placed in
the `--secrets-dir` (default `~/.lighthouse/{network}/secrets`).
where `network` is the name of the Eth2 network passed in the `--network` parameter (default is `mainnet`).
where `network` is the name of the consensus layer network passed in the `--network` parameter (default is `mainnet`).
## Recover a EIP-2386 wallet

26
book/src/mainnet-validator.md
View File

@ -1,4 +1,4 @@
# Become an Eth2 Mainnet Validator
# Become an Ethereum Consensus Mainnet Validator
[launchpad]: https://launchpad.ethereum.org/
[lh-book]: https://lighthouse-book.sigmaprime.io/
@ -8,18 +8,18 @@
[slashing]: ./slashing-protection.md
[discord]: https://discord.gg/cyAszAh
Becoming an Eth2 validator is rewarding, but it's not for the faint of heart. You'll need to be
Becoming an Ethereum consensus validator is rewarding, but it's not for the faint of heart. You'll need to be
familiar with the rules of staking (e.g., rewards, penalties, etc.) and also configuring and
managing servers. You'll also need at least 32 ETH!
For those with an understanding of Eth2 and server maintenance, you'll find that running Lighthouse
For those with an understanding of Ethereum consensus and server maintenance, you'll find that running Lighthouse
is easy. Install it, start it, monitor it and keep it updated. You shouldn't need to interact
with it on a day-to-day basis.
Being educated is critical to validator success. Before submitting your mainnet deposit, we
recommend:
- Thoroughly exploring the [Eth2 Launchpad][launchpad] website
- Thoroughly exploring the [Staking Launchpad][launchpad] website
- Try running through the deposit process *without* actually submitting a deposit.
- Reading through this documentation, especially the [Slashing Protection][slashing] section.
- Running a [testnet validator][testnet-validator].
@ -37,7 +37,7 @@ Remember, if you get stuck you can always reach out on our [Discord][discord].
> occured through the use of Lighthouse. We have an experienced internal security team and have
> undergone multiple third-party security-reviews, however the possibility of bugs or malicious
> interference remains a real and constant threat. Validators should be prepared to lose some rewards
> due to the actions of other actors on the Eth2 network or software bugs. See the
> due to the actions of other actors on the consensus layer or software bugs. See the
> [software license][license] for more detail on liability.
## Using Lighthouse for Mainnet
@ -57,7 +57,7 @@ provide a `--network` flag instead of relying on the default.
There are five primary steps to become a testnet validator:
1. Create validator keys and submit deposits.
1. Start an Eth1 client.
1. Start an execution client.
1. Install Lighthouse.
1. Import the validator keys into Lighthouse.
1. Start Lighthouse.
@ -68,10 +68,10 @@ setting aside one or two hours for this process.
### Step 1. Create validator keys
The Ethereum Foundation provides an "Eth2 launch pad" for creating validator keypairs and submitting
The Ethereum Foundation provides a "Staking Launchpad" for creating validator keypairs and submitting
deposits:
- [Eth2 Launchpad][launchpad]
- [Staking Launchpad][launchpad]
Please follow the steps on the launch pad site to generate validator keys and submit deposits. Make
sure you select "Lighthouse" as your client.
@ -79,10 +79,10 @@ 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
### Step 2. Start an execution client
Since Eth2 relies upon the Eth1 chain for validator on-boarding, all Eth2 validators must have a
connection to an Eth1 node.
Since the consensus chain relies upon the execution chain for validator on-boarding, all consensus validators must have a
connection to an execution client.
We provide instructions for using Geth, but you could use any client that implements the JSON RPC
via HTTP. A fast-synced node is sufficient.
@ -95,7 +95,7 @@ geth. Otherwise [see here](https://github.com/ethereum/go-ethereum/wiki/Installi
#### Starting Geth
Once you have geth installed, use this command to start your Eth1 node:
Once you have geth installed, use this command to start your execution node:
```bash
geth --http
@ -116,7 +116,7 @@ its `--version` info.
### Step 4. Import validator keys to Lighthouse
When Lighthouse is installed, follow the [Importing from the Ethereum 2.0 Launch
When Lighthouse is installed, follow the [Importing from the Ethereum Staking Launch
pad](./validator-import-launchpad.md) instructions so the validator client can
perform your validator duties.

16
book/src/redundancy.md
View File

@ -5,7 +5,7 @@
There are three places in Lighthouse where redundancy is notable:
1. ✅ GOOD: Using a redundant Beacon node in `lighthouse vc --beacon-nodes`
1. ✅ GOOD: Using a redundant Eth1 node in `lighthouse bn --eth1-endpoints`
1. ✅ GOOD: Using a redundant execution node in `lighthouse bn --eth1-endpoints`
1. ☠️ BAD: Running redundant `lighthouse vc` instances with overlapping keypairs.
I mention (3) since it is unsafe and should not be confused with the other two
@ -55,7 +55,7 @@ In our previous example we listed `http://192.168.1.1:5052` as a redundant
node. Apart from having sufficient resources, the backup node should have the
following flags:
- `--staking`: starts the HTTP API server and ensures the Eth1 chain is synced.
- `--staking`: starts the HTTP API server and ensures the execution chain is synced.
- `--http-address 0.0.0.0`: this allows *any* external IP address to access the
HTTP server (a firewall should be configured to deny unauthorized access to port
`5052`). This is only required if your backup node is on a different host.
@ -92,23 +92,23 @@ There are 64 subnets and each validator will result in a subscription to *at
least* one subnet. So, using the two aforementioned flags will result in
resource consumption akin to running 64+ validators.
## Redundant Eth1 nodes
## Redundant execution nodes
Compared to redundancy in beacon nodes (see above), using redundant Eth1 nodes
Compared to redundancy in beacon nodes (see above), using redundant execution nodes
is very straight-forward:
1. `lighthouse bn --eth1-endpoints http://localhost:8545`
1. `lighthouse bn --eth1-endpoints http://localhost:8545,http://192.168.0.1:8545`
In the case of (1), any failure on `http://localhost:8545` will result in a
failure to update the Eth1 cache in the beacon node. Consistent failure over a
failure to update the execution client cache in the beacon node. Consistent failure over a
period of hours may result in a failure in block production.
However, in the case of (2), the `http://192.168.0.1:8545` Eth1 endpoint will
be tried each time the first fails. Eth1 endpoints will be tried from first to
However, in the case of (2), the `http://192.168.0.1:8545` execution client endpoint will
be tried each time the first fails. Execution client endpoints will be tried from first to
last in the list, until a successful response is obtained.
There is no need for special configuration on the Eth1 endpoint, all endpoints can (probably should)
There is no need for special configuration on the execution client endpoint, all endpoints can (probably should)
be configured identically.
> Note: When supplying multiple endpoints the `http://localhost:8545` address must be explicitly

2
book/src/setup.md
View File

@ -10,7 +10,7 @@ base dependencies.
The additional requirements for developers are:
- [`ganache-cli`](https://github.com/trufflesuite/ganache-cli). This is used to
simulate the Eth1 chain during tests. You'll get failures during tests if you
simulate the execution chain during tests. You'll get failures during tests if you
don't have `ganache-cli` available on your `PATH`.
- [`cmake`](https://cmake.org/cmake/help/latest/command/install.html). Used by
some dependencies. See [`Installation Guide`](./installation.md) for more info.

2
book/src/slashing-protection.md
View File

@ -1,6 +1,6 @@
# Slashing Protection
The security of Ethereum 2.0's proof of stake protocol depends on penalties for misbehaviour, known
The security of the Ethereum proof-of-stake protocol depends on penalties for misbehaviour, known
as _slashings_. Validators that sign conflicting messages (blocks or attestations), can be slashed
by other validators through the inclusion of a `ProposerSlashing` or `AttesterSlashing` on chain.

8
book/src/testnet-validator.md
View File

@ -3,17 +3,17 @@
[mainnet-validator]: ./mainnet-validator.md
[prater-launchpad]: https://prater.launchpad.ethereum.org/
Joining an Eth2 testnet is a great way to get familiar with staking in Phase 0. All users should
Joining an Ethereum consensus 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.
To join a testnet, you can follow the [Become an Eth2 Mainnet Validator][mainnet-validator]
To join a testnet, you can follow the [Become an Ethereum consensus Mainnet Validator][mainnet-validator]
instructions but with a few differences:
1. Use the appropriate Eth2 launchpad website:
1. Use the appropriate Staking launchpad website:
- [Prater][prater-launchpad]
1. Instead of `--network mainnet`, use the appropriate network flag:
- `--network prater`: Prater.
1. Use a Goerli Eth1 node instead of a mainnet one:
1. Use a Goerli execution node instead of a mainnet one:
- For Geth, this means using `geth --goerli --http`.
1. Notice that Lighthouse will store its files in a different directory by default:
- `~/.lighthouse/prater`: Prater.

2
book/src/validator-create.md
View File

@ -3,7 +3,7 @@
[launchpad]: https://launchpad.ethereum.org/
>
> **Note: we recommend using the [Eth2 launchpad][launchpad] to create validators.**
> **Note: we recommend using the [Staking launchpad][launchpad] to create validators.**
Validators are fundamentally represented by a BLS keypair. In Lighthouse, we
use a [wallet](./wallet-create.md) to generate these keypairs. Once a wallet

2
book/src/validator-doppelganger.md
View File

@ -6,7 +6,7 @@
From Lighthouse `v1.5.0`, the *Doppelganger Protection* feature is available for the Validator
Client. Taken from the German *[doppelgänger]*, which translates literally to "double-walker", a
"doppelganger" in Eth2 refers to another instance of a validator running in a separate validator
"doppelganger" in the context of Ethereum proof-of-stake refers to another instance of a validator running in a separate validator
process. As detailed in [Slashing Protection], running the same validator twice will inevitably
result in slashing.

10
book/src/validator-import-launchpad.md
View File

@ -1,9 +1,9 @@
# Importing from the Ethereum 2.0 Launch pad
# Importing from the Ethereum Staking Launch pad
The [Eth2 Lauchpad](https://github.com/ethereum/eth2.0-deposit) is a website
The [Staking Lauchpad](https://github.com/ethereum/eth2.0-deposit) is a website
from the Ethereum Foundation which guides users how to use the
[`eth2.0-deposit-cli`](https://github.com/ethereum/eth2.0-deposit-cli)
command-line program to generate Eth2 validator keys.
command-line program to generate consensus validator keys.
The keys that are generated from `eth2.0-deposit-cli` can be easily loaded into
a Lighthouse validator client (`lighthouse vc`). In fact, both of these
@ -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 Launch pad
you will be if you just ran the `./deposit.sh` script from the Staking Launch pad
website). If this is not the case, simply change the `--directory` to point to
the `validator_keys` directory.
@ -38,7 +38,7 @@ section, all other users can use:
lighthouse --network mainnet account validator import --directory validator_keys
```
Note: The user must specify the Eth2 network that they are importing the keys for using the `--network` flag.
Note: The user must specify the consensus client network that they are importing the keys for using the `--network` flag.
After which they will be prompted for a password for each keystore discovered:

2
book/src/validator-inclusion.md
View File

@ -4,7 +4,7 @@ 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,
These endpoints are not stable or included in the Ethereum consensus standard API. As such,
they are subject to change or removal without a change in major release
version.

4
book/src/voluntary-exit.md
View File

@ -15,7 +15,7 @@ This number can be much higher depending on how many other validators are queued
Even though users can perform a voluntary exit in phase 0, they **cannot withdraw their exited funds at this point in time**.
This implies that the staked funds are effectively **frozen** until withdrawals are enabled in future phases.
To understand the phased rollout strategy for Eth2, please visit <https://ethereum.org/en/eth2/#roadmap>.
To understand the phased rollout strategy for Ethereum upgrages, please visit <https://ethereum.org/en/upgrades/#roadmap>.
@ -25,7 +25,7 @@ In order to initiate an exit, users can use the `lighthouse account validator ex
- The `--keystore` flag is used to specify the path to the EIP-2335 voting keystore for the validator.
- The `--beacon-node` flag is used to specify a beacon chain HTTP endpoint that confirms to the [Eth2.0 Standard Beacon Node API](https://ethereum.github.io/beacon-APIs/) specifications. That beacon node will be used to validate and propagate the voluntary exit. The default value for this flag is `http://localhost:5052`.
- The `--beacon-node` flag is used to specify a beacon chain HTTP endpoint that confirms to the [Beacon Node API](https://ethereum.github.io/beacon-APIs/) specifications. That beacon node will be used to validate and propagate the voluntary exit. The default value for this flag is `http://localhost:5052`.
- The `--network` flag is used to specify a particular Eth2 network (default is `mainnet`).

2
book/src/wallet-create.md
View File

@ -3,7 +3,7 @@
[launchpad]: https://launchpad.ethereum.org/
>
> **Note: we recommend using the [Eth2 launchpad][launchpad] to create validators.**
> **Note: we recommend using the [Staking launchpad][launchpad] to create validators.**
A wallet allows for generating practically unlimited validators from an
easy-to-remember 24-word string (a mnemonic). As long as that mnemonic is