Frequently Asked Questions (HPMN)

As development for the release of Dash Platform nears completion, certain drawbacks of the original plan that every Masternode would host Dash Platform have come to light. Voices of concern started forming this year that can be grouped into five main categories:

• The approach of forcing Masternode owners to run Platform.
• The performance of the system.
• The safety of the system (it not going down).
• The cost of the system to the network (ROI).
• The fee cost to users.

We took these concerns seriously and thought about the best way to remedy them with solutions that would be relatively easy to implement. We came up with a solution called High Performance Masternodes that will be explained in this FAQ. While the advantages are many, the main drawback of this solution is that it requires the creation of a new type of Masternode with a higher collateral. We will be polling the Masternode network as we want to ensure that this potential move, which differs from the original plan, is aligned with what the community as a whole wishes. Hence this vote is necessary for us as a project in order to coalesce around a plan for Platform activation.

DCG is proposing 2 categories of solutions to the network:

• The first is that every Masternode must run Platform.
• The second is one of multiple solutions in a category called “High Performance Masternodes”.

The High Performance solutions that will be proposed by DCG would require a new type of Masternode that uses between a 4K to 10K collateral, instead of the standard 1K collateral. The system is designed in such a way that standard Masternode operators should over time see an increase in ROI.

No, as time goes by the needs of the network are going to change. There are two main approaches to scaling: vertical and horizontal. Vertical scaling is when you make the individual nodes more powerful. Horizontal scaling in Dash would mean adding sharding to the network. For example if at some point Platform begins to gain very high usage and it can no longer scale vertically we will need to introduce horizontal scaling. Horizontal scaling can only work to a certain degree with the amount of nodes in the 4K or 10K solutions, hence we would need to reduce the collateral at that time. This can not be done now since sharding has not yet been built for Platform, nor does the network yet have the usage required to rationalize the much more costly infrastructure.

We will be making the following proposals to the network in the December voting cycle:

• Every node must run Platform.
• The 4K High Performance Masternode Solution
• The 10K High Performance Masternode Solution

We expect community proposals to also be made.

If there is no resounding winner (a resounding winner would have over two times the absolute votes of the runner-up), the top two proposals will then go to a runoff in the January cycle. However, if the 4K and 10K HPMN solutions are the two top-voted solutions, we will instead perform a secondary vote where we add proposals for 6K and 8K. The winner would then be the highest voted in the second round between 4K, 6K, 8K and 10K.

The winner of each multiple choice round is determined by the number of YES votes minus the number of NO.

For the second round if there are only two choices there might be only one proposal depending on the winners of the first round.

As this is a poll, we will go with the proposal that has the best chance of being activated by the network.

At the beginning of Dash we used the BIP9 consensus mechanisms, now we use the https://github.com/dashpay/dips/blob/master/dip-0023.md mechanism giving more power to masternode owners. This is the consensus mechanism we currently use on the network. The +10% supermajority that many might think is the required threshold is only required for funding decisions.

On October 20, a poll inside DCG was made. The results were that the developers and non-devs overwhelmingly believed that the usage of HPMNs would be a far superior plan compared to running Platform on every node. The result of the internal poll is shown in the table below.

Using the following parameters and assumptions, we’re able to provide estimates of what the ROI would likely be for each existing potential solution:

• Cost to host a MN: 25$/Month
• Cost to host a HPMN: 100$/Month
• Rewards have stabilized between MNs and HPMNs (see question 31 for an explanation of the yield equilibrium between MNs and HPMNs)
• No fees generated by Platform (at start)
• 3.8M Dash locked in either Masternodes or HP Masternodes
• 45$ Dash price

The estimated fees for various operations using each solution are shown in the table below.

These fees are accurate as of November 15th 2022, but are subject to change as we Tweak various processing costs.

The ratio of fees between each solution would be the same for any operation.

Lower user fees is an attractive advantage of the High Performance Masternode solutions, however DCG would still be in favor of these solutions even if fees were not a factor. The reasons for this become apparent later in this FAQ.

For Platform to be sound in the long term, we should treat it as a business. Treating it as a business means it should be able to support itself through revenue instead of being subsidized through the block reward. In the first major version release following the initial Mainnet release, we will allow Masternodes running Platform to be able to collectively set their fee multiplier level. At this point the network will be able to choose to subsidize fees or raise them to gather more revenue variably.

The main advantage of the 10K solution is that a higher profit can be achieved while maintaining low user fees.

