This guide was written using Geth version 1.13.14-stable.
For newer versions, please consult: https://geth.ethereum.org/docs/getting-started/installing-geth
Geth is an Ethereum node execution client. Historically, an execution client alone was enough to run a full Ethereum node. However, since Ethereum swapped from proof-of-work (PoW) to proof-of-stake (PoS) based consensus in2022, Geth now needs to be coupled to another piece of software called a "consensus client". Both pieces of software must be installed to operate an Ethereum node.
Installation of the Geth Ethereum client and Prysm client on Ubuntu 22.04 LTS is described herein.
1. Install Geth as the “Execution Client”
Minimum system suggested:
4 CPU cores
16 GB RAM
1100+ GB contiguous SSD (more as the blockchain grows over time)
Estimated cost (Mar 2024): $302+ USD/month on a “cloud” VM.
Patience - the sync takes over a week to become usable.
Update your server:
sudo apt update && sudo apt dist-upgrade
Add the Geth PPA repository:
sudo add-apt-repository -y ppa:ethereum/ethereum sudo apt update
Install Geth:
sudo apt install ethereum
Verify that the installation was successful:
geth version
That command should generate a confirmation like so:
SCREEN
Screen is a Linux built-in windowing utility that enables you to operate several Linux programs at the same time. It’s useful when you have to switch back and forth between multiple programs within a single Terminal window. There are other ways of accomplishing this task - including using multiple Terminal windows - but Screen has the added benefit of persistence: the program does not terminate when you close a Screen window (or get disconnected).
Screen is used within this article. Complete instructions: https://linux.die.net/man/1/screen
Shortcuts:
Create a new screen window:
screen -S name_of_window
Detach from a window: Ctrl+a, then d
Attach to a window:
screen -r name_of_window
2. Startup Geth.
a) Create a new account/wallet using Geth.
Create the account:
geth account new
Use a memorable password, like “GeneralBytesIsGreat”.
Save the wallet password somewhere secure!
Verify the account:
geth account list
You may see a few errors (it’s ok), but “Account #0” should be listed at the end.
b) Start the Geth node:
SCREEN is described above: https://generalbytes.atlassian.net/wiki/spaces/ESD/pages/3156279297/Geth+Ethereum+Node+for+CAS#SCREEN
Geth will now start inside the new SCREEN window, and automatically begin searching for other nodes. It won’t begin downloading the blockchain until the next step (installing a consensus client) has completed.
screen -S geth geth --allow-insecure-unlock --http --http.api personal,eth,net,web3
Exit SCREEN using Ctrl+A, then “d” (for detach).
To later return (reattach) to this window, use
screen -r geth
.
3. Install Prysm as the “Consensus Client”.
You may choose any Consensus Client that suits you. You have a half-dozen choices, and the community encourages diversity.
Other consensus clients: https://geth.ethereum.org/docs/getting-started/consensus-clients
For this example I chose “Prysm” because it is also based on the Go software. It was mostly an arbitrary decision. The guidance I provide below differs from the one at their website, as certain assumptions (Ubuntu + Geth + IPC + Mainnet) have already been calculated in.
Full Prysm installation instructions here: https://docs.prylabs.network/docs/install/install-with-script
a) Install Prysm:
mkdir -p /root/.local/prysm cd /root/.local/prysm curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh
b) Start Prysm:
Create a new SCREEN window, and start Prysm:
screen -S prysm /root/.local/prysm/prysm.sh beacon-chain --execution-endpoint=/root/.ethereum/geth.ipc --mainnet --checkpoint-sync-url=https://beaconstate.info --genesis-beacon-api-url=https://beaconstate.info
The IPC endpoint specified is the Linux Geth default.
Exit SCREEN using Ctrl+A, then “d” (for detach).
To later return (attach) to this window, use
screen -r prysm
.
4. Sync.
Now that an account has been created, and a consensus client is operating, Geth & Prysm will begin to automatically synchronize it with the rest of the Ethereum network. This will take quite some time, and is unavoidable. You must be prepared to wait days before the process is complete. Once finished with the initial sync, your Node will keep itself synchronized - but the first time is lengthy.
To view the sync process, reattach to the Geth screen:
screen -r geth
You’ll see Geth fetching blocks from other nodes, confirming the blocks, and adding them to your locally stored blockchain. This is called a “full node implementation”, and they are important to the network. Full nodes are the backbone of Ethereum (and all other blockchain-based networks).
This is an example of the node output:
Notice the “age” and ETA reported in this log.
The synchronization may take a few days. The reported ETA is unreliable and virtually worthless. The actual ETA heavily depends upon several factors, including your CPU, GPU, RAM, storage technology, and Internet bandwidth. Once the entire blockchain has been downloaded and confirmed by your node, you’ll be ready to proceed with the next step of enabling remote access.
From this point forward, we’ll refer to this window as “Geth Server”.
The consensus client “Prysm” has no bearing on the rest of this article. It must still run in it’s own SCREEN window, and you can check in on it at-will, but from this point forward: we’ve no need to change anything in Prysm or see results from it.
The execution client “Geth” is the only software we’ll want to monitor and affect.
Once you are satisfied that the synchronization is underway, exit the SCREEN using Ctrl+A, then “d”.
Watch and wait.
The node will attempt to use all available resources to finish as quickly as possible, and your server’s host may consider it to be abuse. They’ll respond by automatically “killing” your node. Here’s how to tell in the Geth Server:
If you see that, then your node was probably shut down for abusing your host’s “Terms of Service”. Yes, I was guilty of that once. Sorry Google. Explore the use of “cpulimit” to prevent that abuse, or increase the server resources to comply with your hosts demands.
Control.
To monitor the sync progress, you may use the built-in Geth JavaScript client to check up on it. Once you’ve SSH’d in to your server, start the Geth JavaScript console using:
geth attach
You should see something similar to:
The SCREEN containing the Geth Server should still be running merrily in the background.
The Javascript console enables you to monitor & control your node; this is the front door.
More information here: https://geth.ethereum.org/docs/interface/javascript-console
From this point forward, we’ll refer to this window as the “Geth Console”.
Type the following in the Javascript console to identify the synchronization progress of your node:
eth.syncing
If your node is still synchronizing, then you’ll see something like this in the Geth Console:
In this report, “highestBlock” is the number of blocks (total) to confirm.
“currentBlock” is the block that your node is currently confirming.
In the example above, block downloading is about 2857543/10633048 (26.9%) completed.
After that completes, it will update “trie nodes” (States). This number cannot be predicted, and will be very large, each update reporting: “
Imported new state entries
”. This may take days itself, and your sync may seem “stuck”. It isn’t. Be patient.
Many people falsely assume that because they have the blocks, they are in sync. Unfortunately this is not the case, since no transaction was executed, so we do not have any account state available (ie. balances, nonces, smart contract code and data). These need to be downloaded separately and cross checked with the latest blocks. This phase is called the state trie download and it actually runs concurrently with the block downloads; alas it take a lot longer nowadays than downloading the blocks. - from: https://geth.ethereum.org/docs/faq
Eventually, the Geth Console query will result in a “false”, as illustrated here:
This means that your node has stopped synchronizing. This is likely because it has finished successfully, or possibly because your node has been shut down.
The node will attempt to use all available resources to finish as quickly as possible, and your server’s host may consider it to be abuse. They’ll respond by automatically “killing” your node. Here’s how to tell in the Geth Server:
If you see that, then your node was probably shut down for abusing your host’s “Terms of Service”. Yes, I was guilty of that once. Sorry Google. Explore the use of “cpulimit” to prevent that abuse, or increase the server resources to comply with your hosts demands.
Assuming that the Geth Server isn’t shutdown, that it continues to process the network, and that “eth.syncing” generates a “false” reply in the Geth Console, then your blockchain should now be fully sync’d and your node ready for the next step.
You should now backup the account.
You will need both the backup and the password to access your wallet in case of a disaster.
See official documentation for details.
Setup an SSH tunnel to secure inter-server RPC communication.
We discourage running any software on your CAS server (except for CAS itself). This warning includes the Geth Node Server. The simple solution is to use port forwarding to enable CAS access to your separate Geth Node Server. Two options are explained:
Option 1: Using the GB Wallet Tunnel (recommended):
General Bytes includes an integrated open-source ssh client in CAS. The client is designed to work effortlessly with the GB Wallet Tunnel Server.
Click here for instructions to install the GB Wallet Tunnel Server.
Option 2: Creating an SSH tunnel:
You may elect to use the native SSH tunnel for secure RPC communication with this Node:
The general usage would be:
ssh -f -N -i /home/gb/.ssh/cas-geth-node -L 8545:127.0.0.1:8545 gb@35.237.163.176
In the above example (run from your CAS server CLI), the options explained:
"
ssh -f -N
" is the "create a permanent tunnel in the background" command."
-i /home/gb/.ssh/cas-geth-node
" specifies the SSH private key file to be used."
-L 8545:127.0.0.1:8545
" are the Geth's default RPC ports being forwarded."
gb@35.237.163.176
" is the SSH user (and IP) of the Node.
This presumes that your private key file is stored at /home/gb/.ssh/
as: cas-geth-node
We do absolutely encourage password-less logins (use a private key).
If the CAS system permits multiple users, you should password-protect the private key.
Recruit an IT professional if you are uncomfortable with any of this! Protect your funds!
Unlock your account
The Geth Node Server must be running & completely synchronized to successfully proceed.
Locate your account address in the Geth Console by using:
personal.listAccounts
Unlock the wallet using the account address from the previous step:
personal.unlockAccount("0xa890ef99308a2eb5abf5d7956544de31eb594338", null, 0)
Quotes are required with the address.
“null” will cause the Geth Console to request your password. The password is not saved or visible anywhere using this method. You may also provide it in quotes, but that method may expose your wallet password, so use cautiously.
The “0” means “leave it open”. Any other number sets the number of seconds before auto-lock, which is incompatible with CAS. CAS MUST HAVE AN UNLOCKED WALLET TO FUNCTION.
Returns “true” if the wallet is unlocked & opened.
Unlock your wallet every time you start the Geth Node Server.
CAS “Crypto Settings” tests will FAIL if the wallet is locked.
After the Geth Node Server is shutdown, the wallet will automatically close, but if you prefer to do it manually, the following command will accomplish that:
Once the wallet is unlocked, you may exit from the Geth Console at your leisure:
exit
The Geth Server must always be running, and the wallet must remain unlocked.
If either condition fails, ETH transactions via CAS will fail until remedied.