• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Should Platform run on all nodes or should Platform run only on High Performance nodes ?

Are you using “HPMN” (high performance masternode) as synonymous with high collateral masternode?

“High performance masternode” is a misnomer. I’ve heard no evidence or even theory why high collateral nodes would be more “performant” than a 1,000 DASH collateralized node. In practice nodes will generally only be as performant as needed to get paid, and this has nothing to do with the collateral backing them.

I suppose Sam likes the “HPMN” term because it helps sell his idea. Until @QuantumExplorer can show that there is an identifiable link between performance and collateral I consider this naming practice no better than politicians who name bills for marketing purposes rather than descriptive purposes, just to gain popularity - it’s a shameful practice.

Please, everyone, stop calling them high performance masternodes. Call them high collateral masternodes (HCMNs) if you want. I prefer the more descriptive and neutral “platform (master)nodes”.

With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.


With no POSE system in place for Platform, it is disingenuous to call Platforms nodes "High Performance" - there is no compliance
system in place for using sufficient hardware.
 
While we're at it, might as well change "master" because I'm not sure who or what the slave is

These new higher collateral nodes will likely lead to their owners achieving more community influence. Do I get to upgrade my forum badge accordingly? Also, can someone update my forum badge to commemorate my presence here for 7+ years? haha
 
Are you using “HPMN” (high performance masternode) as synonymous with high collateral masternode?

“High performance masternode” is a misnomer. I’ve heard no evidence or even theory why high collateral nodes would be more “performant” than a 1,000 DASH collateralized node. In practice nodes will generally only be as performant as needed to get paid, and this has nothing to do with the collateral backing them.

I suppose Sam likes the “HPMN” term because it helps sell his idea. Until @QuantumExplorer can show that there is an identifiable link between performance and collateral I consider this naming practice no better than politicians who name bills for marketing purposes rather than descriptive purposes, just to gain popularity - it’s a shameful practice.

Please, everyone, stop calling them high performance masternodes. Call them high collateral masternodes (HCMNs) if you want. I prefer the more descriptive and neutral “platform (master)nodes”.

With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.
Thank you for clarifying that! And your assumption was correct. I cant say 100% where but i have in the back of head that it was mentioned the need for running platform will/should be higher but can't remember if it was youtube video or in Discord or forum i read/heard it. But great to have this in the clear.
And to be honest i would not mind to have the HCMN having better hardware if that is what is required. My only beef with 4k/10k etc is that it will divide the community more than anything. To much hurdle to list really but several on the the thread already so i'm sure you know what they are :)
And if DCG has thought about them they sure keep quiet. I feel sometime we dont get the why's only the how's during their presentation.
 
I cant say 100% where but i have in the back of head that it was mentioned the need for running platform will/should be higher
Yes, platform nodes will have higher performance requirements. My point was just that having a higher collateral has nothing to do with node performance. You can get higher performing nodes with any collateral (1k, 4k, 10k, etc).

My only beef with 4k/10k etc is that it will divide the community more than anything.
Yes, that's why I'm going through the trouble of proposing an alternative that gives us high enough security and low enough costs, but without increasing collateral for platform nodes.
 
I am leaning against the High Performance Masternode Solution because of :

Data replication would get a lot more centralized over less nodes. This undermines the availability of data stored on the masternode network / Dash Drive and could by itself form a single point of attack / single point of failure in the future. What if an entity decides to DDoS those select few 100 of High Performance Masternodes ? It is much more difficult to (sybil?) attack 4000 masternodes, then (sybil?) attack 100 High Performance masternodes. Not to mention possible problems during large software updates, where masternode numbers in general drop like flies, because masternode operators don't keep up with Dash updates or run into problems. If you ask me the above picture with the two described solutions is not a choice between more decentralized and less decentralized, but a choice between more decentralized and more centralized (no point avoiding the c word here).

Current Masternode Whales (those with 5 or 10 or more masternodes) would have no problem setting up a High Performance Masternode or two, but everyone else with less then 5 masternodes or less then 10 masternodes (depending on the outcome of the collateral discussion for High Performance Masternodes) would be denied setting up a High Performance Masternode. In my eyes this could seriously undermine the trust of the Dash community / current masternode operators in Dash Platform, as it radically changes the requirements of running a masternode on Dash Platform. Yes people can now choose to not run a masternode on Dash Platform, but at the same time you deny a lot of people that want to run a masternode on Dash Platform that option. And lets not forget that there could be additional revenue streams in the future for those masternodes that participate on Dash Platform. Those revenue streams should be available to all masternodes in my view, not to a select few 100 masternodes.

