# 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 1. [Abstract](#abstract) 1. [Motivation](#motivation) 1. [Prior Work](#prior-work) 1. [Overview](#overview) 1. [Protocol Changes](#protocol-changes) * [Added Dash Platform Fields](#added-dash-platform-fields) * [Managing Masternodes](#managing-masternodes) * [Simplified Masternode List entry](#simplified-masternode-list-entry) * [Long-Living Masternode Quorums](#long-living-masternode-quorums) * [Changes in Governance votes](#changes-in-governance-votes) 1. [Deployment](#deployment) 1. [Reference Implementation](#reference-implementation) 1. [Copyright](#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](https://www.dash.org/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](https://github.com/dashpay/FAQs/blob/master/Platform/platform-activation-evonodes-faq.md), 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: 1. The return on investment (ROI) for hosts 2. The fee costs for users 3. The system’s security 4. The system’s performance 5. 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 * [DIP-0003: Deterministic Masternode Lists](https://github.com/dashpay/dips/blob/master/dip-0003.md) * [DIP-0004: Simplified Verification of Deterministic Masternode Lists](https://github.com/dashpay/dips/blob/master/dip-0004.md) * [DIP-0006: Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md#building-the-set-of-deterministic-connections) * [Evolution Nodes FAQ](https://github.com/dashpay/FAQs/blob/master/Platform/platform-activation-evonodes-faq.md) ## Overview An Evolution masternode (evonode) is like a regular masternode (MN) but with three key differences: 1. The collateral to own an evonode is 4000 DASH as opposed to 1000 DASH for regular masternodes. 2. The recommended specs for evonodes are higher than those for regular masternodes. 3. 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](#motivation) section. Going down the list: 1. **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. 2. **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. 3. **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. 4. **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. 5. **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](https://github.com/dashpay/dips/blob/master/dip-0003.md)) 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](https://github.com/dashpay/dips/blob/master/dip-0006.md) 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](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki), and [SLIP-10](https://github.com/satoshilabs/slips/blob/master/slip-0010.md). The key derivation path SHOULD adhere to [DIP-9](https://github.com/dashpay/dips/blob/master/dip-0009.md), 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: ``` text 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](https://github.com/dashpay/dips/blob/master/dip-0003.md) 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](https://github.com/dashpay/dips/blob/master/dip-0003.md#masternode-rewards): 1. Find the previous masternode payee. If the last payee is a regular masternode, go to step 5. 2. If the last evonode payee was already paid 4 times, go to step 5. 3. If the last evonode is no longer present in the current masternode list, go to step 5. 4. 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. 5. 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](#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](https://github.com/dashpay/dips/blob/master/dip-0004.md) 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](https://github.com/dashpay/dips/blob/master/dip-0006.md) 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: 1. Retrieve the deterministic masternode list that is valid at quorumHeight 2. Keep only the evonodes 3. Continue with current step 2 of the [existing algorithm](https://github.com/dashpay/dips/blob/master/dip-0006.md#1-initialization-phase) #### 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](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) with the name “v19” and using bit 8. ## Reference Implementation Evonodes are implemented in Dash Core v19.0. The initial implementation is available at [https://github.com/dashpay/dash/pull/5039](https://github.com/dashpay/dash/pull/5039). ## Copyright Copyright (c) 2023 Dash Core Group, Inc. [Licensed under the MIT License](https://opensource.org/licenses/MIT)