Get the best data-driven crypto insights and analysis every week:

Running an Ethereum Node from your Home

By Alex R. Mead

The ability to easily set up and run an Ethereum node on consumer-grade hardware is a key selling point in the decentralized nature of the Ethereum network. But just how practical is it for the average person to set up a node and run it from their home? With The Merge now complete, this question has come up quite a lot in the crypto community. At Coin Metrics we have a history of exploring nodes firsthand. For example, see a previous analysis where we rank nodes by their auditability in State of the Network Issue 30.

In this week’s State of the Network, we go through the steps needed to setup and run an Ethereum node from a residence. We’ll start with the basic hardware and networking requirements, move on to software downloading/compiling/installation, and conclude with node operational steps and maintenance. Throughout the issue, we’ll provide insights from a Geth/Lighthouse node the Coin Metrics team has been running continuously since June 2022.

Please note, this article is not an endorsement by Coin Metrics for any particular hardware, Internet service provider, or Ethereum Client, and is not engineering or financial advice. The discussed node is operated independently from Coin Metrics Infrastructure and runs purely for experimentation and research purposes. It has no interaction with any Coin Metrics services and the information provided here is purely for anecdotal purposes. Enjoy!

Hardware and Network Requirements

The Computer

To begin the process of setting up and running your very own Ethereum node, you’ll need a computer and an Internet connection. The computer will need to meet two general requirements, enough RAM and enough disk space. 

Each node client specifies the RAM requirements (see below), but any modern computer with 16 gigabytes of RAM will generally work well. The node may also run on 8 gigabytes of RAM; however, you’ll likely wish you had 16 GB if you use the node for anything beyond saying, “I run an Ethereum node.” It is recommended to run your Ethereum node on a dedicated computer—meaning the sole job of the computer is to run your Ethereum node. No streaming Netflix, editing videos, or other foreground/background processes, just running your node. 

After RAM, you’ll need to make sure your computer has enough disk space to store not only the current Ethereum blockchain (Remember, post-Merge, it now has two parts: Execution Layer and Consensus Layer Beacon Chain) but also a reasonable amount of space for the chain to keep growing. A good rule of thumb, for now, is a 2 terabyte solid-state drive (SSD). The SSD is essential as it allows for fast enough read-write behavior so the node can sync the existing chain locally, and maintain the chain as it grows for perpetuity. 

For our node, we are running a Dell OptiPlex 5080 with 16 MB of RAM, and an Intel Core i7 processor. This machine was purchased “off-the-shelf” directly from Dell via their webpage. Further, to supplement the in-built disk space, a Samsung Portable SSD T7 with 2TB is connected via a USB-C, Type 3 connector (i.e., the USB connector is blue in color). 

Ethereum node: Dell OptiPlex 5080, Wired Ethernet Connection, 2 TB SSD

The Network Connection 

To sync with the Ethereum Network, you'll need at least 25 MBit/sec download speeds, a specification well within most residential Internet plans. For our node, we use a standard Comcast plan available in the Midwest United States with alleged download speeds of 250 MBit/sec and a total data download of 1.2 terabytes per month. This service package, or something similar, is generally available to the users located in metropolitan areas within developed economies. 

Software: What Code and Where to Get it?

Post Merge, all Ethereum nodes must run two pieces of software simultaneously, a Consensus Layer node and an Execution Layer node. Ethereum.org lists the following Execution Layer nodes: Geth, Nethermind, Besu, Erigon, and Akula. For Consensus Layer nodes, it lists: Lighthouse, Lodestar, Nimbus, Prysm, and Teku are listed. 

An analysis of each of these distinct softwares is beyond the scope of this piece; needless to say, we decided to run the good old trusty Geth and the well-respected Lighthouse for our Execution and Consensus Layers, respectively. 

Operating System (OS)