The main advantage of requiring every Masternode to run Platform is that it is the most decentralized option in light of the higher node count. However, higher node count is just one of many factors that go into achieving safety of the overall system, and DCG largely believes that while this is the most decentralized solution it is also one that carries many safety risks. If Masternode operators don’t update their hardware to the much more onerous requirements, the whole system will be sluggish and less responsive. We believe that if this solution is chosen the Platform chain can be more easily halted by an attacker, as stopping the network only requires DDOSing 34 nodes of a 100 quorum set. There are also more disadvantages such as reduced ROI and increased user fees.

Increasing the collateral for Platform nodes is necessary so that an equilibrium between Platform and Core node yields can be achieved while also creating market incentives for a lower number of Platform nodes without setting a hard cap. It also makes it more difficult for individual entities to gain control of enough nodes to cause harm to the network or significantly centralize block validation.

As Masternodes seeking to run Platform must also provide Core services it makes the most sense to keep rewarding them for doing so. See next questions for more information on why 1k collaterals are not DCG-proposed solutions.

No, it’s not possible to do this while also maintaining parity. Let’s imagine 50% of rewards are sent to Platform in this scenario. In this case, a node running Platform+Core would receive on average twice that of what a node just running Core would.

There have been solutions proposed that give only 20% of rewards to Platform, however this solution is plagued by the same issue where a Masternode running Core would just receive 20% less than a Masternode running Platform + Core. In such a scenario we would be left with an insecure system in the case if few masternodes chose to run Platform. The market equilibrium in this solution happens when close to all nodes run Platform, as they would always receive more revenue by doing so. If we assume this to be the case this solution would require really high user fees to offset high network hardware costs, coupled with a reduction of ROI for Masternode Owners.

Yes, this is possible. However, there are a few major downsides. First, to reach the same level of security on Platform as the 4K HPMN solution against participants shutting down the service, there would need to be approximately 2100 Platform nodes with 1K collateral. Second, there would be significantly fewer nodes participating in Core-servicing quorums. InstantSend performance is optimal when the node count is over 1920; in this scenario, we would only have around 1700.

Yes, this is possible and is most likely the best solution that can keep a 1K collateral. DCG however does not recommend it as there are still major downsides and it would introduce a delay for release of Platform.

The first is that work being done on the Core payment chain would not be rewarded on that Chain. DCG would need to develop a more complicated mechanism in order to prove on the Platform chain that Masternodes are properly servicing the Core chain. Then we would need to implement a different proposer selection mechanism that ignores specific nodes not servicing the Core chain. A quick estimate would be that this extra effort would take 1-2 months.

The second downside is that this system only becomes secure with about 2100 Platform nodes. This would significantly lower the ROI for the network (including for normal MNs). At the same time user fees would be significantly higher than the HPMN solutions.

Setting a hard cap on the number of Masternodes running Platform would disallow some MNOs to run a Platform node even if they wanted to. Furthermore such a solution would likely threaten the stability of Platform by introducing a point of unsafe centralization.

Currently, the biggest whale is estimated to own about 270 masternodes. Say we set the hard cap to 1000 total Platform nodes. There would be a 6.35% chance that this owner alone could shut down a validator set each time a new set is chosen by taking their participating nodes offline, therefore halting the chain. There would be a 79.29% chance of them having the opportunity to do so each day with 24 quorums a day.

We would need to set the hard cap to at least 2100 in order to achieve a similar level of security in this regard as the 4k HPMN solution.

The higher collateral requirement does not enforce higher performance. Rather, Masternodes have an economic incentive to follow the specs recommended by DCG: if a node wasn’t performing sufficiently, it would start lagging behind the rest of the network, fail to produce blocks, and miss out on rewards. Thus a HPMN will be required to be stronger than the current average standard masternode in order to receive rewards. A second point is that higher collateral shows a higher stake in the project which should push HPMN owners to have a higher incentive to have more performant hardware servicing Dash Platform.

Yes, but the hardware requirements would increase and the block consensus and validation times would be slower. Currently we have a quorum member count at 100. As quorum member size increases so does the performance requirements as well as the time required to reach consensus. Cosmos hub has recently increased their validator count to 175 from 125, however their minimum hardware requirements for being a validator is 32GB of RAM. Since we have not yet launched the final system it’s hard to know the definitive and exact impact of using a larger quorum size. However, it would be safe to say that the more we want the validator count increased the stronger we need our validator Masternodes to be.

There are currently 24 active Platform quorums. A new Platform validator set is chosen from these 24 every 15 Platform blocks. There is a high probability that these parameters will change during our testing phase before Mainnet release.

Yes, but the more we reduce the number of active quorums, the lower the chance of individual validators getting paid every epoch. Keeping the active quorum count relatively high and the total Platform Masternode count relatively low increases the probability that all nodes will be in at least one quorum per epoch. The worst approach that we could take is to have very few quorums servicing Platform that are chosen from a very large pool of Masternodes.

