Road to Deterministic Masternodes and Systemnodes (III): The New On-Chain System
In this series of articles we have analysed the current system of non-deterministic Masternode and Systemnode lists. We conclude that this model has important limitations that could compromise network consensus, coupled with an inflexible role system. If you have not read the first two articles yet, you can do it here:
That’s why the Crown community has decided to make a push and solve these limitations. Crown Platform is moving towards Deterministic Masternodes and Deterministic Systemnodes. In this article, we present the new on-chain system.
Short explanation
In essence a system based on deterministic MN and SN proposes to keep a single, global, and onchain register of all the MNs and SNs active in the network. In other words, the blockchain will reflect the registration and the status of a given MN or SN. As the data on the blockchain is immutable, each node in the network will have access to the list of all previously registered MNs and SNs. This ensures that each member of the network can determine at anytime what is the list of active MNs and SNs, and of course, this list will coincide with the lists computed by other members of the network. In addition, this update introduces an improvement in the existing roles, and discards the use of the files (masternode/systemnode).conf.
Registration of a new Masternode or Systemnode
To register a new MN or SN in the on-chain list, the node owner must perform a registration transaction. This special transaction known as Provider Registration Transaction (ProRegTx) is part of a set of improvements introduced by Dash called DIP2. ProRegTx includes the following informations in its fields:
- The CRW address or script that will receive the node rewards. This solves the limitation that only the address of the collateral can receive the rewards.
- The “operatorReward” or portion of the rewards corresponding to the operator. If its value is 0, the operator will not receive a portion of the rewards.
- The IP address and port of the node.
When registering the node, the owner can set the IP address to “0” in case it is not known in advance. After this, the operator will set the IP field with a new update transaction. The ProRegTx also contains the output of the MN or SN collateral, and 3 public keys:
- The representative of the MN or SN owner, in other words, the public key associated with the collateral.
- The key associated with the operator, who signs the P2P messages in name of the user executing the MN or SN.
- The public voting key, used to sign the votes in the proposal system.
This model offers a greater flexibility since the owner can decide how to use the keys, like being in charge of the “voter” and “operator” functions himself, or being able to delegate these permissions to a third party. In practice, this will for example allow the owner to delegate the vote right to another user without compromising the collateral.
Each MN or SN is identified by the hash resulting from this registration transaction (ProRegTx).
Update transactions
It is clear that it is necessary to update certain fields given by the registration transaction in order to include, for example, the IP address of the MN, or the CRW address of the operator. This is achieved by entering a special transaction that will only be executed by the operator, known as Provider Update Service Transaction (ProUpServTx). This transaction is also part of DIP2.
In ProUpServTx the operator includes in the fields of this transaction the IP address of the MN or SN (if the IP address has been left at “0” as part of the registration transaction) and also in case he receives a portion of the rewards he must include his CRW address or payment script. If we take as an example a user hosting his MN or SN with a hosting provider, with this transaction the hosting provider can update the node IP address, and the address to receive the benefits in case the owner had chosen to. Thanks to this transaction, the operator can modify his own parameters and not depend on the owner.
Another type of transaction introduced in DIP2, and executed by the owner of the MN or SN is the Provider Update Registrar Transaction (ProUpRegTx). This transaction allows to update the parameters of an active MN or SN. Among the fields to be updated are the CRW reward address or the reward payment script, as well as the public key associated with the operator or the public voting key in the proposal system.
A final update transaction is the Provider Update Revocation Transaction (ProUpRevTx) and allows the operator to indicate that he will discontinue services. In other words, this transaction is only issued by the operator and would modify the parameters of the MN or SN related to the information of the operator’s services.
How the system works
It is possible to form a list of all active MNs and a list of all SNs from consulting the registration transactions and the update transactions. Therefore, with each new block it is necessary to update these lists on the basis of the registration and update transactions included in each block.
When a new registration transaction (ProRegTx) is found, the respective MN or SN is added to a set of MNs or SNs. In addition, all the information provided in the MN or SN registration is stored. If a transaction is found that spends the collateral of any of the MNs or SNs in the registry, that node is removed from the set. Next, a check is made to see if there are any update transactions (ProUpServTx, ProUpRegTx or ProUpRevTx) with reference to any node in the MN set or SN set; if any of these transactions are found, the parameters of the MN or SN in their respective set are updated. In practice this information will be stored locally (off-chain) for more efficient handling.
As part of DIP3 (another set of improvements emerged together with DIP2 to introduce the deterministic MN lists), the concept of “PoSe banned” is introduced, a category to point out the nodes of the set that no longer play the role of network validators, and therefore they should be removed from the set.
Brief summary
- DIP2 and DIP3 allow to keep a single, global, and on-chain register of all the Masternodes and Systemnodes active in the network (deterministic MN list and deterministic SN list).
- In the new system the roles behind a MN or SN have more flexibility: the operator can modify the parameters he needs without affecting the security of the owner, it’s possible to delegate the permissions to vote on proposals to another user, define a different logic to distribute the rewards, etc.
- With the ProRegTx the owner manages to register a new MN or SN and makes this information immutable on the blockchain.
- Thanks to update transactions both the operator and the owner can modify parameters of the execution of the MN or SN.
- Every user of the network can obtain the MN list and SN list on-chain from checking to the last block the registration and update transactions.
Join our channels and stay tuned to find out the exact release dates of the new on-chain system!