Before diving into the software that runs the Ethereum Protocol, a quick word on Operation System (OS) choice; we decided to run Ubuntu 22.04 LTS, bare-metal. Bare-metal means the OS is running directly on the processor’s silicon. No virtual machines, no Docker containers, just an “old-fashioned” OS on a computer. Running on bare-metal offers the best utilization of the hardware resources, requiring no “overhead” for virtualization. Ubuntu 22.04 LTS is available free for download and was chosen in part because of the independent nature of both crypto and the Linux communities, of which Ubuntu is one of several “Linux flavors.” 

To install the Ubuntu OS onto the Dell machine, we must partition the existing hard drive, which runs Windows 10, out of the box. Step-by-step instructions for this process are listed on Ubuntu’s webpage and require a thumb drive USB to load the new OS on the new partition. Installing an operating system can be tricky and is perhaps the first real “bottle-neck” for a non-technical node operator to overcome. It should be noted that one can run the same system on Windows 10 and thus this is not a truly required step. Moreover, many resources exist on the Internet to solve this problem, so we think it is still reasonable for a motivated user with good computer skills to pull this off. 

Execution Layer: Geth

Geth is by far the most used Ethereum node and comprises approximately 80% of all Ethereum clients, according to clientdiversity.org. While this is not ideal for the network, this is the client our node is running. For our client executables (i.e., the program our OS actually runs when you start the node), in true “Don’t trust. Verify.” fashion, we wanted to be sure of the composition of the software. Hence we downloaded the source code using Git from the Official Go Ethereum Repository. With the entire codebase local, we then used GNU Make to build the Geth client, along with several other supporting pieces of software from Go Ethereum, including clef, to create and manage a key-pair for the node. The Go Ethereum webpage has step-by-step instructions for each step.

Downloading source code, compiling it, and installing it on your machine is true software engineer-type work. Likely, this is too much of a lift for the average computer user. As such, Geth also provides pre-built binaries you can download from their webpage if compiling from source is too challenging. Please note, however, while these binaries are very trustworthy, you are in fact trusting their composition. With the source code approach, every single line of code can be individually analyzed and thus requires no trust.  

Consensus Layer: Lighthouse

In the same spirit as Geth, for the node, we downloaded Lighthouse from the Official Lighthouse Repository, which was compiled from source. Similarly to Geth, compiling Lighthouse can be very tricky without software experience. As such, prebuilt binaries are also available for Lighthouse.

Running the Node

When it comes to actually running your node, recall the operator must run two programs (Execution Client, Consensus Client) on the same machine - Geth and Lighthouse in our case. Further, each client will need to write large amounts of data to disk, which brings us to our first step, mounting the SSD to the filesystem.

Mounting the SSD

Similarly to compiling source code, locating the physical SSD drive and then “mounting it” are not easy for the average computer user. It requires the usage of a terminal program and the ability to navigate throughout the folder structure of your computer. For our node, we chose to mount the SSD to the home directory folder ~/ethereum. In this folder (recall, this is actually located on the SSD!) we made two more folders, ~/ethereum/execution_layer and ~/ethereum/consensus_layer. These folders (or as programmers call them, directories) will hold all the files necessary for the node, including the blockchains themselves.

Running the Node Software

With the file location where our node will operate setup, we can now run the node software itself. We began by first following the steps on the Go Ethereum webpage, which includes setting up a user account (EOA - Externally Owned Account) with clef then starting geth itself with several parameters, most importantly the --datadir set to our ~/ethereum/execution_layer folder (i.e., the directory) on the SSD. Please note, --chainid is “1” (without the quotes) for Mainnet (i.e., the real Ethereum we know and love and not a testnet). Additionally, now that geth must connect to the Consensus Layer client (Lighthouse in our case), a few additional parameters must be configured, which are explained by Go Ethereum on their webpage section, Connecting to Consensus Clients. 

This command will start the syncing process for the Mainnet blockchain, as of now, a more than 600 GB resource (October 2022). When starting our original node sync back in June 2022, this process took about five days. 

