This page provides an overview of the steps required to install a validator node on the Energy Web Chain.
You can choose to run your validator node either On-Premise on your own hardware or on a virtual machine / cloud computing instance of your choosing. If you have any questions please contact the EWF NetOps team: [email protected]
The following specifications are strongly recommended, but validators are free to configure their host machine at their discretion in accordance with relevant internal policies or requirements. Please note that hosting a node on a machine with insufficient CPU, storage, RAM, and/or networking capacity may result in node failure (e.g. unable to connect to peers, unable to synchronize, unable to seal blocks) and require extra labor to reconfigure the host machine.
A on-premise node should have these specs or higher. For security reasons these resources must be reserved for the validator node and not shared with other workloads.
Modern Multi-core x64 CPU (at least 4 threads, preferably Xeon-class)
8GB RAM (preferably ECC)
Local SSD storage, 300 GB free capacity for blockchain, redundant in RAID-1
1 GBit NIC
The following specifications are strongly recommended based on the most common cloud environments used by existing EW Chain validators. You may select any cloud provider of your choosing
Amazon AWS
The following EC2 instance sizes are appropriate to run validators. These resources should be reserved for the validator node and not shared with other workloads.
m5.xlarge
m5.2xlarge
m5a.xlarge
m5a.2xlarge
The default EBS storage assigned (normally 8GB) is not large enough to run the node. Make sure to run the node with following EBS storage settings:
General Purpose SSD (gp2)
at least 300GB size
Microsoft Azure
The following Azure Virtual Machine sizes are suitable to run a validator. These resources should be reserved for the validator node and not shared with other workloads.
D4s_v3
DS3_v2
B4ms
Use Premium SSD as attached storage with a size of at least 300GB.
Google Cloud
The following Google Cloud Virtual Machine sizes are suitable to run a validator node. These resources should be reserved for the validator node and not shared with other workloads.
n2-standard-4 and above: https://cloud.google.com/compute/docs/general-purpose-machines#n2_machines
Digital Ocean
The following Digital Ocean Virtual Machine sizes are suitable to run a validator. These resources should be reserved for the validator node and not shared with other workloads.
General Purpose Droplet: 16 GB memory, 4vCPU
CPU-Optimized Droplet: 8 GB memory, 4vCPU
Use Block Storage as attached SSD storage with a size of at least 300 GB.
The following requirements should be met to ensure proper operation:
Wired connection with 100 MBit/s symmetric link to the internet
Low latency connection to next internet hop (<5ms)
No data volume limitations
Even though we recommend a 100MBit/s connection, that connection will likely not be saturated by the node. You can expect 10-30MBit/s when the chain is under load. Traffic will mainly flow on port 30303 (udp/tcp).
c5.xlarge
c5.2xlarge
Additional information for AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html
Additional information for Azure: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-ip-addresses-overview-arm
Verify that the host is dedicated only for the EW Chain Validator client.
If yes, proceed to the next step.
If no, remove all other processes / applications from the host, or create a new isolated instance.
Verify that you have the correct installation script for your chosen OS here: https://github.com/energywebfoundation/ewc-validator-node-install-scripts
If yes, then proceed to the next step.
If no, choose the correct installation script before proceeding.
Review the default safe firewall settings set up by the installation script.
Do these settings comply with your company's firewall settings or will you have to adapt them afterwards?
If the default settings comply with your company’s policies, proceed to the next step.
If the default settings do not comply with your company’s policies, adapt the settings as necessary. If you encounter issues or conflicts with internal IT policies, you can post in the to discuss resolution options.
Review the installation script and verify that there are no errors or discrepancies with your system setup (link above).
If errors are observed, open an Issue in the installation script Github repository or post to ta relevant topic in the Validator Knowledge Base to resolve.
Make sure you have read and understand the operational and governance rules and responsibilities as outlined in the Validator Code of Conduct.
Read the documentation on the validator architecture to ensure you have a robust understanding of the inner workings:
Optional: Read the documentation on the system contracts to familiarize yourself with the overall system.
Confirm that you have at least two ways to contact EWF and the valdiator community if you encounter problems:
NetOps distribution list: [email protected]
Join the #validator channel on Slack: https://ewf-affiliates.slack.com/messages
Join the #technical-discussions channel on Slack:
Ensure that you are prepared to receive and securely handle value-bearing Energy Web Tokens (“EWT”) from block rewards at the time your validator is added to the validator set.
EWF strongly recommends that your organization implements a robust internal governance process and security policy for managing the validator node private keys, accessing the node, and managing its EWT balance.
If you would like to hold block rewards in an address separate from the validator node, you can change the block reward payout address. Please see instructions for calling the setPayoutAddress function in the Reward Contract for further details. Please note that it is not possible to reallocate transaction fees to a separate account, so all validator nodes will accrue and maintain a balance of EWT from transaction fees.
Once all of the above steps are completed, install your validator node following the instructions here.
Running a validator node requires raised awareness of host and node security as authorities are a main attack surface to disturb operation of the blockchain. The following security rules are strongly recommended:
No services are permitted to run on the same host that are not part of the validator node package
All incoming connections on all ports except SSH (22/tcp) and the P2P (30303/tcp, udp) port have to be firewalled on the host with DROP rules. To guarantee proper network etiquette, incoming ICMP has to be accepted.
SSH access is only allowed for non-root users
SSH access is only allowed through RSA keys
Nethermind client RPC endpoints (HTTP, WebSocket) have to be disabled
System updates have to applied regularly and in a timely manner
Regular (monthly) run of rootkit detectors
If you are using AWS please also check out the additional .
This page provides step-by-step instructions for how to install a validator node in the Volta test network and the production Energy Web Chain network.
We recommend using the Nethermind Validator Installation Script, as the OpenEthereum Client is no longer in development and has been deprecated. You can find the validator installation scripts here:
Volta:
EWC:
Install the operating system and prepare the host machine according to the requirements (Step 1 in the previous checklist).
Select the correct Client installation script matching the desired network and installed OS on the energyweb github:
For the VOLTA TEST NETWORK: , or copy the recommended client directory () from the volta-affiliate directory to the host
For the main ENERGY WEB CHAIN: https://github.com/energywebfoundation/ewc-validator-node-install-scripts/tree/master/ewc-affiliate, or copy the recommended client directory (Nethermind) from the ewc-affiliate directory to the host
Make sure the latest system updates are installed by running :
For Debian and Ubuntu:
For CentOS:
Make the script executable with
Run the script (NOTE: please do not use the --auto parameter which can be used to take default for node-name and generate a random key).
If the installation was successful, it should generate a .txt file (named install-summary.txt) that lists the node address, IP address, and influxDB username/password. You will need to provide these details via a form in the next step to successfully add your validator node to the validator system contract.
If you encounter issues with the installation or the install-summary.txt file is not generated:
First review any to see if there is a known issue.
If the issue is not already known, submit a question in the #validators or #technical_questions channels in the to troubleshoot.
After submitting the installation summary via the form, you will receive a confirmation email with next steps and links to helpful resources.
The following Linux-based Operating Systems are supported for running a validator node:
Ubuntu Server 18.04 LTS or later
Debian 9.8 or later
CentOS 7 or later
RedHat Enterprise Linux 7.4 or later
Validators can elect other operating systems at their discretion, but may need to customize the installation scripts. Contact for questions and support.
The following section provide a comprehensive guide for installation of one the supported operating systems. All further deployment procedures are based on the installation results.
On-Premise
Procedure based on version 18.04.2.
Download the ISO from .
Boot the ISO
Select English as language
Choose a convenient keyboard layout
Amazon AWS
Ubuntu AMI's are listed at . Search for "ebs 18.04 amd64" to get the right version.
Microsoft Azure
The URN for the image is Canonical:UbuntuServer:18.04-LTS:latest
On-Premise
Download the NetInst ISO from
Boot the ISO
Select Install from the boot screen
Select English as language
Amazon AWS
The AMI Id's can be found at
Microsoft Azure
The URN for the image is credativ:Debian:9:latest
On-Premise
Download the minimal ISO from
Boot the ISO
Confirm the automatic boot option Test this media & install CentOS 7
Choose English as language
Amazon AWS
The AMI Id's can be found at
Microsoft Azure
The URN for the image is OpenLogic:CentOS:7.5:latest
sudo apt-get update && sudo apt-get dist-upgradesudo yum updatechmod +x ./install-*.shChoose Install Ubuntu
Let the network auto-configure -or- configure manually if needed. The system needs an internet connection.
Select no proxy and keep the mirror address.
Select Use an entire disk and confirm
Choose user name and host name in next screen. Choose a strong password.
Select Install OpenSSH Server but don’t import keys
Don’t select any snaps and continue
Finish installation and let it boot to the prompt
Login as the created user and run a full system update using sudo apt-get update && sudo apt-get dist-upgrade -y
Select Location based on actual location of the host
Chose a convenient keyboard layout
Let the network auto-configure -or- configure manually if needed. The system needs an internet connection.
Name your host. Change it from debian to something else
Choose a strong root password
Create the user account and choose a strong password
Select the proper timezone
For the partitions use Guided - use entire disk
Select All files in one partition
Finish partitioning and write changes to disk
Select No when ask to scan more disks
Choose a mirror close to the host
Opt-out of the package survey
on the Software Selection select only SSH Server and standard system utilities
Install the grub bootloader to MBR and use the primary disk for that
Finish installation and let it boot to the prompt
Login as root and run a full system update using 'apt update && apt dist-upgrade -y'
Reboot
On the installation summary choose Installation destination and confirm automatic partinioning
Back on the installation summary screen click on Network & Hostname
Change the hostname
Enable the network interface and make sure it is configured properly
Click Done to get back to the summary and click Begin Installation
During installation set a root password
Finish installation and let it boot to the prompt
Login as root and run a system update with 'yum update'