Requirements

First, we should see if your computer has what it takes.

My understanding from looking around the web is that your CPU shouldn’t be a problem if you’re running on a computer. If you’re running on a Raspberry Pi or the like, I suggest you look at this tutorial.

The hard drive is the bigger consideration. While it may be possible to sync up to the chain with an HDD drive, the recommendation is SSD. At least 500GB is recommended. With the improvements in Geth, I can testify that it does not need to be an internal drive — an external SSD that connects by USB is fine. As far as stats go, I’ve seen that you should have at least 50MB/s (write/read). Gregoire has instructions for benchmarking your system in his tutorial, if you’re interested in knowing what your hard drive is capable of.

(You may wonder for how long 50MB/s will be enough. While it’s true that the Ethereum blockchain has grown considerably over time, the amount that each node will need to store should decrease with Eth 2.0/Serenity. As of November 2019, the size of my node is roughly 175 GB. Even if the rate of growth picks up, and Eth 2.0 and sharding don’t arrive for a while, I believe that 500GB should hold out for some time. Of course, there’s nothing wrong with getting a whole TB, especially if you also want to run Swarm.)

As for internet connection, I’m guessing that you need at least 10 Mbits/s in order to not impede using your computer for other stuff. If you’re running on a laptop, and will have a slower connection sometimes, I would assume you could pause running your node while in slower areas, and sync back up when you’re back over 10 Mbits/s.

Lastly, have some patience. Even with all the speedups, the initial sync can easily take more than three days. On the bright side, we’re going to turn this into a background process, so it shouldn’t need much attention from you.

Update: A few words on Ethereum Grid before we get started

I got through writing this piece before I discovered Ethereum Grid, and official Ethereum Foundation project to make an easy-to-use, slick GUI for running nodes, and not just Geth — they’ve preloaded a bunch of different clients, it looks like. Here’s a screenshot from their GitHub:

I haven’t played around with Grid, and I do not know what the system requirements are, nor how smoothly it’s running. I mean this as no offense whatsoever, but I have found in the blockchain space much as in the rest of the world that the shortcut sometimes takes longer, so you may want to still follow the tutorial and get your node running the ‘hard way’. Even if you are going to use Grid, you may find the instructions below for setting up an external SSD and installing Go useful.

Another reason to run Geth from the command line may be attaching a Swarm node. Grid promises an app store for plugins, and they’re planning for click-and-launch functionality, but they don’t offer it yet (as of Nov. 2019 — feel free to check if anything has changed). It could be that attaching a Swarm node from the command line to Geth runnning on Grid is just as simple as attaching Swarm to a ‘regular’ Geth node, but I, unfortunately don’t know.

With all of those dissuasions, I do want to emphasize that Grid looks super-slick, and is an Ethereum Foundation project. It may be a good place to start, and may even be an easier experience than this tutorial.

Installation and Sync

Setting up an external SSD

(Special thanks are in order to Gregoire Jeanmart — this section is largely copied from his excellent tutorial for running a node on Raspberry Pi.)

If you’re running off an external SSD, here are some steps for setting it up. Use sudo fdisk -l to locate the drive. Here’s an example output from that command:

Disk /dev/sda: 931.5 MiB, 1000204886016 bytes, 1953525168 sectors Disk model: Kingston FF01BT2

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes



(...)



Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors

Disk model: Portable SSD T5

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

In this case /dev/sdb is your external SSD. We’ll use this as the example moving forward, so if your SSD is at a different location, replace /dev/sdb with whatever location you gleaned from fdisk .

If you need to (re)partition the drive, use the following. This will wipe everything on the drive. Backup the contents elsewhere and then proceed:

sudo mkfs.ext /dev/sdb

Press ‘y’ when prompted.

We’re going to manually mount the SSD (replace user:group with your username and group separated by a colon (:) — if you don’t know about groups, enter groups in the terminal and use the first option):

sudo mkdir /mnt/ssd

sudo chown -R user:group /mnt/ssd

sudo mount /dev/sdb /mnt/ssd

We want the SSD to auto-mount at startup. Type in sudo blkid and get the UUID associated with the SSD (the one at /dev/sdb or wherever your SSD is). Copy it — we’ll need it in a second.

sudo nano /etc/fstab

Add the following (make sure to put a space after where you pasted the UUID):

UUID=**Paste UUID from blkid here** /mnt/ssd ext4 defaults 0 0

Changes won’t take effect without a reboot, so if you want to keep on going and get Geth running, you’ll need to restart. Once you do, you can enter the following to see if the computer did indeed mount the SSD:

df -ha /dev/sdb

The output should include that /dev/sdb is mounted on /mnt/ssd .

Installing and setting up go

We’ll be running Geth, which is an Ethereum client written in Go, so we need to set up Go. The version of Go listed below is the most current version as of this writing, but feel free to check Golang’s site to see if there’s a more current version. We’ll assume a normal 64-bit architecture. If you run into trouble, check the website. Getting Go up and running can be a pain, so we’ll take a shot at simplifying the process:



wget

sudo tar -C /usr/local -xvf go1.13.4.linux-amd64.tar.gz cd ~/Downloadswget https://dl.google.com/go/go1.13.5.linux-amd64.tar.gz sudo tar -C /usr/local -xvf go1.13.4.linux-amd64.tar.gz

Note: this assumes go1.13.5 is the latest version of Go (which is the case as of this update (Dec. 8, 2019)). You can check here to see if this is still the case. If there is a newer version, you can remove 1.13.5 , replacing it with whatever version is the most current stable.

We need to set the environment variables. There’s more than one way to do this, but here’s one:

sudo nano /etc/profile

This will open up the Nano text editor on the /etc/profile file. (If you don’t have Nano, sudo apt install nano should do the trick on Debian-like systems. Replace with your friendly neighborhood package manager if you’re on a different Linux.)

At the bottom of the file, add this:

export PATH=$PATH:/usr/local/go/bin

Press Ctrl+X , hit Y and ENTER to save.

sudo source /etc/profile

This should get it loaded up. If you type go version in your terminal, you should see something like go version go1.13.5 linux/arm as the output. If not, you’re in the wonderful world of Go troubleshooting and I wish you luck! You may have to wipe Go and reinstall it, but you can try to find something useful online about the errors you’re getting.

Installing Geth

Navigate to whatever folder you want to store the Geth source code in.

export GO111MODULE=on

go get -d github.com/ethereum/go-ethereum@v1.9.9

**This may take a minute, don't worry

go install github.com/ethereum/go-ethereum/cmd/geth

Note: @1.9.9 tells go to download version 1.9.9, which is the latest stable Geth release as of this update (Dec 8, 2019). You should definitely check here to see what the most recent stable release version number is — it’ll be the one in big print at the top of the page, replacing 1.9.9 with the version of the most recent stable release.

You may discover various problems with your Go installation at this point. See above, and the wider internet, if this occurs.

sudo mv $GOPATH/bin/go-ethereum/build/bin/geth /usr/local/bin

Now geth version should output information about your current installation. If it does, congratulations! You installed Geth.

Let’s make a data directory with permissions. (This assumes you’re using an external drive mounted to /mnt/ssd , otherwise replace with the internal location — something like /dev/sda1 ):

sudo mkdir /mnt/ssd/ethereum

sudo chown -R user:group /mnt/ssd/ethereum

Syncing with Geth

If that all went well, we’re up and running with Geth and syncing.

There’s been a lot of progress in speeding up the initial sync with the current state of the chain, and there’s even cooler stuff being worked on. What this means is that you want to leverage a special syncing mode which should cut down the initial sync to several days. Try the following:

geth --syncmode fast --cache 1024--datadir /mnt/ssd/ethereum

(If it’s hogging too much memory, try turning down the --cache flag. --cache 256 works just fine, but it’ll take a few days to sync, whereas --cache 1024 should probably only need a couple of days. At 8GB of RAM my system is unaffected at --cache 256 , if that’s of any help.)

If all is well, there should be a pretty solid stream of output. That’s great, but press Ctrl+C to stop it because we’re just checking if it works. We don’t want you to have to manually restart Geth each time you boot up, so we’re going to turn this into a system process (again, copied from Gregoire Jeanmart with permission.)

sudo nano /etc/systemd/system/geth.service

Once in Nano, type in the following (as before, replace user and group with your username and group.):

Formatting note: the line starting ExecStart doesn’t end until after /mnt/ssd/ethereum . I couldn’t figure out a way to get it on one line, and embedding a Gist would cut off the script before the end.

[Unit]

Description: Geth Node

After=network.target auditd.service

Wants=network.target

[Service]

WorkingDirectory=/home/user

ExecStart=/usr/local/bin/geth --syncmode fast --cache 256 --datadir mnt/ssd/ethereum

User=user

Group=group

Restart=always

RestartSec=5s [Install]

WantedBy=multi-user.target

RequiredBy=swarm.service

Alias=geth.service

(Again, the cache above is set at 256. If you are running a dedicated node, or have a lot of RAM, you should probably crank this up to 1024 or even 2048. Also, I would recommend pulling off the --syncmode fast flag once you’ve synced.)

Ctrl+X, then Y and Enter to save changes. The following will reload system daemons, which will now include geth.service , then start geth , then mark this as a service to be launched at startup:

sudo systemctl daemon-reload

sudo systemctl start geth

sudo systemctl enable geth

You can check the logs to see if Geth is running:

sudo tail -f /var/log/syslog

Ctrl+C to get out. Gregoire has great information in his tutorial about the nature of syncing (it’s the section called ‘Syncing’) and has a whole other tutorial about how to set up a log and import it into Google Sheets (or similar) with awesome charts. I’d be copying it out word for word, so I’m going to leave you, awesome new node runner, to check it out yourself.