How to Move a Validator Between Servers

I’m about to test migrating a basic validator setup between systems. Does this process look right? 1 - Spin-up a new node and sync it 2 - Stop gaiad on the new node 3 - Transfer the .gaiad/config home directory from the existing validator to the new node, to create the new validator 4 - Stop gaiad on the old validator 5 - Move the priv-validator-state.json file from the old validator to the new validator 6 - Start gaiad on the new validator Original Post Despite being involved with the validator working group since day 1, the process to move a validator from one server to another’s still not clear to me. I’m writing this topic as I attempt to move my Game of Stakes validator to the gaia-12k testnet. It will be updated as I learn. My hope is it results in a simple set of reference instructions for others to use. In this example, Server A is the original validator server and Server B is the new validator server. My current understanding is that, to move a validator from one server to another, one should - 1 - BACK UP the priv_validator_key.json in the ~/config/ directory on Server A 2 - Confirm you have the recovery seed phrase information for the…

Excerpt (1194 of 1426 characters). Read the whole post on the forum ↗

Chris, All,
has anyone tried out the above steps and moved your validator to the new server smoothly?

Does it make any difference if old Server is windows and new Server is Linux?

Bumping-up this updated post, as it’s been a while since the original post

If you’re copying the entire gaiad directory, why sync the new node from scratch?

Good point. I meant to say the .gaiad/config directory and have updated the post.

I have not tried this yet, but I imagine doing a direct migration of the entire directory would be safer? This mainly stems from the concern that priv_validator_state.json must be handled with care if you sync externally.

I think a safer approach would be to do the following:

1. Have the old (current validator) node continue operating until a halt-height H
2. Have the new node sync up until H (can be done from a snapshot + quick sync). This should take minimal time.
3. Have both nodes both halt at the same height H.
4. Migrate the necessary configs and files (not data) to the new node.
5. Start new node

By having both nodes stop at height H, you ensure there isn’t any issues with the signing file. At least in theory.

<3

Fun.

I’ll let you know how it goes.

Makes sense, too.

Can i have an update on this too. Are the steps from the main thread the correct ones and do they work ?

Are we sure we don’t have to migrate node_key.json if we’re only migrating priv-validator-state.json?

Hey guys, okay so it’s not a terribly bad idea to migrate your node key because the other nodes that you connect to will it expect you to have that ID. Otherwise you will have to update the unconditional peers that your validator connects to.

The most important thing, however, is to preserve the seed phrase that controls your validators wallet, and to preserve priv-validator.json

If you have any more questions please let me know, I have now moved validators several times and probably have to move one today and we have that down to a pretty smooth process at Notional.

jacobgadikian:

If you have any more questions please let me know, I have now moved validators several times and probably have to move one today and we have that down to a pretty smooth process at Notional.

hey jacob, I have a question for you. I see many times that priv_validator_stare.json is suggested to be copied on validator migration to avoid double signing, but I cannot really find any information about “on what circumstances” there will be a double signing if this file is not copied.
Maybe could it be in the case that we stop the backup node (future validator) before stopping our running validator and migrating priv_validator_key.json? so new validator start at an height before the previous validator had been stopped (and maybe it has also signed a blocks in that time)? or are there other cases?
thanks!

In theory it should not be an issue as long as you have your validator keys imported to only one node at a time.

Double signing occurs if your node signs the same block twice from two nodes (or at chain halts from the same node, but other story).

My procedure for switching validators is normally:

• sync node B as a completely new and fresh node
• stop node A
• delete priv_validator_keys.json on node A
• restart node A
• check with “[binary] status” that the voting power of the node is 0
• import priv_validator_keys.json on node B
• start node B

This way there will also be time between you stopped node A being a validator and starting node B as a validator. The chain will thus have moved past the height in your priv_validator_state.json and the risk on double signing is 0.