Also the centralization aspect of the High Performance Masternode Solution opens Dash up to attacks from Dash competitors, claiming Dash itself to be centralized. It will be difficult to defend Dash from that, because there is truth in it.

So at this point i am favoring the Masternode Solution, where Dash Platform is run on all nodes and way more decentralized.
I agree with you 100%
 
I agree with you 100%

Unfortunately some safety issues with the Platform on all nodes arised later in this discussion thread, that were never publicly disclosed to the Dash community before and in the many years of Platform development were never addressed or prioritized by Platform developers, which currently handicaps the Platform on all nodes solution. Some can be mitigated by a Proof of Service (PoSe) for Dash Platform, some need a different solution.

Knipsel.JPG


So personally i am having difficulty with any of the upcoming DCG decision proposals (4K HPM, 10K HPM, Platform on all nodes) and i am currently looking into alternative solutions, like Rion's solution.

It is unfortunate that we find ourself in this situation now, where pretty much all available start options (excluding Platform on all nodes, but this start option has its own very specific safety issues) lead to Platform network centralization. With some leading to more Platform network centralization (and more risk to censorship), then others.

10K HPM : Estimated 180 Platform masternodes according DCG Presentation. I checked today on mnowatch.org the estimate lead to 159 Platform masternodes (see my next post).

This also has the risk of possible future censorship, as the top 7 masternode whales have a 60% Platform masternodes majority in that 10K HPM solution and if DCG decides that only Platform masternodes get to vote on what types of content can be stored on Platform, those top 7 masternode whales ultimately get to dictate (through Platform voting) what kind of content is allowed on Platform and what kind of content is not allowed on Platform.

4K HPM : Estimated 450 Platform masternodes according DCG Presentation. I checked today on mnowatch.org the estimate lead to 430 Platform masternodes (see my next post).

This also has the risk of possible future censorship, as the top 7 masternode whales have a 60% Platform masternodes majority in that 4K HPM solution and if DCG decides that only Platform masternodes get to vote on what types of content can be stored on Platform, those top 7 masternode whales ultimately get to dictate (through Platform voting) what kind of content is allowed on Platform and what kind of content is not allowed on Platform.

