• 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 ?

Status
Not open for further replies.
QuantumExplorer said:
@qwizzie Sorry I didn't realize it earlier, but 1k split solution can't work because it is impossible to split rewards. Since everyone would be running core, it is impossible to take rewards from core to give them to Platform and have a market equilibrium.

Imagine rewards are going 50% to core and 50% to platform, with everyone running core. There is no way for the number of nodes to stabilize, basically everyone would then run platform or lose 50% of their rewards.
Click to expand...

Okay, so it works out like this ?

1K Platform nodes --> 50% of MN Rewards for Core service (which could increase if normal 1K Classical group gets smaller) --> Platform Credits to compensate for higher hardware requirements, claimable every 18 days (after an epoch)
Have to pay for additional hardware requirements / higher VPS costs.

Versus

1K Classical nodes --> 50% MN rewards for Core service (which could increase if this group gets smaller)
No additional hardware requirements / no higher VPS costs.

Why would everyone go to Platform ? You only get those Platform Credits to compensate for the higher hardware requirements / higher VPS costs (and get a tiny bit extra)
 
Last edited:
@qwizzie You are missing something I think, all nodes always are rewarded in core, platform or not. I guess this could be changed though.
 
qwizzie said:
Unfortunetely this is pretty much the first time we hear about it.
Click to expand...
I guess most blockchains do not disclose some of these facts. I'm here trying to be as transparent as possible. The worrying part is that I feel like we are doing better than most of the competition in terms of decentralization / chance the network can go down / security, but because we are being honest about whatever shortcomings we do have it might appear that we are worse.
 
QuantumExplorer said:
@qwizzie You are missing something I think, all nodes always are rewarded in core, platform or not. I guess this could be changed though.
Click to expand...

I did kinda wonder about that before : see https://www.dash.org/forum/threads/...gh-performance-nodes.53374/page-6#post-232316

Knipsel.JPG


If we consider 1K normal nodes and 1K Platform nodes as seperate assets, then the rewards for Core services would in some way (50/50 split) need to reach both the 1K normal nodes and the 1K Platform nodes. And there need to be interaction between these two assets, so when the time interval between MN payments for Core services get shorter (more mn payments), it affects both assets.
 
Last edited:
The thing is that we still want platform nodes servicing core services, otherwise we are left with too few nodes in core, causing instant send to start to be suboptimal (it would still be okay). Optimal for IS is anything about 1920 nodes.

Platform nodes also still need to run core.

I just don't see this working.
 
QuantumExplorer said:
The thing is that we still want platform nodes servicing core services, otherwise we are left with too few nodes in core, causing instant send to start to be suboptimal (it would still be okay). Optimal for IS is anything about 1920 nodes.

Platform nodes also still need to run core.

I just don't see this working.
Click to expand...

The 1K masternode solution fully takes into account Platform providing Core services (it has from the start i think, i just did not realise this untill peter brought it up, so i worked it out later).

See : https://www.dash.org/forum/threads/...gh-performance-nodes.53374/page-5#post-232308

Knipsel.JPG


This is the part that needs to be worked out for devs, for this solution to work :

If we consider 1K normal nodes and 1K Platform nodes as seperate assets, then the rewards for Core services would in some way (50/50 split) need to reach both the 1K normal nodes and the 1K Platform nodes. And there need to be interaction between these two assets, so when the time interval between MN payments for Core services get shorter (more mn payments), it affects both assets.
Click to expand...

The coding for the seperate assets has already be done for 4K/10K HPM (that 1 hour work), so above is basically what remains.

With regards to InstantSend only working optimal on 1920 nodes or more (which needs to be established on 1K normal side & 1K Platform side, because both are providing Core services), perhaps there needs to be done some research into what the likely outcome is. Who would most likely move to 1k normal nodes and who most likely move to 1K Platform nodes ? How easy can 1K Platform nodes flip back to 1K normal nodes to boost the number there ? How can we put incentives into place to encourage a favourable outcome with regards to Instandsend staying optimal ? How does having stronger hardware requirements on the Platform side affect InstantSend ? (maybe less Platform nodes required then, to run InstantSend optimal ?)

If this 1K masternode solution turns out to be unworkable due to InstantSend not working optimal, then i suspect a lot of small masternode owners that want Dash to stay decentralized, will vote for the Platform on all nodes solution (with twice as high Storage fees). Which would be the only option left for them.

From a Platform storage fees point of view that would be a bit of a setback (if the Platform on all nodes decision proposal passes).
I do realise every solution needs to be workable.
 
Last edited:
qwizzie said:
If we no longer focus on the willingly attacks aspect (with the attacking Platform 365 days a year part) and instead focus on a sudden move of Binance to shutdown all of its nodes at once, then we should also look at the motive and explore ways to stop large Dash whales from possibly stopping the Platform chain by the 'stopping all their nodes at once' vulnerability. This should be done through additional coding to protect Platform against this.
What we should not do, is just rely on a centralized solution to control this situation and have devs develop tunnel vision towards that centralized solution.
Click to expand...

