...

Initializing the network with the genesis block

• Release the script used to create Rhoc/Rev conversion data
• Script together with validator list, can be used to create a local copy of the genesis block. This will be used by validators when approving the genesis block and thus launching the network (see protocol below)

Is there a risk of the network launching early?

• Not really. Would require most of our own chosen validators to decide to carry out the protocol below before the actual launch. Why would they do that?

Protocol for validators approving a block

An important assumption in this protocol is that such users will be able to reliably learn who the initial validators are. This assumption means that an attacker generating their own "approved block" using fake validators will not be successful as users will know that the validator set is not correct. We also assume that the block being approved, B, already exists from some other process; this protocol merely creates proof that enough validators agreed in its correctness. The protocol proceeds in the following steps:

1. A bootstrap node exists and will distribute a "raw genesis" block B to those that connect to it.
2. 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.
3. 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.
The "raw genesis" block (validators participating in this approval process know the bootstrap node address in advance and have also set up their own nodes with a copy of what they believe B and the minimum number of signatures should be. They also generate a signature based on this information and give it to the node.
4. B (a BlockMessage Protobuf) is communicated as part of a special message (UnsignedGenesis UnapprovedBlock Protobuf) which contains additional information:
   
   1. The minimum number of signatures needed for the genesis block B to become validapproved
   2. The timestamp this message was sent
   3. The amount of time during which signatures in excess of the minimum requirements will be accepted 
5. 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 ApprovedBlock Protobuf) to all participants containing the raw genesis block B and the following additional information:
   1. The minimum number of signatures needed for the genesis block B to be valid
   2. The signatures obtained
6. When a validator's node receives the UnsignedGenesis the UnapprovedBlock 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 compared with the version specified by the validator at setup. The minimum number of signatures is also compared. If they match then the signature generated by the private key (corresponding to the public key they are using as their validator identity) to sign signing the hash of the "raw genesis block" B (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 , which was given during setup is sent along with the validator's public key as a response to the bootstrap node.
7. Once created, the SignedGenesis the ApprovedBlock message will then be available to for others to obtain, thus allowing them to also joining the blockchain network. A signed genesis block An ApprovedBlock 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.

...

• When starting in stand alone mode, no Casper instance is created. Instead new peers are sent the UnsignedGenesis UnapprovedBlock 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 ApprovedBlock 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 ApprovedBlock 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 valid ApprovedBlock block. It will query each new peer for such a message until one is received.  After getting a SignedGenesis ApprovedBlock 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 informationNote that this can also be used to address "weak subjectivity" if we regularly issue newly updated ApprovedBlocks based on recently finalized blocks.