28 - High-Performance Masternodes#

  DIP: 0028
  Title: High-Performance Masternodes
  Author(s): Paul DeLucia, Odysseas Gabrielides, Łukasz Klimek, Ivan Shumkov, Samuel Westrich
  Special-Thanks:
  Comments-Summary: No comments yet.
  Status: Proposed
  Type: Standard
  Created: 2023-02-15
  License: MIT License

Table of Contents#

Abstract
Motivation
Prior Work
Overview
Protocol Changes
Deployment
Reference Implementation
Copyright

Abstract#

Note that the terms “High-Performance Masternode” and “HPMN” have been formally deprecated in favor of “Evolution masternode” and “evonode” as of May 2023.

This DIP is meant to introduce and describe the protocol changes necessary for implementing High-Performance Masternodes (HPMNs) into the Dash ecosystem. High-Performance Masternodes are a new type of masternode created to host Dash Platform. Dash Platform is a Web3 technology stack for building decentralized applications on the Dash network. It is built as a Layer 2 solution on top of the existing payment blockchain implemented by Dash Core. The platform consists of two services: DAPI - a decentralized HTTP API, and Drive - a separate blockchain and storage which are deployed on the High-Performance Masternodes.

Implementing High-Performance Masternodes for Dash Platform brings about a number of important advantages over using regular masternodes, with minimal disadvantages. We will briefly discuss the motivation behind their creation, their design, advantages, and disadvantages before describing the protocol changes needed for their implementation. Much of the information in this DIP was taken from the High-Performance Masternodes FAQ, which contains more details and answers to commonly-asked questions.

Motivation#

As development for the release of Dash Platform neared completion, certain drawbacks of the original plan where every masternode would host Dash Platform came to light. These drawbacks can be grouped into five main categories of concern:

The return on investment (ROI) for hosts
The fee costs for users
The system’s security
The system’s performance
The approach of requiring all masternodes to host Platform

We at Dash Core Group took these concerns very seriously and thought about the best way to remedy them with solutions that would be relatively easy to implement. As a result, we came up with the “High-Performance Masternodes” solution described in this DIP.

Prior Work#

Overview#

A High-Performance Masternode (HPMN) is like a regular masternode (MN) but with three key differences:

The collateral to own an HPMN is 4000 DASH as opposed to 1000 DASH for regular masternodes.
The recommended specs for HPMNs are higher than those for regular masternodes.
HPMNs serve Platform along with Core, while regular masternodes only serve Core.

HPMNs will provide all the services for Platform. Regular masternodes will not perform any Platform services. In Core quorums, HPMNs will act just like regular masternodes. In the DAO, they will have 4 times more voting power due to their collateral being 4 times greater.

HPMNs will receive 100% of the fees generated from Platform and 37.5% of the masternode portion of Core block rewards. Regular MNs will receive the remaining 62.5% of the masternode portion of Core block rewards and 0% of Platform fees.

Because the reward distribution percentages are fixed, the number of HPMNs is expected to stabilize around a fixed number based on the total number of masternodes (considering the current number of ~3850 Masternodes, ~450 HPMNs are expected). This is because if there are more than that fixed number of HPMNs, running a regular MN will be more profitable than running an HPMN, and hosts will convert their HPMNs into MNs. This also works in reverse. We call this mechanism the yield equilibrium, and it is one of the key factors that make this solution work so well, as will be made clear in the Advantages section.

Advantages#

The High-Performance Masternodes solution addresses all of the concerns outlined in the Motivation section. Going down the list:

The ROI for hosts. With the HPMN solution, the ROI for regular masternodes will remain about the same as they were before Platform, while they would have decreased significantly under the original plan. This is because masternodes would have been incurring much greater costs with diminished returns. While the cost of hosting a Platform node goes up by about 4x with this solution, the number of nodes goes down by about 9x due to the yield equilibrium described earlier. The result is that Platform fees are distributed to a smaller number of nodes, and their ROIs increase. The ROI increase spills over to regular masternodes as well due to the yield equilibrium.
The fee costs for users. Another result of the 9x decrease in the total number of nodes hosting Platform is that user fees will also decrease by 9x.
The system’s security. With HPMNs, both Platform and Core become more secure. Platform becomes more secure because the higher collateral makes it harder to gain enough nodes to have a chance to halt the chain or censor blocks. The more performant nodes can also handle higher loads, providing greater protection against DDoS attacks. Core becomes more secure because it is not dependent on Platform nodes and will therefore be unaffected by a potential bug in Platform.
The system’s performance. HPMNs are expected to be more performant than regular masternodes due to the higher recommended specifications, and therefore they are expected to yield higher transaction throughput. Nodes lacking sufficient resources will not be competitive, will miss out on rewards, and end up with a very weak ROI. We expect this to adequately incentivize higher performance of individual nodes and, therefore, the entire system.
The approach of requiring all masternodes to host the system. Since Core nodes and Platform nodes are separate, hosting Platform becomes optional.

