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
This commit is contained in:
Michael Sproul
parent
c64e17bb81
commit
1c9ec42dcb
@ -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:
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user