In a future version of Dash Core we will stabilize Platform quorum Masternode selection to allow for smoother payouts, but this is not a feature we will have at release. Currently the quorum member selection is completely random.

Sharding would take at least four, and likely six to twelve months to implement without an increase to our development capacity. Our view on the matter is that we should get everything working in our system first, release Platform to mainnet, and then at the right time when usage is sufficiently high implement sharding.

Below is a list of the technical challenges associated with implementing sharding in Platform:

• We would need a robust PoSe solution to know which MNs aren’t properly participating or not participating at all.
• We would need to have a way to prove this information securely to our core software which currently has the responsibility of creating quorums.
• We would need to alter the selection mechanism of quorums.
• IBC needs to work (it’s currently planned for post-release).

Platform uses Core services and needs them locally with low latency. Without serious effort this is not possible.

No, one of the tradeoffs for supporting efficient proofs using threshold cryptography is that all validators must be of the same weight in the system. As such, this breaks the delegated proof of stake model. Since all Masternodes running Platform would hold the same collateral this is not a problem.

The advantages of having only a subset of Masternodes support Platform are the following:

• The stability of Core would be further ensured – if all Platform nodes went offline, Core would still run; Chain Locks would still form, InstantSend would still lock transactions.
• It’s an opt-in solution – Masternode owners don’t need to support Platform if they don’t want to.
• User fees would be cut by up to around 20x as overall network costs go down, depending on the solution chosen.
• Network ROI would stay stable (4K) or even increase (10K) as the total hardware cost of the network goes down.

Data which provided insight into Dash Masternodes and whales was taken from mnowatch.org, a community-run website which provides information and services about and for the Dash network. We would like to specifically thank xkcd and demo for their valuable contributions.

A High Performance Masternode is a proposed new type of Masternode which would be used to serve the network by participating in consensus on both the Dash Platform chain and the Dash Payment (Core) chain. In the solutions that use HPMNs the standard Masternode would continue serving only the Dash Payment chain. HPMNs would have greater requirements than a standard Masternode regarding collateral amount and would require higher performance specs as they would be running two chains instead of just one.

The main advantages are:

1. Increased safety for the Core payment chain due to the supermajority of nodes not running the Platform chain. If every node running the Platform chain was to go offline, the Core payment chain would only be minimally affected.

2. Hosting Platform is optional, so you can still run a Core node and not have to participate in Platform if you don’t want to.

3. A market equilibrium allowing ROI to vary based on difficulty/desire to run Platform or not.

4. Decreased fees on Platform due to the decrease in total nodes hosting the network. They are estimated to be cut by up to around 20 times depending on the chosen solution.

5. Compared to a 1k optional solution there is increased safety due to the decrease of variability in quorum selection allowing big whales a lower to null chance to either maliciously or inadvertently stop the platform chain.

6. Increased yield for the entire network compared to non-HPMN solutions.

7. Estimated stronger nodes, leading to higher transactions per second.

8. Estimated stronger nodes, leading to higher resilience against malicious attacks.

The biggest drawback of the HPMN solutions are the reduction in the total number of nodes hosting Platform, which is both a good and bad thing. It is a good thing because of lower user fees and various other reasons already mentioned. It is a bad thing because the max network query-able load is reduced as there are less nodes to query data from. This however is offset by nodes having a greater capacity to respond to queries. We do not expect this to be an issue in the first few years of Platform activation as we do not expect to come close to the network limit.

Another downside is that compared to forcing every node to run Platform we do have more centralization in the HPMN solutions. However we believe that the slight increase in centralization versus all the benefits of the HPMN solutions are worth the tradeoff especially since the overall HPMN solutions have increased safety.

Another aspect which may be seen as a drawback is the higher barrier to entry for hosting an entire Platform node as it would increase collateral.

No, even though we would see a decrease in total Masternode count as collateral moved into HPMNs we would still have more than enough nodes to efficiently serve the payment chain.

We anticipate that the implementation of HPMNs would add only a few hours of development compared to the original plan of having every node run Platform.

HPMNs would have an increase in governance voting power proportional to the increase in the amount of collateral. For example, a HPMN requiring a 4000 DASH collateral would have 4 votes while a standard masternode would still have 1.

The Masternode part of the block reward would be split into two parts, one allocated for Platform services and one for Core services. Each is then split equally among all HPMNs and standard Masternodes. HPMNs would get rewards both from the Platform chain and from the Core payment chain. All Masternodes, standard and high performance, would be equivalent from Core’s perspective. Hence we can consider that the first 1K of collateral would be logically associated with Core while the remainder is associated with Platform. Therefore a 4K HPMN would get 75% (¾) of its rewards from the Platform chain and 25% (¼) of its rewards from the Core payment chain. A 10K HPMN would get 90% (9/10) of its rewards from the Platform chain and 10% (1/10) from the Core payment chain.