The Consensus Layer Client, Lighthouse, is run in the same manner as Geth above. Again, be sure to specify --datadir correctly to the SSD to ensure you have enough disk space to store all the needed data. Further, Lighthouse will need to communicate with Geth as they both operate to support Ethereum post-Merge. Specific instructions for this connection process are provided by the Lighthouse documentation in the section, Connecting to an execution engine. Syncing the Beacon Chain took about two days for our node. Please note, we first synced the mainnet chain (i.e. Geth), then started the Beacon Chain (i.e. Lighthouse) sync. 

Mount SSD: 
$sudo mount /dev/sda ~/ethereum

Run clef:
$clef --keystore ~/ethereum/execution_layer/keystore 
         --configdir ~/ethereum/execution_layer/clef
         --chainid 1

Run geth:
$geth --datadir ~/ethereum/execution_layer
          --signer=~/ethereum/execution_layer/clef/clef.ipc
          --mainnet
          --syncmode snap
          --http
          --authrpc.jwtsecret ~/ethereum/execution_layer/geth/jwtsecret
          --authrpc.addr localhost
          --authrpc.port 8551
          --authrpc.vhosts localhosts
          --cache 1024

Run lighthouse:
$lighthouse breacon_node
          --network mainnet
          --datadir ~/ethereum/consensus_layer
          --http
          --execution-endpoint localhost:8551
          --execution-jwt ~/ethereum/execution_layer/geth/jwtsecret

Ethereum node: Lighthouse STDOUT on left screen, Geth STDOUT on right screen.

Using Your Node

While the node is syncing, you can expect large amounts of data to be downloaded. This is literally the entire blockchain history of Ethereum, including the Beacon Chain, being copied to your local computer. With this information fully downloaded, you can query your local node for any information and trust no one to verify the Ethereum system. With this setup, you can truly live the mantra, “Don’t trust. Verify.” when it comes to the Ethereum Network and all the DApps that go with it. 

Connecting to your node is straightforward, using the locally hosted RPC for either the Geth or Lighthouse node components. The APIs are well documented for both the Execution Layer and the Consensus Layer. For Python users, using the open source Web3.py module is an excellent choice, with many examples freely provided via blog posts and question forum responses, such as Stack Overflow. If you’re not familiar with API’s there will be a learning curve here; however, with Python and numerous resources available for this ecosystem, motivated users can certainly find the resources online to learn all they require. 

Node Performance

With Proof of Stake (PoS) as the consensus mechanism, Ethereum block timing has become very predictable. Blocks arrive with high consistency every 12 seconds (24, 36, etc. for missed blocks), with other communications (e.g., attestations) occurring at the 6-second intervals between block propagation. Running a dedicated node (i.e., the computer only runs Ethereum), this is very clearly visible in both the CPU and Network Activity Monitor displayed below. This is exactly as expected, and it is always a reassuring sign to have the “theory” of a system match the observed data. Recall this is our own node, compiled from source code and set up using all the basic building blocks.  

Ethereum node: CPU Load Percentage and Network Data Rate for Standard Operation.

To further show the node in operation, we called an endpoint for the Consensus Layer to return the set of all Validators (i.e., /eth/v1/beacon/states/{state_id}/validators ), a result of more than 400,000 validators at the time of writing. This query took a couple of minutes to run, and as seen below, the CPU visibly increased usage during the request handling, then dropped back down to “normal” once the request was served. 

Ethereum node: Beacon node serving API call and then returning to normal node operational load. 

Continuing Node Operations

As with all software systems, new versions are constantly being developed. For Geth and Lighthouse this is no different—and, from time to time, you must update your node software. For us, this involves pulling the latest version from the Github repositories, compiling new executables, and restarting Geth and Lighthouse with the latest stable versions. For our simple node, we just recompile and restart. A deployment pipeline with development, staging, and a fully monitored production environment would be appropriate in more production-facing nodes. If you’re not compiling yourself, you can download the latest pre-compiled binaries and restart the node using those. Further, the operating system also has updates that must be downloaded and installed. These are of particular importance to avoid security issues at the OS level.

