diff --git a/book/src/advanced_database_migrations.md b/book/src/advanced_database_migrations.md index 3c56fcadc1..e9954e2ad9 100644 --- a/book/src/advanced_database_migrations.md +++ b/book/src/advanced_database_migrations.md @@ -125,7 +125,7 @@ Several conditions need to be met in order to run `lighthouse db`: 2. The command must run as the user that owns the beacon node database. If you are using systemd then your beacon node might run as a user called `lighthousebeacon`. 3. The `--datadir` flag must be set to the location of the Lighthouse data directory. -4. The `--network` flag must be set to the correct network, e.g. `mainnet`, `holesky` or `sepolia`. +4. The `--network` flag must be set to the correct network, e.g. `mainnet`, `hoodi` or `sepolia`. The general form for a `lighthouse db` command is: diff --git a/book/src/advanced_release_candidates.md b/book/src/advanced_release_candidates.md index 9f00da9ae9..f5aee05ede 100644 --- a/book/src/advanced_release_candidates.md +++ b/book/src/advanced_release_candidates.md @@ -40,4 +40,4 @@ There can also be a scenario that a bug has been found and requires an urgent fi ## When *not* to use a release candidate -Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Holesky). +Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Hoodi). diff --git a/book/src/advanced_web3signer.md b/book/src/advanced_web3signer.md index 6145fd4a71..4280d58500 100644 --- a/book/src/advanced_web3signer.md +++ b/book/src/advanced_web3signer.md @@ -56,3 +56,11 @@ SSL client authentication with the "self-signed" certificate in `/home/paul/my-k > with a new timeout in milliseconds. This is the timeout before requests to Web3Signer are > considered to be failures. Setting a value that is too long may create contention and late duties > in the VC. Setting it too short will result in failed signatures and therefore missed duties. + +## Slashing protection database + +Web3signer can be configured with its own slashing protection database. This makes the local slashing protection database by Lighthouse redundant. To disable Lighthouse slashing protection database for web3signer keys, use the flag `--disable-slashing-protection-web3signer` on the validator client. + +> Note: DO NOT use this flag unless you are certain that slashing protection is enabled on web3signer. + +The `--init-slashing-protection` flag is also required to initialize the slashing protection database locally. diff --git a/book/src/api_vc_auth_header.md b/book/src/api_vc_auth_header.md index f792ee870e..3e536cf3c8 100644 --- a/book/src/api_vc_auth_header.md +++ b/book/src/api_vc_auth_header.md @@ -32,7 +32,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/holesky/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/hoodi/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 @@ -46,7 +46,7 @@ Response: ```json { - "token_path": "/home/karlm/.lighthouse/holesky/validators/api-token.txt" + "token_path": "/home/karlm/.lighthouse/hoodi/validators/api-token.txt" } ``` diff --git a/book/src/api_vc_endpoints.md b/book/src/api_vc_endpoints.md index e51f5d29ae..87c9a517a5 100644 --- a/book/src/api_vc_endpoints.md +++ b/book/src/api_vc_endpoints.md @@ -226,26 +226,33 @@ Example Response Body ```json { "data": { - "CONFIG_NAME": "holesky", + "CONFIG_NAME": "hoodi", "PRESET_BASE": "mainnet", - "TERMINAL_TOTAL_DIFFICULTY": "10790000", + "TERMINAL_TOTAL_DIFFICULTY": "0", "TERMINAL_BLOCK_HASH": "0x0000000000000000000000000000000000000000000000000000000000000000", "TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH": "18446744073709551615", "MIN_GENESIS_ACTIVE_VALIDATOR_COUNT": "16384", - "MIN_GENESIS_TIME": "1614588812", - "GENESIS_FORK_VERSION": "0x00001020", - "GENESIS_DELAY": "1919188", - "ALTAIR_FORK_VERSION": "0x01001020", - "ALTAIR_FORK_EPOCH": "36660", - "BELLATRIX_FORK_VERSION": "0x02001020", - "BELLATRIX_FORK_EPOCH": "112260", - "CAPELLA_FORK_VERSION": "0x03001020", - "CAPELLA_FORK_EPOCH": "162304", + "MIN_GENESIS_TIME": "1742212800", + "GENESIS_FORK_VERSION": "0x10000910", + "GENESIS_DELAY": "600", + "ALTAIR_FORK_VERSION": "0x20000910", + "ALTAIR_FORK_EPOCH": "0", + "BELLATRIX_FORK_VERSION": "0x30000910", + "BELLATRIX_FORK_EPOCH": "0", + "CAPELLA_FORK_VERSION": "0x40000910", + "CAPELLA_FORK_EPOCH": "0", + "DENEB_FORK_VERSION": "0x50000910", + "DENEB_FORK_EPOCH": "0", + "ELECTRA_FORK_VERSION": "0x60000910", + "ELECTRA_FORK_EPOCH": "2048", + "FULU_FORK_VERSION": "0x70000910", + "FULU_FORK_EPOCH": "18446744073709551615", "SECONDS_PER_SLOT": "12", - "SECONDS_PER_ETH1_BLOCK": "14", + "SECONDS_PER_ETH1_BLOCK": "12", "MIN_VALIDATOR_WITHDRAWABILITY_DELAY": "256", "SHARD_COMMITTEE_PERIOD": "256", "ETH1_FOLLOW_DISTANCE": "2048", + "SUBNETS_PER_NODE": "2", "INACTIVITY_SCORE_BIAS": "4", "INACTIVITY_SCORE_RECOVERY_RATE": "16", "EJECTION_BALANCE": "16000000000", @@ -253,9 +260,36 @@ Example Response Body "MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT": "8", "CHURN_LIMIT_QUOTIENT": "65536", "PROPOSER_SCORE_BOOST": "40", - "DEPOSIT_CHAIN_ID": "5", - "DEPOSIT_NETWORK_ID": "5", - "DEPOSIT_CONTRACT_ADDRESS": "0xff50ed3d0ec03ac01d4c79aad74928bff48a7b2b", + "DEPOSIT_CHAIN_ID": "560048", + "DEPOSIT_NETWORK_ID": "560048", + "DEPOSIT_CONTRACT_ADDRESS": "0x00000000219ab540356cbb839cbe05303d7705fa", + "GAS_LIMIT_ADJUSTMENT_FACTOR": "1024", + "MAX_PAYLOAD_SIZE": "10485760", + "MAX_REQUEST_BLOCKS": "1024", + "MIN_EPOCHS_FOR_BLOCK_REQUESTS": "33024", + "TTFB_TIMEOUT": "5", + "RESP_TIMEOUT": "10", + "ATTESTATION_PROPAGATION_SLOT_RANGE": "32", + "MAXIMUM_GOSSIP_CLOCK_DISPARITY_MILLIS": "500", + "MESSAGE_DOMAIN_INVALID_SNAPPY": "0x00000000", + "MESSAGE_DOMAIN_VALID_SNAPPY": "0x01000000", + "ATTESTATION_SUBNET_PREFIX_BITS": "6", + "MAX_REQUEST_BLOCKS_DENEB": "128", + "MAX_REQUEST_BLOB_SIDECARS": "768", + "MAX_REQUEST_DATA_COLUMN_SIDECARS": "16384", + "MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS": "4096", + "BLOB_SIDECAR_SUBNET_COUNT": "6", + "MAX_BLOBS_PER_BLOCK": "6", + "MIN_PER_EPOCH_CHURN_LIMIT_ELECTRA": "128000000000", + "MAX_PER_EPOCH_ACTIVATION_EXIT_CHURN_LIMIT": "256000000000", + "MAX_BLOBS_PER_BLOCK_ELECTRA": "9", + "BLOB_SIDECAR_SUBNET_COUNT_ELECTRA": "9", + "MAX_REQUEST_BLOB_SIDECARS_ELECTRA": "1152", + "NUMBER_OF_COLUMNS": "128", + "NUMBER_OF_CUSTODY_GROUPS": "128", + "DATA_COLUMN_SIDECAR_SUBNET_COUNT": "128", + "SAMPLES_PER_SLOT": "8", + "CUSTODY_REQUIREMENT": "4", "MAX_COMMITTEES_PER_SLOT": "64", "TARGET_COMMITTEE_SIZE": "128", "MAX_VALIDATORS_PER_COMMITTEE": "2048", @@ -304,23 +338,45 @@ Example Response Body "MAX_BLS_TO_EXECUTION_CHANGES": "16", "MAX_WITHDRAWALS_PER_PAYLOAD": "16", "MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP": "16384", - "DOMAIN_DEPOSIT": "0x03000000", - "BLS_WITHDRAWAL_PREFIX": "0x00", - "RANDOM_SUBNETS_PER_VALIDATOR": "1", - "DOMAIN_SYNC_COMMITTEE": "0x07000000", - "TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE": "16", - "DOMAIN_BEACON_ATTESTER": "0x01000000", - "DOMAIN_VOLUNTARY_EXIT": "0x04000000", - "DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF": "0x08000000", - "DOMAIN_CONTRIBUTION_AND_PROOF": "0x09000000", - "EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION": "256", - "TARGET_AGGREGATORS_PER_COMMITTEE": "16", - "DOMAIN_APPLICATION_MASK": "0x00000001", - "DOMAIN_AGGREGATE_AND_PROOF": "0x06000000", - "DOMAIN_RANDAO": "0x02000000", - "DOMAIN_SELECTION_PROOF": "0x05000000", + "MAX_BLOB_COMMITMENTS_PER_BLOCK": "4096", + "FIELD_ELEMENTS_PER_BLOB": "4096", + "MIN_ACTIVATION_BALANCE": "32000000000", + "MAX_EFFECTIVE_BALANCE_ELECTRA": "2048000000000", + "MIN_SLASHING_PENALTY_QUOTIENT_ELECTRA": "4096", + "WHISTLEBLOWER_REWARD_QUOTIENT_ELECTRA": "4096", + "PENDING_DEPOSITS_LIMIT": "134217728", + "PENDING_PARTIAL_WITHDRAWALS_LIMIT": "134217728", + "PENDING_CONSOLIDATIONS_LIMIT": "262144", + "MAX_ATTESTER_SLASHINGS_ELECTRA": "1", + "MAX_ATTESTATIONS_ELECTRA": "8", + "MAX_DEPOSIT_REQUESTS_PER_PAYLOAD": "8192", + "MAX_WITHDRAWAL_REQUESTS_PER_PAYLOAD": "16", + "MAX_CONSOLIDATION_REQUESTS_PER_PAYLOAD": "2", + "MAX_PENDING_PARTIALS_PER_WITHDRAWALS_SWEEP": "8", + "MAX_PENDING_DEPOSITS_PER_EPOCH": "16", + "FIELD_ELEMENTS_PER_CELL": "64", + "FIELD_ELEMENTS_PER_EXT_BLOB": "8192", + "KZG_COMMITMENTS_INCLUSION_PROOF_DEPTH": "4", "DOMAIN_BEACON_PROPOSER": "0x00000000", - "SYNC_COMMITTEE_SUBNET_COUNT": "4" + "DOMAIN_CONTRIBUTION_AND_PROOF": "0x09000000", + "DOMAIN_DEPOSIT": "0x03000000", + "DOMAIN_SELECTION_PROOF": "0x05000000", + "VERSIONED_HASH_VERSION_KZG": "1", + "TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE": "16", + "DOMAIN_VOLUNTARY_EXIT": "0x04000000", + "BLS_WITHDRAWAL_PREFIX": "0x00", + "DOMAIN_APPLICATION_MASK": "0x00000001", + "DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF": "0x08000000", + "DOMAIN_SYNC_COMMITTEE": "0x07000000", + "COMPOUNDING_WITHDRAWAL_PREFIX": "0x02", + "TARGET_AGGREGATORS_PER_COMMITTEE": "16", + "SYNC_COMMITTEE_SUBNET_COUNT": "4", + "DOMAIN_BEACON_ATTESTER": "0x01000000", + "UNSET_DEPOSIT_REQUESTS_START_INDEX": "18446744073709551615", + "FULL_EXIT_REQUEST_AMOUNT": "0", + "DOMAIN_AGGREGATE_AND_PROOF": "0x06000000", + "ETH1_ADDRESS_WITHDRAWAL_PREFIX": "0x01", + "DOMAIN_RANDAO": "0x02000000" } } ``` @@ -352,7 +408,7 @@ Example Response Body ```json { - "token_path": "/home/karlm/.lighthouse/holesky/validators/api-token.txt" + "token_path": "/home/karlm/.lighthouse/hoodi/validators/api-token.txt" } ``` diff --git a/book/src/archived_key_management.md b/book/src/archived_key_management.md index 3f600794e0..d8b00e8352 100644 --- a/book/src/archived_key_management.md +++ b/book/src/archived_key_management.md @@ -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 Holesky testnet named `wally` and saves it in `~/.lighthouse/holesky/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 Hoodi testnet named `wally` and saves it in `~/.lighthouse/hoodi/wallets` with a randomly generated password saved to `./wallet.pass`: ```bash -lighthouse --network holesky account wallet create --name wally --password-file wally.pass +lighthouse --network hoodi account wallet create --name wally --password-file wally.pass ``` -Using the above command, a wallet will be created in `~/.lighthouse/holesky/wallets` with the name +Using the above command, a wallet will be created in `~/.lighthouse/hoodi/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/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. +> - When navigating to the directory `~/.lighthouse/hoodi/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 holesky account validator create --wallet-name wally --wallet-password wally.pass --count 1 +lighthouse --network hoodi 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/holesky/wallets`, updating it so that it generates a new key next time. -- Create a new directory `~/.lighthouse/holesky/validators` containing: +- Derive a single new BLS keypair from wallet `wally` in `~/.lighthouse/hoodi/wallets`, updating it so that it generates a new key next time. +- Create a new directory `~/.lighthouse/hoodi/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/holesky/secrets` which stores a password to the validator's voting keypair. +- Create a new directory `~/.lighthouse/hoodi/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. diff --git a/book/src/faq.md b/book/src/faq.md index 62a93166b1..b97a82fcca 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -275,7 +275,7 @@ network configuration settings. Ensure that the network you wish to connect to is correct (the beacon node outputs the network it is connecting to in the initial boot-up log lines). On top of this, ensure that you are not using the same `datadir` as a previous network, i.e., if you have been running the -`Holesky` testnet and are now trying to join a new network but using the same +`Hoodi` testnet and are now trying to join a new network but using the same `datadir` (the `datadir` is also printed out in the beacon node's logs on boot-up). diff --git a/book/src/installation_docker.md b/book/src/installation_docker.md index 8ee0c56bb4..12ce4f690c 100644 --- a/book/src/installation_docker.md +++ b/book/src/installation_docker.md @@ -99,7 +99,7 @@ You can run a Docker beacon node with the following command: docker run -p 9000:9000/tcp -p 9000:9000/udp -p 9001:9001/udp -p 127.0.0.1:5052:5052 -v $HOME/.lighthouse:/root/.lighthouse sigp/lighthouse lighthouse --network mainnet beacon --http --http-address 0.0.0.0 ``` -> To join the Holesky testnet, use `--network holesky` instead. +> To join the Hoodi testnet, use `--network hoodi` instead. > The `-v` (Volumes) and `-p` (Ports) and values are described below. diff --git a/book/src/mainnet_validator.md b/book/src/mainnet_validator.md index ba35ba6f12..8da8b98f89 100644 --- a/book/src/mainnet_validator.md +++ b/book/src/mainnet_validator.md @@ -12,7 +12,7 @@ managing servers. You'll also need at least 32 ETH! Being educated is critical to a validator's success. Before submitting your mainnet deposit, we recommend: -- Thoroughly exploring the [Staking Launchpad][launchpad] website, try running through the deposit process using a testnet launchpad such as the [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/). +- Thoroughly exploring the [Staking Launchpad][launchpad] website, try running through the deposit process using a testnet launchpad such as the [Hoodi staking launchpad](https://hoodi.launchpad.ethereum.org/en/). - Running a testnet validator. - Reading through this documentation, especially the [Slashing Protection][slashing] section. - Performing a web search and doing your own research. @@ -38,7 +38,7 @@ There are five primary steps to become a validator: > **Important note**: The guide below contains both mainnet and testnet instructions. We highly recommend *all* users to **run a testnet validator** prior to staking mainnet ETH. By far, the best technical learning experience is to run a testnet validator. You can get hands-on experience with all the tools and it's a great way to test your staking hardware. 32 ETH is a significant outlay and joining a testnet is a great way to "try before you buy". -> **Never use real ETH to join a testnet!** Testnet such as the Holesky testnet uses Holesky ETH which is worthless. This allows experimentation without real-world costs. +> **Never use real ETH to join a testnet!** Testnet such as the Hoodi testnet uses Hoodi ETH which is worthless. This allows experimentation without real-world costs. ### Step 1. Create validator keys @@ -48,7 +48,7 @@ The Ethereum Foundation provides the [staking-deposit-cli](https://github.com/et ./deposit new-mnemonic ``` -and follow the instructions to generate the keys. When prompted for a network, select `mainnet` if you want to run a mainnet validator, or select `holesky` if you want to run a Holesky testnet validator. A new mnemonic will be generated in the process. +and follow the instructions to generate the keys. When prompted for a network, select `mainnet` if you want to run a mainnet validator, or select `hoodi` if you want to run a Hoodi testnet validator. A new mnemonic will be generated in the process. > **Important note:** A mnemonic (or seed phrase) is a 24-word string randomly generated in the process. It is highly recommended to write down the mnemonic and keep it safe offline. It is important to ensure that the mnemonic is never stored in any digital form (computers, mobile phones, etc) connected to the internet. Please also make one or more backups of the mnemonic to ensure your ETH is not lost in the case of data loss. It is very important to keep your mnemonic private as it represents the ultimate control of your ETH. @@ -71,10 +71,10 @@ Mainnet: lighthouse --network mainnet account validator import --directory $HOME/staking-deposit-cli/validator_keys ``` -Holesky testnet: +Hoodi testnet: ```bash -lighthouse --network holesky account validator import --directory $HOME/staking-deposit-cli/validator_keys +lighthouse --network hoodi account validator import --directory $HOME/staking-deposit-cli/validator_keys ``` > Note: The user must specify the consensus client network that they are importing the keys by using the `--network` flag. @@ -132,10 +132,10 @@ Mainnet: lighthouse vc --network mainnet --suggested-fee-recipient YourFeeRecipientAddress ``` -Holesky testnet: +Hoodi testnet: ```bash -lighthouse vc --network holesky --suggested-fee-recipient YourFeeRecipientAddress +lighthouse vc --network hoodi --suggested-fee-recipient YourFeeRecipientAddress ``` The `validator client` manages validators using data obtained from the beacon node via a HTTP API. You are highly recommended to enter a fee-recipient by changing `YourFeeRecipientAddress` to an Ethereum address under your control. @@ -153,7 +153,7 @@ by the protocol. ### Step 5: Submit deposit (a minimum of 32ETH to activate one validator) -After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Holesky staking launchpad](https://holesky.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending ETH to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad. +After you have successfully run and synced the execution client, beacon node and validator client, you can now proceed to submit the deposit. Go to the mainnet [Staking launchpad](https://launchpad.ethereum.org/en/) (or [Hoodi staking launchpad](https://hoodi.launchpad.ethereum.org/en/) for testnet validator) and carefully go through the steps to becoming a validator. Once you are ready, you can submit the deposit by sending ETH to the deposit contract. Upload the `deposit_data-*.json` file generated in [Step 1](#step-1-create-validator-keys) to the Staking launchpad. > **Important note:** Double check that the deposit contract for mainnet is `0x00000000219ab540356cBB839Cbe05303d7705Fa` before you confirm the transaction. diff --git a/book/src/run_a_node.md b/book/src/run_a_node.md index 15567497e5..6c43ef5e32 100644 --- a/book/src/run_a_node.md +++ b/book/src/run_a_node.md @@ -54,7 +54,7 @@ Notable flags: - `--network` flag, which selects a network: - `lighthouse` (no flag): Mainnet. - `lighthouse --network mainnet`: Mainnet. - - `lighthouse --network holesky`: Holesky (testnet). + - `lighthouse --network hoodi`: Hoodi (testnet). - `lighthouse --network sepolia`: Sepolia (testnet). - `lighthouse --network chiado`: Chiado (testnet). - `lighthouse --network gnosis`: Gnosis chain. diff --git a/book/src/ui_installation.md b/book/src/ui_installation.md index 0bd14f6183..df0522f07a 100644 --- a/book/src/ui_installation.md +++ b/book/src/ui_installation.md @@ -38,7 +38,7 @@ We recommend running Siren's container next to your beacon node (on the same ser specified as well as the validator clients `API_TOKEN`, which can be obtained from the [`Validator Client Authorization Header`](./api_vc_auth_header.md). Note that the HTTP API ports must be accessible from within docker and cannot just be listening on localhost. This means using the - `--http-address 0.0.0.0` flag on the beacon node and validator client. + `--http-address 0.0.0.0` flag on the beacon node and, and both `--http-address 0.0.0.0` and `--unencrypted-http-transport` flags on the validator client. 1. Run the containers with docker compose diff --git a/book/src/validator_voluntary_exit.md b/book/src/validator_voluntary_exit.md index c17c0f4fc4..d5d1722d59 100644 --- a/book/src/validator_voluntary_exit.md +++ b/book/src/validator_voluntary_exit.md @@ -27,13 +27,13 @@ After validating the password, the user will be prompted to enter a special exit The exit phrase is the following: > Exit my validator -Below is an example for initiating a voluntary exit on the Holesky testnet. +Below is an example for initiating a voluntary exit on the Hoodi testnet. ``` -$ lighthouse --network holesky account validator exit --keystore /path/to/keystore --beacon-node http://localhost:5052 +$ lighthouse --network hoodi account validator exit --keystore /path/to/keystore --beacon-node http://localhost:5052 -Running account manager for Holesky network -validator-dir path: ~/.lighthouse/holesky/validators +Running account manager for Hoodi network +validator-dir path: ~/.lighthouse/hoodi/validators Enter the keystore password for validator in 0xabcd @@ -58,6 +58,27 @@ Please keep your validator running till exit epoch Exit epoch in approximately 1920 secs ``` +## Generate pre-signed exit message without broadcasting + +You can also generate a pre-signed exit message without broadcasting it to the network. To do so, use the `--presign` flag: + +```bash +lighthouse account validator exit --network hoodi --keystore /path/to/keystore --presign +``` + +It will prompt for the keystore password, which, upon entering the correct password, will generate a pre-signed exit message: + +``` +Successfully pre-signed voluntary exit for validator 0x[redacted]. Not publishing. +{ + "message": { + "epoch": "12959", + "validator_index": "123456" + }, + "signature": "0x97deafb740cd56eaf55b671efb35d0ce15cd1835cbcc52e20ee9cdc11e1f4ab8a5f228c378730437eb544ae70e1987cd0d2f925aa3babe686b66df823c90ac4027ef7a06d12c56d536d9bcd3a1d15f02917b170c0aa97ab102d67602a586333f" +} +``` + ## Exit via the execution layer The voluntary exit above is via the consensus layer. With the [Pectra](https://ethereum.org/en/history/#pectra) upgrade, validators with 0x01 and 0x02 withdrawal credentials can also exit their validators via the execution layer by sending a transaction using the withdrawal address. You can use [Siren](./ui.md) or the [staking launchpad](https://launchpad.ethereum.org/en/) to send an exit transaction. @@ -97,7 +118,7 @@ There are two types of withdrawal credentials, `0x00` and `0x01`. To check which - A fixed waiting period of 256 epochs (27.3 hours) for the validator's status to become withdrawable. -- A varying time of "validator sweep" that can take up to _n_ days with _n_ listed in the table below. The "validator sweep" is the process of skimming through all eligible validators by index number for withdrawals (those with type `0x01` and balance above 32ETH). Once the "validator sweep" reaches your validator's index, your staked fund will be fully withdrawn to the withdrawal address set. +- A varying time of "validator sweep" that can take up to _n_ days with _n_ listed in the table below. The "validator sweep" is the process of skimming through all eligible validators by index number for withdrawals (those with type `0x01` and balance above 32ETH). Once the "validator sweep" reaches your validator's index, your staked fund will be fully withdrawn to the withdrawal address set.
diff --git a/scripts/local_testnet/README.md b/scripts/local_testnet/README.md index 159c89badb..9d9844c4c4 100644 --- a/scripts/local_testnet/README.md +++ b/scripts/local_testnet/README.md @@ -83,3 +83,7 @@ The script comes with some CLI options, which can be viewed with `./start_local_ ```bash ./start_local_testnet.sh -b false ``` + +## Further reading about Kurtosis + +You may refer to [this article](https://ethpandaops.io/posts/kurtosis-deep-dive/) for information about Kurtosis. \ No newline at end of file diff --git a/wordlist.txt b/wordlist.txt index 9feb07b67b..682fae0261 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -46,6 +46,7 @@ Goerli Grafana Holesky Homebrew +Hoodi Infura IPs IPv