The Dash Core team has announced an upcoming major overhaul to the masternode system by introducing deterministic masternode lists, which will enable a variety of improvements to the masternode structure as well as previously unsupported special features on mobile devices.

In a blog post released this week by Alexander Block, Dash Core announced three new Dash Improvement Proposals (DIPs): Special Transactions, Deterministic Masternode Lists, and Simplified Verification of Masternode Lists (DIPs 2, 3, and 4, respectively), to improve the way masternodes are queried by the network:

“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 upcoming changes plan to simplify the way a list of masternodes is accessed by the network by separating their form of identification from a single key, which is how the system works now. While seemingly 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.

Assinging three different masternode roles to improve management

In order to allow for the new deterministic listing for masternodes, new roles will be introduced for masternodes, allowing different functions of a single node to be managed by separate keys, and therefore separate entities:

“In the new system, we recognize and assign three different roles. Each of these roles has its own keys and each of these can only perform a subset of actions and updates on the masternode metadata. 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.

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.”

These 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, facilitating trusting a hosting service, as well as setting up automated payments from a portion of the masternode rewards. Additionally, separating a voting key can allow masternode owners to delegate voting rights to another party without also granting access to other functions such as running the node.

Improvements for SPV clients, including allowing PrivateSend to be used trustlessly on mobile

In addition to streamlining the masternode setup, the new improvements will address some challenges currently facing simple payment verification (SPV) clients”

“In the current/old system, SPV clients are not able to verify the masternode list. The reason for this is that they would need to verify the collateral UTXO of each masternode, which can only be done on the full chain.”

Because of the deterministic masternode lists, now mobile clients will be able to access the masternode list more easily, enabling special features such as PrivateSend anonymous transactions to be used on mobile without trusting a third party:

“This change will have some nice effects in the Dash ecosystem. It will allow SPV clients (including mobile clients) to use advanced Dash features like PrivateSend and receival/verification of InstantSend (sending does not require the masternode list). It is also the basis for future, Evolution related features on SPV clients.”

Presently, no cryptocurrency with advanced privacy offerings works on mobile devices natively. Because of how mobile wallets communicate with nodes, transmitting payment information privately has been a difficult problem to solve, especially with coins that employ encryption-based privacy offerings. Deterministic masternode lists may allow Dash to be the first coin to perform this function privately on mobile devices without needing to trust a full node.