By using this site, you agree to our use of cookies, which we use to analyse our traffic in accordance with our Privacy Policy. We also share information about your use of our site with our analytics partners.

Blockchain Explained

My Journey to Becoming a Validator on Ethereum 2.0

This is the first in a series of articles describing how an individual, with ~32 ETH and technical knowledge, can participate in the launch of the Ethereum beacon chain
by Coogan BrennanNovember 25, 2020
teku validator flow

Image: The image above, by Ben Edgington of Teku (who also writes the essential Eth2.news newsletter), describes the steps we鈥檒l be taking over the next three blog posts.

This article is the first in a four-part series on how to run your own Eth2 validator. If you are new to this series, be sure to check out Part 2: Setting Up Your Eth2 Client, Part 3: Installing Metrics and Analyzing P&L and Part 4: Safely Migrating Your Eth2 Node.

Note: While the deadline has passed for validators to be included in the Genesis event for the beacon chain, people can still deposit 32 ETH in the Deposit contract following the steps below. According to Alex Tudorache of Eth2stats, once the chain starts on December 1st, 12:00 UTC, 2020, individuals who deposit from November 24th 12:00 UTC, 2020, to genesis will be queued and follow the normal activation procedure.

  1. Introduction
  2. Disclaimer
  3. Materials and Requirements
  4. Acquiring 32 ETH on MetaMask
  5. Launchpad Overview
  6. Key Generation
  7. Linking Ethereum 1.0 and 2.0 and Locking-in 32 ETH
  8. Conclusion

1. Introduction

This is the first in a series of articles describing how an individual, with ~32 ETH and technical knowledge, can participate in the launch of the Ethereum beacon chain, Phase 0 of the Ethereum 2.0 project. Before we get into the first step of sending ETH to the Deposit Contract and getting our validator keys, I鈥檇 like to discuss some of the motivations behind Ethereum 2.0.

Ethereum is about to embark on a new and exciting journey into uncharted territory for any blockchain network. The shift from Proof of Work to Proof of Stake is the most significant protocol change in the short history of public blockchains. The closest equivalent would be the Segregated Witness (or, SegWit) hard fork of Bitcoin 鈥 an adjustment to the way block sizes were processed in the Bitcoin network. That change, relatively minor in comparison to Ethereum 2.0, resulted in a contentious, bitter fight and ultimately led to the fragmentation of the Bitcoin community.聽聽

The launch of Ethereum 2.0 makes SegWit look like a tire change. There are two major reasons why this community would undertake such a significant reworking. First, the Ethereum community is a community of developers. Developers do not launch a product and never touch it again. We constantly deploy, observe, discuss and iterate on the ideas and work we produce. That cycle is accompanied by high levels of planning, modeling and coordination across many teams who, in other settings, might be considered competitors. When there are mistakes, the community comes together to solve them in the best way possible.

The second reason we are undertaking this new endeavor is that we believe public blockchains are far from their full potential. Proof of Work was an untested hypothesis when Bitcoin launched in 2009. The vast majority of people did not believe you could solve the double-spend problem except by the use of trusted intermediaries. Bitcoin, and other Proof of Work networks, have now proven we can implement a monetary system as a peer-to-peer protocol (me sending you money) without a third party.

Proving that point was just the beginning. Ethereum was nicknamed Bitcoin 2.0 by the community when it was first being developed: It recognized the shortcomings of Bitcoin鈥檚 operating system and launched to extend the capability of peer-to-peer protocols. Ethereum 1.0 will continue to make great strides over the years as we build 2.0 alongside it, but as Vitalik Buterin said in a recent Reddit AMA:

