• 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.
You have stated it like 10 times already. I just don't understand why you keep on stating it. We get it, you hate the change, you were promised ridiculous non functional things by evan duffield years ago and now QE tries to make a functional product and you're angry evan duffield lied to you, but like come on... Is it really QE's fault? In your place i would be coming with pitchforks at evan, not at QE. He's the one actually delivering something positive for you and you hate him. I don't understand why.

You guys keep talking about how platform will fail and how it'll drive the price down. You're trying to make it a self fulfulling prophecy. Do you really think it's the amount of nodes supporting platform or how the community behaves toward it's development org that offputs new people? You realize fully how image and marketing is important right?

A lot of generalization and personal assumptions about me, in one post.
And yes i do realize fully how image and marketing is important. I also realize how centralization in Dash Platform can irreparably harm Dash image and marketing. I wonder if you realize that as well ?

Anyways, this topic was initiated by DCG, introduces centralization to Dash Platform, introduces safety issues to the Platform on all nodes solution that were never fully disclosed to the Dash community before (and took ages before getting described in here in full detail) and it involves upcoming DCG decision proposals, while CTO of DCG is already making statements about wanting a winner, regardless if those decision proposals passes or not.. how did you think this would go ?
 
Last edited:
...
Have you read the past 5 or so pages? i have participated a bunch and in there somewhere i answered to the same questions over and over on why it is problematic. I can repeat again but at some point please read what i already stated so that i don't have to repeat myself all day :|.
Tbh, the past 5 pages or so (and the 1st few) is all I've read and I don't really feel like going over the other 10 or 12 looking for point to brainstorm when discussion is falling of deaf ears (or quietly going into an IP portfolio just like most of Blockstreams "innovations").

