Image: The image above, by Ben Edgington of Teku (who also writes the essential Eth2.news newsletter), describes the steps we’ll 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.
Introduction
Disclaimer
Materials and Requirements
Acquiring 32 ETH on MetaMask
Launchpad Overview
Key Generation
Linking Ethereum 1.0 and 2.0 and Locking-in 32 ETH
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’d 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’s 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:
“If 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’s get started.
2. Disclaimer
This is a post I’m 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’m optimizing for cost and ease of use: I don’t have thousands of ETH to yield substantial rewards, so I am taking some shortcuts. I also don’t want to have to maintain a server in my apartment for cost and logistical purposes so I’m using Amazon Web Services (AWS) to host my validator node. It’s a service I’m familiar with as a developer and it’s virtual so I can access it from anywhere for maintenance. (Initially, I was considering using my 8GB RAM Raspberry Pi but didn’t 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’m 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’ve 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’ll need and the overall steps we’ll 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’s 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
Acquire 32 ETH on MetaMask, Walkthrough Launchpad
Configure AWS instance (three year commitment, can be less but you save money with more time and you are locked in), harden security features
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’m 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’m 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’t 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’s 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’ll get into it more later, but I wanted to let folks know why we’re 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’s 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’m 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’ve 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’s 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 “miners” (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’s the 32 ETH, table stakes for participating in Proof of Stake consensus.
And since the network is still under development, there’s no exiting yet for validators (what if you find the DAO hack on the new network? We can’t let you leave…). So everyone’s in for the long haul. (that covers Transfer Delay and Commitment)
Last, if you “misbehave” as a validator in the network (either out of malice or ignorance or happenstance), you are penalized. In Ethereum 2.0, it’s called slashing. On the positive side, if you behave correctly as a validator, you get the “mining rewards” associated with the network (we’ll 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’m 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 (“votes 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:
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’s 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’s the transaction that comes into the Ethereum 1.0 contract, with the BLS signature parameter circled:
There’s one more parameter here (withdrawal credentials) which we haven’t discussed, which is essentially a one-use key to withdraw the 32 ETH once we are allowed to do so. We’ll generate that with Launchpad as well.
As you can see, it’s 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’s two excellent pieces Ethereum 2.0 Terms Demystified and A Validator’s 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’ve 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’s not a requirement to move forward.
Next, you’ll go to the “Generate Keys” section, shown below:
I’ve 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’d like to setup the software:
I’m choosing to download the CLI app, and it takes me to the download page on the Ethereum Foundation’s Github page (the release version may look different for you, just be sure it’s 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 --chain mainnet
There’s a constant reminder to include --chain 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’d like to run and follow the steps.
I’m 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’s allowed 2) This step is just for Teku users: Create a plaintext file that contains the password you’ve 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 “Upload 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’ll see this:
Now, Launchpad will ask us to connect the software wallet with the account we sent our 32 ETH to earlier:
Once you’ve done that successfully, you’ll 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’ll see a summary of the information, along with further emphasis on the risk and long-term commitment of what you’re about to do:
Once you’ve gone through these disclosures and warnings carefully, comes the moment of truth:
Once you click “Initiate the Transaction” you’ll be confronted with one of the most exciting confirmation boxes in YOUR (crypto) LIFE! Take a deep breath, be sure you’re ready because there’s no turning back once you hit confirm! (Well, MetaMask does have a time sensitive “Cancel Transaction” feature, cause it’s a great wallet, but pretend as though you don’t have that!)
Once it’s all been confirmed and mined, you’ll see a screen like this:
8. Conclusion
Congratulations! You’ve 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’ll then work on security hardening and node monitoring using a tool like Grafana.
For the next installment, all we’ll 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.