gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-04-27 01:33:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove Goerli support (#5770)

Browse Source 
* Delete Goerli

* Generate validator manager test vectors

* Fix newlines in CLI docs

* Fix deposit-cli tests

* Run web3signer tests for Holesky from Bellatrix

* Fix mainnet bellatrix web3signer test

* Merge remote-tracking branch 'origin/unstable' into rm-goerli

* Fix snafu
This commit is contained in:
Michael Sproul
2024-05-27 17:59:10 +10:00
committed by GitHub
parent 6f05863007
commit 7f8b600f2a
46 changed files with 64 additions and 255 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -686,7 +686,7 @@ The first few lines of the response would look like:
"slot": "1",
"parent_slot": "0",
"proposer_index": 93,
"graffiti": "EF #vm-eth2-raw-iron-prater-101"
"graffiti": "EF #vm-eth2-raw-iron-101"
},
"attestation_rewards": {
"total": 637260,

4
book/src/api-vc-auth-header.md
View File

@@ -31,7 +31,7 @@ When starting the validator client it will output a log message containing the p
to the file containing the api token.
```text
Sep 28 19:17:52.615 INFO HTTP API started api_token_file: "$HOME/prater/validators/api-token.txt", listen_address: 127.0.0.1:5062
Sep 28 19:17:52.615 INFO HTTP API started api_token_file: "$HOME/holesky/validators/api-token.txt", listen_address: 127.0.0.1:5062
```
The _path_ to the API token may also be fetched from the HTTP API itself (this endpoint is the only
@@ -45,7 +45,7 @@ Response:
```json
{
"token_path": "/home/karlm/.lighthouse/prater/validators/api-token.txt"
"token_path": "/home/karlm/.lighthouse/holesky/validators/api-token.txt"
}
```

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

@@ -225,7 +225,7 @@ Example Response Body
```json
{
"data": {
"CONFIG_NAME": "prater",
"CONFIG_NAME": "holesky",
"PRESET_BASE": "mainnet",
"TERMINAL_TOTAL_DIFFICULTY": "10790000",
"TERMINAL_BLOCK_HASH": "0x0000000000000000000000000000000000000000000000000000000000000000",
@@ -353,7 +353,7 @@ Example Response Body
```json
{
"token_path": "/home/karlm/.lighthouse/prater/validators/api-token.txt"
"token_path": "/home/karlm/.lighthouse/holesky/validators/api-token.txt"
}
```

4
book/src/help_bn.md
View File

@@ -345,8 +345,8 @@ OPTIONS:
Defines how many seconds to wait between each message sent to the monitoring-endpoint. Default: 60s
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--network-dir <DIR>
Data directory for network keys. Defaults to network/ inside the beacon node dir.

4
book/src/help_general.md
View File

@@ -61,8 +61,8 @@ OPTIONS:
The maximum size (in MB) each log file can grow to before rotating. If set to 0, background file logging is
disabled. [default: 200]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--safe-slots-to-import-optimistically <INTEGER>
Used to coordinate manual overrides of the SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override

4
book/src/help_vc.md
View File

@@ -175,8 +175,8 @@ OPTIONS:
Defines how many seconds to wait between each message sent to the monitoring-endpoint. Default: 60s
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--proposer-nodes <NETWORK_ADDRESSES>
Comma-separated addresses to one or more beacon node HTTP APIs. These specify nodes that are used to send
beacon block proposals. A failure will revert back to the standard beacon nodes specified in --beacon-nodes.

4
book/src/help_vm.md
View File

@@ -57,8 +57,8 @@ OPTIONS:
The maximum size (in MB) each log file can grow to before rotating. If set to 0, background file logging is
disabled. [default: 200]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--safe-slots-to-import-optimistically <INTEGER>
Used to coordinate manual overrides of the SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override

4
book/src/help_vm_create.md
View File

@@ -100,8 +100,8 @@ OPTIONS:
If present, the mnemonic will be read in from this file.
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--output-path <DIRECTORY>
The path to a directory where the validator and (optionally) deposits files will be created. The directory
will be created if it does not exist.

4
book/src/help_vm_import.md
View File

@@ -64,8 +64,8 @@ OPTIONS:
The maximum size (in MB) each log file can grow to before rotating. If set to 0, background file logging is
disabled. [default: 200]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--safe-slots-to-import-optimistically <INTEGER>
Used to coordinate manual overrides of the SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY parameter. This flag should
only be used if the user has a clear understanding that the broad Ethereum community has elected to override

4
book/src/help_vm_move.md
View File

@@ -76,8 +76,8 @@ OPTIONS:
The maximum size (in MB) each log file can grow to before rotating. If set to 0, background file logging is
disabled. [default: 200]
--network <network>
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, prater, goerli, gnosis,
chiado, sepolia, holesky]
Name of the Eth2 chain Lighthouse will sync and follow. [possible values: mainnet, gnosis, chiado, sepolia,
holesky]
--prefer-builder-proposals <prefer-builder-proposals>
If this flag is set, Lighthouse will always prefer blocks constructed by builders, regardless of payload
value. [possible values: true, false]

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

@@ -75,21 +75,21 @@ mnemonic is encrypted with a password. It is the responsibility of the user to
define a strong password. The password is only required for interacting with
the wallet, it is not required for recovering keys from a mnemonic.
To create a wallet, use the `lighthouse account wallet` command. For example, if we wish to create a new wallet for the Goerli testnet named `wally` and saves it in `~/.lighthouse/goerli/wallets` with a randomly generated password saved
To create a wallet, use the `lighthouse account wallet` command. For example, if we wish to create a new wallet for the Holesky testnet named `wally` and saves it in `~/.lighthouse/holesky/wallets` with a randomly generated password saved
to `./wallet.pass`:
```bash
lighthouse --network goerli account wallet create --name wally --password-file wally.pass
lighthouse --network holesky account wallet create --name wally --password-file wally.pass
```
Using the above command, a wallet will be created in `~/.lighthouse/goerli/wallets` with the name
Using the above command, a wallet will be created in `~/.lighthouse/holesky/wallets` with the name
`wally`. It is encrypted using the password defined in the
`wally.pass` file.
During the wallet creation process, a 24-word mnemonic will be displayed. Record the mnemonic because it allows you to recreate the files in the case of data loss.
> Notes:
>
> - When navigating to the directory `~/.lighthouse/goerli/wallets`, one will not see the wallet name `wally`, but a hexadecimal folder containing the wallet file. However, when interacting with `lighthouse` in the CLI, the name `wally` will be used.
> - When navigating to the directory `~/.lighthouse/holesky/wallets`, one will not see the wallet name `wally`, but a hexadecimal folder containing the wallet file. However, when interacting with `lighthouse` in the CLI, the name `wally` will be used.
> - The password is not `wally.pass`, it is the _content_ of the
> `wally.pass` file.
> - If `wally.pass` already exists, the wallet password will be set to the content
@@ -100,18 +100,18 @@ During the wallet creation process, a 24-word mnemonic will be displayed. Record
Validators are fundamentally represented by a BLS keypair. In Lighthouse, we use a wallet to generate these keypairs. Once a wallet exists, the `lighthouse account validator create` command can be used to generate the BLS keypair and all necessary information to submit a validator deposit. With the `wally` wallet created in [Step 1](#step-1-create-a-wallet-and-record-the-mnemonic), we can create a validator with the command:
```bash
lighthouse --network goerli account validator create --wallet-name wally --wallet-password wally.pass --count 1
lighthouse --network holesky account validator create --wallet-name wally --wallet-password wally.pass --count 1
```
This command will:
- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/goerli/wallets`, updating it so that it generates a new key next time.
- Create a new directory `~/.lighthouse/goerli/validators` containing:
- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/holesky/wallets`, updating it so that it generates a new key next time.
- Create a new directory `~/.lighthouse/holesky/validators` containing:
- An encrypted keystore file `voting-keystore.json` containing the validator's voting keypair.
- An `eth1_deposit_data.rlp` assuming the default deposit amount (`32 ETH`) which can be submitted to the deposit
contract for the Goerli testnet. Other networks can be set via the
`--network` parameter.
- Create a new directory `~/.lighthouse/goerli/secrets` which stores a password to the validator's voting keypair.
- Create a new directory `~/.lighthouse/holesky/secrets` which stores a password to the validator's voting keypair.
If you want to create another validator in the future, repeat [Step 2](#step-2-create-a-validator). The wallet keeps track of how many validators it has generated and ensures that a new validator is generated each time. The important thing is to keep the 24-word mnemonic safe so that it can be used to generate new validator keys if needed.

1
book/src/merge-migration.md
View File

@@ -209,4 +209,3 @@ guidance for specific setups.
- [Ethereum Staking Launchpad: Merge Readiness](https://launchpad.ethereum.org/en/merge-readiness).
- [CoinCashew: Ethereum Merge Upgrade Checklist](https://www.coincashew.com/coins/overview-eth/archived-guides/ethereum-merge-upgrade-checklist-for-home-stakers-and-validators)
- [EthDocker: Merge Preparation](https://eth-docker.net/About/MergePrep/)
- [Remy Roy: How to join the Goerli/Prater merge testnet](https://github.com/remyroy/ethstaker/blob/main/merge-goerli-prater.md)

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

@@ -32,7 +32,7 @@ Below is an example for initiating a voluntary exit on the Holesky testnet.
```
$ lighthouse --network holesky account validator exit --keystore /path/to/keystore --beacon-node http://localhost:5052
Running account manager for Prater network
Running account manager for Holesky network
validator-dir path: ~/.lighthouse/holesky/validators
Enter the keystore password for validator in 0xabcd
@@ -82,7 +82,7 @@ There are two types of withdrawal credentials, `0x00` and `0x01`. To check which
If your withdrawal credentials is of type `0x01`, it means you have set your withdrawal address previously, and you will not be able to change the withdrawal address.
### 3. When will my BTEC request (update withdrawal credentials to type `0x01`) be processed ?
Your BTEC request will be included very quickly as soon as a new block is proposed. This should be the case most (if not all) of the time, given that the peak BTEC request time has now past (right after the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12<sup>th</sup> April 2023 and lasted for ~ 2 days) .
### 4. When will I get my staked fund after voluntary exit if my validator is of type `0x01`?