To me, this is one of my major concerns with dash masternodes, let alone an even smaller set of critical infrastructure. Since the Tornado Cash incident, look at how compliant Ethereum is now:

Compliance does not mean everyone functions the same way. Typically, every bank / organization interprets the rules differently and often they are over compliant just to be sure. It is akin to licking the regulators arse and, frankly, regulators like it that way.

But this is still all very tame. Dash has never stolen enough limelight to witness the wrath of coordinated international law enforcement. Look at previous drug ring takedowns with hundreds of warrants served simultaneously. Dash currently has, let's say, 1000 - 1500 unique masternode owners. Maybe less given the entire masternode count is only 3669..So where does that leave us with a fraction of nodes being HPMNs?

Bitcoin nodes, unlike the miners, do not receive a direct financial incentive, which also makes the operators less of a target. But wherever people are rewarded, authorities like to turn up the heat and make examples of them. e.g the association of coin mixing and money laundering. Or the hosting of content that is politically sensitive / censorship "resistant".

Sorry to say, but I feel Sam comes across as a very nice guy but also at times somewhat naive and trusting. Dash has not yet really witnessed network wide state level intervention and this is what we should be focusing on.
 
The 1K masternode solution could also be combined with reducing the 1000 dash collateral, this would most likely increase the number of masternodes on the Dash network for both assets. Making it more easy to get optimal performance of InstantSend on both assets. It would need to be a reducing of collateral that does not create too many masternodes, but enough to comfortably support InstantSend on both assets.

Reducing Dash collateral from 1000 dash to 500 dash would most likely trigger a growth in number of masternodes from 3669 (current number of active masternodes) to well over 7000 masternodes. That would be more then enough to support InstantSend on both assets.

Dash highest number of active masternodes with our current 1000 dash collateral is 5007 (end 2020)
 
Last edited:
QuantumExplorer said:
Basically the quorum would stop if more than 34 members out of 100 were to turn off their nodes within the same day. The MNOs don't even need to be malicious... This is currently one of the systems greatest flaws. Fixing it will take time and I don't want to delay Platform any more. However we probably will slightly improve it to some smaller time length. This is easiest to do with the 10k system.
Click to expand...

If 34 members (out of 100) turn off their nodes, couldnt these 34 be replaced by some other standby members?
Probably the concept of "standby member" is a solution for this flaw.
The whole DashPlatform database could be signed by the quorum and available for download.
And in case 34% turn off their nodes, the stanby members will be available to replace them quickly.
A collateral fee could be asked for someone to become a standby member, and some rewards could be given to them for beeing standby.
 
Last edited:
vazaki3 said:
If 34 members (out of 100) turn off their nodes, couldnt these 34 be replaced by some other standby members?
Probably the concept of "standby member" is a solution for this flaw.
The whole DashPlatform database could be signed by the quorum and available for download.
And in case 34% turn off their nodes, the stanby members will be available to replace them quickly.
A collateral fee could be asked for someone to become a standby member, and some rewards could be given to them for beeing standby.
Click to expand...
No, not in the current system, as I said things could be built... but it all takes time.
 
GrandMasterDash said:
Sorry to say, but I feel Sam comes across as a very nice guy but also at times somewhat naive and trusting. Dash has not yet really witnessed network wide state level intervention and this is what we should be focusing on.
Click to expand...
Thanks :) I am a nice guy.

However I don't think there really is an issue. The market should fix these things. If people stop running Platform in the Split scenarios that means more rewards for the rest which would incentivize more people to run Platform and maybe even buy more Dash if returns are very lop sided.
 
QuantumExplorer said:
Thanks :) I am a nice guy.

However I don't think there really is an issue. The market should fix these things. If people stop running Platform in the Split scenarios that means more rewards for the rest which would incentivize more people to run Platform and maybe even buy more Dash if returns are very lop sided.
Click to expand...

Yes. But with the 4x/10x solutions, MN rewards will be subsidizing PMNOs to run fewer nodes to get the same payouts.
MNOs are required to pay for a single VPS for every 1000 Dash in collateral to get a standard superblock MN reward.
PMNOs will only be required to run a single VPS that provides the same standard MN services to get 4x/10x the standard payout.
Even if PMNOs decide to run high performance systems, this adds very little value to standard MN services that the superblock reward is meant to compensate.

To be fair, if we go with 4x/10x solution, we should allow other MNOs to consolidate all their MNs with into 4x/10x collateralized MNs and have their payouts based on their collateral without them having to provide platform services. This would allow cost savings on both sides. Although, this really wouldn't be fair to someone who could only afford the collateral for a single MN. ;)
 