It has nothing to do with distributed computation we have gone over it already you and i, we are not doing distributed computations but distributed storage (Btw fun but unrelated topic, distributed computation is not simply magic and always have a minimum overhead that implies you can't distribute forever. You hit a limit at some point.). You say that there was no argument against it, do i really need to link to previous statements?
...
Distributed computing ususaly includes distributed storage along with data redundancy to allow for node faliure. So far we don't even have any kind of benchmarking in the client/MN list to even gauge how much storage the MN network has and how reliably available it is, the first step to planning out reliable distributed storage.

...
I don't know how to tell you. There are no other viable solution. Decentralization implies duplication of data. You are sticking to a wrong idea that you deduced from god knows statements someone must have made 10 years ago without even thinking of how such a prodcut can work. You have to reduce the amount of nodes, can't go around that. You want platform to succeed or it to be running on four thousand remote servers creating ridiculous overhead? Or you want a solution like ours which is decentralized and works?
...
If every additional node causes a reduction in performance then you're doing it wrong. Just because no blockchain has found a way to strengthen anything other than security by additional nodes doesn't mean it can't be done. The same issue exists in nature and nature has found ways of addressing it, every additional element makes the whole stronger and that's the kind of innovation that was once the hallmark of Dash.
 
You have been over it with QE and me both. It has nothing to do with PoSe and PoSe does not solve any of the technical challenges at hand. Have you read our answers? i want you to state that you did or i will not answer further. I want you o acknowledge this has nothing to do with PoSe.

I have no idea why you're saying PoSe (Proof of Service) when I explicitly said PoS (Proof of Stake). So what is there for me to acknowledge if you're mis-quoting me?

Your wording implies more than what you mean. There being no perfect solution doesn't mean we failed to find one.

So which solution did you find for everyone running Platform? Or did you change the problem to make your solution fit? Dash has never had more than one type of masternode, but please prove me wrong.

I don't know how to tell you. There are no other viable solution. Decentralization implies duplication of data. You are sticking to a wrong idea that you deduced from god knows statements someone must have made 10 years ago without even thinking of how such a prodcut can work. You have to reduce the amount of nodes, can't go around that. You want platform to succeed or it to be running on four thousand remote servers creating ridiculous overhead? Or you want a solution like ours which is decentralized and works?

That is fine. An admission that after 7 years, DCG has failed to deliver without adding a new node type. Just understand, the dash DAO is a legal entity and any attempt to breach it's governance system may trigger legal action.
 
I hereby request assistance / intervention from the 2022 Dash Trust Protectors:

Rodrigo Ambrissi
Simone Trustee Mascarello
Foulagi Johnson
Zane Robert Cook
Jared Matthew Lyman
Patrick Michael Quinn

---
Tag: @solarguy
 
Last edited:
@DCG

DCG seems not willing to give us an opportunity to vote on REGULAR 1K MN WITH VOLUNTARY ADHERENCE TO PLATFORM,
and an INITIAL LIMIT OF 10% or at most 20% of all MNs able to participate in Platform
, as long as we don't know whether the
Code is secure and bugfree and won't cause any freezes or collapses of MN or even Blackouts on our Payment Network making it stall
for hours or even days.
Such INITIAL LIMIT of 10% or at most 20% of MN able to participate could over time be relaxed or completely abolished, but only after
we have seen the Code is safe and secure, but still should happen gradually.
Who obtains a Platform slot could be decided on a first-come-first-serve basis or by competing on the most important aspects
of hardware resources. (Bandwidth, Space, CPU, memory etc.)

You claim too many nodes make Platform slower or too slow, oh really?
THEN WHAT MAKES YOU AFRAID OF A REGULAR 1K MN WITH VOLUNTARY ADHERENCE TO PLATFORM (and an INITIAL LIMIT to the number of nodes) ????

Its the most natural, non-coercive and sensible way of starting Platform.
But DCG has already decided against it, and therefore will not let us vote on it.
Perhaps somebody else will give us the chance to vote on it.
 
What do you guys think about time-locked 4000 DASH trustless MN shares propsed by @QuantumExplorer ?

It doesn't sound that bad to me, after all community was asking for trustless mn shares for ages. It seems better then just going 4k/10k HPMNs way.

What are the downsides in your opinion ?

Oh sorry, I forgot to answer. Imo it is the best solution. I think 10K is too much and that the best approach is iterative with lower fees such as 2-3-4K at first and gradually going up. That would be more annoying for the operators supporting platform as they'd have to upgrade perhaps twice. But that would let the occasion to see how the system actually fares and seeing how well the models translate to reality as it's complex topics with many little details that influence the outcomes. I don't see any downside to HPMN+shares as the main/sole drawback of HPMN without shares is, if you ask me, the unfairness of the selection. Sharing solves this issue.
 
For clarification purpose :

The problem that i currently have with the Platform on all nodes solution is that the safety issues as described by Sam recently are more then having the 'Platform down, all nodes down' safety issue that most of us were familiar with.

Well maybe I didn't touch on this enough during my presentation. And that's really on me. It's been talked about inside DCG so I should have included this aspect.

If a platform bug somehow completely takes Masternodes down (not just platform, but core too). In the "every node runs platform choice" that means pretty much all nodes would go down. In the 4k choice only 20% of nodes go down. In the 10k choice only 10% of nodes go down. So yeah one solution is quite a bit safer.


So there are a few safety issues that could happen. Some of them PoSe helps, some PoSe doesn't really do anything.

So let's list them out in the situation that everyone is forced to run Platform.

* 1 Entity could have too much Power - very low risk on non optional Platform - PoSe doesn't do anything.
* Nodes could propose blocks, but not respond to queries - PoSe helps a lot - this is what it is designed for.
* Platform having a bug that could take down the network - PoSe doesn't do anything.
* Not enough nodes will actually start strong enough Platform - PoSe helps a little.

* Sharding - PoSe required
* Sharding security - PoSe doesn't really help all that much.

This complicated the Platform on all nodes solution further for me and showed me that Proof of Service does not help with all the safety issues.
Which is why i made my previous comment about downvoting all three DCG decision proposals, as i previously still had hope that Proof of Service (or a simple form of Proof of Service, as mentioned by krilen) could be developed to fix the safety issue with Platform on all nodes. Unfortunetely there is currently more than one safety issue and Proof of Service does not fix in my view some of the more important safety issues.

After having heard about the safety issues with starting Dash Platform on all nodes
force DCG to start thinking of a way to use the Platform on all nodes option, without having the current safety issues form a factor.

I am referring here to all the safety issues with Platform on all nodes, as mentioned above by Sam. And it would most likely require something more then just developing Proof of Service.
 
Last edited:
The problem that i currently have with the Platform on all nodes solution is that the safety issues as described by Sam are more then having the 'Platform down, all nodes down' safety issue that most of us were familiar with.






This complicated the Platform on all nodes solution further to me and showed me that Proof of Service does not help with all the safety issues.
Which is why i made my previous comment about downvoting all three DCG decision proposals, as i previously still had hope that Proof of Service could be developed to fix the safety issue with Platform on all nodes. Unfortunetely there is currently more than one safety issue and Proof of Service does not fix in my view some of the more important safety issues.




I am referring here to all the safety issues with Platform on all nodes, as mentioned above by Sam. And it would most likely require something more then just developing Proof of Service.

Now this is a discourse that we can have, that's proper talk. Thank you for getting it back on healthier tracks for both of us and being the bigger man. I appreciate it. I should have not mentioned duffield and I apologize.


This complicated the Platform on all nodes solution further to me and showed me that Proof of Service does not help with all the safety issues.
Which is why i made my previous comment about downvoting all three DCG decision proposals, as i previously still had hope that Proof of Service could be developed to fix the safety issue with Platform on all nodes. Unfortunetely there is currently more than one safety issue and Proof of Service does not fix in my view some of the more important safety issues.

I do not understand why you would downvote our proposals if our proposals are not what worry you. To make it clear, we do not want to use all nodes, right? HPMNs do not have this issue, right? there is no safety issue on HPMNs, the only worry is whale takeover and we showed numbers that quantify how (un)likely it is. For the 1k solution of Rion, the whale takeover chance is too high. For 4/10/w.e.-K solution, this is not the case.



force DCG to start thinking of a way to use the Platform on all nodes option, without having the current safety issues form a factor.

So, so far among the more serious solutions that have been fleshed out, there was:

-all nodes (old design) -> secure for whales takeover, but if there is a catastrophic failure on Platform, it impacts DASH as a whole. And this, you cannot go around, by definition they all run platform so if platform has a bug... yeah. There is nothing to think about here. It's like asking a filled doughnut: that isn't a doughnut anymore, that's another pastry.

-1k nodes + limit the number of nodes (by rion) -> whale takover chances are way too high

-4k/10k nodes (us) -> no glaring security issue
 
Fun fact, some people actually told us they agreed with our design choice there, but they are too afraid to get the same negativity we do, so they stay silent. You are effectively creating a negative feedback loop for yourselves, and that is nothing that me or QE or anyone can pull you out from. So i will stop participating in the talk, and i will advise QE to do the same. Nothing productive anymore.

Hi Virgile, I'm new here so I'll take the hits.

I for one support QE and DCG in their recent efforts in getting platform out.

I think it's been said a few times now. QE did not make these promises to the community and has to deal with immense pressure in making it work. If their math says this is the way forward in order to preserve decentralization then unless you have better math, this is the best way forward.

What I do think DCG failed in was preparing before hand and having an extensive FAQ prepared before even approaching the community for feedback and I think the fastest they can get that FAQ out the better. I would argue that they should 100% stop responding to questions about it until it's available.

Perhaps that was not possible initially but either way it's imperative that this FAQ is released. And I reiterate that the operative word here is EXTENSIVE. ALL of the questions asked on the forums, Discord and the AMA should be in there. All of the options that "could" be voted on there should be presented as well with the caveat that these are not the final choices and if any community members have reasonable, researched, alternatives that these should be presented to the network for inclusion in the options to be voted on.

Additionally I think it's important that we get clear understanding as to how things will be voted on. While the governance system isn't ideal for this we should agree on what would be ideal so that we can find a way forward.

Lastly to all of the overly loud voices on this thread.

Please tone it down, stop shouting, stop hurling insults, stop feeding your ego's with pain. You are not being reasonable and your threats and unprofessional tantrums are not winning you over. I'm rather put off from trying to read any of your ideas when the aggression towards QE and DCG are so unnecessary. They are professional staff and they don't have to take such abuse. QE didn't promise us Evo years ago, QE took over from other non-preforming staff and honestly the ONLY reason I'm still invested in Dash is thanks to guys like QE who have no-doubt worked themselves to near death in order to deliver this promise made to us by other people. QE and Virgile are not your enemy, they all want what is best for the network so treat them with a modicum of respect or rather just keep quiet or find a new community.

I too am disappointed that in their proposal we all may not be running platform on our MNs but if the latest math says this is the best way forward and QE+DCG are thinking harder at these problems, than some of the other lesser platforms that keep going down or being hacked are, then perhaps this is the best way forward. Dash has always focused on doing the hard things the right way and that is why this has taken so long.

Personally I am VERY interested in the "masternode shares" + 4-10k solution and I think this is the best compromise we will get while also getting masternode shares, which we've all been waiting for forever as well.
 
I do not understand why you would downvote our proposals if our proposals are not what worry you. To make it clear, we do not want to use all nodes, right?

I would still prefer a Platform on all nodes solution, but because of the safety issues specific to Platform on all nodes, that has become impossible for me to vote yes on.
Specially now knowing that a possible future Proof of Service implementation does not fix all safety issues (particularly it does not fix the Platform down, all masternodes down safety issue).

4K HPM & 10K HPM are impossible for me to vote yes on, due to Platform network centralization issues / concerns.

With regards to denk and rion (and possibly still krilen) alternative solutions : i need to think more and read more about those solutions. Hopefully those alternative solutions get formalized, finalized and easily accessable for all to read later on. Currently they are a bit buried in this thread.
 
Last edited:
Does 4K or 10K collateral really solve anything, if such 4K or 10K nodes use lame connections and barely (or don't) fulfill Platforms hardware requirements?
Whales owning dozens or even 100+ 1K MN would still be over-represented in such a 4K or 10K scenario. It hardly makes any sense.

First you have to define the optimum amount of Nodes in Platform, or dynamically calculate this figure.
Then Masternodes will have to COMPETE ON HARDWARE-RESOURCE-RELATED GROUNDS to obtain one of the available Platform slots.

Changing collateralization or introducing a super-collateralized node type will only cause confusion & discrimination and ultimately serve nothing.
We only need REGULAR 1K NODES with VOLUNTARY COMPETITION ON HARDWARE in order to reach the optimal amount of Platform nodes.
 
I will be voting on the 10k option as it poses the best outcome for us from a poor set of alternatives.

Some people on this forum seem to think that the 4k and 10k solutions would be more centralised and I must admit I thought the same at first until I really thought about it. The reason why these options are not more centralised is precisely because the stake required is so high, at 10k there are few whales with enough Dash to be able to form a majority stake in Dash in order to control the Platform, so 10k is by far the safest and most decentralised option. As we go to smaller stakes, the risk becomes that a big whale could create enough nodes such that they control the network and do the bad things. This is most obviously in the 1k opt in model where MNOs choose to run Evo with 1k collaterals, if the network size were say 600 Evo 1k nodes, then our largest whale could wind up controlling a third of the network which is the threshold where they can start to mess with it.

One solution to this is to force all 1K MNs to run Evo, this keeps the network as a homogeneous blob, which the community desires, but has the following issues. Firstly, the severe burden of running evo on every MN means our effective ROI will plummet as we over pay for hosting fees, this will see attrition as the network shrinks to boost ROI. Secondly, there is an issue that a catastrophic evo fault could also halt the L1 payments chain, thirdly, the platform fees would be too high for regular people to bother with using it, thus turning platform into a still-born. Finally, the fact that Evo allows the storage of arbitrary binary data (could be CP or whatever), is a risk to MNOs that host their nodes in their own name, or connect to their VPS without first connecting to a VPN which was paid for anonymously... Well some people just might not want to run such a risky service, but with the 1K option they have no choice, this would likely result in some further attrition.

So, clearly this leaves the 4k and 10k options as the only viable options. Their benefits can be listed as follows, it's opt in, so entirely democratic, it protects the L1 payments chain from fault, it keeps the fees down on Evo which won't hinder adoption, it's more decentralised because a whale will find it harder to amass enough coins when the stake is so large to gain dominance in the network and by reducing the number of servers running Evo, the network's overall expenditure on hosting fees will be less, thus our ROI will not be impacted as it would be in the 1K option where everyone has to upgrade to far beefier VPS plans at their own cost.
 
Some people on this forum seem to think that the 4k and 10k solutions would be more centralised and I must admit I thought the same at first until I really thought about it. The reason why these options are not more centralised is precisely because the stake required is so high, at 10k there are few whales with enough Dash to be able to form a majority stake in Dash in order to control the Platform, so 10k is by far the safest and most decentralised option. As we go to smaller stakes, the risk becomes that a big whale could create enough nodes such that they control the network and do the bad things.
10k is not the most decentralized option. 1k is more decentralized than 10k. The one who has enough money in order to destroy the decentralization and control the Platform in the 1k solution, can do this more easily (or at worst at the same difficulty) in the 10k solution. If we consider the difficulty is the same, even then for the 1k solution we still have the hope that the network may be decentralized (and we can prove the level of decentralization by investigating individualities)

As long as there are a few people that can afford the 10k solution, the total staked collateral for the 10k solution will be less than the total staked collateral for the 1k solution. This makes the 1k solution a more decentralized solution, because the total stake for the 1k solution will be bigger than the 10k solution stake. So someone who want to control the network, can do it with less money in the 10k solution. Unless of course the total stake is arbitralily set identical for both 1k and 10k solutions. If the total stake is set identical for both 1k and 10k solutions, then this second argument does not apply.

This is most obviously in the 1k opt in model where MNOs choose to run Evo with 1k collaterals, if the network size were say 600 Evo 1k nodes, then our largest whale could wind up controlling a third of the network which is the threshold where they can start to mess with it.
When arguing, you mismatch the cases. You can compare (1k, 10k both mandatory). You can compare (1k, 10k both opt in). You can compare (1k opt in, 10k mandatory). You can finnaly compare (1k mandatory, 10k opt in). Each set of two elements requires a different analysis, and has different advantages and disadvantages. You cannot argue for the advantages of the (1k, 10k mandatory) set and then argue for the disadvantages of the (1k opt in, 10k opt in) set, and then come to a conclusion. This is a mismatch. You have to examine and compare each case, as a set of two elements.

Lets analyze.
(1k, 10k both mandatory). How can 10k be mandatory? We dont know the 10k whales, so we cannot force them to participate in the Platform. We may have a clue about them, but it is just a clue.
(1k, 10k both opt in). This is a possible scenario.
(1k opt in, 10k mandatory). Again, how can 10k be mandatory? We dont know the 10k whales, so we cannot force them to participate in the Platform.
(1k mandatory, 10k opt in). This is also a possible scenarion.

So the 10k solution is always opt in. And if we do not set a mandatory total collateral for the Platform to start, then the 10k solution may become tottaly centralized, because maybe we will have very few 10k whales that they will be interested.
 
Last edited:
That's assuming shared masternodes actually arrive, should some unforeseen issue crop up that would result in a very small handful of whales receiving twice the block rewards of the entire treasury. Maybe that sounds far fetched, apparently trustless masternode shares are ready to go but after the failed promises so far it's what I'm expecting.

Maybe it's time to bring up another failed promise, when do we get sporks handled in a decentralised manner? I doubt DCG would hold the network to ransom but the spork activation keys give them that option in the event of any other development teams offering alternative approaches.
 
Maybe it's time to bring up another failed promise, when do we get sporks handled in a decentralised manner? I doubt DCG would hold the network to ransom but the spork activation keys give them that option in the event of any other development teams offering alternative approaches.

Sporks are being slowly removed and DCG is working on code that will allow us to hard fork in the future without the need for the sporks, so they are working towards that goal, there's just so much other work to do and constraints on what can be done.

1666710145673.png
 
Another factor I did not mention is that we need to think about how much value is to be secured in Platform. I did the calculation somewhere else, but the payment cycle on Platform is every 18 days and every MN gets paid at the same time, so just before payment Platform will hold almost 7k Dash in credits, after payments, MNOs will move that Dash off Platform and convert it to regular Dash, so by my estimates, maybe 10k Dash (equivalent) will held on Platform, but let's say MNOs get lazy, or Platform gets super popular and many people transfer Dash into credits and there is a float of about 50k Dash worth of credits, just how much of the Masternode network do we really need to protect that value? Surely not the entire 4000 strong network? So, doesn't it make sense to assign the job of securing Platform to just a few nodes and leave the rest of the network securing damn near 11 million Dash?
 
There is a great incentive to do a good job, if you use "proof of work", "proof of service" or "proof of usefull work" (and by the way, the forum thread that mentions PouW is deleted. why??????). So you can use the above argument, when arguing in favor for the proof of work/service.

The forum thread about Proof-of-Useful Work, which retains the key benefits of PoW while consuming energy in a more sustainable way, was somehow deleted. The administrator of the forum was unable to restore the post when I asked him to. At that time, I took a snapshot of the thread, which you can find here.
 
Another factor I did not mention is that we need to think about how much value is to be secured in Platform. I did the calculation somewhere else, but the payment cycle on Platform is every 18 days and every MN gets paid at the same time, so just before payment Platform will hold almost 7k Dash in credits, after payments, MNOs will move that Dash off Platform and convert it to regular Dash, so by my estimates, maybe 10k Dash (equivalent) will held on Platform, but let's say MNOs get lazy, or Platform gets super popular and many people transfer Dash into credits and there is a float of about 50k Dash worth of credits, just how much of the Masternode network do we really need to protect that value? Surely not the entire 4000 strong network? So, doesn't it make sense to assign the job of securing Platform to just a few nodes and leave the rest of the network securing damn near 11 million Dash?

Yes, it's something to keep in mind indeed that Platform is not made for payments, credits are just here to pay masternodes for the storage services, so without checking the values/calculations, i can certainly say that your estimates are logical.
 
The forum thread about Proof-of-Useful Work, which retains the key benefits of PoW while consuming energy in a more sustainable way, was somehow deleted. The administrator of the forum was unable to restore the post when I asked him to. At that time, I took a snapshot of the thread, which you can find here.

This is VERY serious. Who deleted the thread , and for what reason?
 
Fun fact, some people actually told us they agreed with our design choice there, but they are too afraid to get the same negativity we do, so they stay silent.
Indeed, a mistake. Our positive feedback is dominated by a very negative minority.
It seems, that it needs to be spelled out in bold and all upper case: POSITIVE FEEDBACK.

With all the very good explanations from Sam, the 10k-HPMN solution seems to be the best choice for the first release. The DCG guys are smart and very patient. They listen to all feedback and try their best to evaluate other ideas. Delays are quite normal in such field of software development.

Again, keep up DCG! You DTRT!

Thanks for your efforts!
Peter
 
Status
Not open for further replies.
Back
Top