ethup
Syncing of multiple Ethereum nodes
Intro
In order to interact with the Ethereum Blockchain and the best levels of security, one need to first have a running node that is fully synchronised. With the increasing traffic on Ethereum, this is becoming more and more difficult for regular users to stay in sync. This article introduces ethup, a simple tool that aims at doing just that.
ethup can be found on github at: https://github.com/chevdor/ethup and has been published on npm.
Server vs Casual User
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:
- the ability to reduce the amount of data stored locally
- speed up the synchronisation using frequent snapshots that client can securely share among them
- compress the data going over the network
- to support ‘light’ clients that can work without downloading the full blockchain
- splitting clients and UI
Most of those improvements are barely noticed by users but often the result of very clever optimisations.
Light clients
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.
ethup
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:
- https://github.com/paritytech/parity/issues/8244
- https://github.com/ethereum/go-ethereum/issues/16400
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.
Installation
Installing ethup is easy (you need NodeJS/npm) and you can find the full documentation at: https://github.com/chevdor/ethup
$ npm install -g ethupYou can then immediately use it:
ethup -c "parity --chain kovan" && ethup -c "geth --rinkeby"When the command above exits, both your kovan and rinkeby chains will be in sync.
You can now start every day in sync!
