From ef502eb9102d99b31267cd4302a164cc55229909 Mon Sep 17 00:00:00 2001 From: RedWest <71982739+redwest88@users.noreply.github.com> Date: Thu, 9 Jan 2025 19:45:03 +0100 Subject: [PATCH 1/3] docs: add validator migration guide and networks list table --- how-to-guides/validator-node.md | 72 +++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) diff --git a/how-to-guides/validator-node.md b/how-to-guides/validator-node.md index c559d8a0f41..b6d15e5cc9a 100644 --- a/how-to-guides/validator-node.md +++ b/how-to-guides/validator-node.md @@ -181,6 +181,12 @@ Now, connect to the network of your choice. You have the following option of connecting to list of networks shown below: +| Name | Type | Chain ID | CLI Usage | +|-------------------------------------------------------------------|---------------|-------------|-------------------------| +| [Celestia](https://docs.celestia.org/how-to-guides/mainnet) | Mainnet Beta | `celestia` | `--chain-id celestia` | +| [Mocha](https://docs.celestia.org/how-to-guides/mocha-testnet) | Testnet | `mocha-4` | `--chain-id mocha-4` | +| [Arabica](https://docs.celestia.org/how-to-guides/arabica-devnet) | Devnet | `arabica-11`| `--chain-id arabica-11` | + Continuing the validator tutorial, here are the steps to connect your validator to Mocha: @@ -240,6 +246,72 @@ Follow the instructions under [transaction indexer configuration options](/how-to-guides/consensus-node#optional-transaction-indexer-configuration-options) to configure your `config.toml` file to select which transactions to index. +## Migrating a validator to another machine + +:::tip NOTE +Moving a validator to a new machine is a sensitive process that needs to be done carefully. If the transfer isn’t handled properly, it could result in double signing, which will permanently slash your validator, wipe out delegated tokens, and remove you from the active validator set. To avoid this, make sure to follow the steps closely and stop the old node completely before starting the migration. +::: + +### Step 1: Set up a new full consensus node + +First, set up a new [full consensus node](https://docs.celestia.org/how-to-guides/consensus-node) on the new server and make sure the node is fully synced with the chain. To check whether your node is synced, you can check the `catching_up` status using: + +```bash +celestia-appd status | jq '{ "catching_up": .SyncInfo.catching_up }' +``` + +If the node is synced, the output will look like this: + +```json +{ + "catching_up": false +} +``` + +### Step 2: Stop the old validator + +After your new full consensus node is synced, proceed to stop the current validator on the old machine. If you’re running it with [SystemD](https://docs.celestia.org/how-to-guides/systemd), use the following command: + +```bash +sudo systemctl stop +``` + +Additionally, it’s recommended to disable the service to prevent it from restarting automatically after a system reboot. You can do this with: + +```bash +sudo systemctl disable +``` + +For extra safety, you may also delete the service file from the server: + +```bash +sudo rm -rf /etc/systemd/system/.service +``` + +### Step 3: Backup and transfer `priv_validator_key.json` + +Once the old validator is stopped and the new node is synced, you’ll need to back up the `priv_validator_key.json` file from the old server (if it has not been backed up earlier). This file is located at: + +```plaintext +~/.celestia-app/config/priv_validator_key.json +``` + +Copy this file to the same location on the new server. To verify that the file has been transferred correctly, compare its contents on both servers using: + +```bash +cat ~/.celestia-app/config/priv_validator_key.json +``` + +### Step 4: Start the new validator + +If everything checks out, you can now restart the new node with the updated validator key: + +```bash +sudo systemctl restart +``` + +After this, your validator will resume signing blocks on the new server, and the migration is complete. Validators operate within a 10,000 signed block window, and missing more than 2,500 blocks in this window will result in downtime jail. The faster you complete the transfer, the fewer blocks your validator will miss. + ## Additional resources For additional resources, refer to From 236da4304281653700a27acea81bea1b4f69ea0a Mon Sep 17 00:00:00 2001 From: RedWest <71982739+redwest88@users.noreply.github.com> Date: Sat, 11 Jan 2025 12:25:34 +0100 Subject: [PATCH 2/3] use constants for chain IDs and relative links --- how-to-guides/validator-node.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/how-to-guides/validator-node.md b/how-to-guides/validator-node.md index b6d15e5cc9a..fdddc3ad006 100644 --- a/how-to-guides/validator-node.md +++ b/how-to-guides/validator-node.md @@ -181,11 +181,11 @@ Now, connect to the network of your choice. You have the following option of connecting to list of networks shown below: -| Name | Type | Chain ID | CLI Usage | -|-------------------------------------------------------------------|---------------|-------------|-------------------------| -| [Celestia](https://docs.celestia.org/how-to-guides/mainnet) | Mainnet Beta | `celestia` | `--chain-id celestia` | -| [Mocha](https://docs.celestia.org/how-to-guides/mocha-testnet) | Testnet | `mocha-4` | `--chain-id mocha-4` | -| [Arabica](https://docs.celestia.org/how-to-guides/arabica-devnet) | Devnet | `arabica-11`| `--chain-id arabica-11` | +| Name | Type | Chain ID | CLI Usage | +|--------------------------------|---------------|--------------------------------|--------------------------------------------| +| [Celestia](./mainnet.md) | Mainnet Beta | {{ constants.mainnetChainId }} | `--chain-id {{ constants.mainnetChainId }}`| +| [Mocha](./mocha-testnet.md) | Testnet | {{ constants.mochaChainId }} | `--chain-id {{ constants.mochaChainId }}` | +| [Arabica](./arabica-devnet.md) | Devnet | {{ constants.arabicaChainId }} | `--chain-id {{ constants.arabicaChainId }}`| Continuing the validator tutorial, here are the steps to connect your validator to Mocha: @@ -254,7 +254,7 @@ Moving a validator to a new machine is a sensitive process that needs to be done ### Step 1: Set up a new full consensus node -First, set up a new [full consensus node](https://docs.celestia.org/how-to-guides/consensus-node) on the new server and make sure the node is fully synced with the chain. To check whether your node is synced, you can check the `catching_up` status using: +First, set up a new [full consensus node](./consensus-node.md) on the new server and make sure the node is fully synced with the chain. To check whether your node is synced, you can check the `catching_up` status using: ```bash celestia-appd status | jq '{ "catching_up": .SyncInfo.catching_up }' @@ -270,7 +270,7 @@ If the node is synced, the output will look like this: ### Step 2: Stop the old validator -After your new full consensus node is synced, proceed to stop the current validator on the old machine. If you’re running it with [SystemD](https://docs.celestia.org/how-to-guides/systemd), use the following command: +After your new full consensus node is synced, proceed to stop the current validator on the old machine. If you’re running it with [SystemD](./systemd.md), use the following command: ```bash sudo systemctl stop From 12c5ba9ca141b2bd5ef04d55fbe703fba3951b40 Mon Sep 17 00:00:00 2001 From: Josh Stein <46639943+jcstein@users.noreply.github.com> Date: Mon, 27 Jan 2025 16:31:52 -0500 Subject: [PATCH 3/3] Apply suggestions from code review Co-authored-by: Rootul P --- how-to-guides/validator-node.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/how-to-guides/validator-node.md b/how-to-guides/validator-node.md index fdddc3ad006..cc26c12d5bd 100644 --- a/how-to-guides/validator-node.md +++ b/how-to-guides/validator-node.md @@ -254,7 +254,7 @@ Moving a validator to a new machine is a sensitive process that needs to be done ### Step 1: Set up a new full consensus node -First, set up a new [full consensus node](./consensus-node.md) on the new server and make sure the node is fully synced with the chain. To check whether your node is synced, you can check the `catching_up` status using: +First, set up a new [consensus node](./consensus-node.md) on the new server and make sure the node is fully synced with the chain. To check whether your node is synced, you can check the `catching_up` status using: ```bash celestia-appd status | jq '{ "catching_up": .SyncInfo.catching_up }' @@ -270,7 +270,7 @@ If the node is synced, the output will look like this: ### Step 2: Stop the old validator -After your new full consensus node is synced, proceed to stop the current validator on the old machine. If you’re running it with [SystemD](./systemd.md), use the following command: +After your new consensus node is synced, proceed to stop the current validator on the old machine. If you’re running it with [SystemD](./systemd.md), use the following command: ```bash sudo systemctl stop