diff --git a/README.md b/README.md index 00900b8c3..acf5f5926 100644 --- a/README.md +++ b/README.md @@ -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. diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index f719a3a2b..22d279d8b 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -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) diff --git a/book/src/advanced_networking.md b/book/src/advanced_networking.md index 461f33f22..c79ddab01 100644 --- a/book/src/advanced_networking.md +++ b/book/src/advanced_networking.md @@ -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, diff --git a/book/src/api-bn.md b/book/src/api-bn.md index b82a8da1d..f806f8783 100644 --- a/book/src/api-bn.md +++ b/book/src/api-bn.md @@ -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 diff --git a/book/src/api-lighthouse.md b/book/src/api-lighthouse.md index 77800b539..ea282cf2b 100644 --- a/book/src/api-lighthouse.md +++ b/book/src/api-lighthouse.md @@ -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). diff --git a/book/src/api-vc-endpoints.md b/book/src/api-vc-endpoints.md index 1066d5ef3..ae091130f 100644 --- a/book/src/api-vc-endpoints.md +++ b/book/src/api-vc-endpoints.md @@ -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 diff --git a/book/src/api.md b/book/src/api.md index 56c1ff5ce..f8c54ad9a 100644 --- a/book/src/api.md +++ b/book/src/api.md @@ -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: diff --git a/book/src/cli.md b/book/src/cli.md index 60c87d5dc..6540d3fc3 100644 --- a/book/src/cli.md +++ b/book/src/cli.md @@ -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 diff --git a/book/src/contributing.md b/book/src/contributing.md index da18439c8..9204ff846 100644 --- a/book/src/contributing.md +++ b/book/src/contributing.md @@ -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 diff --git a/book/src/faq.md b/book/src/faq.md index 02a4bfea6..e14947fb0 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -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? diff --git a/book/src/http.md b/book/src/http.md index 0f9cd124d..82a688586 100644 --- a/book/src/http.md +++ b/book/src/http.md @@ -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/). diff --git a/book/src/intro.md b/book/src/intro.md index b31deeef8..fca075892 100644 --- a/book/src/intro.md +++ b/book/src/intro.md @@ -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 diff --git a/book/src/key-management.md b/book/src/key-management.md index 23d11d550..30d649f34 100644 --- a/book/src/key-management.md +++ b/book/src/key-management.md @@ -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. diff --git a/book/src/key-recovery.md b/book/src/key-recovery.md index e45887c29..2474d123c 100644 --- a/book/src/key-recovery.md +++ b/book/src/key-recovery.md @@ -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 diff --git a/book/src/mainnet-validator.md b/book/src/mainnet-validator.md index c5881c606..0f91b8e27 100644 --- a/book/src/mainnet-validator.md +++ b/book/src/mainnet-validator.md @@ -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. diff --git a/book/src/redundancy.md b/book/src/redundancy.md index b01a01dd2..3409effb3 100644 --- a/book/src/redundancy.md +++ b/book/src/redundancy.md @@ -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 diff --git a/book/src/setup.md b/book/src/setup.md index e4e1d92ff..cd9bce803 100644 --- a/book/src/setup.md +++ b/book/src/setup.md @@ -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. diff --git a/book/src/slashing-protection.md b/book/src/slashing-protection.md index a9bd31645..9ae6c102e 100644 --- a/book/src/slashing-protection.md +++ b/book/src/slashing-protection.md @@ -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. diff --git a/book/src/testnet-validator.md b/book/src/testnet-validator.md index 0bcd58c9a..98ba66c24 100644 --- a/book/src/testnet-validator.md +++ b/book/src/testnet-validator.md @@ -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. diff --git a/book/src/validator-create.md b/book/src/validator-create.md index e7c316a95..f13c449b9 100644 --- a/book/src/validator-create.md +++ b/book/src/validator-create.md @@ -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 diff --git a/book/src/validator-doppelganger.md b/book/src/validator-doppelganger.md index 3fa29043d..d880cce0a 100644 --- a/book/src/validator-doppelganger.md +++ b/book/src/validator-doppelganger.md @@ -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. diff --git a/book/src/validator-import-launchpad.md b/book/src/validator-import-launchpad.md index 6bde24732..aee9ac7b9 100644 --- a/book/src/validator-import-launchpad.md +++ b/book/src/validator-import-launchpad.md @@ -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: diff --git a/book/src/validator-inclusion.md b/book/src/validator-inclusion.md index 67e17feca..e6fbc0f16 100644 --- a/book/src/validator-inclusion.md +++ b/book/src/validator-inclusion.md @@ -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. diff --git a/book/src/voluntary-exit.md b/book/src/voluntary-exit.md index 593bc9969..0a26cbac1 100644 --- a/book/src/voluntary-exit.md +++ b/book/src/voluntary-exit.md @@ -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 . +To understand the phased rollout strategy for Ethereum upgrages, please visit . @@ -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`). diff --git a/book/src/wallet-create.md b/book/src/wallet-create.md index 17cac248b..0ebb44917 100644 --- a/book/src/wallet-create.md +++ b/book/src/wallet-create.md @@ -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