Versions Compared

Version Old Version 6 New Version Current
Changes made by

Charles Wernicke

Charles Wernicke

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

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.

...

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+Aa, then Dd

  • Attach to a window: screen -r name_of_window

...

For this example I chose “Prysm” because it is also based on the Go software. It was mostly an arbitrary decision. The guide 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:

Code Block
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:

Code Block
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.

...

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 prepare 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 a bearlengthy.

To view the sync process, reattach to the Geth screen:

...

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.

...

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, but your server’s host may classify it as 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.

The point is: check in on the process from time-to-time, and restart it (if needed). You lose nothing but time, as the download will be recovered from the moment it was killed.

...

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:

...

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, Ensure that the Geth Server isn’t shutdown (i.e. for abuse, see above) and that it continues to process the network, and that . If “eth.syncing” generates a “false” reply in the Geth Console, then your blockchain should is now be fully sync’d synchronized and your node ready for the next step.

...

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

...

a secure tunnel for encrypted 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 ServerYour CAS server and this node must have a secure line. Your passphrase and other sensitive information will be passed back & forth. Encrypt (and protect) this communication by using a secure SSH tunnel.

The GB Wallet Tunnel is recommended.

General Bytes has incorporated an open-source SSH client into CAS.

Click here for instructions to install the GB Wallet Tunnel Server on this node.

...

Alternative (unsupported):

Build an SSH tunnel

...

You may elect to use the native SSH tunnel for secure RPC communication with this Node:

The general usage would be:

Code Block
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.

...

(instead of the GB Wallet Tunnel), see: https://generalbytes.atlassian.net/l/cp/b7j5AVHA

  • For those instructions, set FORWARDED_PORT=8545

...

Unlock your account

Note

The Geth Node Server must be running & completely synchronized to successfully proceed.

...