Updating

From time to time validators need to be updated to support new features in the software and chain, or new configuration to support various changes. The setup documentation and config files will always be updated to incorporate these updates, so this document is mainly targeted for users who have pre-existing installations.

Updates

Versions

Release Date Version Archive Name Notes
2022-12-12 912717-v5.0.0 elvmasterd-18ee34-v5.0.0.tgz Updates Ethereum base to 1.10.19 (including EIP155)
2022-08-12 4c79e3-main elvmasterd-4c79e3-main.tgz Adds Genesis Update Commands

Forks

From time to time the chain needs to be updated to support new capabilities and features. When this happens, the chain is forked by specifying a block where the agreed upon changes will happen. This table will document which features are activated, at which block ,and if certain minimum software is needed to support this.

Block Genesis File Minimum Software Release Notes
22680000 genesis.json 912717-v5.0.0 Enables muirGlacier, berlin, london, arrowGlacier, grayGlacier features
17793000 Archived genesis.json 4c79e3-main Enables constantinople, petersburg, and istanbul features

Config

When the example configurations found on the Configuration page are updated to reflect new features or changes to best practices, it may be hard to know what was changed. Here is a summary of changes by date. Please reference the files for the specific changes. Table will note the example file name.

Release Date Example File Changed Parameters Nature of Change
2022-12-12 N/A N/A No config changes needed to support 912717-v5.0.0
2022-08-12 system-scope-elvmasterd.service Type Add/Change to allow proper TERM signals to elvmasterd
2022-08-12 system-scope-elvmasterd.service KillMode Add/Change to allow proper TERM signals to elvmasterd
2022-08-12 system-scope-elvmasterd.service ExecStart Added --allow-insecure-unlock so miner can function
2022-08-12 validator.toml enc_block Updated to reflect new Genesis
2022-08-12 validator.toml discovery_urls Introduced discovery_urls and removed staticnodes since discovery_urls preferred

How To…

Local Database Backup

From time to time the local state database used by elvmasterd changes in such a way that it is not possible to rollback. The following proceedure is only needed on upgrade and the resulting backup can be removed once it has been determined the upgrade was successful. If this step is skipped, a full re-sync of the database is needed, which can take 24hrs or more with the current chain size.

This example presumes the datadir where the database files are located in the same location defined in the example config.toml. Ensure the correct directory (defined in node.datadir of the config.toml is used)

sudo systemctl stop elvmasterd
cp -r /var/elvmasterd-data/elvmasterd /var/elvmasterd-data/elvmasterd.$(date +%Y-%m-%d)
sudo systemctl start elvmasterd

Update elvmasterd

The attached script, update_elvmasterd.sh is an example updater. It works with a system-level install of elvmasterd installed at /usr/local.

ELUVIO_PKG_GCS_URL=https://storage.googleapis.com/eluvio-public-builds
ELV_TGZ=elvmasterd-18ee34-v5.0.0.tgz

hash curl || {
   echo "Please install curl to use this script"
   exit 1
}

if [ $# -ne 1 ]; then
   echo "need a binary to deploy"
   exit 1
fi

if [[ $1 =~ \.tgz$ ]]; then
   ELV_TGZ=${1}
else
   echo "file does not look right"
   exit 1
fi

curl --output /dev/null --silent --head --fail "${ELUVIO_PKG_GCS_URL}/${ELV_TGZ}" || {
    echo "${ELVTAR} does not exist"
    exit 1
}

(
   sudo systemctl stop elvmasterd
   curl -s ${ELUVIO_PKG_GCS_URL}/${ELV_TGZ} | sudo tar -C /usr/local -zxvf -
   sudo systemctl start elvmasterd
)

To use it, Run the script with the latest elvmasterd tar as the only argument. The latest is listed above in the versions section, so the script would run like so:

./update_elvmasterd.sh elvmasterd-18ee34-v5.0.0.tgz

Update Genesis

The latest fork at block TBD is to enable features up tp Grey Glacier. New chains which are setup with the example config in this document will not need to do anything to pick up these changes. If the validator was setup prior to these updates and prior to this block, a new Genesis will need to be applied. The following steps will need to be followed:

  1. Update to the latest elvmasterd following the instructions in this document, or by pulling a new version of the container.
  2. Run the genesis-update command with the genesis.json in the Configuration

Running genesis-update is straightforward. The daemon will need to be stopped to access the database, which is protected by a mutex to ensure only one process can access it.

Assumes install location is /usr/local and genesis.json is located in /tmp.

sudo systemctl stop elvmasterd
/usr/local/bin/elvmasterd genesis-update /tmp/genesis.json --config /etc/elvmasterd/config.toml
sudo systemctl start elvmasterd

Stop the container, then run the following. Place the genesis.json in the /fast-disk/conf equivalent.

podman run \
   --hostname org-validator-01 --rm=true -ti \
   -v /fast-disk/conf:/conf \
   -v /fast-disk/data:/data \
   -p 40304:40304 \
   -p 40304:40304/udp \
   elvmasterd-validator:latest genesis-update /conf/genesis.json --config /conf/config.toml

Then restart the container

Checking Update

There are 2 simple checks to ensure the genesis was updated correctly and that config or software changes have been applied correctly (outside of ensuring the daemon is simply running)

Checking currently synced block number

On a chain that has been sitting inactive for some time (common on restart or when not updated on a fork), the simplest test to see if syncing activity is occurring is to see what the current block number is. If it is behind, it should grow a lot in a short period of time as the local chain syncs with the peers. If it is synced up, the current block will still advance regularly as new transactions are written.

/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "eth.blockNumber"
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "eth.blockNumber"

Then restart the container

Checking number of peers

When a local node is misconfigured or has problems with the genesis (such as not having the same genesis due to a fork), nodes will be unable to connect to peers due to the mismatch. The simplest check to perform is to see how many peers the local node has. The following command will print the current count. A good value is over 3.

/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "admin.peers.length"
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "admin.peers.length"

Then restart the container

Start Miner

On restart the wallet will be locked and the miner process will be off. The following can be run to unlock the wallet and start the miner:

Assumes install location is /usr/local

/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "personal.unlockAccount(eth.coinbase, 'the password goes here', 0)"
/usr/local/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "miner.start(8)"

Assumes container instance is named org-validator-01

podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "personal.unlockAccount(eth.coinbase, 'the password goes here', 0)"
podman exec -ti org-validator-01 /usr/loca/bin/elvmasterd attach /tmp/elvmasterd.socket \
   --exec "miner.start(8)"