Last edited:
My biggest concern is making large changes to the MN structure which are not necessary to deploy Platform. Let's keep it simple. When it's ready, just release the Platform build as an optional install for the MN network. Do this as a beta release of Platform. Don't make any huge announcements. Once Platform is activated, let beta testers hammer it. And it may turn out that certain platform services are too slow or too expensive. But at least now we have real-world metrics. We can than use these metrics to figure out what changes, if any, we need to make to the MN network. We shouldn't be making changes like this until we have the metrics to justify it.
 
QuantumExplorer said:
@qwizzie, this is not a vulnerability. This is the case with most PoS blockchains.
Click to expand...

This part still puzzles me. Dash is a Proof of Work blockchain (PoW) with a Proof of Service element (Masternodes). Is Dash Platform and the Tendermint version / sidechain it uses (TenderDash) to be considered a Proof of Stake (PoS) blockchain ? And due to using Proof of Stake (PoS) for Dash Platform we are now hitting a flaw with Dash Platform that is inherent to most Proof of Stake (PoS) blockchains ? The flaw for Dash being that quorums would stop if more than 34 members out of 100 were to turn off their nodes within the same day. And that flaw would most likely to hit us during large Dash Core updates (when large Dash whales will turn down their nodes for a brief moment to update their Dash Core software version).

Is that a fair summarization or do you mean something else with 'PoS blockchains' ? (Proof of Service for example)

Update : after doing some googling it seems that we are indeed talking about Proof of Stake (PoS) with regards to Tendermint / TenderDash
See : https://blog.cosmos.network/tenderm...-to-the-public-blockchain-domain-f22e274a0fdb

Which ironically makes this classification even more correct for Dash, after we launch Dash Platform : https://coinmarketcap.com/view/hybrid-pow-pos/
This page lists the top proof of work / proof of stake hybrid coins and tokens.
Click to expand...


After reading above article the following grabbed my attention :

Tendermint is modeled as a deterministic protocol, live under partial synchrony, which achieves throughput within the bounds of the latency of the network and individual processes themselves
Click to expand...

If Tendermint is modeled as a deterministic protocol and TenderDash is a fork of Tendermint, why are the Platform Credits not deterministic of nature as well ?
Instead Platform Credits are probabilistic of nature ? Are TenderDash and Platform Credits perhaps not that closely related ? Or is it something else ?

With regards to interruption of Core services : does Dash not already have some interruption in Core services during large Dash Core software updates ? I remember problems with CoinJoin mixing during large Dash Core software updates, with the advice given to the Dash community to wait with CoinJoin mixing untill most masternodes have upgraded to get a much better experience. So problems with Core services during large Dash Core software updates are not really new to Dash, we now just get an additional problem during large Dash Core software updates specifically with InstantSend, due to how Dash Platform / TenderDash works.

I have changed my view on this flaw needing to be fixed with priority before launch of Dash Platform, i now think this flaw can just as easily be fixed after launch of Dash Platform, because of already existing problems with Core services during large Dash Core updates (mainly CoinJoin mixing).

Just inform the Dash users that Core services (CoinJoin mixing and InstantSend) could be affected during a large Dash Core software update and look for ways to mitigate the last one (through coding) after launch of Dash Platform ?
 
Last edited:
Sam mentioned that the 1K split system would not work because Core services needs to be provided both by Platform nodes and normal nodes in a 50/50 split and every normal node would move to Platform, because they lost half of their Core rewards (due to that 50/50 split) and would therefore go to Platform to claim the other 50%.

Yet Sam also mentioned that with the 10K HPM system 90% of the rewards come from Platform, 10% from Core (because 10K nodes would do far more work on Platform, then on Core). I assume here that normal nodes would receive far more rewards from Core, in direct comparison to 10K HPM's.

www.youtube.com/watch?v=zRj2cLjVR8Q&t=3s
Timestamp 39:15

So i am wondering why the same can not be done for the 1K split system, where those that setup 1K Platform nodes would get more rewards from Platform and less rewards from Core (as they are doing far more work on Platform, then on Core) and those that setup 1K normal masternodes would get far more rewards from Core (as they are doing far more work on Core), in direct comparison with 1K Platform nodes. The amount of work that a 1K Platform node does and the amount of work that a 4K HPM node or 10K HPM node does is the same, collateral by itself does not affect amount of work.

How are below ROI's that DCG 's research department provided with regards to the 1K split system, calculated anyways ?

At network start (no fees generated) AND Assuming platform nodes get slightly more rewards (educated guesses on how the system will stabilise).

1K split system:

Masternodes: 6.4%
HPMasternodes: 6.6%

At network start (no fees generated) AND Assuming platform nodes get slightly more rewards AND platform nodes run stronger hardware to better server the network and ensure their profits(educated guesses on how the system will stabilize and hardware used).

1K split system:
Masternodes: 6.4%
HPMasternodes: 6.6%
Click to expand...
 
Last edited:
Status
Not open for further replies.
Back
Top