鈥淚f you are here in Ethereum today, you should be here not because you believe the current rules (economic or technical) deserve to be protected and stabilized at all costs, but because you believe in where the ecosystem is going. [鈥 Participation in Ethereum is unavoidably in part a prediction that the roadmap is a good one and that once this upgrading process ends we actually will get to a place where the network is efficient and stable and powerful and capable of being the base of significant parts of the global economy鈥

Proof of Stake in this stage of Ethereum 2.0 is actually a bet on the ability of the Ethereum developers and community, who have built so much already, to deliver even more to the greater world. You should expect to lock any funds you put in this Deposit Contract for at least two years, most likely longer. Please do not underestimate the risks and only invest what you can afford to lose. However, by contributing to this first step, you are participating in a potentially historic moment to push public blockchains into the next stage of development.

Let鈥檚 get started.

2. Disclaimer

This is a post I鈥檓 writing as an employee of ConsenSys and someone planning to actually stake on the beacon chain. The former statement means I prioritize ConsenSys products (ConsenSys products are typically best in class for Ethereum, and I also have access to engineering teams who can help me answer questions and troubleshoot). The latter statement means I鈥檓 optimizing for cost and ease of use: I don鈥檛 have thousands of ETH to yield substantial rewards, so I am taking some shortcuts. I also don鈥檛 want to have to maintain a server in my apartment for cost and logistical purposes so I鈥檓 using Amazon Web Services (AWS) to host my validator node. It鈥檚 a service I鈥檓 familiar with as a developer and it鈥檚 virtual so I can access it from anywhere for maintenance. (Initially, I was considering using my 8GB RAM Raspberry Pi but didn鈥檛 want to have to worry about internet connection, making the site power is still on, overheating and speed, or if my dog kicks over my laptop when I鈥檓 away. That is an option and Ethereum on ARM is a group that provides materials for staking Ethereum 2.0 on Raspberry Pi)聽

Many people in the crypto community would disagree with using an Infura endpoint rather than a local Ethereum 1.0 client and hosting on AWS (part of the Amazon goliath). These are decisions I鈥檝e made to make staking on Ethereum 2.0 as straightforward and accessible for individuals as possible but come with trade-offs to decentralization and privacy. However, you can follow the broad direction tutorial below and choose to run your own Ethereum 1.0 client and host locally. In fact, if you can do that, I would encourage you to!聽

3. Materials and Requirements

Here are the materials we鈥檒l need and the overall steps we鈥檒l be taking over the course of three posts:

Materials

  • A three year commitment to staking 32 ETH and maintaining a validator node
  • 32 ETH (plus <1 ETH for gas costs)
  • $717.12 (three-year reserved instance pricing for an m5.xlarge instance) + 120 (one year鈥檚 cost of 100 GB of storage, conservatively assuming nearly full storage capacity) = $837.12 paid over the course of the year to AWS
  • MetaMask Extension (free install)聽
  • Infura Account (free tier)

Steps

  1. Acquire 32 ETH on MetaMask, Walkthrough Launchpad
  2. Configure AWS instance (three year commitment, can be less but you save money with more time and you are locked in), harden security features
  3. Import verification keys, run Teku, setup monitoring聽

There are some great, more general tutorials walking through this process, namely Mara Schmiedt and Collin Myers鈥 walkthrough in Bankless newsletter. This tutorial will be different as I鈥檓 walking through my own individual staking process and adding steps specific to my overall setup.

4. Acquiring 32 ETH on MetaMask

Both the easiest and the hardest step of this tutorial. As I鈥檓 writing this, Ethereum is going through a price run which dramatically increases the cost of staking (Evan Van Ness has a delightful post which traces the cost of validating back for many months, starting with March 2019, when it cost $3,100USD to buy 32 ETH to Oct 2020 when it costs $12,000USD). There are a few folks who have bought and, ahem, HODLed Ethereum for quite some time. If you haven鈥檛 blown your crypto on a pizza in 2010, consider yourself a lucky 鈥 erm 鈥 strategic investor.

Why do we need a browser-based wallet like MetaMask? The flow of locking up ETH in the Deposit contract on Ethereum 1.0 Mainnet and connecting it to Ethereum 2.0 Beacon chain requires a delicate dance of sorts. The two chains use different classes of cryptography, so we have to generate entirely new types of cryptographic keys. Those keys have to be connected to our Ethereum 1.0 addresses with the 32 ETH however. It would be very tricky to do on one鈥檚 own, so the Ethereum Foundation and ConsenSys have set up a website which handles the process called the Launchpad. To interact with that website, though, we need a browser-based wallet with the Ethereum 1.0 keys associated with our 32 ETH balance. We鈥檒l get into it more later, but I wanted to let folks know why we鈥檙e doing this.

If you do not hold any ether (the base currency for the Ethereum network): You can buy directly on MetaMask. You can also buy ETH on certified exchanges like Gemini, but be warned that there is an extensive KYC process and Gemini will keep and can submit records to local, state and national state agencies. If you hold ERC-20 tokens but not ether: I recommend using MetaMask鈥檚 new swaps feature directly in your MetaMask wallet, which combines decentralized exchange aggregators like Uniswap and AirSwap to get the best prices and lowest network fees.聽 If your ETH is on a Trezor or Ledger hardware wallet, I recommend you follow these steps to connect that wallet to MetaMask. I鈥檓 using MetaMask, but the Ethereum Foundation also recommends browser-based wallets like Portis or Fortmatic.聽

For me, this was a bit nerve-wracking to see a substantial amount of money at my disposal with a straightforward cryptographic signature. Probably a good time to marvel at the incredible power of crypto to be able to bestow this on individuals, while also reminding folks to make sure you鈥檝e backed up your private keys or recovery phrases.

5. Launchpad Overview

Image: Launchpad.ethereum.org

Now that we have custody of the 32 ETH for staking, we can go to Launchpad.ethereum.org, the Launchpad website we mentioned earlier. Mara and Collin鈥檚 Bankless guide goes through the initial page (shown below) very well and much of it is self-explanatory but I wanted to give my own personal interpretation on a few things:

The first four steps (Overview, Signup, Responsibilities, and Slashing) are a basic synopsis of Ethereum 2.0, staking and your responsibilities as a validator. Essentially, the Proof of Stake consensus mechanism relies on 鈥渕iners鈥 (in Proof of Work parlance) putting their money where their mouth is, rather than expending tremendous amounts of CPU solving Proof of Work puzzles. That鈥檚 the 32 ETH, table stakes for participating in Proof of Stake consensus.聽

And since the network is still under development, there鈥檚 no exiting yet for validators (what if you find the DAO hack on the new network? We can鈥檛 let you leave鈥). So everyone鈥檚 in for the long haul. (that covers Transfer Delay and Commitment)

Last, if you 鈥渕isbehave鈥 as a validator in the network (either out of malice or ignorance or happenstance), you are penalized. In Ethereum 2.0, it鈥檚 called slashing. On the positive side, if you behave correctly as a validator, you get the 鈥渕ining rewards鈥 associated with the network (we鈥檒l discuss that more later). As a quick aside, the disincentive / incentive balance is different from Proof of Work, where there are only incentives for miners to not sabotage the network and behave correctly.聽

Next is the key system I mentioned before. The key signature system Ethereum 2.0 will be using is BLS. I鈥檓 not a cryptography expert, but the takeaway from BLS is it allows multiple digital signatures to be collapsed into a single verifiable one. This is helpful with collecting attestations of the beacon (鈥渧otes in regards to the validity of a shard block or beacon鈥). Most pertinent for us, the BLS scheme is different from the scheme used for Ethereum 1.0.

For more information about BLS, please see this thread from Jeff Coleman or this Reddit post about the history of BLS development for Ethereum 2.0.聽

Typically, changing a private key scheme for a large public network would be near-impossible. However, since Ethereum 2.0 will be running alongside Ethereum 1.0, core developers have come up with a clever solution, which is a classic handshake:

Launchpad

In the diagram above, the blue key and boxes represent Ethereum 1.0 and its cryptographic scheme and the red key and boxes represent Ethereum 2.0 and its cryptographic scheme. The deposit contract, which exists on Ethereum 1.0 Mainnet, allows the user to prove they have private keys for Ethereum 1.0 and Ethereum 2.0. Here鈥檚 how that works:

The transaction submitted to the deposit contract on Ethereum 1.0 has to be signed by an Ethereum 1.0 private key (like any transaction submitted on Mainnet). However, that transaction is wrapped around another private key signature, the Ethereum 2.0 private key. The beacon chain is watching the deposit contract on Ethereum 1.0, if a valid transaction is submitted to the contract with the correct balance, the beacon chain then unwraps the first layer of encryption and accesses the second layer, the Ethereum 2.0 digital signature. That is used to confirm the Ethereum 2.0 validator address and connect it to an Ethereum 1.0 address.

For folks familiar with Solidity, here鈥檚 the transaction that comes into the Ethereum 1.0 contract, with the BLS signature parameter circled:

There鈥檚 one more parameter here (withdrawal credentials) which we haven鈥檛 discussed, which is essentially a one-use key to withdraw the 32 ETH once we are allowed to do so. We鈥檒l generate that with Launchpad as well.

As you can see, it鈥檚 a complicated process that would be challenging for an individual user to do solo. Launchpad gives us a guided process to assist and reduce complexity.

The next three sections (Commitment, Early-Adopter Risk and Confirmation) are one last reminder about the risky and long-term commitment of participating in Ethereum 2.0聽

For more about Ethereum 2.0 terminology and understanding the role of a validator, please see Alex Tudorache鈥檚 two excellent pieces Ethereum 2.0 Terms Demystified and A Validator鈥檚 Journey Through the Beacon Chain.

6. Key Generation

Now that we have a general overview of our role in Ethereum 2.0 as a validator, we will go ahead with the meat of the process: generating validator keys and linking them to Ethereum 1.0 with a transfer of 32 ETH to the Ethereum 1.0 Mainnet Deposit contract.

Upon confirmation you鈥檝e read the disclosures, Launchpad will walk through the options you have for selecting an Ethereum 1.0 and 2.0 client. We will get to these in another post and it鈥檚 not a requirement to move forward.聽

Next, you鈥檒l go to the 鈥淕enerate Keys鈥 section, shown below:

I鈥檝e selected 1 Validator, and it shows me my cost. It then asks my current operating system to help me download a small bit of software to generate the validator key pairs. This is tricky, because while my validator client will be running on Linux, I use a Mac day-to-day. So I select Mac and it takes us to the next step, asking us how we鈥檇 like to setup the software:

I鈥檓 choosing to download the CLI app, and it takes me to the download page on the Ethereum Foundation鈥檚 Github page (the release version may look different for you, just be sure it鈥檚 the latest version):

Scroll down to see the download section:

Download the `tar.gz` file for your appropriate operating system and unpack the file.

We now need to open our command-line terminal and navigate to the directory of our unpacked file, called eth2deposit-cli. A shortcut for some machines is to type cd then drag and drop the directory into the terminal, which will give you the path to the directory. Hit enter and, in the eth2deposit-cli directory run the following command provided by Launchpad:

./deposit new-mnemonic 鈥揷hain mainnet

There鈥檚 a constant reminder to include 鈥揷hain mainnet, because previous tutorials had different chains for different testnets. So be sure to add mainnet otherwise your transaction information will not be valid!

Enter the number of validators you鈥檇 like to run and follow the steps.

I鈥檓 not going to share screenshots for the next few steps, as it involves generating sensitive keys and passwords. Two main things though: 1) Back-up the mnemonic phrase you get as this is the only way to withdraw the ETH you stake once that鈥檚 allowed 2) This step is just for Teku users: Create a plaintext file that contains the password you鈥檝e entered for your validator keys. Save it with the same name as your keystore .json file but with a .txt suffix in the same directory with your keys and deposit info. For example, if your keystore file is KEYSTORE-M_123456_789_ABCD.json, the plaintext file with your password should be called KEYSTORE-M_123456_789_ABCD.txt. This will be used later when running Teku.