Rion : Estimated 600 Platform masternodes according his post (https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-12#post-232537), but that could be subject to change.

If any of above start options passes, the future revenue streams from Platform (either through increased Platform usage or through dapps providing additional revenue streams in the future), will be limited to those specific small Platform masternode groups.
 
Last edited:
What happens if a masternode humpback service such as Binance or Crowdnode opens up to HPMNs and ALL their customers choose to have their shares completely in HPMNs i.e. too many HPMNs and not enough MNs? When the end customer has no actual stake they will make irrational decisions and the Humpback services can not breach what the customer expects. Isn't this also a security risk?
 
I ran the calculations on the data from mnowatch.org just now and came with the following numbers for masternode whale node estimates for 10K and 4K

Knipsel.JPG

Source : https://mnowatch.org/Types/index.html?1=

For 10K the estimated total number of Platform masternodes currently comes at 159 and 60% majority is currently at 95.4 / 7 Whales (101)
For 4K the estimated total number of Platform masternodes currently comes at 430 and the 60% majority is currently at 258 / 7 Whales (260)

Not so long ago (30th of october 2022) it could take 5 whales to reach a 60% majority, now it requires 7 whales. So the situation and the estimated numbers are fluid, not fixed. Most likely due to smaller masternode whales buying more dash and setting up more masternodes, as the numbers of the top 5 masternode whales have not changed that much. Also Masternode whale 'Tantalum' seems to be a new rising top masternode whale spotted by mnowatch.org, since very recent (8th of Nov 2022).

Crowdnode does not seem to have much of an impact so far on above estimates.
Binance needs to have a lot of operational liquidity in dash for their exchange, so i don't think they will drastically increase the number of masternodes from their large stash of dash any time soon.
 
Last edited:
What happens if a masternode humpback service such as Binance or Crowdnode opens up to HPMNs and ALL their customers choose to have their shares completely in HPMNs i.e. too many HPMNs and not enough MNs? When the end customer has no actual stake they will make irrational decisions and the Humpback services can not breach what the customer expects. Isn't this also a security risk?
it's pretty unlikely that there will be "too many HPMNs platform nodes and not enough MNs" if the allocation is thought out well. The roughly 650 nodes my model predicts is based on a 20% allocation. DCG's proposals all allocate 50% to platform nodes. Either way, you're not going to have a situation where the platform node yield is much lower (if at all) than normal masternode yield. At least not if we're considering just the basic economic incentives.
 
it's pretty unlikely that there will be "too many HPMNs platform nodes and not enough MNs" if the allocation is thought out well. The roughly 650 nodes my model predicts is based on a 20% allocation. DCG's proposals all allocate 50% to platform nodes. Either way, you're not going to have a situation where the platform node yield is much lower (if at all) than normal masternode yield. At least not if we're considering just the basic economic incentives.

This is assuming yield is always the deciding factor or that the humpback operators will not lie to their customers about allocation. For example, if there's an important proposal (and self-published?), the humpback may decide the best incentive is voting power and simply pay off the difference. In essence, there is NOTHING at the protocol level to enforce how the humpbacks behave. Until this is fixed, dash governance and the entire treasury is at substantial risk.
 
For 10K the estimated total number of Platform masternodes currently comes at 159 and 60% majority is currently at 95.4 / 7 Whales (101)
For 4K the estimated total number of Platform masternodes currently comes at 430 and the 60% majority is currently at 258 / 7 Whales (260)
Just an FYI, DCG and I are both assuming there is risk when any single entity controls 33%+ of a quorum. At 60% (or is it 66%) there is risk of more serious problems (like funds at risk). According to the statistical calculations being able to control 33% of a 100-node quorum starts happening when 1 (or more if you're accounting for collusion) entity controls around 20% of the platform nodes.
 
This is assuming yield is always the deciding factor or that the humpback operators will not lie to their customers about allocation. For example, if there's an important proposal (and self-published?), the humpback may decide the best incentive is voting power and simply pay off the difference. In essence, there is NOTHING at the protocol level to enforce how the humpbacks behave. Until this is fixed, dash governance and the entire treasury is at substantial risk.
Right. That's why I said "At least not if we're considering just the basic economic incentives."

If we're considering scenarios where 3rd party custodian humpbacks (like Binance) are lying to their customers, propping up yield from non-native sources, and in general acting maliciously then all (or at least most) bets are off with platform security.

That's actually exactly why I'm proposing time locks, so that potentially malicious 3rd party custodians are more hindered in converting significant amounts of their nodes to platform nodes.
 
Perhaps better to ask, what are the odds of collusion? I've been trying to highlight this risk for ages, let alone with an elite group of HPMNs.

I am not voting Yes on any proposal requiring more than 1000 dash. We will have more benefit from reducing current masternode requirements, decentralize the network further. And no, not all MNOs would switch to running more nodes, some have bills to pay / more desperate and would welcome the option to sell some dash yet retain a masternode.
 
Right. That's why I said "At least not if we're considering just the basic economic incentives."

If we're considering scenarios where 3rd party custodian humpbacks (like Binance) are lying to their customers, propping up yield from non-native sources, and in general acting maliciously then all (or at least most) bets are off with platform security.

That's actually exactly why I'm proposing time locks, so that potentially malicious 3rd party custodians are more hindered in converting significant amounts of their nodes to platform nodes.

Yes, and I am glad this is recognized, especially in light of recent events.
 
Just an FYI, DCG and I are both assuming there is risk when any single entity controls 33%+ of a quorum. At 60% (or is it 66%) there is risk of more serious problems (like funds at risk). According to the statistical calculations being able to control 33% of a 100-node quorum starts happening when 1 (or more if you're accounting for collusion) entity controls around 20% of the platform nodes.

I am using the 60% majority to show whales concentration in the specific case only Platform nodes get to vote in the nearby future on what types of content can be stored on Platform. So basically it is a 60% voting majority (currently 7 masternode whales), that have enough nodes / possible voting power, to make future Platform proposals on Platform content pass. It is not related to quorums, but it is related to how DCG plans to deal with future content storage on Platform (which by the way requires a Platform PoSe). Details about how DCG plans to deal with future content storage on Platform can be found here here : https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-18#post-232783

quote from Sam:

Knipsel.JPG


+

1668692575546.png


The smaller the Platform group nodes (4K HPM / 10K HPM), the more centralized the future voting power on Platform content by Platform nodes becomes (if only Platform nodes get to vote on what types of content can be stored on Platform), together with an increased risk of possible censorship on future Platform content storage.
 
Last edited:
Can someone please tell me what is wrong with my idea for crowdfunded LPs operating like a Lightning Network? I genuinely want to know, see here....


Maybe you can also create a separate discussion topic about this in the General Discussion section, just like krilen did with his Distributed Platform Storage concept idea ? This would increase visibility to your concept idea and have less risk of it getting drowned in this thread.

I have no experience with Lightning channels or Liquidity Pools, so i have difficulty visualizing the concept to be honest. Reducing the collateral to 500 dash would most likely trigger current masternode whales to just setup twice as many masternodes. I am not sure how it would entice those current masternode whales to join a liquidity pool, instead of just setting up another masternode... unless the idea is to have both ? Have more masternodes and have liquidity pools ?

Also with setting up another masternode, you are pretty guaranteed of your additional revenue. Is the same with liquidity pools or is there a build-up phase untill you start receiving revenue (first gather 5000 dash, then receive LP revenue ?)
 
Last edited:
View attachment 11403

Source : www.youtube.com/watch?v=EMmvP6G3NrE
Timestamp 52:30

Please take the time to fully watch the discussion of this topic by Dash Platform team during their Dash Platform Product Update S91 (see above source link and timestamp).

For the High Performance Masternode Solution there is talk of raising the Dash collateral to either 10.000 dash (higher TPS but more centralized) or 5.000 dash (less TPS but a bit more decentralized, but nowhere near as decentralized as having Dash Platform run on all nodes ofc).

Nothing is finalized, everything is still very much in flux. The Dash Platform team indicated feedback from the Dash community would be helpfull, so that is why i am kickstarting the discussion here.

Update 7th of October 2022 :

DCG : Introductory presentation on High Performance Masternodes
Link : www.youtube.com/watch?v=oQ0iJZ1pvsc
it would be better instead of saying more or less decentralized in a chart, what it means. It seems the less decentralized option actually means easily censorable/ designed to be censored.
 
Hear me out, 1337 nodes, collateral fixed, but not rounded, I wrote all this out earlier, this makes it hard for whale accounting,
Does not raise collateral signficantly but keeps all the Platform nodes identical in collateral which apparently is required for
threshold sigs. Also, 1 Platform node gets 1 vote like 1 core node, but core rewards are weighted to 1.337.
 
With that out of the way, i like the idea of making high collateral optional. We discussed this very thing on a call a while ago. The idea would be to let operators choose a higher collateral to back a node, so for example instead of running two 1,000 DASH-backed nodes, you could run one 2,000 DASH-backed node. The latter would get paid the same as the former, but would have lower operating costs. That would incentivize multi-node operators to run fewer nodes, which Could be better for the network. It’s definitely something to consider and research more. I’m guessing DCG has thought of it, but I haven’t heard anything about it.

With regards to lower operating costs :

two 1,000 DASH-backed nodes

1x server
2x 1000 dash collateral
2x dedicated IP addresses
2x RAM usage for dashd processes
2x SDD storage for full Dash blockchains

Server costs : renting 1 VPS server, having 1 dedicated ip address + renting 1 additional dedicated ip address, picking RAM & SSD that has required RAM amount & SSD storage for running 2 masternodes

Receiving 2x 1,44 dash per 7 days

one 2,000 DASH-backed node

1x server
1x 2000 dash collateral
1x dedicated IP address
1x RAM usage for dashd process
1x SSD storage for full Dash blockchain

Server costs : renting 1 VPS server, having 1 dedicated ip address, picking RAM & SSD that has required RAM amount & SSD storage for running 1 masternode

Receiving 2x 1,44 dash per 7 days

The lower operating costs is mostly in being able to rent a VPS with a lower price tier plan, with less RAM and less SSD storage.
Correct ? Or am i looking at this the wrong way ?

I am mentioning this because i suspect most masternode owners with multiple masternodes (4 or 5), will most likely just have 1 VPS server with a bunch of additional ip addresses (renting 1 additional ip address is just a few dollars / euro's per month). And with options to increase CPU core numbers, RAM amount, and SSD storage amount, by moving to a higher price tier. I don't think they actually rent several separate VPS servers.

Note : not all VPS providers allow people to downgrade to a lower price tier. Could lead to a situation of people having to cancel their current VPS setup and starting a new VPS with lower hardware / tier

On a slightly different (but related) topic :

Same goes for 4K Platform nodes and maybe even 10K Platform nodes, those could also be running on the same VPS server. The lower VPS renting costs that Sam mentioned with 4K Platform nodes & 10K Platform nodes, is then basically selecting a lower price tier on their already rented VPS server and cutting back on rented ip addresses. Same goes for big masternode whales running a lot of masternodes that require a few separate VPS servers with a lot of maxed-out additional ip addresses, they also can then just select a lower price tier on those rented VPS's and cut back on rented ip addresses.

Note : the downgrade depends on what they currently have running with regards to CPU, RAM and SSD requiments and what Platform ultimately requires them to run with.
 
Last edited:
Back
Top