Initializing the Blockchain -- Protocol for generating the Genesis block

The goal of this protocol is to produce a genesis block which can be verified as correct by early adopters of the network. Note that an important assumption in this protocol is that such users will be able to reliably learn who the initial validators are. The protocol proceeds in the following steps:

1. A bootstrap node exists and will distribute a "raw genesis" block to those that connect to it.
   1. The idea here is that out of protocol, the address of the bootstrap node was agreed upon and given to the initial set of validators. This set of validators is also decided out of protocol.
   2. The contents of the raw genesis block, including the initial validator set, their bonds and what Rholang code is deployed (this would include any Rhoc/Rev conversion info), is also decided out of protocol in advance, however this protocol provides a mechanism to ensure those agreements are upheld when the network is launched.
2. The "raw genesis" block (BlockMessage Protobuf) is communicated as part of a special message (UnsignedGenesis Protobuf) which contains additional information:
   
   1. The minimum number of signatures needed for the genesis block to become valid
   2. The timestamp this message was sent
   3. The amount of time signatures in excess of the minimum requirements will be accepted 
3. The bootstrap node will send these messages to any other node that connects to it. From the time the first message is sent, it will wait the specified amount of time for responses. After this time has elapsed, the bootstrap will check if enough signatures have been accumulated. If no then it will continue waiting for signatures, repeating the check with each new signature received. If yes, then it will send a special message (SignedGenesis Protobuf) to all participants containing the raw genesis block and the following additional information:
   1. The minimum number of signatures needed for the genesis block to be valid
   2. The signatures obtained
4. When a validator's node receives the UnsignedGenesis message, the contained BlockMessage is saved to the node data directory as a text-proto and a log message is generated that the genesis is ready for review. It is up to the user to notice this message and manually review the genesis block, as well as the number of required signatures, then use their private key (corresponding to the public key they are using as their validator identity) to sign the hash of the "raw genesis block" (which is contained in the BlockMessage) plus the minimum number of signatures (plus defined by interpreting the hash as an unsigned integer). The user passes this signature and their public key to the node via a gRPC interface, which triggers a response to be sent to the bootstrap node.
5. Once created, the SignedGenesis message will then be available to for others to obtain, thus also joining the blockchain network. A signed genesis block is valid if there are at least the minimum number of signatures, and each signature was obtained by one of the bonded validators signing in the way specified above.

Impacts on the Node software

• When starting in stand alone mode, no Casper instance is created. Instead new peers are sent the UnsignedGenesis Protobuf (will need to ask Pawel Szulc (Unlicensed) about adding in this hook). Moreover, the node will execute the signature accumulation logic. Once the SignedGenesis message has been created, it will distribute it to all peers, then create a Casper instance based on the contained BlockMessage and become a normal bootstrap node (as per how the software works today).
• An additional flag must be available to start the node in "initial validator mode". This mode must follow the behaviour of point 4 above. When the SignedGenesis block is received, a Casper instance is created from the underlying BlockMessage and normal node operating behaviour is resumed.
• When the node is started in all other conditions, it will not create a Casper instance until it has received a valid SignedGenesis block. It will query each new peer for such a message until one is received.  After getting a SignedGenesis block, it will create a Casper instance based on the contained BlockMessage and resume normal operating behaviour. TODO: revisit this behaviour with the broader idea of "weak subjectivity" in mind; the node should actually be asking about last finalized blocks and deriving a starting point based on that information.