Ethereum Client Platforms: Parity versus Go-Ethereum
The next step in the Ethereum world, after mastering the basics of the Solidity language and the smart contract development, is about developing simple production applications. The key ingredient here is client software. In this article, I review parity, the newer client software layer, and compare it to geth, the product of the Homestead project.
What does the client software do? It downloads the whole blockchain onto your system on a regular basis, keeping the tab on the whole network. It verifies all transactions and contracts on the blockchain. If you are building your own contracts, it broadcasts them to the network so that they are included in the next block and confirmed by the miners. Client software can also do the mining but these days you may need a super-computer do make any ether this way.
With both clients, I recommend downloading the source and compiling the code. The code changes so often than any binaries are already old when you get to them. The situation is complicated by multiple spam attacks on the Ethereum blockchain, including "from Shanghai with love" https://www.infoq.com/news/2016/09/Ethereum-DOS-Attack and https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/, https://blog.ethereum.org/2016/10/13/announcement-imminent-hard-fork-eip150-gas-cost-changes/. There is no such thing as stable geth or parity clients so the latest commit is the best call.
What does the client software do? It downloads the whole blockchain onto your system on a regular basis, keeping the tab on the whole network. It verifies all transactions and contracts on the blockchain. If you are building your own contracts, it broadcasts them to the network so that they are included in the next block and confirmed by the miners. Client software can also do the mining but these days you may need a super-computer do make any ether this way.
Why is this important? In order to successfully integrate blockchain transactions into a real-world application, a reliable client layer is needed. Just using https://etherscan.io/ or another chain scanner for the back-end would be to defeat the purpose of blockchain, a verified decentralized transaction ledger. Differently coded, independently running clients only can provide the robustness, or "antifragility" (@nntaleb) of the blockchain.
With both clients, I recommend downloading the source and compiling the code. The code changes so often than any binaries are already old when you get to them. The situation is complicated by multiple spam attacks on the Ethereum blockchain, including "from Shanghai with love" https://www.infoq.com/news/2016/09/Ethereum-DOS-Attack and https://blog.ethereum.org/2016/09/22/transaction-spam-attack-next-steps/, https://blog.ethereum.org/2016/10/13/announcement-imminent-hard-fork-eip150-gas-cost-changes/. There is no such thing as stable geth or parity clients so the latest commit is the best call.
Configuring the computer
Both geth and parity require 2-4GB of RAM and 50-100GB of hard drive space for storing the blockchain. And both require extensive memory so ~4GB swap needs to be set up. By default, the Digitalocean Ubuntu cloud computers come with no swap space. A great instruction is here: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04. Adding a 4GB swap file, which is running on a fast SSD drive, helped to move the synchronization forward.
It is important to sync the clock on the system. A wrong time can seriously impact the peer communications.
Installing and running geth
First step is to run the standard installation that takes care of all dependencies.
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository -y ppa:ethereum/ethereum
$ sudo add-apt-repository -y ppa:ethereum/ethereum-dev
$ sudo apt-get update
$ sudo apt-get install ethereum
The next step is to install the most recent commit:
$ git clone https://github.com/ethereum/go-ethereum
$ sudo apt-get install -y build-essential libgmp3-dev golang
$ cd go-ethereum
$ make geth
$ build/bin/geth --datadir /mnt/volume=nyc1-01/.ethereum/
Installing and running parity
First step is to run the standard installation that takes care of all dependencies. I used the following command - this could be obsolete by now but googling can help.
bash <(curl https://get.parity.io -Lk)
The second step is to download and compile the source code.
$ git clone https://github.com/ethcore/parity
$ cd parity
$ cargo build --release
$ ./target/release/parity -j --db-path /mnt/volume=nyc1-01/./parity/ --cache-size-db 1024
Unlike geth, parity does not include any console tools. However, node/npm can be used:
$ npm install web3
$ node
>> var Web3 = require('web3');
>> var web3 = new Web3();
>> web3.setProvider(new Web3.providers.HttpProvider('http://localhost:8545'));
>> web3.eth.syncing
Process control
Regular crashes and hang-ups are expected in this space. I set up Supervisor (supervisord) to automatically start and restart both parity and geth.
Goal and results
The goal of running these clients is to have an up-to-date copy of the blockchain on the computer at all times. Go-Ethereum and Parity were both executed on two copies of Ubuntu installation on the third-cheapest option of Digitalocean cloud box, with an attached 100GB separate SSD (the one provided by default has only 20GB, which is insufficient for any real Ethereum work).
What are the conclusions? Both clients seem to struggle to stay up-to-date. It takes about 12 hours on to fully synchronize on parity and about a day to do the same in geth. As more and more complex contracts have been added to the chain, the later blocks are very heavy to process. Both clients required extensive baby-sitting to get them to work - crashes and hang-ups happen all the time.
Abstracting from the technical details - what does this all mean for the future of Ethereum?
Abstracting from the technical details - what does this all mean for the future of Ethereum?
1. Scalability limits. What are the practical limitations of Ethereum and how they can be managed? Obviously, in the current stage, Ethereum will not be able to handle the kind of transaction volume that takes place on a payments or transactions network. We need to be able to reliably share the workload across the network. Some people talk about sharding the data, some people talk about removing the decentralization concept by having permissioned ledgers - the jury is out on what may be the solution. It is also possible to use Ethereum for projects that do not require such massive scale.
2. Need for software diversification. If the same software is used by all network participants, pure software level attacks can be very successful at disabling the network. An example is a purposefully buggy contract that somebody created during the Shanghai developer conference. The Ethereum developers had to scramble to deliver a fix for that contract. The chance of one software problem affecting a significant number of peers will be reduced if multiple teams of coders work on different client software independently.
3. Heavy computing demand. Should Ethereum be widely used, quite heavy requirements for the participating computers, or peers! Running multiple network connections at the same time, performing public key cryptography calculations, and saving the transactions from the whole world on one local computer is the day-to-day reality of the Ethereum client. There is no way one mobile device or a small laptop can handle that amount of work, and that is where cloud computing comes in. In order for the Ethereum platform to remain decentralized and, by inference, reliable, the participants will need to run multiple cloud systems and the light clients will need to connect to a computer "on the cloud" (or, at least, a big system in your bedroom, basement or garage). In order to be useful in the real world, Ethereum must scale well, something that many people are thinking about.


Comments