Guide to Staking on Ethereum 2.0 (Ubuntu/Prysm/Witti)

Image for post
Image for post

UPDATE (2020–08–11): The Witti testnet is no longer in use. Check my other stories for the latest guides.

This is a step-by-step guide to staking on Ethereum 2.0 via the Witti multi-client testnet. It is based on the following technologies:

This guide includes instructions on how to:

  • Configure a newly running Ubuntu server instance.
  • Compile and configure the Prysmatic Labs beacon chain and validator software for Ethereum 2.0, Phase 0 and run them as a service.
  • Send validator deposits for staking on the Witti multi-client testnet.
  • Install and configure Prometheus metrics and set up a Grafana dashboard to view them.

Version

1.0 — Guide is current as of 05/31/2020.

Acknowledgements

This guide is based on information I pulled together from various sources. They are listed in the references section at the bottom and this guide wouldn’t exist without them. Thank you, all! Thanks also to Prysmatic Labs for their cool software, great documentation, and their assistance with running my own staking setup (especially Ivan Martinez and Nishant Das from the Prysm core team, and Ethereum developer Afri Schoedon).

Disclaimer

I’m not an expert in any of the technologies listed in this guide. I got it working and it’s a lot of fun, so I wanted to share it with others. Please forgive any errors or ill-informed choices. Feedback is always welcome!

Prerequisites

This guide assumes basic knowledge of Ethereum, ETH, staking, Linux, and MetaMask. Before you get started you will need to have your Ubuntu server instance up and running. For simplicity I used a VM hosted in a virtual public cloud, but a locally hosted instance is fine. It will help to have the MetaMask browser extension installed and configured. The rest we will do along the way. GLHF!

Note for Raspberry Pi Users

I haven’t tested this guide on a Rpi. If you want to try, just swap out the software listed below for the ARM version, where available. No guarantee it will work! You can get support on the Prysmatic Labs Discord.

Note on Conventions

Throughout the guide I use “#” or “$” on terminal command code blocks. Don’t include those when copying the terminal commands. Also, this platform doesn’t seem to allow scrolling code blocks, so you should be careful to copy each line fully. Blocks with multiple commands are separated by “#” or “$” and each instance indicates a separate execution in the terminal. For example:

Requirements

  • Ubuntu server instance. I used v20.04 (LTS) amd64 server VM.
  • MetaMask crypto wallet browser extension, installed and configured.
  • Hardware minimum requirements to run Prysm software:
    — Operating System: 64-bit Linux
    — Processor: Intel Core i5–760 or AMD FX-8100 or better
    — Memory: 4GB RAM
    — Storage: 20GB available space SSD
    — Internet: Broadband connection

Step 1 — Secure Your System

Security is important. This is not a comprehensive security guide, rather just some basic settings: a firewall and a user account. This assumes you have console access to your Ubuntu instance and are logged in via SSH as the root user.

Configure the 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).

