Road to Deterministic Masternodes and Systemnodes
Part One: On the Current non-deterministic System
In the MNPoS consensus system introduced by Crown, both Masternodes (MN) and Systemnodes (SN) work as full nodes, verifying all transactions broadcasted through the network and fulfilling the role of servers with a copy of the whole chain, synchronized 24/7. Additionally, both types of nodes are responsible for creating new blocks with transactions and adding them to the blockchain. In fact, only MNs and SNs can perform the Proof of Stake (PoS) in Crown. Masternodes have the additional responsibility of participating in the governance (Crown Decentralized Governance Proposal System), where 1MN is equal to 1 vote. Also they are in charge of processing InstantX transactions.
Of course, it is easy to deduce the importance of both types of special nodes for the proper running of the network, and obviously the consensus: the more MNs and SNs are active, the more secure the network will be.
To run a MN or SN on Crown, it is necessary to “lock” a collateral amount (10.000 CRW for MNs and 500 CRW for SNs), by a single UTXO. That is, to be considered an active node, it is necessary to associate a CRW address that has a collateral amount of 10.000 or 500 CRW.
When the MN or SN is created, it is pointed to the input that contains the collateral fund, in this way the address that will activate the node is specified, whose private key allows moving the collateral. The user who holds this private key will be the “owner” of the node. At the same time, a second private key (mn/sn-key) is created, which will be used to sign the messages to be distributed over the P2P network. But whoever knows this second key will not be able to spend or unlock the collateral fund.
This system allows running a node for two client roles on two different machines: the “hot” one who will sign the input, and would know both keys; and the “cold” client who would only know the second key and would execute the node. In this way the collateral fund would not be compromised, and the “hot” client could remain disconnected from the network. In practice, the “hot” client is known as the mn-sn owner, and the “cold” client as the mn-sn operator.
At this point in the initial configuration, the “hot” client should modify the local (masternode/systemnode).conf file and start the node using the masternode start alias command. By this way, a message is sent to the P2P network, including the UTXO of the signed collateral, the public key, the public key of the second key, an IP address, and other fields. Periodically a Ping message is sent to verify if the node is active (all MN/SN must have their ports open). This message includes the UTXO of the collateral, and a signature using the second key (mn/sn-key). This way everyone can know the active nodes in the network. In case the associated collateral is moved or spent, or the MN/SN interrupts its function as a validator in the network, the node will no longer be considered an active MN/SN by the rest of the users.
Each full client on the Crown network stores a cache object with the active MN/SNs it knows and their status. Each new client that joins the network sends a command to the P2P network peers that are directly connected asking for the list of MN/SNs that the other knows. Therefore, the composition of this list depends on the peers and the messages. It is not always the case that all the network’s clients have the same MN/SN list. In other words, the list of MNs and the list of active SNs is non-deterministic (there is no single list known by everyone). The moment of synchronization of both lists occurs after the client is fully synchronized with the blockchain.
Brief summary
- Masternodes and Systemnodes play a key role in Crown´s consensus system.
- The MN/SN have an owner, who owns the collateral associated to the node, and an operator, who executes the node, but without access to the owner’s funds.
- The network knows the active MN/SN through a system of P2P messages, signed by the user who executes the node.
- The list of all active MN/SN of the network is not unique and will depend on the peers connected and the messages received. This is called a non-deterministic MN/SN list.
Stay tuned for Part Two of the Road to Deterministic Masternodes and Systemnodes series and join our channels for further discussion.
