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 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.
From this point forward, we’ll refer to this window as the “Geth Node Server”.
Watch and wait:
You should see something similar to:
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.
You may elect to use the native SSH tunnel for secure RPC communication with this Node:
The general usage would be:
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.
"firstname.lastname@example.org" 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:
Unlock the wallet using the account address from the previous step:
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: