Learn RCon3

RChain test net genesis ceremony

On September 5th, validators from around the world convened in Berlin, Germany to launch the test net. More precisely, they launched the first of several test nets that will be run between now and early 2019 when the “Mercury” main net launches.
While the node software has been tested and debugged routinely over the past several months, this is the first worldwide network that is intended to run continuously. So it is also the first time the RChain community has created and agreed upon a genesis block.

Bootstrapping consensus

A live RChain network uses a Casper proof of stake algorithm to make sure all the validators form consensus over the block DAG. Casper is a brilliant game in which validators sign off on which block they believe comes next in the DAG and lose money if they ever get caught cheating. Casper is so important that the smart contract in charge of running it goes directly in the genesis block.
But if Casper can’t start until we have a genesis block, then how can we ever agree on a genesis block? It turns out the best way to do that is the old fashioned way. Meet people face to face, work together, build trust, and then all agree to sign off on a particular genesis block.
The genesis block contains these key features which everyone must agree on.

  1. Time stamp
  2. Minimum number of signatures
  3. Wallets
  4. Bonds (for initial validators)

How the protocol works

Once all of the good old fashioned discussion about the parameters above is completed, the genesis ceremony can begin. If all goes well, the process executes according to a script that does the following.

  • One validator, known as the “standalone node”, creates a genesis block and sends it to all the other validators.
  • Each validator compares the genesis block to the one they expected based on the prior agreement. If everything looks correct, the validator signs the block and sends it back to the standalone node.
  • The standalone node collects signatures for a predetermined (but unliaterally chosen) amount of time. If the minimum number of signatures is reached when the time runs out, the genesis block becomes official, and the network launches successfully.

The responsibility of validators

The validators are the only thing that keep the network secure and decentralized. Their duty is to carefully inspect the genesis block that the standalone node proposed. They should check every RHOC balance, every validator public key, and every bond amount to ensure that the standalone node is not trying to trick anyone. Only then should they cryptographically sign the block. If the network is to be secure, validators must not sign any old block candidate that comes their way.
Luckily the RNode software automates nearly all of this process. The human node operator merely has to supply her own correct bonds, wallets, timestamp, and minimum signatures, and RNode will do all the tedious comparisons. But this means that the node operator must take care to supply correct wallets and the correct bonds of the validators they’ve met. The one thing a validator must never do is sign any old block they never checked over.

Looking forward

There will be a few more releases of RNode before main net, which will bring exciting features such as a name registry in node 0.7. Sharding will come in node 0.8, and perhaps the node 0.7 test net can live on as a child shard of the node 0.8 test net. It’s been suggested that such a relationship may form between Mercury and Venus in the main net.
For each release, validators will once again practice this genesis process. By the time main net launches in early 2019, launching a network will be second nature.
If you’re interested in becoming a validator, join the co-op, and follow the #node-testing channel on Discord.