We expect it to be just slightly higher. As this is a market solution giving people the choice to run or not run Platform it is not possible to be sure of the outcome. If there are less HPMNs then the system equilibrium would require then HPMN rewards will be higher than that of Masternodes. If there are too many HPMNs then Masternode rewards would be higher.

If at some given time, HPMNs are receiving much higher yields than standard Masternodes, there will be an incentive to combine existing MNs to create HPMNs. This drives the total number of MNs down and the number of HPMNs up. The yield of HPMNs therefore will go down and the yield of masternodes up until the equilibrium is reached.

Standard Masternode rewards are expected to stay roughly the same: the rewards will be smaller each time, but will occur more often. The average ROI should even increase in the case of 10K HPMNs as the total infrastructure cost to the network would go down. As this is a market solution giving people the choice to run or not run Platform it is not possible to be completely sure of the outcome. The yield equilibrium referred to in question 24 ensures that every bit of money put in masternodes would yield the same percentage of return as HPMNs, and more money entering the system from Platform fees means all nodes will have increased yields.

Yes, fees will generate revenue except in one extreme case. If the price of Dash were to go below half the average price that was paid in Dash per byte for all bytes stored in the Platform state, revenue generation would be lower than storage hosting costs. Adjustments to the fee multiplier (originally set to 2) could cause this to fluctuate to more than or less than the “half” from the previous statement.

Satoshi’s vision for Bitcoin was that the source of system revenue would transition from block rewards to network fees. The same applies to Dash. Dash has the opportunity to become a business where users and enterprises pay for the service and the Dash network actually makes money on every transaction.

They are expected to generate revenue indirectly from Platform because the equilibrium described in question 24 that exists between HPMN rewards and normal MN rewards would be driven higher as more Platform fees are generated.

Note: during Platform’s launch, nodes will be able to run with 8GB of RAM due to the low initial usage anticipated. However, we do not recommend this amount except in that period of low usage.

It depends on the total number of nodes in the system when Platform launches as well as the HPMN masternode block reward allocation. The following values are for a 50/50 allocation scheme.

The main security concern for Platform is a single entity controlling more than a third of the nodes in a Tenderdash validator set (34+ out of 100). It would allow them to halt the chain either by malice or a stroke of bad luck if they were to take their nodes offline while they were comprising over a third of the set.

In the tables below we provide our calculations of the security of each solution in this regard. The calculations were made assuming there would be a total of 450 HPMNs in the 4K system and 200 HPMNs in the 10K one, and that the current top whale would upgrade all their current nodes (in reality they likely won’t).

* value is so small it’s in machine error range

** top whale would have less than 34 nodes

In the HPMN solutions, regardless of their increased collateral, a HPMN would be treated the same as a standard Masternode in the quorum selection process. For Platform quorums only HPMNs would be chosen.

As far as registration goes, setting up a high performance masternode would be very similar to setting up a normal masternode, except for the higher collateral.

While DCG has already invested substantial effort into finding and evaluating all possible methods of hosting Platform, we are always open to hearing additional suggestions from our community, and anyone can always submit a proposal to the DAO.

A few solutions from non-DCG staff have already been informally proposed, which you can find in the FAQ on GitHub linked above, along with summaries of our reviews for each. These proposals either do not actually work, might work but would require a significant delay to the start of Platform, are unsafe due to introducing points of centralization, or cause ROI to significantly decrease as network costs increase.

If you think you have an idea that hasn’t already been suggested that would both work and achieve consensus in the community, feel free to send it to us for a review, or make a proposal to the network.

DCG has done due diligence on all community proposed solutions, other solutions either lead to heavy centralization for Platform, heavily reduce the ROI of nodes, or are simply not feasible without significant delay for launch.

DCG would respect the vote.

There are a few exceptions though:

• If the solution proposed isn’t technically possible.
• If the solution proposed is not clearly defined and in our best efforts we can not figure out a clear implementation plan. In this case we will ask the proposer for an implementation plan.
• If the solution proposed could lead to a level of centralization such that there would be a chance that just two entities could steal funds locked up in the Platform chain by having more than two thirds of Platform nodes.
• That the solution has a vulnerability leading to a loss of funds.

In the case of a proposal that would add a significant amount of additional work, DCG would estimate the delay incurred by the solution, and potentially make another vote confirming the intention of the network.