In order to improve the masternode structure and introduce several new features on mobile devices, the Dash cryptocurrency team has announced a revamp of the masternode system through the introduction of deterministic masternode lists.
Three new DIPs (Dash Improvement Proposals) have been announced by Alexander Block, core developer at Dash, to improve the way masternodes are queried by the network. They are Special Transactions (DIPs2), Deterministic Masternode Lists (DIPs3), and Simplified Verification of Masternode Lists (DIPs4).
Deterministic masternode lists
Deterministic masternode lists are masternode lists which are fully derived from on-chain data. DIP2 & DIP3 introduce new transaction structures & specific types that allow the network to register and update masternodes on-chain. As other nodes will derive their masternode lists from these on-chain transactions, all nodes will come to the same consensus regarding the currently valid masternode list.
The proposed changes, once implemented, will simplify the manner in which the network gains access to a list of masternodes. Even though it appears to be a simple improvement, implementing DIPs 2-4 will constitute a major overhaul of the network structure and will enable many special features, both for managing and operating masternodes and for mobile/light wallet clients.
Currently, a masternode owner has to create a 1000 Dash collateral and configure his local wallet to reference the masternode IP, collateral UTXO and private key of his masternode. At the same time the masternode has to be configured to run with the masternode private key.
For the masternode to start, the owner should issue a “masternode start-xxx” command to announce it to the network. Every time the masternode is down for too long, or when an update is needed, the owner would need to issue a new “masternode start-xxx” command.
Deterministic masternodes system (new)
In the new system, the masternode is created by sending a special transaction (ProRegTx) to the network. This transaction contains the necessary metadata (IP, public keys, reward addresses, …) and also moves the 1000 Dash collateral to a new address. After this transaction is mined, the masternode is added to the masternode list and is immediately expected to be functioning (no “masternode start-xxx” command needed). Other special transactions (ProUpRegTx, ProUpServTx) may then be used to update the metadata of the masternode.
Assigning different masternode roles
Under the new system, masternodes will have new roles, which will allow different functions of a single node to be managed by separate keys, and therefore separate entities. This will effectively achieve the deterministic listing for masternodes.
The three roles are:
1. Owner: This is the owner of the 1000 Dash collateral. The owner is allowed to modify the payout address for rewards and delegate operational and voting rights to other people.
2. Operator: This is the operator of the masternode. The operator can only modify the IP and operator reward address.
3. Voter: This is the person who is allowed to vote on behalf the masternode. He cannot modify any of the masternode metadata.
According to Alexander Block
“The three roles are internally differentiated by the associated public keys, which are specified in the registration transaction. If all keys are set to the same, it means that the owner is also the operator and voter. If different keys are used, it implies delegation of roles to other keys and/or people. If any key is unassigned (zero), the transaction is invalid.”
The proposed improvements to the masternode setup reduce the amount of trust needed for a masternode collateral holder to place in an operator to help run the node. This enables trusting a hosting service, as well as setting up automated payments from a portion of the masternode rewards.
In the current system, SPV clients are not able to verify the masternode list. Furthermore, the network traffic required to to keep the masternode list up-to-date is not very mobile friendly. DIP4 introduces a way for SPV clients to retrieve and verify the full masternode list.
This change will allow SPV clients (including mobile clients) to use advanced Dash features like PrivateSend and receive/verification of InstantSend.
The manner in which mobile wallets communicate with nodes has made it difficult for transmitting payment information, privately. With the introduction of Deterministic masternodes, Dash may become the first cryptocurrency to perform this function privately on smart phones, without a need to trust a full node.