update external links in the guide (#5651)
This commit is contained in:
Miran
GitHub
parent
e4cc3ad752
commit
2f694b9279
|
|
@ -27,7 +27,7 @@ sudo useradd -g nimbus nimbus -m -d /var/lib/nimbus
|
|||
|
||||
### 2. Create the service file
|
||||
|
||||
`systemd` services are created by placing a [service](https://www.freedesktop.org/software/systemd/man/systemd.service.html) file in `/etc/systemd/system`, or, if Nimbus was installed by a package manager, `/usr/lib/systemd/system`.
|
||||
`systemd` services are created by placing a [service](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html) file in `/etc/systemd/system`, or, if Nimbus was installed by a package manager, `/usr/lib/systemd/system`.
|
||||
|
||||
A good starting point is the [example service file](https://raw.githubusercontent.com/status-im/nimbus-eth2/stable/scripts/package_src/nimbus_beacon_node/image/lib/systemd/system/nimbus_beacon_node.service) in the Nimbus repository.
|
||||
|
||||
|
|
@ -36,7 +36,7 @@ A good starting point is the [example service file](https://raw.githubuserconten
|
|||
curl -s https://raw.githubusercontent.com/status-im/nimbus-eth2/stable/scripts/package_src/nimbus_beacon_node/image/lib/systemd/system/nimbus_beacon_node.service | sudo tee /etc/systemd/system/nimbus_beacon_node.service > /dev/null
|
||||
```
|
||||
|
||||
The format of service files is documented in the [systemd manual](https://www.freedesktop.org/software/systemd/man/systemd.service.html).
|
||||
The format of service files is documented in the [systemd manual](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html).
|
||||
|
||||
!!! tip
|
||||
Automatic restarts increase the risk that the doppelganger detection fails - set `RestartPreventExitStatus=129` to prevent this from happening
|
||||
|
|
@ -142,4 +142,4 @@ When running multiple beacon nodes, make sure that each service:
|
|||
## Further examples
|
||||
|
||||
- A [service template file](https://github.com/chfast/ethereum-node/blob/main/nimbus%40.service) by Pawel Bylica which allows you to start two services at the same time, e.g. `nimbus@holesky.service` and `nimbus@mainnet.service`.
|
||||
- The [EthereumOnARM](https://github.com/diglos/ethereumonarm/blob/main/fpm-package-builder/nimbus/extras/nimbus.service) project maintains a service file as part of their Ethereum installation package repository.
|
||||
- The [EthereumOnARM](https://github.com/EOA-Blockchain-Labs/ethereumonarm/blob/main/fpm-package-builder/l1-clients/consensus-layer/nimbus/extras/nimbus-beacon.service) project maintains a service file as part of their Ethereum installation package repository.
|
||||
|
|
|
|||
|
|
@ -6,17 +6,26 @@ For those of you who are unfamiliar, a [checksum](https://en.wikipedia.org/wiki/
|
|||
Verifying a checksum ensures there was no corruption or manipulation during the download and that the file was downloaded completely and correctly.
|
||||
For a short and simple guide on how to do so, [see here](https://www.devdungeon.com/content/how-verify-checksum).
|
||||
|
||||
In the case of the [v1.1.0](https://github.com/status-im/nimbus-eth2/releases/tag/v1.1.0) release for example, the SHA512 checksums are:
|
||||
In the case of the [v23.11.0](https://github.com/status-im/nimbus-eth2/releases/tag/v23.11.0) release for example, the SHA512 checksums are:
|
||||
|
||||
```
|
||||
# Linux AMD64
|
||||
8d553ea5422645b5f06001e7f47051706ae5cffd8d88c45e4669939f3abb6caf41a2477431fce3e647265cdb4f8671fa360d392f423ac68ffb9459607eaab462 nimbus_beacon_node
|
||||
1f53f58373fa3540028ff17f2a46254f4d9236f844a01fb548359e3241bd9e9791abc3637b474b4e834a08c36d259b84032db01975944d5eb92aef4fbab14821 nimbus_beacon_node
|
||||
efd1d5f0261b30cfb7e81c3e19ae5f2e2828a1af37a6f85c3151545a1725c68003d7331390ab4b24ac583cf62ccae448755b607c4717a7ec660bb95b4981d9a3 nimbus_validator_client
|
||||
# Linux ARM64
|
||||
93ffd03a0ce67f7d035e3dc45e97de3c2c9a05a8dd0c6d5f45402ddb04404dc3cf15b80fee972f34152ef171ce97c40f794448bc779ca056081c945f71f19788 nimbus_beacon_node
|
||||
27a2572216afead921a3c59ab1582ba3b0a06a53c753ac46a3aee4afe0122d01e2ddc4436b2518993369db06e3eff5fab88c1613dd79f1668b55be15b77802aa nimbus_beacon_node
|
||||
4affb3c9fb1c3fa83f99e6f806967db2a5fb1b474a4613ab4747d73fe6c0ed2e54391b6b8495cf438d50ee3b41ee46b824e4128bb4a9606e612a18bc0908998b nimbus_validator_client
|
||||
# Linux ARM
|
||||
f2e75f3fae2aea0a9f8d45861d52b0e2546c3990f453b509fab538692d18c64e65f58441c5492064fc371e0bc77de6bab970e05394cfd124417601b55cb4a825 nimbus_beacon_node
|
||||
83b5a99eb3bc98ebfa0a6c0c609c837e3e582e03a1728487dcdcfdca937d3185c6b4ca71ca2eb835b47840ff87b965286a2266ec876f1e0cff66d71e9d87d059 nimbus_beacon_node
|
||||
9a13849a1c72ca30adf54c87abaa603f1028b82f6eec5d0f4baca0e914ae422e86b42e8b9688f8031488032aa71d8819e0ccdea76d5f43bfd02d233dced8536a nimbus_validator_client
|
||||
# Windows AMD64
|
||||
fd68c8792ea60c2c72e9c2201745f9698bfd1dae4af4fa9e1683f082109045efebd1d80267f13cafeb1cd7414dc0f589a8a73f12161ac2758779369289d5a832 nimbus_beacon_node
|
||||
|
||||
625ac9fabc65679f484c0988ceb664c51c5e3749ac84ad90426d8029ba49590585f377f0fdeba92ff7330a43335f9068c03c09f628a44053a6c42e202b06a699 nimbus_beacon_node.exe
|
||||
78aa38439e6e6dbec7c68c33ce4e316bc06da9983409828ea61aa014d794bea968b482c954d38055f4ca36f12e8b5287d3afaa78b2c3650cb535ab1a127f30cb nimbus_validator_client.exe
|
||||
# macOS AMD64
|
||||
9f6d4b66cc9ee5334c1675e748c0bc99a1fae55a15ed5ac4db3d6ef287bc2ebaccda85984f613991d35f7c86c87c857281ab80aace02abaf1e94828a2690085a nimbus_beacon_node
|
||||
df7b676f451cd9bb05c6f55c2a1eaf5f166fdc7592e1f2b6d54c81f4c0234b6788d936a872d38dd922bd6bdd54e5276bc6d032d83540e76fb93ba65fee765a21 nimbus_validator_client
|
||||
# macOS ARM64
|
||||
1a8efc60b0cdedf0f931ba15509393c268285cd8f1fe3f21f123f241c83fa79befd5bd7aaae99a43ed6a87f69a9a1a8bcef37f1b9ca2c488cbaa124725111fbd nimbus_beacon_node
|
||||
96dd77e672aac8d92d6339b89891260d35d18d5938ae97f1126eb3f8fc86e25fafb506caf1f900479a17c762f76ad71b57bafb49d848627d2244d16075b45ee5 nimbus_validator_client
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Before building Nimbus for the first time, make sure to install the [prerequisit
|
|||
## Helpful resources
|
||||
|
||||
* [Ethereum consensus spec](https://github.com/ethereum/consensus-specs/)
|
||||
* [Ben Edgington's annotated spec](https://eth2book.info/bellatrix/)
|
||||
* [Ben Edgington's annotated spec](https://eth2book.info/capella/)
|
||||
* [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md)
|
||||
|
||||
## Nim programming language
|
||||
|
|
@ -208,7 +208,7 @@ To change the number of validators and nodes:
|
|||
make VALIDATORS=192 NODES=6 USER_NODES=1 local-testnet-minimal
|
||||
```
|
||||
|
||||
If you’d like to see the nodes running on separated sub-terminals inside one big window, install [Multitail](https://www.vanheusden.com/multitail/index.php) (if you're on a Mac, follow the instructions [here](https://brewinstall.org/Install-multitail-on-Mac-with-Brew/)), then:
|
||||
If you’d like to see the nodes running on separated sub-terminals inside one big window, install [Multitail](https://www.vanheusden.com/multitail/) (if you're on a Mac, follow the instructions [here](https://brewinstall.org/Install-multitail-on-Mac-with-Brew/)), then:
|
||||
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -32,5 +32,5 @@ sudo apt install vnstat
|
|||
|
||||
To run it:
|
||||
|
||||
*TBC - See [here](https://docs.rocketpool.net/guides/node/performance.html#beaconcha-in-website-using-the-beacon-chain-as-a-metric-source) for more info*
|
||||
*TBC - See [here](https://docs.rocketpool.net/guides/node/performance#beaconcha-in-website-using-the-beacon-chain-as-a-metric-source) for more info*
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ When building from source, you will need additional build dependencies to be ins
|
|||
|
||||
=== "Android"
|
||||
|
||||
- Install the [Termux](https://termux.com) app from FDroid or the Google Play store
|
||||
- Install the [Termux](https://termux.dev/en/) app from FDroid or the Google Play store
|
||||
- Install a [PRoot](https://wiki.termux.com/wiki/PRoot) of your choice following the instructions for your preferred distribution.
|
||||
Note, the Ubuntu PRoot is known to contain all Nimbus prerequisites compiled on Arm64 architecture (the most common architecture for Android devices).
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ You should be fine as long as you haven't changed the time and date settings on
|
|||
|
||||
=== "Linux"
|
||||
|
||||
On Linux, it is recommended to install [chrony](https://chrony.tuxfamily.org/).
|
||||
On Linux, it is recommended to install [chrony](https://chrony-project.org).
|
||||
|
||||
To install it:
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ For more on how keys are derived, see this [excellent post](https://blog.ethereu
|
|||
To stay consistent with the rest of the book, we'll take you though how to do this using the [deposit-cli's](https://github.com/ethereum/eth2.0-deposit-cli) [binary executable](https://github.com/ethereum/eth2.0-deposit-cli/releases).
|
||||
|
||||
Specifically, we'll be using the `existing-mnemonic` command.
|
||||
Here's a description of the command from the deposit-cli's [README](https://github.com/ethereum/eth2.0-deposit-cli#step-2-create-keys-and-deposit_data-json):
|
||||
Here's a description of the command from the deposit-cli's [README](https://github.com/ethereum/staking-deposit-cli#step-2-create-keys-and-deposit_data-json):
|
||||
|
||||
> This command is used to re-generate or derive new keys from your existing mnemonic.
|
||||
Use this command, if (i) you have already generated keys with this CLI before, (ii) you want to reuse your mnemonic that you know is secure that you generated elsewhere (reusing your eth1 mnemonic .etc), or (iii) you lost your keystores and need to recover your keys.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ As such, we try our best to explain things from first-principles.
|
|||
Keep in mind that you need to plug the disk to an USB 3.0 port (the blue port).
|
||||
|
||||
!!! note
|
||||
If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, please [read this recommended fix](https://www.raspberrypi.org/forums/viewtopic.php?t=245931#p1501426).
|
||||
If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, please [read this recommended fix](https://forums.raspberrypi.com/viewtopic.php?t=245931#p1501426).
|
||||
|
||||
## Steps
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ As such, we try our best to explain things from first-principles.
|
|||
|
||||
[Raspberry Pi Imager](https://www.raspberrypi.org/blog/raspberry-pi-imager-imaging-utility/) is an imaging utility that makes it simple to manage your microSD card with Raspberry Pi OS (the free Pi operating system based on Debian, previously called Raspbian).
|
||||
|
||||
You can find the [download](https://www.learnenough.com/command-line-tutorial/basics) link for your operating system here: [Windows](https://downloads.raspberrypi.org/imager/imager_1.4.exe), [macOS](https://downloads.raspberrypi.org/imager/imager_1.4.dmg), [Ubuntu](https://downloads.raspberrypi.org/imager/imager_1.4_amd64.deb).
|
||||
You can find the download link for your operating system here: [Windows](https://downloads.raspberrypi.org/imager/imager_1.4.exe), [macOS](https://downloads.raspberrypi.org/imager/imager_1.4.dmg), [Ubuntu](https://downloads.raspberrypi.org/imager/imager_1.4_amd64.deb).
|
||||
|
||||
### 2. Download 64-bit Raspberry Pi OS
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ network={
|
|||
|
||||
### 6. Enable SSH (using Linux or macOS)
|
||||
|
||||
You can [access the command line](https://www.raspberrypi.org/documentation/remote-access/ssh/) of a Raspberry Pi remotely from another computer or device on the same network using [SSH](https://en.wikipedia.org/wiki/Ssh_(Secure_Shell)).
|
||||
You can [access the command line](https://www.raspberrypi.com/documentation/computers/remote-access.html) of a Raspberry Pi remotely from another computer or device on the same network using [SSH](https://en.wikipedia.org/wiki/Ssh_(Secure_Shell)).
|
||||
|
||||
While SSH is not enabled by default, you can enable it by placing a file named `ssh`, without any extension, onto the boot partition of the SD card.
|
||||
|
||||
|
|
@ -253,7 +253,7 @@ Follow [this RPi4 guide](https://www.tomshardware.com/how-to/boot-raspberry-pi-4
|
|||
rpi-clone sda
|
||||
```
|
||||
|
||||
For more on `raspi-config`, see [here](https://www.raspberrypi.org/documentation/configuration/raspi-config.md).
|
||||
For more on `raspi-config`, see [here](https://www.raspberrypi.com/documentation/computers/configuration.html).
|
||||
|
||||
!!! tip
|
||||
To shutdown your Pi safely, run `sudo shutdown -h now`
|
||||
|
|
@ -424,7 +424,7 @@ Keep an eye on the number of peers you're currently connected to (in the above c
|
|||
!!! note
|
||||
15 - 20 peers and an average sync speed of **0.5 - 1.0** blocks per second is normal on `Holesky` with a Pi.
|
||||
If your sync speed is much slower than this, the root of the problem may be your USB3.0 to SSD adapter.
|
||||
See [this post](https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=245931) for a recommended workaround.
|
||||
See [this post](https://forums.raspberrypi.com/viewtopic.php?f=28&t=245931) for a recommended workaround.
|
||||
|
||||
|
||||
## Mainnet advice
|
||||
|
|
@ -442,7 +442,7 @@ Although we don't expect a modern Pi to fail, we recommend buying a spare Pi, an
|
|||
|
||||
### Systemd
|
||||
|
||||
Now that you have Nimbus up and running, we recommend [setting up a systemd service](https://www.raspberrypi.org/documentation/linux/usage/systemd.md) with an autorestart on boot (should you experience an unexpected power outage, this will ensure your validator restarts correctly).
|
||||
Now that you have Nimbus up and running, we recommend [setting up a systemd service](https://www.raspberrypi.com/documentation/computers/remote-access.html#server-configuration) with an autorestart on boot (should you experience an unexpected power outage, this will ensure your validator restarts correctly).
|
||||
|
||||
Systemd will also ensure your validator keeps running when you exit your ssh session (`Ctrl-C`) and/or switch off your laptop.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,4 +26,4 @@ Systemd will also ensure your validator keeps running when you exit your ssh ses
|
|||
|
||||
## Ethereum Foundation's Checklist
|
||||
|
||||
As a final check, we recommend you also go through the EF'S [staker checklist](https://launchpad.ethereum.org/checklist).
|
||||
As a final check, we recommend you also go through the EF'S [staker checklist](https://launchpad.ethereum.org/en/checklist).
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ This can lead to better packing in some cases, which can lead to slightly greate
|
|||
|
||||
## Useful resources
|
||||
|
||||
- [The journey of a validator balance](https://kb.beaconcha.in/rewards-and-penalties)
|
||||
- [The journey of a validator balance](https://kb.beaconcha.in/ethereum-staking/rewards-and-penalties)
|
||||
|
||||
- [Validator rewards in practice](https://pintail.xyz/posts/validator-rewards-in-practice/)
|
||||
|
||||
|
|
|
|||
|
|
@ -161,5 +161,5 @@ See our page on [monitoring the health of your node](./health.md) for more.
|
|||
### Trouble transferring data to/from USB3.0 SSDs
|
||||
|
||||
We have seen reports of degraded performance when using several types of USB3.0 to SSD adapters or when using native USB3.0 disk drives.
|
||||
[This post on RPi forums](https://www.raspberrypi.org/forums/viewtopic.php?t=245931#p1501426) details why there is a difference in behaviour from models prior to Pi 4 and the recommended workaround.
|
||||
[This post on RPi forums](https://forums.raspberrypi.com/viewtopic.php?t=245931#p1501426 ) details why there is a difference in behaviour from models prior to Pi 4 and the recommended workaround.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Web3Signer
|
||||
|
||||
[Web3Signer](https://docs.web3signer.consensys.net/en/latest/) is a remote signing server developed by Consensys.
|
||||
[Web3Signer](https://docs.web3signer.consensys.io) is a remote signing server developed by Consensys.
|
||||
It offers a [standardized REST API](https://consensys.github.io/web3signer/web3signer-eth2.html) allowing the Nimbus beacon node or validator client to operate without storing any validator keys locally.
|
||||
|
||||
You can instruct Nimbus to connect to a Web3Signer instance by supplying the `--web3-signer-url` command-line option. Since Nimbus obtains the list of validator keys automatically through the [`/api/v1/eth2/publicKeys`](https://consensys.github.io/web3signer/web3signer-eth2.html#tag/Public-Key/operation/ETH2_LIST) Web3Signer API endpoint, no further configuration is required.
|
||||
|
|
@ -135,7 +135,7 @@ If you are already using a threshold signing setup (e.g. based on Vouch and Dirk
|
|||
|
||||
The verifying Web3Signer is an experimental extension to the [Web3Signer protocol](https://consensys.github.io/web3signer/web3signer-eth2.html#tag/Signing/operation/ETH2_SIGN) which allows the remote signer to verify certain details of the signed blocks before creating a signature (for example, the signer may require the signed block to have a particular fee recipient value).
|
||||
|
||||
To enable this use case, the `BLOCK_V2` request type of the `/api/v1/eth2/sign/{identifier}` endpoint is extended with an additional array field named `proofs`. The array consists of objects with the properties `index`, `proof` and `value`, where `index` is an arbitrary [generalized index](https://github.com/ethereum/consensus-specs/blob/v1.4.0-beta.3/ssz/merkle-proofs.md#generalized-merkle-tree-index) of any property nested under the block body and `proof` is its corresponding Merkle proof against the block body root included in the request. The `value` property is optional and it is included only when the SSZ hash of the field included in the Merkle proof doesn't match its value.
|
||||
To enable this use case, the `BLOCK_V2` request type of the `/api/v1/eth2/sign/{identifier}` endpoint is extended with an additional array field named `proofs`. The array consists of objects with the properties `index`, `proof` and `value`, where `index` is an arbitrary [generalized index](https://github.com/ethereum/consensus-specs/blob/v1.4.0-beta.5/ssz/merkle-proofs.md#generalized-merkle-tree-index) of any property nested under the block body and `proof` is its corresponding Merkle proof against the block body root included in the request. The `value` property is optional and it is included only when the SSZ hash of the field included in the Merkle proof doesn't match its value.
|
||||
|
||||
Since the generalized index of a particular field may change in a hard-fork, in the remote keystore format the proven fields are usually specified by their name:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue