From 1c9ec42dcbe3b143adc947ce1d87e6834495534d Mon Sep 17 00:00:00 2001 From: Michael Sproul Date: Fri, 26 Aug 2022 21:47:50 +0000 Subject: [PATCH] More merge doc updates (#3509) ## Proposed Changes Address a few shortcomings of the book noticed by users: - Remove description of redundant execution nodes - Use an Infura eth1 node rather than an eth2 node in the merge migration example - Add an example of the fee recipient address format (we support addresses without the 0x prefix, but 0x prefixed feels more canonical). - Clarify that Windows support is no longer beta - Add a link to the MSRV to the build-from-source instructions --- book/src/installation-binaries.md | 4 +--- book/src/installation-source.md | 11 +++++++---- book/src/installation.md | 6 ++++-- book/src/merge-migration.md | 7 ++++--- book/src/redundancy.md | 29 ++++++++--------------------- book/src/suggested-fee-recipient.md | 11 +++++++++++ 6 files changed, 35 insertions(+), 33 deletions(-) diff --git a/book/src/installation-binaries.md b/book/src/installation-binaries.md index 7a5aad32b..2365ea7ed 100644 --- a/book/src/installation-binaries.md +++ b/book/src/installation-binaries.md @@ -4,8 +4,6 @@ Each Lighthouse release contains several downloadable binaries in the "Assets" section of the release. You can find the [releases on Github](https://github.com/sigp/lighthouse/releases). -> Note: binaries are provided for Windows native, but Windows Lighthouse support is still in beta testing. - ## Platforms Binaries are supplied for four platforms: @@ -13,7 +11,7 @@ Binaries are supplied for four platforms: - `x86_64-unknown-linux-gnu`: AMD/Intel 64-bit processors (most desktops, laptops, servers) - `aarch64-unknown-linux-gnu`: 64-bit ARM processors (Raspberry Pi 4) - `x86_64-apple-darwin`: macOS with Intel chips -- `x86_64-windows`: Windows with 64-bit processors (Beta) +- `x86_64-windows`: Windows with 64-bit processors Additionally there is also a `-portable` suffix which indicates if the `portable` feature is used: diff --git a/book/src/installation-source.md b/book/src/installation-source.md index 1f8477260..661035ca5 100644 --- a/book/src/installation-source.md +++ b/book/src/installation-source.md @@ -52,10 +52,9 @@ choco install cmake --installargs 'ADD_CMAKE_TO_PATH=System' choco install llvm ``` -These dependencies are for compiling Lighthouse natively on Windows, which is currently in beta -testing. Lighthouse can also run successfully under the [Windows Subsystem for Linux (WSL)][WSL]. -If using Ubuntu under WSL, you should follow the instructions for Ubuntu listed in the [Dependencies -(Ubuntu)](#ubuntu) section. +These dependencies are for compiling Lighthouse natively on Windows. Lighthouse can also run +successfully under the [Windows Subsystem for Linux (WSL)][WSL]. If using Ubuntu under WSL, you +should follow the instructions for Ubuntu listed in the [Dependencies (Ubuntu)](#ubuntu) section. [WSL]: https://docs.microsoft.com/en-us/windows/wsl/about @@ -138,6 +137,10 @@ See ["Configuring the `PATH` environment variable" Make sure you are running the latest version of Rust. If you have installed Rust using rustup, simply type `rustup update`. +If you can't install the latest version of Rust you can instead compile using the Minimum Supported +Rust Version (MSRV) which is listed under the `rust-version` key in Lighthouse's +[Cargo.toml](https://github.com/sigp/lighthouse/blob/stable/lighthouse/Cargo.toml). + If compilation fails with `(signal: 9, SIGKILL: kill)`, this could mean your machine ran out of memory during compilation. If you are on a resource-constrained device you can look into [cross compilation](./cross-compiling.md), or use a [pre-built diff --git a/book/src/installation.md b/book/src/installation.md index e222c401a..bc546e098 100644 --- a/book/src/installation.md +++ b/book/src/installation.md @@ -1,6 +1,6 @@ # 📦 Installation -Lighthouse runs on Linux, macOS, and Windows (still in beta testing). +Lighthouse runs on Linux, macOS, and Windows. There are three core methods to obtain the Lighthouse application: @@ -8,9 +8,11 @@ There are three core methods to obtain the Lighthouse application: - [Docker images](./docker.md). - [Building from source](./installation-source.md). -The community maintains additional installation methods (currently only one). +Community-maintained additional installation methods: - [Homebrew package](./homebrew.md). +- Arch Linux AUR packages: [source](https://aur.archlinux.org/packages/lighthouse-ethereum), + [binary](https://aur.archlinux.org/packages/lighthouse-ethereum-bin). Additionally, there are two extra guides for specific uses: diff --git a/book/src/merge-migration.md b/book/src/merge-migration.md index 9ac22a761..104a7ead6 100644 --- a/book/src/merge-migration.md +++ b/book/src/merge-migration.md @@ -11,11 +11,12 @@ There are two configuration changes required for a Lighthouse node to operate co the merge: 1. You *must* run your own execution engine such as Geth or Nethermind alongside Lighthouse. - You *must* update your Lighthouse configuration to connect to the execution engine using new + You *must* update your `lighthouse bn` configuration to connect to the execution engine using new flags which are documented on this page in the [Connecting to an execution engine](#connecting-to-an-execution-engine) section. 2. If your Lighthouse node has validators attached you *must* nominate an Ethereum address to - receive transactions tips from blocks proposed by your validators. This is covered on the + receive transactions tips from blocks proposed by your validators. These changes should + be made to your `lighthouse vc` configuration, and are covered on the [Suggested fee recipient](./suggested-fee-recipient.md) page. Additionally, you _must_ update Lighthouse to v3.0.0 (or later), and must update your execution @@ -76,7 +77,7 @@ lighthouse \ --network mainnet \ beacon_node \ --http \ - --eth1-endpoints http://localhost:8545,https://TOKEN@eth2-beacon-mainnet.infura.io + --eth1-endpoints http://localhost:8545,https://mainnet.infura.io/v3/TOKEN ``` Converting the above to a post-merge configuration would render: diff --git a/book/src/redundancy.md b/book/src/redundancy.md index 3409effb3..d4156832b 100644 --- a/book/src/redundancy.md +++ b/book/src/redundancy.md @@ -4,8 +4,8 @@ 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 execution node in `lighthouse bn --eth1-endpoints` +1. ✅ GOOD: Using a redundant beacon node in `lighthouse vc --beacon-nodes` +1. ❌ NOT SUPPORTED: Using a redundant execution node in `lighthouse bn --execution-endpoint` 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 @@ -94,23 +94,10 @@ resource consumption akin to running 64+ validators. ## Redundant execution nodes -Compared to redundancy in beacon nodes (see above), using redundant execution nodes -is very straight-forward: +Lighthouse previously supported redundant execution nodes for fetching data from the deposit +contract. On merged networks _this is no longer supported_. Each Lighthouse beacon node must be +configured in a 1:1 relationship with an execution node. For more information on the rationale +behind this decision please see the [Merge Migration](./merge-migration.md) documentation. -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 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` 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 execution client endpoint, all endpoints can (probably should) -be configured identically. - -> Note: When supplying multiple endpoints the `http://localhost:8545` address must be explicitly -> provided (if it is desired). It will only be used as default if no `--eth1-endpoints` flag is -> provided at all. +To achieve redundancy we recommend configuring [Redundant beacon nodes](#redundant-beacon-nodes) +where each has its own execution engine. diff --git a/book/src/suggested-fee-recipient.md b/book/src/suggested-fee-recipient.md index bcd587802..c966481a3 100644 --- a/book/src/suggested-fee-recipient.md +++ b/book/src/suggested-fee-recipient.md @@ -65,11 +65,22 @@ Below is an example of the validator_definitions.yml with `suggested_fee_recipie The `--suggested-fee-recipient` can be provided to the VC to act as a default value for all validators where a `suggested_fee_recipient` is not loaded from another method. +Provide a 0x-prefixed address, e.g. + +``` +lighthouse vc --suggested-fee-recipient 0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b ... +``` + + ### 3. Using the "--suggested-fee-recipient" flag on the beacon node The `--suggested-fee-recipient` can be provided to the BN to act as a default value when the validator client does not transmit a `suggested_fee_recipient` to the BN. +``` +lighthouse bn --suggested-fee-recipient 0x25c4a76E7d118705e7Ea2e9b7d8C59930d8aCD3b ... +``` + **This value should be considered an emergency fallback**. You should set the fee recipient in the validator client in order for the execution node to be given adequate notice of block proposal.