A while ago I made the decision to accumulate enough ETH to stake when the Ethereum 2.0 Beacon chain launched. I look after design at Argent and I am inexperienced with maintaining the systems needed for a blockchain validator.
Stressful and involved though it was, I was determined to contribute to the Eth2 effort. I believe it's important and could also be financially rewarding.
With my ETH ready, there were a lot of other decisions to make. This post goes through my decision process. I've tried to structure it in a way that is quick to read (skim the headings), with added detail should you wish to go deeper.
Let me know @graemeblackwood if you find it useful or have any questions (or challenges to some of my decisions – I may have made incorrect assumptions in places). Bear in mind that my decisions were made after a lot of research, and I am well aware of the risks involved in running an eth2 validator. Please do your own research on these risks.
Full validator or stake through a service?
- RocketPool and Stkr are fantastic services for people without the full 32 ETH required to stake and run their own node.
- No inactivity / slashing risk is great too.
- In my opinion they are preferable to staking through a centralised exchange like Kraken.
- And they are not as "ideal" as independently-run nodes, as they act as a middleman of sorts.
- I am committed to decentralisation, so I felt it important to run my own node.
Decision: Run a full validator
Node-at-home or Node-in-the-Cloud?
Decision 2 – use a cloud-based service like Digital Ocean, or go it alone?
- Cloud-based would mean a lot of my concerns around up-time, remote access and monitoring would be easier to set up and manage.
- But again, Cloud-based tends toward a type of centralisation. If every eth2 node is running in AWS, is that censorship resistant?
Hardware: Laptop? Mini-PC?
I'd read that the recommended specs are 8GB RAM, 100GB SSD (spare storage) and an i7 CPU. And I had read elsewhere that a 1TB SSD is wiser, and 32GB RAM, if you want to have a future-proof setup, and run a full ETH node too.
I had a spare, powerful Windows laptop at home which would handle that. Should I use it?
- A laptop is great because it is compact and has a built-in screen.
- They consume more power than a NUC though (important consideration for uptime on a UPS battery backup)
- Also I use the laptop for other high-performance things (e.g. 3d / CAD)
- And the built-in SSD is only 1 TB, and already heavily used.
Decision: Buy a new mini-PC
Choosing a mini-PC
NUCs aren't the nicest looking things. And I wanted my node to look nice. My first thought was a new Mac mini, but then I began hearing that the M1 chip could cause problems with dual-booting, and I realised it's probably wiser to have a dedicated, single-boot machine for this.
- The validator node is going to sit somewhere quite visible, so it needs to look nice.
- It needs to be quiet.
- It needs to be compact.
- It needs to be future-proof.
Decision: An aluminium mini ITX
After a lot of searching, I found a great-looking Mac-mini esque PC at inside-tech.co.uk. I decided to up the spec to a 2TB SSD, 32GB RAM and a 9th-gen i7. Here it is again:
It's a bit bigger than a NUC, but not by much. Now that it is running, it's quiet, but not silent. Something to bear in mind… I looked for a fanless PC but couldn't find one that I liked the look of, at this spec.
Oh… I forgot about the screen!
Seems obvious, but as someone who has used a laptop daily since 2003, forgive me for forgetting that I need a screen! Also a wired keyboard and mouse… 😬
- Once it dawned on me, I realised I didn't want to buy a new screen and have it take up space.
- I wanted a way to access it remotely, i.e. a "headless" box.
- But I needed to set that up somehow…
Decision: TV, temporarily, then AnyDesk + an HDMI dummy plug
I dragged my TV over and plugged it in using the HDMI cable. I then installed AnyDesk, ensuring I set an alias. Otherwise the ID changes every time the PC restarts and you'll need that TV again! 😅
Once I was confident it all worked, I put the TV back. Then I tried to access with AnyDesk again and it failed! After further research I realised that the video card needs to be told what resolution to output. I could either have used Linux start scripts to force it, or an HDMI dummy plug. I chose the plug. You can get them for a few £ / $ / € on Amazon.
Since then it has worked quite well. The only issue is sometimes when I am typing remotely from my Mac, it double-types on the node. I have no idea how to fix this.
UPS to reduce inactivity penalties due to unexpected down time
Running from home means a risk of power cuts, lightning strikes or internet outages. I decided to get a UPS (uninterruptible power supply). Even more research!
Decision: APC BX1400UI
After a ton of searching and reading, I settled on an APC. Their website lets you choose how long you want to run for in an outage, based on the load you place on the battery. I also chose an APC because they have better support in the UK than CyberPower. The APC BX1400UI should give me around 50 minutes of up time in a power outage.
Which operating system?
MacOS, Windows or Linux? DappNode or work it out myself?
- I'm not sure I want to run MacOS without Apple hardware.
- I have been using a Mac so long that Windows scares me.
- I have never used Linux before, but it seemed best suited to the task.
- The company building the PC offered Ubuntu 20.04 free.
Decision: Ubuntu 20.04*
Ubuntu + Gnome came with the PC, and I was impressed! Having never used Linux before, here was a familiar UI. But did I really want to set up the rest of my Ethereum node myself? Or would DappNode make it easier for me?
*I decided to try DappNode first. After downloading the ISO file and finding a USB stick lying around, I attempted to burn to it. I tried repeatedly with Etcher and it threw errors no matter what I did. Eventually I had to format the USB with a specific filesystem (I can't remember which – sorry!) and give Etcher full disk access (MacOS settings > Security & Privacy > Privacy > Full Disk Access) AND run Etcher as root. 😩
Then I rebooted the node, entered the BIOS and told it to boot from the USB (I also set up AC Power Recovery whilst I was at it).
I went through the DappNode guide until I got to step 11 – Partition disk - Select disk to partition: [SCSIX (0,0,0) (sda) - ...]
Now call me stupid, but the only disk labeled SCSIX (0,0,0) (sda) was the USB! As weird as I thought it to partition the USB, that's what the guide said, and that's what I did. Surprise surprise it b0rked it. Then I had to go back through the Etcher process all over again (and yes I had forgotten what filesystem I had used).
By the time I had finished preparing the USB again, I realised I didn't want to risk trashing a working Ubuntu + Gnome setup with an unknown DappNode setup. So I decided to stop, and try using Ubuntu.
Infura or local full Ethereum 1 node?
Given my commitment to decentralisation, you can guess my decision…
- Infura is an amazing service. And… an oft-touted single point of failure for Ethereum.
- I want to contribute to the resilience too. I had already decided I want a local node before I chose the size of SSD.
- Then the question was which ETH 1 client? Geth, Nethermind, Parity, Besu? How should I know?! 😩
Decision: Local full Ethereum 1 node using Geth
With a bit of research and some help from my Argent colleagues, I chose to run Geth. It turned out to be easier than I thought. I did accidentally trigger a full sync by stopping and restarting the process part way through (a full sync can take weeks to complete). So I stopped it again, deleted everything and restarted with a fast sync.
One thing I found confusing is that the Geth setup guide assumes you want to sign ETH 1 transactions. I started messing about with Clef before realising that was unnecessary.
geth console and
geth attach are the only commands you need!
Eth2 client: Lighthouse, Prysm, Nimbus or Teku?
- Lighthouse sounded solid, but the documentation put me off. Even though I understood what "pre-built binaries" meant, it felt intimidating.
- Likewise Teku – the link on the eth2 launchpad sent me straight to "Build from source" on the Teku docs. No thanks…
- Nimbus is designed for low-spec devices
- Prysm's documentation was great and easy to follow. They also had a web UI for monitoring my node. Maybe the others do too, but I didn't get that far.
Decision: Prysm + Prysm Web UI
For something like this, documentation is so, so important. It is the UX of a command-line based product, and adoption depends on it.
Last few steps
After all that, I was at last ready to generate my validator keys and submit my deposit. Nerve-wracking when 32 ETH is a good chunk of my liquid net-worth. Unfortunately I haven't been in this game as long as some, who seem to have enormous bags of crypto. This was a big deal for me.
I completed the remaining steps following the instructions on the eth2 Launchpad, and now I await activation!
Still to do…
- Set up alerting, e.g. PagerDuty
- Set up automated backups, preferably image-based so I can get the node back up and running rapidly if the SSD fails.
- Or at least backup my Geth node to save me 24 hours+ of downtime whilst it resyncs.
- Maybe also write a shell script to automate rebuilding my environment as a fallback.
- And maybe set a cron job to check if AnyDesk has frozen or crashed, and auto-kill / restart it.
I'll need help with these, though…
Getting my home-based eth2 validator up and running was involved and tiring. I understand the temptation to just use a cloud-based service. The move to Proof of Stake is designed to enable true decentralisation, though, and I was determined to follow the spirit of that effort.
The majority of the work was finding and choosing the hardware (PC and UPS). Had I been an engineer, and/or run local blockchain nodes before, the rest would have been trivial. Having some experience of using a command-line interface was a real benefit to me though.
I hope I've proven that it is possible to run Ethereum 2 at home, and it is possible even for a designer!
I'd love to hear about your experience / decisions running (or not) eth2.