Creating the genesis block

The bootstrap node and each of the genesis validators will all create their own copies of the genesis block and confirm they are all the same during the approved block creation protocol (see Initializing the Blockchain -- Protocol for generating the Genesis block). This page describes the inputs needed to produce the genesis block. If all nodes use the same input, they will all get the same genesis block output.

The Genesis Deploys Timestamp

The timestamp on a deploy is used to seed the random number generator used in the tuplespace for creating unforgable names. In order for all nodes to get the same genesis block they need to have the same random number state and therefore need to use the same timestamp in the deploys which go into the genesis block. These deploys contain the "blessed" contracts that help to run the system. Since this piece of data essentially only effects the hash of the genesis block and not its semantic content, this can be used to distinguish the "real" genesis block created during official launch events from those created by others trying to launch the network early. The timestamp to be used can be given out arbitrarily close to the launch event because it has no semantic impact on the block.

The Bonded Validators

This is a list of public keys together with bond amounts. This list is used to instantiate the proof of stake contract with the initial set of validators. At the time of writing keys need to be ED25519 public keys. This file input is created in collaboration with those that have chosen to become validators at genesis. Each of them provides a public key together with an Ethereum address where some RHOC is held (see the next section for more details), which will be used to determine the initial stake amount for that validator.

The RHOC/REV Swap ("Wallets File")

This is a list of public keys together with the algorithm used to verify signatures (Secp256k1 or ED25519) and a REV balance. Each of these is turned into a "BasicWallet" which exists at the name "@`rho:pubkey:${w.algorithm}:${w.pk}`" and can be accessed using the private key corresponding to the given public key. This input is to be generated from a script which scrapes Ethereum for addresses with RHOC holdings at a given block height. Therefore, the block height is in a sense the real input to the genesis block. Note that in order to avoid duplicate issuance it is required that addresses being used for bonding a genesis validator (see previous section) must not be included in the wallets file. This means some filtering of the output from the script will likely need to occur. Development of this script is being tracked in RHOL-601.