ethup

Initially, Ethereum nodes such as geth or parity have been design to run 24/7 and never… ever… stop. For such a piece of software to never break is not an easy task and passionate developers work hard everyday to ensure the stability of your favourite Ethereum client.

Before going any further, let’s give a short definition for what I call casual user. The casual user is using Ethereum from time to time but not all the time. The casual user is using a standard computer and may turn it on and off from time to time. As much as nodes running 24/7 on servers, the casual user is a key element to a successful Blockchain as it its main user.

Until about last year, synchronising the Ethereum blockchain as a casual user was rather easy. You just had to start your favourite client, let it spin a few minutes or an hour at most to catch up with the latest blocks from a week or two.

This has changed. Synchronising weeks of the Ethereum blockchain takes a long time. On a good laptop (with SSD drive) with a good internet connect and a killer internet connection, you should get a speed of 3~5 blocks a second. During that time, new blocks are created every ~15s on the fundation network and and you also need to catch up with those.

Developers feel this issue ever harder as they often synchronise several chains such as the “testnet” chains (ie: kovan, rinkeby, ropsten). Those are very similar to the official Ethereum Blockchain but offer different properties such as different consensus algorithms, faster block generation and most important Ether has no value on those chains.

The issue is known and the developers of Ethereum clients are working hard to improve the situation. Their work includes:

Most of those improvements are barely noticed by users but often the result of very clever optimisations.

Some improvements however are real tradeoffs. Using a light client for instance, means that you no longer have the entire blockchain locally and your node will need to fetch some of the data, when needed, from trusted sources.

I wrote ethup in order to help synchronising nodes using parity or geth with the various chains they support. ethup lets you start your client and reads its console output. When ethup thinks the chain has been entirely synchronised, it will stop the node.

Since I started this article, I also opened issues for both clients. You can find them at:

The ability to stop the node after it bas been synchronised means that you can then start synchronising another chain without changing the configuration or the ports being used.

I am personally using an alias I call ethupall to synchronise all my chains: alias ethupall=’time ethup -c “parity --chain kovan”; time ethup -c “parity --chain ropsten”; ethup -c “parity”; time ethup -c “geth --rinkeby”’

Since the issues mentioned above have been opened, some interesting discussions started. While geth does not seem to have a feature allowing to stop the node once the chain has been synced, the proposal for this change has been positively welcomed and seems to be being implemented.

As far as parity is concerned, a similar feature seems to exist already but I could not get it to work. If you follow the discussion, you will however find some interesting tricks from @5chdn showing how you can start several parity nodes in parallel as long as you shift their ports to prevent conflicts. This may be a good option if you only use parity nodes.

Installing ethup is easy (you need NodeJS/npm) and you can find the full documentation at: https://github.com/chevdor/ethup

You can then immediately use it:

When the command above exits, both your kovan and rinkeby chains will be in sync.

You can now start every day in sync!