After running eth2deposit-cli from your terminal successfully and adding the password file, your directory should look like this:

eth2deposit-cli/

鈹斺攢鈹 validator_key_info/

聽聽聽鈹溾攢鈹 KEYSTORE-M_123456_789_ABCD.json

聽聽聽鈹溾攢鈹 KEYSTORE-M_123456_789_ABCD.txt

聽聽聽鈹斺攢鈹 DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

鈹斺攢鈹 MNEMONIC_BACKUP.txt

7. Linking Ethereum 1.0 and 2.0 and Locking-in 32 ETH

The last step for this tutorial will be sending our validator information to the Deposit contract on Ethereum 1.0 mainnet with the correct information that the beacon chain will also be able to recognize (the handshake we mentioned earlier).

The 鈥淯pload Validator鈥 tab has a spot to drag and drop the other file created by eth2deposit-cli: Your deposit data file (DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json on the example directory above) . Drag and drop that file from your computer to the spot on the Launchpad page:

If the deposit data is correctly formatted, you鈥檒l see this:

Now, Launchpad will ask us to connect the software wallet with the account we sent our 32 ETH to earlier:

Once you鈥檝e done that successfully, you鈥檒l see this:

New security features from MetaMask require a website to request to connect with each account specifically 鈥 if the account with 32 ETH is not selected when you connect, just open MetaMask, click the account that does have the 32 ETH and connect it to Launchpad.

When you click continue, you鈥檒l see a summary of the information, along with further emphasis on the risk and long-term commitment of what you鈥檙e about to do:

Once you鈥檝e gone through these disclosures and warnings carefully, comes the moment of truth:

Once you click 鈥淚nitiate the Transaction鈥 you鈥檒l be confronted with one of the most exciting confirmation boxes in YOUR (crypto) LIFE! Take a deep breath, be sure you鈥檙e ready because there鈥檚 no turning back once you hit confirm! (Well, MetaMask does have a time sensitive 鈥淐ancel Transaction鈥 feature, cause it鈥檚 a great wallet, but pretend as though you don鈥檛 have that!)

Once it鈥檚 all been confirmed and mined, you鈥檒l see a screen like this:

8. Conclusion

Congratulations! You鈥檝e participated in one of the most exciting developments in public coordination history!!

But the work has just begun. Our next two posts will be setting up an AWS Ubuntu 20.04 Server instance for our Teku validator node using Infura as an Ethereum 1.0 endpoint. We鈥檒l then work on security hardening and node monitoring using a tool like Grafana.聽

For the next installment, all we鈥檒l need from this post is the contents of the eth2deposit-cli/validator_key_info directory, examples given below:

eth2deposit-cli/

鈹斺攢鈹 validator_key_info/

聽聽聽鈹溾攢鈹 KEYSTORE-M_123456_789_ABCD.json

聽聽聽鈹溾攢鈹 KEYSTORE-M_123456_789_ABCD.txt

聽聽聽鈹斺攢鈹 DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

Stay tuned!

Thanks to James Beck, Meredith Baxter, Chaminda Divitotawela, Ben Edgington, The Dark Jester, Somer Esat, Joseph Lubin, Collin Meyers, Nick Nelson, Mara Schmiedt, Adrian Sutton, and Alex Tudorache for support and technical assistance.