Migrating a validator node to a new environment

Sometimes an organization needs to migrate their validator node into a new environment. Common reasons for this include:

• Changing infrastructure providers (e.g. switching cloud or on-premise vendors)

• Wanting to upgrade host environment configuration

• Rotating access due to security procedures or policies.

If you are currently operating a validator node on Volta of the EW Chain and need to migrate it from its existing host environment to a new one, there are two options:

Install a new node and retire the existing one

• This option requires provisioning a new host environment and following the installation procedures to establish an entirely new node (note: this will result in a new address, private key, EWT balance, etc.). Once your new node is installed, the current one will be removed from the network and you will be able to retire / deprecate the legacy node and host environment.

• The benefits of this approach are:

  • It is easy to replicate the node installation process, so the overall migration is simpler;

  • You don't have to worry about independently modifying the installation script;

  • You can maintain continuity by simultaneously retiring the original node and adding the new one to the network;

• The drawbacks of this approach are:

  • You must determine a secure way to maintain access to the legacy block rewards held on the original node address;

  • Depending on your organization's IT policies and procedures, it may be more complex and costly to procure multiple host environments during the migration.

  • You may need to replicate or modify access management policies and procedures for the new environment.

Migrate your existing node to a new environment

• This option involves migrating the existing node (i.e. maintaining the same address and private key) to a new host environment. To do this, you must extract the private key from the existing environment and then re-run a modified installation script in the new environment, using the private key of the validator node.

• The benefits of this approach are:

  • You maintain continuity by keeping the same address and private key;

  • You don't need to operate two validator nodes (and thus host environments) simultaneously.

• The drawbacks of this approach are:

  • Depending on the parameters of the existing vs. new environment, you may need to modify configurations and access management.

  • You must securely extract the private key from the existing node, temporarily store it, and import it into the new environment.

  • You will experience a period of "downtime" throughout the migration, during which your organization's validator node will not be operational.

Follow the steps to migrate existing nodes to new node:

1. 1. Migrate existing nodes: Follow the steps to migrate existing nodes to new node:

      1. Collect and store the following necessary info from Old Instance -

         1. You can stop containers in old instance. docker-compose down

         2. Value of Validator Address, InfluxDB Username, InfluxDB Password . You’ll find this info in install-summary.txt file.

         3. Value of docker-stack/keystore/.secret To copy the .secret key to your local instance:

            scp -P 2222 -i YOURKEYS.pem user@YOUR_INSTANCE:/home/user/docker-stack/keystore/.secret ~/Downloads/

         5. [optional] keep a backup of docker-stack/ dir.

      2. Commented out the following lines from script

         1. Volta validator installation script

         2. EWC validator installation script

   [line from 180-213] -

   from echo "Creating Account..." [line 180] till docker rm -f nethermind [line 213] .

   1. Then run the script in the new instance.

      1. The End Result would be the the following . Validator Address, Enode, InfluxDB Username and InfluxDB Password field would be empty

         ==== EWF Affiliate Node Install Summary ==== Company: Company_Name Validator Address: Enode: null IP Address: New_IP_ADDESSS InfluxDB Username: InfluxDB Password:

      2. In the new Instance, There is the docker-stack/ dir. Enter to the directory and run docker-compose ps and run docker-compose down to kill node and telemetry containers.

      3. The .secret file in docker-stack/keystoredir needs to be updated with the older one. [ .secret file is in only readonly mode. Change mode before updating with old value. chmod 644 .secret ]

      4. The .env file in docker-stack/ dir needs to be updated.

         1. Update the VALIDATOR_ADDRESS= field with old value.

         2. Update the NETHERMIND_KEY_FILE=./keystore/UTC--* with correct name.

      5. In the docker-stack/configs/volta.cfg or docker-stack/configs/energyweb.cfg, the following 2 value needs to be updated. In the new instance, this value would be empty. Update the value with old Validator Address

         "KeyStore": { "PasswordFiles": ["keystore/.secret"], "UnlockAccounts": ["Old Validator Address goes here..."], "BlockAuthorAccount": "Old Validator Address goes here..." },

      6. Copy the Validator’s mining private key to your new instance

         • Copy the UTC--* file from old instance to docker-stack/keystore dir or create that file in docker-stack/keystore/ dir with exact same name and same value. To copy the file to your local instance:

           scp -P 2222 -i YOURKEYS.pem user@YOUR_INSTANCE:/home/user/docker-stack/keystore/UTC_PART ~/Downloads/

         • [Optional] If you want a exact sync of database, you can copy db files from the old instance to the new instance -

           • DB Path - docker-stack/database/volta or docker-stack/database/energyweb

         • Run docker-compose up -d

         • Check logs of parity container -

           • docker-compose logs -f nethermind

           • docker-compose logs -f nethermind_telemetry

   The Validator’s IP address and enode will change. Once you have completed the migration, fill out the installation summary form (for Volta here, and for Energy Web Chain here) to provide the new IP and enode information. You can also contact netops@energyweb.org to provide notification of the migration.