For our node, there was a learning curve for getting the node to run continuously at first. Managing the RAM utilization of each process was the first hurdle, as the computer “randomly” shuts down without enough RAM. Further, initially, the node was using WiFi, and the wireless router crashed due to data overload. With these issues addressed (i.e., cache limits and wired Ethernet), the node has operated for months at a time without downtime. 

Conclusions

Running your own local Ethereum node is possible using consumer-grade computer hardware and a residential-based Internet connection. While running clients (Consensus and Execution Layers) compiled locally from source may be a stretch for most users, pre-compiled executables are available for the most typically used clients. Further, setting up an SSD to store the blockchains and getting an operating system (OS) running is a challenge for most users; yet remains within the capabilities of a motivated user with some patience and willingness to learn.

The next step for a node operator is deciding whether to become a validator or not. For this, the node must run a third client locally (Lighthouse ships with a validator client as well), and 32 Ether must be staked. It’s a bit more complicated than this node setup. Furthermore, one should note that off-line penalties and the possibility of messing up private keys for the staked Ether poses a risk. As such, a user should understand what they are doing before running a validator. We have not run a validator ourselves, but given the complexity of running our node, it would be wise to run your own node for at least a month, then decide if you’d like to run your own Validator on top of your node as well. 

Tips for Running your node, in no particular order

Pro-Tip #1

If you want to ensure Geth and Lighthouse are running continuously, or at least with as little downtime as possible, you can also use systemd to ensure it is running as a background process whenever the machine is on. This helps if your computer ever gets rebooted accidently to ensure the node starts operating again as soon as possible. 

Pro-Tip #2

To ensure you don’t overwhelm your WiFi router, ensure you are connected to the Internet via a physical Ethernet cable. Not only will this typically give you higher download/upload speeds, but it will also prevent your router from “crashing.” Crashing a WiFi router means you put too much data through it, and it stalls. This requires a hard reset (unplugging the power cord is the typical method), and this obviously prevents the node from syncing (when this will likely happen) or from keeping up with the head of the chain if you are already synced. 

Pro-Tip #3

Limit the amount of RAM Geth and Lighthouse can use. There are various methods to do this. A good start is using the --cache parameter to Geth. This will ensure you have some “leftover” RAM so you can interact with the node; for example, querying for blocks and their content while still keeping up with the Network.

Pro-Tip #4

Check on your node periodically to ensure the clients are still running. We’d recommend a few times a day when getting started and syncing the chains. Then daily for a week or so after the chains are synced. Finally, once the node is up and running, you can check it every few days. Remember, however, if the node isn’t running, it’s “falling behind,” so check at an interval that meets your needs.  You may run a server monitoring software that will notify you of outages. However, this starts to get pretty involved and perhaps should be left to professional node operators in cloud-based data centers. 

Acknowledgements

Thank you to Matías Andrade, Youngjun Ko, Antoine Le Calvez, Nate Maddrey, and Kyle Waters, all of Coin Metrics, for their comments and suggestions.

Network Data Insights

Summary Metrics

Source: Coin Metrics Network Data Pro

In recent news, XEN token mint on the Ethereum blockchain consumed up to 50% of available blockspace, burning over 3,100 ETH over the last week, bringing supply created since the merge down from slightly over 13,000 to 9,300 ETH.

Coin Metrics Updates

This week’s updates from the Coin Metrics team:

• To discuss SOTN and other CM research, come join our community on gm.xyz.

• Members of the CM research team are in Bogotá, Colombia this week for Devcon VI!

As always, if you have any feedback or requests please let us know here.

Subscribe and Past Issues

Coin Metrics’ State of the Network, is an unbiased, weekly view of the crypto market informed by our own network (on-chain) and market data.

If you'd like to get State of the Network in your inbox, please subscribe here. You can see previous issues of State of the Network here.

© 2022 Coin Metrics Inc. All rights reserved. Redistribution is not permitted without consent. This newsletter does not constitute investment advice and is for informational purposes only and you should not make an investment decision on the basis of this information. The newsletter is provided “as is” and Coin Metrics will not be liable for any loss or damage resulting from information obtained from the newsletter.