WoopChain Node Installation

WoopChain Configuration.

WoopChain Validator Hosting

Below are the suggestions for properly hosting a validator node in a WoopChain network. Please check all the items listed below to make sure that your validator setup is properly configured to be secure, stable and performant.

Minimum system requirements

Service configuration

woop  binary needs to run as a system service autowoopally upon established network connectivity and have start / stop / restart functionalities. We recommend using a service manager like  systemd

Example  systemd  system configuration file:

  
[Unit]
Description=WoopChain Server
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=10
User=ubuntu
ExecStart=/usr/local/bin/woop server --config /home/ubuntu/woopchain/config.yaml

[Install]
WantedBy=multi-user.target
  

Data storage

The  data/  folder containing the entire blockchain state should be mounted on a dedicated disk / volume allowing for autowoop disk backups, volume extension and optionally mounting the disk/volume to another instance in case of failure.

Log files

Log files need to be rotated on a daily basis, with a tool like  logrotate 
● Warning If configured without log rotation, log files could use up all the available disk space which could
   disrupt the validator uptime.

Example  logrotate  configuration:

  
/home/ubuntu/woopchain/logs/node.log
{
        rotate 7
        daily
        missingok
        notifempty
        compress
        prerotate
                /usr/bin/systemctl stop woop.service
        endscript
        postrotate
                /usr/bin/systemctl start woop.service
        endscript
}
  

Additional dependencies

WoopChain  is statically compiled, requiring no additional host OS dependencies.

Maintenance

Below are the best practices for maintaining a running validator node of a WoopChain network.

Backup

There are two types of backup procedures recommended for WoopChain nodes. The suggestion is to use both, whenever possible, with the WoopChain backup being always available option.

  ●  Volume backup:
     Daily incremental backup of the   data/  volume of the WoopChain node, or of the complete VM if possible.

  ●  WoopChain backup:
     Daily CRON job which does regular backups of WoopChain and moves the  .dat  files to an offsite location or
     to a secure cloud object storage is recommended.

The WoopChain backup should ideally not overlap with the Volume backup described above.
Refer to Backup/restore node instance for instructions on how to perform backups of WoopChain.

Logging

The logs outputted by the WoopChain nodes should:

  ●  be sent to an external data store with indexing and searching capabilities
  ●  have a log retention period of 30 days

If this is your first time setting up a WoopChain validator, we recommend to start the node with the  --log-level=DEBUG  option to be able to quickly debug any issues you might face. The  --log-level=DEBUG  will make the node's log output be as verbose as possible. Debug logs will drastically increase the size of the log file which must be taken into account when setting up log rotation solution.

OS security patches

Administrators need to ensure that the validator instance OS is always updated with the latest patches at least once every month.

Metrics
System metrics

Administrators need to setup some kind of system metrics monitor, (e.g. Telegraf + InfluxDB + Grafana or a 3rd party SaaS). Metrics that need to be monitored and that need to have alarm notifications setup:

Validator metrics

Administrators need to setup collection of metrics from WoopChain's Prometheus API to be able to monitor the blockchain performance. Refer to Prometheus metrics to understand which metrics are being exposed and how to setup Prometheus metric collection.

Extra attention needed to the following metrics:

  ●  Block production time if block production time is higher than normal, there is a potential problem with the network
  ●  Number of consensus rounds if there is more than 1 round, there is a potential problem with the validator set in the     network
  ●  Number of peers if the number of peers drop, there is a connectivity issue in the network

Security

Below are the best practices for securing a running validator node of a WoopChain network.

API services

  ●  JSON-RPC Only API service that needs to be exposed to the public ( via load balancer or directly ). This API should run on all interfaces or on a specific IP address ( example: --json-rpc 0.0.0.0:8545 or --json-prc 192.168.1.1:8545 ). As this is publicly facing API it is recommended to have a load balancer / reverse proxy in front of it to provide security and rate limiting.

  ●  LibP2P This is the networking API used by nodes for peer communication. It needs to run on all interfaces or on a specific ip address ( --libp2p 0.0.0.0:1478 or --libp2p 192.168.1.1:1478 ). This API should not be publicly exposed, but it should be reachable from all other nodes. If ran it on localhost ( --libp2p 127.0.0.1:1478 ) other nodes will not be able to connect.

  ●  GRPC This API is used only for running operator commands and noting else. As such it should run exclusively on localhost ( --grpc-address 127.0.0.1:9632 ).

WoopChain secrets

WoopChain secrets (  ibft  and  libp2p  keys ) should not be stored on a local file system. Instead, a supported Secret Manager should be used. Storing secrets to local file system should only be used in non-production environments.

Update

Following the update procedure for validator nodes, described as step-by-step instructions.

Update procedure

  ●   Download the latest WoopChain binary from the official GitHub releases .

  ●  Stop the WoopChain service ( example: sudo systemctl stop woop.service )

  ●  Replace the existing woop binary with the downloaded one ( example: sudo mv woop /usr/local/bin/ )

  ●  Check if correct woop version is in place by running  woop version   it should correspond to the release version

  ●  Check the release documentation if there are any backwards compatibility steps needed to be done before starting woop service.

  ●  Start woop service ( example: sudo systemctl start woop.service )

  ●  Finally, check the woop log output and make sure everything is running without any [ERROR] logs

Warning When there is a breaking release, this update procedure must be performed on all nodes as the currently running binary is not compatible with the new release
This means that the chain must be halted for a short period of time ( until woop binaries are replaced and service restarted ) so plan accordingly.

You can use tools like Ansible or some custom script to perform the update efficiently and minimize chain downtime.

Startup procedure

Following is the desired flow of the startup procedure for WoopChain validator

  ●  Apply the latest OS patches on the validator node
  ●  Download the latest woop binary from the official GitHub releases and place it in local instance PATH
  ●  Initialize one of the supported secrets managers using woop secrets generate CLI command
  ●  Generate and store secrets using woop secrets init CLI command
  ●  Take note of NodeID and Public key (address) values
  ●  Generate genesis.json file as described in cloud setup using woop genesis CLI command
  ●  Generate default config file using woop server export CLI command
  ●  Edit default-config.yaml file to accommodate local validator node environment ( file paths, etc. )
  ●  Create a WoopChain service ( systemd or similar ) where woop binary will run the server
    from a default-config.yaml file
  ●  Start WoopChain server by starting the service ( example: systemctl start woop )
  ●  Check the woop log output and make sure the blocks are being generated and that there are no [ERROR] logs
  ●  Check the chain functionality by calling a JSON-RPC method like eth_chainId