Allow Grafana — Allows incoming requests to the Grafana web server (port 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.

Now enable the firewall.

Check to verify the rules have been correctly configured.

Output should look something like this.

Create a new user and grant administrative privileges

Using the root user to log in is risky. Let’s create a user-level account with admin privileges instead.

You will asked to create a password and some other information.

Grant admin rights to the user by adding them to the sudo group.

When you log in as <yourusername> you can type sudo before commands to perform actions with superuser privileges.

Step 2 — Update Your System

SSH into your Ubuntu instance with your newly created username and apply the following commands to update the system.

Step 3 — Install Bazel

Bazel is an open-source build tool. We will use it to compile the Prysm software.

Curl is required so we can download the Prysm code.

Download and add the Bazel gpg distribution URI as a package source. When you copy the line make sure you don’t miss the (-) after the add: sudo apt-key add -.

According to Bazel’s documentation, the component name “jdk1.8” is kept for legacy reasons only and doesn’t relate to supported or included JDK versions anymore.

Install Bazel. First install the latest version, then install 3.0.0. Prysm requires version 3.0.0.

Step 4 — Install and Build Prysm

Prysm is made up of two binaries: the beacon-chain and the validator. To connect to and validate Witti you will need to compile both from the witti branch. This is done by pulling down the branch and using Bazel to compile it.

Clone (make a local copy of) the Prysm git repo.

Mark the witti branch as the one we are interested in.

Use Bazel Build to compile the beacon chain and validator binaries. It will fetch any necessary dependencies.

Beacon chain takes a while to build. Good time to get some water or a coffee, or maybe read my article: “Schlesi is Dead, Long Live Witti!”.

Building the validator is faster as most of the dependencies have already been downloaded and/or built.

If both builds succeed then move on. If not, try again, or get help on the Prysm Discord.

Step 5 — Configure the Beacon Chain

We will run the beacon chain as a service so if the system restarts the process will automatically start back up again.

Setup Accounts and Directories

Create an account for the service to run under. This type of account can’t log into the server.

Create the data directory for the beacon chain. This is required for storing the beacon chain database. Use the -p option to create the full path.

Set directory permissions. The beaconchain account needs permission to modify the database directory. The -R means recursive.

Next, copy the newly compiled beacon-chain binary to the /usr/local/bin directory.

You will need to do this step each time you pull/build a new version of the beacon-chain binary.

Set the ownership to the beaconchain user account we created above.

Create and Configure the Service

Create a systemd service file to store the service config. We will use the config file to tell systemd to run the beacon-chain process as the beaconchain user.

Paste the following exactly as it is into the file.

We are using an Environment variable to get the client IP address Environment="ClientIP=$(curl -s v4.ident.me)" because ExecStart doesn’t allow the call in-line. Using --p2p-host-ip=${ClientIP} is the work-around.

Check the screen shot below for reference. Your file should look like that. Exit and save.

Reload systemd to reflect the changes.

Start the service.

Check the service status to make sure it’s running correctly.

Output should look like this.

If you did everything right, it should say Active: active (running) in green text. If not then go back and repeat the steps to fix the problem. Press Q to quit.

Enable the beacon-chain service to automatically start on reboot.

The beacon-chain will begin to sync. It may take several hours for the node to fully sync. You can check the progress by running the journal command.

The terminal output gives status information and an estimate for time remaining to fully sync.

Prysmatic Labs recommends that you wait for the sync to complete before you run the validator.

“NOTICE: The beacon node you are using should be completely synced before submitting your deposit for the validator client, otherwise the validator will not be able to validate and will inflict minor inactivity balance penalties.”

Now your beacon chain is running as a service. Congratulations! While the beacon node is syncing, let’s move onto the next step.

Step 5 — Configure validator staking keys

Your beacon node does not have to be synced to do these steps.

The validator allows you to define one or more validator accounts. Each account has a unique public key (identifies the validator), a signing key (used to sign validation work), and a withdrawal key (to withdraw the staked ETH). Each validator account you create will need to be associated with a 32 Göerli ETH deposit into the Witti multi-client testnet staking deposit contract

Get Staking ETH

To become a validator on the Witti testnet you will need to get 32 ETH from the Göerli Test Network. Do not use mainnet ETH. Follow these steps:

  1. Click on the MetaMask browser extension and log in.
  2. Using the dropdown at the top, select the Göerli Test Network.
  3. Click on your name to copy your Göerl iETH wallet address.
  4. Head over to the Prysm Labs Discord.
  5. Ask one of the mods nicely to transfer you some ETH and paste your Göerli ETH wallet address.
  6. If you are planning on running multiple validators you can ask for what you need (32 x number of validators).

Once the ETH appears in your MetaMask wallet we are ready to continue to the next step.

Preapre Your MetaMask Wallet

In order to validate you will need to deposit 32 Göerli ETH into the Witti Testnet staking deposit contract. Let’s make sure we are ready to proceed.

Open MetaMask and if necessary, sign-in. Using the dropdown at the top, select the Göerli Test Network. Make sure you have sufficient ETH in your wallet. A balance of 32 ETH or more is required. If you don’t have enough, go back to the previous section.

Make sure the Show HEX Data option is on so we can attach the validator binary data to our 32 Göerli ETH validator deposit. Click on the circle on the top right of the wallet and choose Settings. Click on Advanced then scroll down until you see Show HEX Data. Switch it on.

Generate Validator Account(s)

Create a place to store the validator account data.

Set permissions on the directory. Change <youruseraccount> to the account you’re currently logged in as.

Next we will generate a validator account which includes the validator keys.

Repeat these steps for each validator account you wish to create. Change <yourvalidatorpassword> to a password of your choice. Use the same password for each account.

The function call will output the Deposit Data that we will send to the deposit contract along with 32 GöETH. This associates the staking deposit with the validator account.

Copy the Deposit Data without the header and footer somewhere (e.g. Notepad) so we have it on hand. Also make note of the public Key. This will be useful later to view the validator account status on beaconcha.in.

The key files will all be stored here /home/prysm/eth2/validators and the validator binary will manage all of your keys for you, as we will see later.

Repeat this process by calling the validator accounts create function for each validator account you want to create. Copy the data and public key along the way. Each account you create requires 32 GöETH to be staked before it can be activated. We will do that next.

Step 6 — Make the Staking Deposit(s)

Open MetaMask and make sure the Göerli Test Network is selected in the dropdown at the top of the wallet.

Click on Send then enter the Witti testnet deposit contract address as shown below in the Add Recipient field. Add it to your address book when prompted to make things easier.

Enter 32 ETH for the amount to send.

Scroll down until you see the HEX Data box and paste the validator transaction data there then click Next.

Confirm the transaction address, amount, and data then click Confirm to make the payment. Once the transaction is confirmed you have staked your ETH and your validator deposit is on the blockchain. Repeat this process for each validator account you created.

You can confirm the transaction on the blockchain via Etherscan by clicking on the small arrow labelled View on Etherscan on the confirmed transaction.

Step 7— Configure the Validator

Your beacon node should be fully synced before continuing with this step.

Check by running the journal command.

When synced it has output similar to this.

Setup Accounts and Directories

We will run the validator as a service so if the system restarts the process will automatically start back up again.

Create an account for the service to run under. This type of account can’t log into the server.

We already have a place to store the validator account data /home/prysm/eth2/validators. We created this above when creating the validator accounts.

Set directory permissions. The validator account needs permission to modify the validator account data directory.

Next, copy the validator binary that we compiled earlier to the /usr/local/bin directory.

You will need to do this step each time you pull/build a new version of the validator binary.

Set the user and group ownership to the validator user account we created above.

Create and Configure the Service

Create a systemd service file to store the service config. We will use the config file to tell systemd to run the validator process as the validator user.

Paste the following into the file. Make sure you change <yourvalidatorpassword> to match the password you used to create the validator account(s) in Step 5.

The --graffiti flag is an optional string to include in proposed blocks.

Check the screen shot below for reference. Your file should look like that. Exit and save.

Reload systemd to reflect the changes.

Start the service.

Check the status to make sure it’s running correctly.

You should see output that looks something like this.

If you did everything right, it should say Active: active (running) in green text. If not then go back and repeat the steps to fix the problem. Press Q to quit.

Enable the validator service to automatically start on reboot.

You can check the progress by running the journal command.

It can take 12 hours or longer to activate the validation accounts(s). The output from the validator process indicates the status.

You will see output for each validator account you created. As I mentioned above, the validator will handle all of your keys within the same running instance.

Once activated you should see something like this for each key.

You can check the status of your validator via beaconcha.in. Simply do a search for your validator public key(s). It may be a while before they appear on the site.

That’s it. We have a functioning beacon chain and validator. Congratulations: you are awesome!

Step 7 — Install Prometheus

Prometheus is an open-source systems monitoring and alerting toolkit. It runs as a service on your Ubuntu server and its job is to capture metrics. More information here.

We are going to use Prometheus to expose runtime data from the beacon-chain and validator as well as instance specific metrics.

Create User Accounts

Accounts for the services to run under. These accounts can’t log into the server.

Create Directories

Program and data directories.

Set directory ownership. The prometheus account will manage these.

Download Prometheus software

Adjust the version number for the version you want from the Prometheus download page. Rpi users remember to get the ARM binary.

Unpack the archive. It contains two binaries and some content files.

Copy the binaries to the following locations.

Set directory ownership. The prometheus account will manage these.

Copy the content files to the following locations.

Set directory and file (-R) ownership. The prometheus account will manage these.

Remove the downloaded archive.

Edit the Configuration File

Prometheus uses a configuration file so it knows where to scrape the data from. We will set this up here.

Open the YAML config file for editing.

Paste the following into the file taking care not to make any additional edits and exit and save the file.

The scrape_configs define the output target for the different job names. We have 3 job names: validator, beacon node, and node_exporter. The first two are obvious, the last one is for metrics related to the server instance itself (memory, CPU, disk, network etc.). We will install and configure node_exporter below.

Set ownership for the config file. The prometheus account will own this.

Finally, let’s test the service is running correctly.

Output should look something like this. Press Ctrl + C to exit.

Set Prometheus to Auto-Start as a Service

Create a systemd service file to store the service config which tells systemd to run Prometheus as the prometheus user, with the configuration file located in the /etc/prometheus/prometheus.yml directory, and to store its data in the /var/lib/prometheus directory.

Paste the following into the file. Exit and save.

Reload systemd to reflect the changes.

And then start the service with the following command.

Check the status to make sure it’s running correctly.

Output should look something like this. If you did everything right, it should say Active: active (running). If not then go back and repeat the steps to fix the problem. Press Q to quit.

Lastly, enable Prometheus to start on boot.

Install Node Exporter

Prometheus will provide metrics about the beacon chain and validators. If we want metrics about our Ubuntu instance, we’ll need an extension called Node_Exporter. You can find the latest stable version here if you want to specify a different version below. Rpi users remember to get the ARM binary.

Unpack the downloaded software.

Copy the binary to the /usr/local/bin directory and set the user and group ownership to the node_exporter user we created above.

Remove the downloaded archive.

Set Node Exporter to Auto-Start as a Service

Create a systemd service file to store the service config which tells systemd to run Node_Exporter as the node_exporter user.

Paste the following into the file. Exit and save.

Reload systemd to reflect the changes.

And then start the service with the following command.

Check the status to make sure it’s running correctly.

Output should look something like this. If you did everything right, it should say Active: active (running). If not then go back and repeat the steps to fix the problem. Press Q to quit.

Enable Node Exporter to start on boot.

Test Prometheus and Node Exporter

Everything should be ready to go. You may optionally test the functionality by opening a port in the firewall (see Step 1) and browsing to http://<yourserverip>:9090. From there you can run queries to view different metrics. For example try this query to see how much memory is free in bytes:

Or try this query to see the balance for all of your validators.

Step 8 — Install Grafana

While Prometheus is our datasource, Grafana is going provide our reporting dashboard capability. Let’s install it and configure a dashboard.

We will install using an APT repository because it is easier to install and update. Grafana is available in the official Ubuntu packages repository, however the version of Grafana there may not be the latest, so we will use Grafana’s official repository.

Download the Grafana GPG key with wget, then pipe the output to apt-key. This will add the key to your APT installation’s list of trusted keys.

Add the Grafana repository to the APT sources.

Refresh the apt cache.

Make sure Grafana is installed from the repository.

Output should look like this.

Verify the version at the top matches the latest version shown here. Then proceed with the installation.

Start the Grafana server.

Check the status to make sure it’s running correctly.

Output should look something like this. If you did everything right, it should say Active: active (running) in green. If not then go back and repeat the steps to fix the problem. Press Q to quit.

Enable Grafana to start on boot.

Configure Grafana Login

Great job on getting this far! Now that you have everything up and running you can go to http://<yourserverip>:3000/ in a browser and the Grafana login screen should come up.

Enter admin for the username and password. It will prompt you to change your password and you should definitely do that.

Configure the Grafana Data Source

Let’s configure a datasource. Move your mouse over the gear icon on the left menu bar. A menu will pop-up — choose Data Sources.

Click on Add Data Source and then choose Prometheus. Enter http://localhost:9090 for the URL then click on Save and Test.

Import a Grafana Dashboard

Now let’s import a dashboard. Move your mouse over the + icon on the left menu bar. A menu will pop-up - choose Import.

Paste the JSON from here and click Load then Import. You should be able to view the dashboard. At first you may not have sufficient data, but after running for a while you will see some metrics.

Final Remarks

Okay… That’s it! We are done! I hope you enjoyed this guide.

  • If you have feedback you can reach me on Twitter or Reddit.
  • If you liked this guide and think others would benefit from it then please share it using the friends link!
  • Tips: somer.eth

References

I used a bunch of sites and guides to put this together. Thank you to those authors for showing me how!

Logging in as root is bad

Initial Server Setup with Ubuntu 20.04

UFW firewall

UFW Essentials

Bazel

Prysmatic Labs

Prysmatic Eth2 Testnet

Prysmatic Labs Discord

Installing Bazel on Ubuntu

ethdo wallet

Prometheus

Node_Exporter

How to Install Prometheus on Ubuntu 16.04

How to install and secure Grafana on Ubuntu 18.04

Attestantio’s Systemctl Examples

GuillaumeMiralles Grafana Dashboard

Markdownguide.org — Basic Syntax

Stack Edit

beaconcha.in

Görli

Written by

Passionate about Ethereum and decentralized technology.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store