Geth Ethereum Node for CAS

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 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, Geth needs to be coupled to another piece of software called a "consensus client".

Installation of the Geth Ethereum client on Ubuntu 22.04 LTS is described herein.

Install Geth on an Ubuntu 22.04 LTS server.

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:

Create a new Geth account.

Create the account:

geth account new

• Use a memorable password, like “GeneralBytesIsGreat”.

Verify the account:

geth account list

You may see a few errors (it’s ok), but “Account #0” should be listed at the end.

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.

Sync Geth

Now that an account has been created, we’re ready to startup the node to synchronize it with the rest of the Ethereum network. This will take quite some time, and is unavoidable. You must prepare 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 a bear.

Start the Geth node:

geth --allow-insecure-unlock --http --http.api personal,eth,net,web3

Geth will start, and automatically begin searching for other nodes, fetching blocks from those discovered 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 while “live”:

• Notice the “age” reported in this log.

The synchronization may take a few days. This 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.

Watch and wait:

To monitor your progress, you’ll need to open a second terminal window to your server. Once you’ve SSH’d in to your server and have an additional command prompt, start the Geth JavaScript console using:

geth attach

You should see something similar to:

• The Javascript console enables you to monitor & control your node.

• More information here: https://geth.ethereum.org/docs/interface/javascript-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 may be because it has finished successfully, or that your node has 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 abuse. They’ll respond by automatically “killing” your node. Here’s how to tell in the Geth Node Server:

If you see that, then your node was probably shut down for abusing your host’s “Terms of Service”. Yes, I did that. 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 Node 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.

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

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.

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

Next: Configure CAS to use this node.