28 - Evolution Masternodes#

  DIP: 0028
  Title: Evolution 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#

This DIP is meant to introduce and describe the protocol changes necessary for implementing Evolution masternodes (evonodes) into the Dash ecosystem. Evolution 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 Evolution masternodes.

Implementing Evolution 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 Evolution Nodes 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 “Evolution masternodes” solution described in this DIP.

Prior Work#

Overview#

An Evolution masternode (evonode) is like a regular masternode (MN) but with three key differences:

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

Evonodes will provide all the services for Platform. Regular masternodes will not perform any Platform services. In Core quorums, evonodes 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.

Evonodes 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 evonodes is expected to stabilize around a fixed number based on the total number of masternodes (considering the current number of ~3850 Masternodes, ~450 evonodes are expected). This is because if there are more than that fixed number of evonodes, running a regular MN will be more profitable than running an evonodes, and hosts will convert their evonodes 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 Evolution masternode solution addresses all of the concerns outlined in the Motivation section. Going down the list:

The ROI for hosts. With the evonode 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 evonodes, 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. Evonodes 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 evonode, 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 evonode 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 evonodes 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 evonodes.

New Masternode Type#

To distinguish an evonode 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 evonode.

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

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 evonode.	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 evonodes, 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#

Prior to Dash Platform release#

Since evonodes have 4 times more collateral than regular masternodes, it would not be fair to keep the masternode rewards as it is during the transition period where evonodes are enabled but Dash Platform has not been released. Therefore, evonodes 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 evonode payee was already paid 4 times, go to step 5.
If the last evonode is no longer present in the current masternode list, go to step 5.
Select the last evonode 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.

After Dash Platform release#

Once Dash Platform is activated, evonodes will begin receiving the majority of their rewards directly from Dash Platform as described in the Overview. At that point both regular masternodes and evonodes will receive a single reward per payment cycle from the Core chain.

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 (evonode) 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 evonode.	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 evonodes.

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 evonodes
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 evonodes 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#

Evonodes are implemented in Dash Core v19.0. The initial implementation is available at dashpay/dash#5039.