Building a Proof of Authority network with Parity

This essay is an opinion of the process to reproduce the Demo PoA tutorial on wiki.parity.io.

A Proof of Authority network is a new advancement in blockchain research created by the Parity team and coined by Gavin Wood. A big PR was created in August 2017 to merge PoA code into the Parity application. This code has since been merged and as of the build on my machine (Parity/v1.10.2-unstable-f4ae813fd-20180423/x86_64-macos/rustc1.24.1) the tutorial progressed nicely.

First impressions reminds me of previous work I’ve done with distributed computing infrastructure. Clustered database and compute platforms like Erlang OTP, CouchDB and Riak have a similar bootstrapping procedure. Cloud Native platforms like Kubernetes have a distributed key/value database called etcd that also reminds me of Proof of Authority.

The gist of the tutorial goes like this

1. Create a chain specification using the AuthorityRound engine
2. Create three accounts, one for the “authority” on each node and a single “user” for testing transactions
3. Update the chain specification to include the two addresses as validators for the AuthorityRound engine and a single blessed user with lots of fake ETH monies to spend
4. Include passwords (shared secrets) to unlock the validator accounts as a configuration file. Opinions on this later…
5. Configure the validators as each other’s miners using the engine_signer keyword with the address of the other node’s validator account, specified in the chain spec
6. Obtain the enode identifier URL for node0 and pass it to node1 as an association. In other words, inform the nodes about each other
7. Do transactions as the user account on node0

A PoA cluster mining a transaction and importing the blocks

Seven steps. Not bad for a distributed computing tutorial. Excluding the time spent compiling the Parity client from source, it took me about two hours to get this demo running while writing a few scripts to automate some of the copy + paste steps and begin the draft of this essay.

I’ve published my work at https://github.com/lazzarello/proof-of-authority-tutorial

So what makes this system different to the other distributed computing applications I’ve cited above?

A “multi-master” environment emerges from the nodes following the manual bootstrapping process. The short time where the validators are bootstrapped is the only point where the network is in a state where there are “master” nodes which have more privileges than other nodes. Once they are configured to be validators they have the privilege of putting blocks into a pool but they also contain all the features as any other node in the network. All RPC functions are available from all nodes and state will converge the same way as on any other Ethereum network.

Transactions can originate from any node and will find the path towards validation without any user intervention beyond what is expected from an Ethereum node. This messes up the “multi-master” model in my brain a little since transactions can be sent to any node, even one that isn’t a master. It’s like there is a thin multi-master distributed database as an overlay to the whole cluster that works to validate transactions.

This model is very compelling to me. It’s hands down the fastest bootstrapping process to get up and running to do smart contract dev, understand infrastructure and build Ðaaps. There is an open source project to provide a PoA network and utilities like a block explorer. There’s also protocols in development to migrate from an existing PoA chain to a different chain with a different transaction validation model, for example the Proof of Work model in the Foundation mainnet as of this writing.

On shared secrets

Bootstrapping nodes with a shared secret (aka a password) is quick for a tutorial where the reader is present to do copy and paste operations into a config file. For a decentralized network, this security model might not scale. Passing around and storing shared secrets presents a risk.

Since we are using Proof of Authority for our validators, we can borrow concepts from traditional distributed computing patterns. Part of the validation process could include a public key exchange and a signed certificate issued by the validation authority. This is a manual exchange which would require explicit trust between the validation authority and the potential new validator node.

An example from the Web 2.0 years is the Chef cloud automation platform. It uses a public key infrastructure (PKI) with validator certificates to bootstrap new nodes in a cluster. There is also an option to explicitly trust a user certificate and validate new nodes using that trust relationship. While this pattern has been adapted to the world of containers in platforms like Kubernetes, the PKI remains.

Running a node

It’s worth noting that Parity sponsors (built?) a new PoA test network called Kovan with some faucets to get ETH and try things out. As of this writing I don’t know the process to prove one’s authority and become a validator node on Kovan. Running Parity locally on Kovan is as simple as parity --chain kovan. Also as of this writing, the sync time is about 30 minutes to obtain data from 233 snapshots.

Syncing the Kovan PoA network with Parity

About 7 million verified blocks were synced to my node in 30 minutes. New blocks and transactions began flowing in immediately. This is a vast improvement over the > 2 weeks (~ 20160 minutes) required for a full archive of the PoW Foundation mainnet.

I’m excited to experiment more with Proof of Authority networks. I’ll be writing more during this process.