Today we’re Building an Ethereum Validator Node for Medalla Testnet. I have been a long-time lurker of Cryptocurrencies and the overall Blockchain Industry. As a junior DevOps Engineer, it has been incredibly exciting to have an understanding of the vast power these systems have to shape our future for the better. However, the more I researched the more I felt that a lot of these concepts were over my head and the speed at which the industry was changing, growing, and maturing felt as if I would never be able to keep up.
Enter Ethereum. For some reason the more I learned about it the more things “clicked”. Today (08/01/2020) we are officially two days (and 14 hours – but who’s counting?) to the official launch of the ETH2 Proof-of-Stake Testnet (Medalla). I’ve gathered enough information and confidence to be part of this historic moment.
Below are my experiences/notes from building an Ethereum Validator Node for Medalla Testnet. By no means do I consider myself an ‘authority’ on this – heck Ethereum only just celebrated its 5th anniversary, so this whole system is very new. But I wanted to post this for a few reasons:
- For people curious about Cryptocurrency/Blockchain who want to see more content (like me)
- To show those on the fence about partaking in the Testnet because of fear – you can do this
- To document my process to help the Ethereum community and overall blockchain industry
Please keep in mind that these are the notes on how we at Unvetica set up our node; this article shouldn’t be considered as a guideline for your production-ready system. Make sure to do your own research and have your own firm understanding before diving in.
Before we detail the specific steps of Building an Ethereum Validator Node for Medalla Testnet, I want to say that there are multiple ways to achieve this goal. I’m simply outlining the process we chose to configure our node at Unvetica. There are multiple Operating Systems and multiple Clients you can run as a Validator, and those are completely up to each individual.
We’ll specifically be focusing on deploying a Linux-based Ethereum Validator Node using the Prysm Client by Prysmatic Labs.
Items you’ll need:
- Internet Connection
- Dedicated Node hardware (Server, Desktop, etc.)
- USB Drive
Below, we will detail the steps necessary to setup/configure a node from a fresh installation of Linux Ubuntu 20.04 Server, configuring your machine for the Medalla Testnet, and finally configuring your validator node.
The Physical Hardware
There are a lot of questions about Building an Ethereum Validator Node for Medalla Testnet, and the first is always what type of hardware is best for a validator node? Hardware needs to be given careful consideration since you are effectively locking at least 32 Ether away for two years – you need to ensure that your investment is secure.
For example, there are people who are using a Raspberry Pi as their validator node. Though that may work today, there is a question as to if there is enough physical overhead to be an efficient solution when Ethereum launches Phase 1 and Phase 2 of their platform. The key here is to think long-term. Ensure that you have enough processing power for today and adequate overhead for tomorrow.
Furthermore, since we know we’re going to be using Prysm we can look at their hardware requirements as a frame of reference. For Prysm’s exact hardware specifications go here.
These specifications must be met in order to successfully run the Prysm client.
- Operating System: 64-bit Linux, Mac OS X 10.14+, Windows 64-bit
- Processor: Intel Core i5–760 or AMD FX-8100 or better
- Memory: 4GB RAM
- Storage: 20GB available space SSD
- Internet: Broadband connection
These hardware specifications are recommended, but not required to run the Prysm client.
- Processor: Intel Core i7–4770 or AMD FX-8310 or better
- Memory: 8GB RAM
- Storage: 100GB available space SSD
- Internet: Broadband connection
Based on the hardware guidelines provided by Prysm Labs, we decided to build on a Dell PowerEdge R210 II.
We chose this because we had it on hand and didn’t have to purchase anything, but also because we’re able to upgrade the CPU, add additional RAM, install a redundant power supply, and otherwise future-proof it as Ethereum grows and matures.
We’ve configured the Dell PowerEdge R210 II with an Intel Xeon Quad-Core E31270 @ 3.40 GHz which is capable of 8 threads, 16 GB of 1333 DDR3 RAM, and a 240GB SSD Drive. We plan on upgrading the SSD drive from 240GB to 1TB after we’ve verified a successful build.
Installing the Operating System
You can build an Ethereum Validator Node on any Operating System. We choose Ubuntu Server 20.04 LTS – figuring, why build an open-source Validator Node on anything other than an open-source Operating System? Just know that you can absolutely use a Windows or MacOS distribution to run a validator node.
We’re not going to outline how to install Ubuntu step-by-step, that’s outside the purview of this post. However, if you’re unfamiliar with this process – we’d recommend checking out this tutorial from LearnLinuxTV – it’s a great tutorial.
The next steps will outline how to configure a fresh installation of Ubuntu 20.04 in preparation for the validator installation.
Disable SSH password Authentication + Enable SSH Keys-Only Authentication
Login to the remote server
Create new user (using vitalik an example):
useradd -m -s /bin/bash vitalik
Set password for new user vitalik
Add user to sudo group
usermod -aG sudo vitalik
Verify user has correct permissions
su - vitalik id vitalik
These next steps need to be made on your local Desktop to Create the Key Pair
ssh-keygen -t rsa
Install the Public key to the remote server
ssh-copy-id -i $HOME/.ssh/id_rsa.pub vitalik@server-ip-here
Test SSH access
Now log into the remote server to disable root login and password based login
Edit the /etc/ssh/sshd_config file
sudo vi /etc/ssh/sshd_config
Find ChallengeResponseAuthentication and set to no
Next, find PasswordAuthentication set to no
Search for UsePAM and set to no
Finally, look for PermitRootLogin and set to no
Reload SSH server
sudo systemctl reload ssh
Verify You’re able to login
Configure Your Firewall
Ubuntu 20.04 servers can use the default UFW firewall to restrict traffic to the server. We need to allow SSH, Grafana (for metrics), and Prysm (for incoming P2P connections) to connect to the server.
Allow SSH – Allows connection to the server over SSH (port 22/TCP)
ufw allow 22/tcp
Allow Grafana — Allows incoming requests to the Grafana web server (port 3000/TCP).
ufw allow 3000/tcp
Allow Prysm — Allows P2P connections with peers for actions on the beacon node. Ports 13000/TCP and 12000/UDP are listed as defaults by Prysmatic Labs.
ufw allow 13000/tcp ufw allow 12000/udp
Now enable the firewall
Update your system
SSH into your Ubuntu instance with your newly created username and apply the following commands
sudo apt-get update -y && sudo apt-get upgrade -y
Follow the ETH2 Launch Pad for Medalla Testnet
You have just completed the initial steps to prepare your system for the validator installation. Now we need to prepare the server to be on the ETH2 Medalla Testnet.
The Ethereum Foundation has the link outlining these steps here: https://medalla.launchpad.ethereum.org/overview
After you have read through and understand the information provided in the ‘Overview’ section about the importance of each component, the next step is to Generate Key Pairs.
We’ve chosen to use Linux so we’ll follow the applicable instructions
We need to ensure that the proper prerequisite developer libraries are installed. Specifically Python3.7+, PIP3, and GIT.
Next we need to make sure the ‘software-properties-common’ package is installed in our machine so that we can add PPA into our machine
sudo apt install software-properties-common
Now we can add the deadsnakes PPA using the following
sudo add-apt-repository ppa:deadsnakes/ppa
Now that the required PPA is added into our Ubuntu server, we can use apt command to install Python 3.8
sudo apt install python3.8
Now we need to install PIP3
sudo apt install python3-venv python3-pip
Lastly, install GIT
sudo apt install git-all
At this point, the Ubuntu Server has all of the necessary software/binaries to begin to generate deposit keys using the Ethereum Foundation Deposit Tool. Use the following commands on your Server (These are 3 separate commands listed below):
git clone https://github.com/ethereum/eth2.0-deposit-cli.git cd eth2.0-deposit-cli sudo ./deposit.sh install
After running the next command you’ll be provided a seed phrase. I’ll be showing the screenshot for reference purposes only – but I can’t stress this enough –
DO NOT EVER SHOW THIS SEED PHRASE TO ANYONE EVER – FOR ANY REASON. If someone were to obtain your seed phrase, they effectively own your validator/wallet. Please understand what you’re doing before continuing.
sudo ./deposit.sh --num_validators 1 --chain medalla
You should see something like this
The system will then ask you to verify the Seed Phrase to ensure that you have written this down (and in a safe place).
When you have successfully input your correct Seed Phrase, you will be greeted with a success! message and the location of your keys:
Save the key files and get the validator file ready:
The next step is to upload your previously created Deposit File. The deposit-data-[timestamp].json is located in the /eth2.0-deposit-cli/validator_keys directory.
In our case, we’re going to SCP the file from the remote host to our local machine.
scp firstname.lastname@example.org:/home/admxn/eth2.0-deposit-cli/validator_keys/* /Your/Local/Directory
Once your deposit file has been downloaded locally, upload it to the ETH2 LaunchPad:
Now you need to connect a Wallet to deposit 32 Goerli to ETH1 to initiate your ETH2 Validator. In our case, we’ll be connecting our MetaMask Wallet:
After you hit continue you’ll be greeted with a Summary page. Review and acknowledge the warnings and prompts.
The last step in the ETH2 Launch Pad process is to sign the individual transaction. Simply click ‘start’:
After you have signed the transaction you’ll need to wait a moment for the Blockchain to process it, you can see it process in real-time by viewing on Alethio Explorer link which is auto-provided:
Once the transaction is verified and you hit continue, you’ll be greeted with a Congratulations! screen.
At this point, we need to choose a client to run our validator. This is the choose your own adventure section – we’ve decided to go with Prysm.
The Prysm project is a full-featured client for the Ethereum 2.0 network written entirely in the Go programming language. Created by Prysmatic Labs, Prysm implements the official Ethereum 2.0 specification, which is the product of an ongoing collective research and development effort by various teams across the Ethereum ecosystem, including the Ethereum Foundation.
We’ll need to use the Official Prysm ‘Medalla’ Testnet documentation which can be found here. To begin we’ll install Prysm using their installation script.
Create a working directory and enter it:
mkdir prysm && cd prysm
prysm.sh script from Github and make it executable:
curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh
Next, we’ll need to Import the validator accounts into Prysm. For this step, you’ll need to copy the path to the
validator_keys folder under the
eth2.0-deposit-cli directory you created during the launchpad process. In our case we’d run:
./prysm.sh validator accounts-v2 import --keys-dir=/home/admxn/eth2.0-deposit-cli/validator_keys
After the script processes, you’ll be asked to enter a wallet directory and a location to store passwords.
You’ll be asked for a password to import the accounts. This will be the password that you provided during the LaunchPad Process:
Now we can run the Beacon and Validator nodes
In a separate terminal, run:
Once you’re done, you should see the following screens for your Beacon and Validator respectively:
Please note that it may take anywhere from 5 to 12 hours for nodes in the ETH2 network to process a deposit. In the meantime, leave both terminal windows open and running; once the node is activated by the ETH2 network, the validator will immediately begin receiving tasks and performing its responsibilities. If the chain has not yet started, it will be ready to start proposing blocks and signing votes as soon as the genesis time is reached.
That’s it. We’ve now set up and are running a Validator node. There are numerous optimizations that are optional to further secure your node and help connect more effectively to additional nodes. We’ll outline those steps in a future post. For now, enjoy the progress.