Building an Ethereum Playground with Docker (part 1 — Introduction)

I have updated this article on December/2017. I no longer create a custom Docker image, because Ethereum official image already brings an "all-tools" version that includes bootnode and other treats.

This is the first article in an ongoing series "Building an Ethereum Playground with Docker". The articles already published are:

We will cover using the official "ethereum/go-ethereum" Docker image, playing with Ethereum Wallet, provisioning the ethereum nodes on public clouds and deployment of a sample app.

Introduction

Both blockchain and Docker are technologies that have been under a lot of hype for a few years now.

Docker itself is already past-hype and has become the de facto standard for containers — and containers are now the standard for pretty much everything on software development and delivery (unless, of course, you have been hiding in a cave).

Blockchain, on the other hand, is yet to deliver the wonders it is praised for. Beyond Bitcoin and its variants, blockchain technology can be used in several other scenarios (like digital property, voting, identity management, to name a few). In fact, from an entrepreneur point of view, a blockchain network can be seen as a platform for crafting a whole new set of products.

BTW, these articles assume some understanding about blockchain technology and will not try to explain it in any way.

Enter Ethereum

The Ethereum network was built to deliver the platform concept, not focusing on the digital currency aspect like the Bitcoin network does. Quoting Ethereum documentation:

Ethereum is an open blockchain platform that lets anyone build and use decentralized applications that run on blockchain technology.

So one can actually see an Ethereum network as a platform for running decentralized applications — and indeed it is such a thing. The blockchain technology allows this platform "…extreme levels of fault tolerance, ensures zero downtime, and makes data stored on the blockchain forever unchangeable and censorship-resistant".

Indeed a rich ecosystem of apps (or "dapps", that stands for "distributes applications") is flourishing on the Ethereum network.

Wait: is it "the network" or "a network"?

This question can be rephrased: is there a single blockchain Ethereum network ("the" network) or a plethora of networks? Well, both.

There is The Ethereum blockchain network, public and controlled by no one in particular. Well, actually there is also The Ethereum "classic" network, but that is another story.

Unlike a regular cloud computing platform where you "own" (control and trust) the nodes that execute your applications, a public blockchain network is quite the opposite: it is entirely composed of untrusted participants that build consensus in a trusted way (thanks to the blockchain). So the meaning of public is that anyone can read it, transact with and participate in the consensus process (just install the Ethereum Wallet and voilà) — the decentralization actually adds to its value.

This is somewhat hard to understand: nobody "owns" all of the network's nodes, but since Ethereum developers need to improve their software and protocol everybody agrees on updating the software from time to time. So there are soft forks and hard forks, but the whole point is to preserve the network's value while evolving its software.

Since Ethereum is open-source software nothing stops anyone from starting a new public network — it just doesn't make sense to do so. From a technical point of view blockchain networks differ only on their genesis block, algorithm and protocol but a public network's value relies intrinsically on widespread use.

Private networks, on the other hand, can be spun at will for any purpose that comes to mind (there are actually many valid use cases). Once again, just create a new genesis block, start a set of nodes and put them to work.

It is very easy to stumble upon heated discussions on whether private blockchain networks actually make sense or not (why use a decentralized and inefficient solution if you actually trust the participants), but from a developer point of view it is very desirable to be able to create and blow away a platform — several times a day. This is the point of this series of articles.

Why Docker?

Seriously? Call me a fanboy, but nowadays one would actually have a hard time to explain why not to use containers.

The next article in this series will discuss provisioning an entire private Ethereum network — locally or on a public cloud — relying on containers. Despite the fact that there are several offers around for ethereum-vms provisioning (like Azure's Blockchain as a Service offerings), going the container way is always a wiser choice. During the time it take to re-provision an Azure set of VMs (even with automated scripts) you can restart or recreate a Docker swarm several times.