Disadvantages#

The main disadvantage of this solution is that the collateral required to host an HPMN, and therefore Platform, is increased from 1000 DASH to 4000 DASH. This means some current masternode owners will only be able to host a regular masternode. Some have also expressed concern that this increase in collateral and decrease in the number of nodes will lead to centralization issues. We will address both of these concerns now.

First, the centralization concern is understandable, but we do not share it. The following will explain why. A higher node count is not always a good thing. For example, users must pay fees to compensate every node hosting the network - the number of nodes is a direct multiplicative factor in the fee cost calculation. With 9x more nodes, user fees are 9x higher. Also, under the HPMN solution, there is still only a 0.015% chance per year that the current top whale would get enough of their nodes in a Tenderdash validator set to halt the chain or censor blocks for an hour. Although that number is higher than the old plan, it is still a minuscule number, and the consequences are limited. A halted chain can be restarted, and having a 0.015% chance that blocks will be censored for one hour out of an entire year is not significant considering the solution’s many benefits.

Regarding some current masternode owners being unable to host a Platform-supporting masternode, we expect node-sharing services to enable participation by hosting a fraction of a Platform node in the future.

Protocol Changes#

Previously, the Deterministic Masternode List (DIP-3) only contained fields necessary for a masternode’s Dash Core services: its IP address and the Core peer-to-peer (P2P) port.

Drive and DAPI expose additional ports that should be discoverable by light clients and other HPMNs to ensure connectivity to the network. Making these settings configurable enables more flexible masternode deployment architecture scenarios, like:

Supporting application-layer firewalls in front of the Masternode
Reducing IPv4 address demand using NAT (network address translation) / PAT (port address translation) techniques
Providing easier deployment in virtual environments

Added Dash Platform Fields#

Platform HTTP port#

Clients use the HTTP port to establish connections to public APIs provided by Platform, including:

JSON-RPC
gRPC
gRPC-Web

Default HTTP port: 443

Platform P2P port#

The Platform P2P port is used by the platform consensus engine for internal communication between Platform nodes. Validators must be able to determine the P2P port in order to directly establish deterministic connections between themselves, in the same way as described in DIP-6 for Long-Living Masternode Quorums.

Default P2P port: 26656

Platform Node ID#

The Node ID is a platform node identifier derived from a public key that is used to secure the consensus engine connectivity over the Platform P2P port. In addition, it is used to authenticate peers when establishing a peer-to-peer connection.

For non-validators, the Node ID can be discovered using the PEX (Peer Exchange) protocol; however, the PEX protocol cannot guarantee peer node ID discovery when establishing the deterministic connection to a new, unknown peer.

Calculating the platform Node ID#

platformNodeID MUST be derived from an ED25519 key (“P2P key”). P2P key SHOULD be generated and stored securely for future use.

P2P key MAY be generated using key derivation, in accordance with BIP-32, BIP-44, and SLIP-10. The key derivation path SHOULD adhere to DIP-9, with feature 3’ and subpath 4’/* (for example, m/9’/5’/3’/4’/0’).

platformNodeID is the first 20 bytes of SHA256 checksum of the public part of the P2P key (SHA256-20). The following pseudocode represents the generation algorithm:

hash :=sha256(publicKey)
platformNodeID := hash[0:20]

Tenderdash contains a reference implementation of P2P key pair and platformNodeID generation. The tenderdash gen-node-key command generates and displays a node ID (the “id” field) and P2P private key.

Managing Masternodes#

The following section details changes made to DIP-3 to support HPMNs.

New Masternode Type#

To distinguish an HPMN from a regular masternode, a new masternode type (1) is defined. Masternode type 1 requires a 4000 DASH collateral.

Changes in ProRegTx#

A ProRegTx with masternode type 1 indicates registration of a 4000 DASH collateral HPMN.

If the version is 2 and the type is 1, then the platformNodeID, platformP2PPort, and platformHTTPPort fields are serialized in that order between the inputsHash and payloadSigSize fields.

Field	Type	Size	Description	Serialized
platformNodeID	byte[]	0 or 20 bytes	Dash Platform node ID, derived from P2P public key. Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.
platformP2PPort	uint_16	0 or 2 bytes	TCP port of Dash Platform peer-to-peer communication between nodes (network byte order). Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.
platformHTTPPort	uint_16	0 or 2 bytes	TCP port of Platform HTTP/API interface (network byte order). Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.

Changes in ProUpServTx#

Since the ProUpServTx does not currently include the type field, version 2 of the transaction adds it and serializes it right after the version field. A ProUpServTx of masternode type 1 indicates an update registrar of a 4000 Dash collateral HPMN.

Also, if the version is 2 and the type is 1, then the platformNodeID, platformP2PPort, and platformHTTPPort fields are serialized in that order between the inputsHash and payloadSig fields.

Field	Type	Size	Description	Serialized
type	uint_16	0 or 2 bytes	Masternode type. 0 for regular masternode, 1 for HPMN.	Only when `version` is 2.
platformNodeID	byte[]	0 or 20 bytes	Dash Platform node ID, derived from P2P public key. Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.
platformP2PPort	uint_16	0 or 2 bytes	TCP port of Dash Platform peer-to-peer communication between nodes (network byte order). Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.
platformHTTPPort	uint_16	0 or 2 bytes	TCP port of Platform HTTP/API interface (network byte order). Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.

Added validation rules#

The following new ProRegTx rules are added and are only applicable when type is 1:

collateralOutpoint hash is not null and collateralOutpoint index references a 4000 DASH output in the ProRegTx
collateralOutpoint hash is null and a 4000 DASH output is found in the UTXO specified by the hash and n

The following new rules are added for both ProRegTx and ProUpServTx and are only applicable when type is 1:

platformP2PPort and platformHTTPPort MUST be valid port values [1, 65535]
platformP2PPort, platformHTTPPort, and port from ipAddress MUST be distinct
For mainnet HPMNs, platformP2PPort and platformHTTPPort MUST be set to the default values
- Default Platform P2P port: 26656
- Default Platform HTTP port: 443
platformNodeID MUST be a non-empty Hex string
platformNodeID MUST be unique network-wide

Changes in Masternode Rewards#

Since HPMNs have 4 times more collateral than regular masternodes, it would not be fair to keep the masternode rewards as it is. Therefore, HPMNs will be paid in four consecutive blocks each time they are selected for payment.

The following steps precede the existing algorithm described in DIP-3:

Find the previous masternode payee. If the last payee is a regular masternode, go to step 5.
If the last HPMN payee was already paid 4 times, go to step 5.
If the last HPMN is no longer present in the current masternode list, go to step 5.
Select the last HPMN as payee and increment its consecutive payment state by one. Skip the remainder of the algorithm since the payee has been located.
Continue with the current algorithm.

Simplified Masternode List entry#

Light clients use the Simplified Masternode List (SML) entry structure described in DIP-4 to obtain and verify the Deterministic Masternode List (DML). Since light clients connecting to Platform are expected to use the HTTP API rather than P2P connections, P2P information is not required in the SML.

There are two important changes related to the SML. First, to be backward compatible with old clients, a version field is added to the MNLISTDIFF message between cbTx and deletedQuorumsCount starting from protocol version 70225:

Field	Type	Size	Description
version	uint_16	2	Version of the `MNLISTDIFF` reply

Second, in the case of version 2 MNLISTDIFF messages, all SML entries will contain a new type field describing the type of the corresponding masternode. The type field is serialized after the isValid field. If the type is 1 (HPMN) then the platformHTTPPort and platformNodeID fields are serialized after the type field.

Field	Type	Size	Description	Serialized
type	uint_16	0 or 2 bytes	Masternode type. 0 for regular masternode, 1 for HPMN.	Upon activation of this DIP. Only when `version` is 2.
platformHTTPPort	uint_16	0 or 2 bytes	TCP port of Platform HTTP/API interface (network byte order). Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.
platformNodeID	byte[]	0 or 20 bytes	Dash Platform node ID, derived from P2P public key. Only present for masternode type 1.	Only when `version` is 2 and `type` is 1.

Changes in calculating the Merkle root of the Masternode list#

New blocks will contain the merkle root of the masternode list based on the above changes.

Long-Living Masternode Quorums#

The following changes are made to DIP-6 to support HPMNs.

Changes in the DKG Initialization phase#

On mainnet, the existing LLMQ_100_67 is designated for Platform use. This DIP introduces the following special logic for the initialization phase of this LLMQ only:

Retrieve the deterministic masternode list that is valid at quorumHeight
Keep only the HPMNs
Continue with current step 2 of the existing algorithm

New LLMQ Type#

Name	quorumType	quorumSize	quorumMinSize	quorumThreshold	quorumDkgInterval	quorumDkgPhaseBlocks	quorumDkgBadVotesThreshold	quorumSigningActiveQuorumCount	Notes
LLMQ_TEST_PLATFORM	106	3	2	2 (67%)	24 (1 Hour)	2	2	2	For testing only (regtest)
LLMQ_DEVNET_PLATFORM	107	12	9	8 (67%)	24 (1 Hour)	2	7	4	For devnets only

Changes in Governance votes#

Weighted vote#

All HPMN votes will have a weight of four compared to one for regular masternodes. This weight is based on the amount of collateral for each type.

Deployment#

This DIP will be deployed by “version bits” BIP-9 with the name “v19” and using bit 8.

Reference Implementation#

High-Performance Masternodes are implemented in Dash Core v19.0. The initial implementation is available at dashpay/dash#5039.