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

[QuantumExplorer]

as their reward will at minimum be equal to 1K masternodes

No this is incorrect, it's a market, so they could have lower rewards, incentivizing them to switch to 1K Masternodes.

the 1K masternodes could actually receive less rewards in comparison with 4K masternodes over time, if i remember correctly from the presentation

Well when it's a market I can't know for sure what will happen, this is an experiment that I do not think has ever been done before exactly like this. However market theory would say that the 4K masternodes would only get more rewards because of a potential risk that they would undertake. I am going to guess that the market will value this risk quite low. So maybe we would see normal MNs get 7.4% and HPMNs 7.8% or something like that.

Now lets imagine high platform usage causing rewards for HPMNs to go up to about 9%. The market would still exist, so normal masternodes would see their rewards also go up (maybe to something like 8.5%).

The Platform fees can also be set by a fee multiplier (not immediately but soon after release) so basically if we choose the 10k system and then the masternodes vote to have the fee multiplier at 6 instead of the base 2 then Masternode rewards could become quite high while users would see the same fees at they would have in the 4k system. This is really the very strong benefit of the 10k system.

But what bothers me the most is that the presentation has so much guesstimation and speculation about TPS, Fees, Equilibrium trends, Dash whales activity, while at the same time asking masternode owners to make a decision based on all that.

I really wish I could give more concrete numbers, but things just aren't at that point yet and won't be for at least another month. Waiting to be 100% sure on the numbers would push this conversation out too late. The estimations I gave were based on tests though.

 

[qwizzie]

Question : what happens to below stated Platform storage fees in case of a Dash price increase ?

Lets say Dash price increase 10x, does that mean that the Platform storage fees go 10x as well (aka Ethereum gas fee model) or does the Dash Platform team have control over these storage fees (keeping them at current fee level) in the situation of a higher Dash price ? (bull market).

Question goes for all three solutions.

I suspect the fee multiplier comes into play in such a scenario as well ? Perhaps setting fee multiplier below base 2, after Masternodes voted over it ? Or is it more dynamic and/or automated ?

 

[QuantumExplorer]

The fee multiplier will be coming from a contract in Platform where Masternode owners will be able to essentially vote on their preferred fee. If the price of Dash goes x10 or goes down masternode owners should react by changing the multiplier to keep Platform either competitive or to make sure the fees are high enough to support the network infrastructure. Fees can change once per Epoch (18 days).

 

[seanjae]

While this might seem true at a first glance it isn't. And I must admit it's not so simple to understand why.

Rewards from Platform actually will creep back through market forces back to the 1k Masternodes not running platform. Let me explain. Platform will generate profit from fees. There is the base cost for hosting a node and then there are the fee rewards. Let's call the net fee profit the fee rewards minus the hosting costs.

So if the net fee profit is very high this will in turn cause more nodes to be attracted to the High Performance nodes. More nodes being attracted will in turn leave more core rewards for 1k Masternodes.

What we are achieving here is both low fees and everyone wins. The fact of the matter is either we make hosting providers more rich or we instead allow for lower fees, and make the system more attractive.

This whole “selling point” seems nonsensical. The idea that non-mnos or 1k mnos will see the huge profits being reaped by hpmnos and decide to become a hpmno will never happen. The barrier to entry is simply to high. 400k usd for 10k and even 160k usd for 4K. It’s laughable this is being used as the justification when you look at the numbers.

Why are you worried about hosting provider profits? Who cares. That’s a personal mno decision. The community needs to know what hardware runs platform the best and individuals will make the decision to invest in the project or not. To do that, simply release platform.

 

[QuantumExplorer]

The barrier to entry is simply to high

There currently are more than twice the number of MNOs that have 4k. So while it might be a big barrier to initial entry. The network surely has enough MNOs to perform this switch.

The barrier to receive rewards from the network stands at 1k.

Why are you worried about hosting provider profits? Who cares.

Proper incentivization is very important, and it makes more people invest. If you are looking to make a quick buck by selling off when Platform is released sure you don't care about long term. But I do and I'm sure most MNOs do too.

 

[seanjae]

There currently are more than twice the number of MNOs that have 4k. So while it might be a big barrier to initial entry. The network surely has enough MNOs to perform this switch.

The barrier to receive rewards from the network stands at 1k.



Proper incentivization is very important, and it makes more people invest. If you are looking to make a quick buck by selling off when Platform is released sure you don't care about long term. But I do and I'm sure most MNOs do too.

What? Why would you sell off when platform is released. Instead I’d expect folks to participate (if they can), but not with an increased collateral requirement. That only favors a few. Also, I don’t think folks are waiting on pins and needles for platform. It will happen and we will see.

 

[vazaki3]

So we have a pool of 3500 nodes, and we randomly select 100 among them to serve the DashPlatform. This is Tendermint's implementation.
I assume in case these 100 become 99 due to a sudent failure of a node, a brand new node among the 3500 replaces the failed one.

My question is, how long the service of these 100 lasts, in case nobody among these 100 fails to provide the DashPlatform service?
Is this time customizable, or hardcoded into the code?

And I have another question.
In Tendermint (the underlying system of DashPlatform), the speed of synchronization progress does not depend on system parameters, but instead depends on real network speed.

So the question is, is there any attempt to force the masternodes to serve the network with a minimum acceptable bandwidth?

No matter how high you set the collateral fee for the masternodes that are about to host the Dashplatform, if you do not force the masternodes to serve the network with a minimum bandwidth, then the Dashplatform will fail.

The community needs to know what hardware runs platform the best and individuals will make the decision to invest in the project or not. To do that, simply release platform.

So DCG hasn't given yet the specifications for the minimum hardware and bandwidth required to run the DashPlatform? Embarassing.....

 

[vazaki3]

I believe you didn't understand. 4 top whales would only be able to stop the platform chain, not take it over, and the payment chain would be fine. Dashpay would actually continue to work as well, though you would not be able to create new contacts. Not take it over, stoping it by colluding wouldn't really give them any benefit at all. They would not be able to steal anyones money, and they would lose all their rewards, and DCG would issue a patch within a day, most likely banning them from consensus (up the network to adopt it). There are some ways we can "bootstrap" the network if it stalls because of colluding whales, but it would either mean giving one entity the power to do this, or would require a few months to build.

Are you nuts?
Instead of designing a fair protocol, your solution is "DCG would issue a patch within a day, most likely banning them from consensus" ????
What kind of awfull DCG centralization is this???????????????
For decentralized God's sake, your above quote is absolutely scary!

 

[xkcd]

And I have another question.
In Tendermint (the underlying system of DashPlatform), the speed of synchronization progress does not depend on system parameters, but instead depends on real network speed.

So the question is, is there any attempt to force the masternodes to serve the network with a minimum acceptable bandwidth?

No matter how high you set the collateral fee for the masternodes that are about to host the Dashplatform, if you do not force the masternodes to serve the network with a minimum bandwidth, then the Dashplatform will fail.


So DCG hasn't given yet the specifications for the minimum hardware and bandwidth required to run the DashPlatform? Embarassing.....

So, in tendermint you can configure the block time and it can be as agressive as once per second, but I believe on Platform it would be set once every few seconds since our network is well distributed across the planet and it takes a bunch of time to send data across the globe.

Using Tendermint | Tendermint Core

docs.tendermint.com

The way it would work is if you are running a node (PMN) that is unable to keep up with the network, then it will miss out on proposing new blocks and your pay is proportional to the number of blocks your PMN proposes, so best to keep the VPS well powered in order to keep up with the quick pace.

That said, I would caution the devs on using a a block time that is too aggressive, because it would tend to centralise the network, for example if the majority of PMN were in Europe, then nodes running in Asia might have trouble keeping up, eg in the case of 1 second block times and thus they would be dis-advantged and the PMNOs would ultimately decide the best solution is to use hosting in Europe and before long we would be centralised to the same continent and probably even the same datacentre.

 

[qwizzie]

Are you nuts?
Instead of designing a fair protocol, your solution is "DCG would issue a patch within a day, most likely banning them from consensus" ????
What kind of awfull DCG centralization is this???????????????
For decentralized God's sake, your above quote is absolutely scary!

DCG has a pretty bad reputation with issueing hot fixes within a day anyways. We are still waiting on v18.0.2 hot fix that has been created 10 days ago and which is still not released. Why are we waiting that long on a simple hotfix ? No idea.
Link : https://github.com/dashpay/dash/commits/v18.0.2

Sacrificing decentralization, security and relying on DCG for 1 day hotfixes in case security does get compromised, all in order to obtain very low Platform fees is a bad move if you ask me.

I just wish DCG was more focused right now on releasing the v18.0.2 hotfix and more focused on pushing v18.1 to release, which according to Pasta should be released two to four weeks after activation of v18.0.1 which means v18.1 should be released any day now, taking into account that two to four weeks time period (i think v18.0.1 got activated 14th of September 2022).

Link : www.youtube.com/watch?v=qXeT5mV5MJs (time stamp 1:10:08)

Something tells me DCG is nowhere near ready with releasing v18.1 to Dash Mainnet.

Again this all is not looking very promising with the claim of Sam that the High Performance Masternode solution should not delay Dash Platform or impact the Dash Roadmap too much, while DCG continues to have problems / delays with their update release schedule to this very date.

Also i worry how these highly controversial DCG decision proposals (sacrifing decentralisation and security for very low fees) could potentially backfire on DCG and their own DCG budget proposals. Masternode owners that vote can be pretty emotional with their voting, and this topic could stir some strong emotional response to DCG budget proposals that already have a very low passing (+45). When i mentioned the low voting participation in one of the DCG budget proposals (https://www.dashcentral.org/p/DCG-COMP-OCT-DEC22#comments), i did not think DCG would come up with this highly controversial topic or these upcoming decision proposals. I am not sure it is a very smart move of DCG.

 

[Adding1kDash]

Honestly a very long discussion while there is a simple question. Which is is 0,58 cents too much ? NO its not !

So it's a non starter question to begin with ! Just to be clear during the bull run ETH fees where well over 100 dollars at times !!!! and it still was processing about 13tps.

- Running it on all nodes, will be major news event, running it semi decentralized is certainly not, and even a break on dash its original promise, image in crypto is extremely important = more funding
- To add to that,sharding will come in 2 to 4 yeas ! which will lower that price multiple times +adding the option supershard, meaning if its not decentralized enough people can store the data on multiple shards instead of just one
- current storage roadmap for SSD's is looking at 5x increase in storage capacity in about 8years
- multiple battles both in cpu and gpu markets are taking place, the tech is getting faster currently by at least 10% per year.
- software optimalisations will be implemented as time goes by

All these things combined it would likely mean that 0,58cents fee will be less than 0,01cent !

In short no delay, no loss of decentralisation,

And if anybody is worried well just make very clear that the first 3 monts are open beta, its not like mainchain will stop running !?!
Maybe request all remaining dash budget for a couple of month, and just pump out querry, and stress test it, than remove all that data once the testing is done.
Don't get cold feet guys it will work ! and if all else fails, multiple networks have constantly failed such as SOL and not even a small price drop happens.

Seriously: GOGOGOGOGO

a side nodes:
Implementing schnorr signatures on the mainchain will provide a massive reduction in fees/storage as well, especially for private send transactions.

 

[Semarg]

Are you nuts?
Instead of designing a fair protocol, your solution is "DCG would issue a patch within a day, most likely banning them from consensus" ????
What kind of awfull DCG centralization is this???????????????
For decentralized God's sake, your above quote is absolutely scary!

Absolutely agree. Not only this quote is scary but also this sudden sharp move to centralization and imminent voting they force us to make scare me to the bone. I have never been so unsure in the Dash's future and I'm in Dash since 2017.

 

[kot]

Why this discussion even takes place?

There is no reason to discuss this HIGHLY theoretical matter.
There is no platform in place.
There is no dapps in place.
There is no confirmed problems with the platform performance.
There is no data in place, confirming necessity to implement different type of nodes.

Don’t waste your time for the discussion that makes no sense at this moment. Focus your efforts on delivering platform to mainnet, using the existing network architecture.

 

[Semarg]

Why this discussion even takes place?

There is no reason to discuss this HIGHLY theoretical matter.
There is no platform in place.
There is no dapps in place.
There is no confirmed problems with the platform performance.
There is no data in place, confirming necessity to implement different type of nodes.

Don’t waste your time for the discussion that makes no sense at this moment. Focus your efforts on delivering platform to mainnet, using the existing network architecture.

I wonder if it's the case for Trust Protectors to interfere. Could someone attract their attention please? If Sam so eagerly wants network to vote on this subject then TPs could at least postpone the voting until after the release and some data collected, make devs focus on release. Do not waste last money to one more sideback issue.

 

[qwizzie]

I have a suspicious feeling that Sam is more interested in the Discord MNO channel and feedback he is receiving from masternode whales there, then from the very negative feedback he is receiving here. Kinda explains his initial decision to launch three decision proposals right away, despite the very negative response in here.

Anyone keeping taps on that Discord MNO channel ? What is the mood / preference there ?

 

[QuantumExplorer]

I am concerned about the negative feedback here. But I am also concerned that people for some reason think that there is some ill motivation at play. My role, and DCG's role is to serve the network. My incentives are that the Dash network does well. I am here in good faith to try to explain why a certain system might improve things, but I am not here trying to force anything down anyone's throat. I will do my best to respond to questions and rectify some things that were said in error.

So far the results of the poll inside DCG (it's the weekend):

All nodes running it : 0 votes.
4k collateral: 3 votes
10k collateral: 0 votes
4 or 10k collateral (doesn't matter): 2 votes
All nodes or 4k collateral: 1 vote
All options work for me: 1 vote

 

[QuantumExplorer]

So DCG hasn't given yet the specifications for the minimum hardware and bandwidth required to run the DashPlatform? Embarassing.....

In the presentation we did give these:

 

[QuantumExplorer]

Are you nuts?
Instead of designing a fair protocol, your solution is "DCG would issue a patch within a day, most likely banning them from consensus" ????
What kind of awfull DCG centralization is this???????????????
For decentralized God's sake, your above quote is absolutely scary!

Are you saying we are not allowed to propose software that would restart the network if it came under attack? What's your alternative?

 

[Semarg]

Sam @QuantumExplorer why not make the release first? @kot has made a good point: the moment you chose to make a fundamental change in ecosystem, kicking hundreds of MNOs out of Platform, drastically changing cash flows and investment value - seems not very good. Not to say that such decisions must not be made in such a hurry, but I also fear that without the first dapps in the next several months DCG will simply run out of money. It might run out of money anyway - I just don't see any other option not to sink in depths of coinmarket for good. Dapps (with any fees) have the potential to change the wind, another delay has a potential to ruin the whole project. With dash=5usd there will be no devs to implement any decision made and masternoding will lose any economic sense still left. Since a certain point of price lowering there will be no coming back. So, please, focus on release, put that HPM-thing in queue.

 

[QuantumExplorer]

Again this all is not looking very promising with the claim of Sam that the High Performance Masternode solution should not delay Dash Platform or impact the Dash Roadmap too much, while DCG continues to have problems / delays with their update release schedule to this very date.

Here's the thing, this change is somethings like 15 lines of code. We'll spend 1 hour on Monday writing it. I'll time one dev to see, so we can dispel any thoughts that it might delay anything.

With Glenn's (our ex CFO) departure I was forced to spend a considerable amount of time dealing with things like actually paying people, changing systems from Glenn to me and or other management. This was very time consuming on top of coding and a lot of other things. I'm not really trying to excuse myself, however there are only so many hours in a day, so I just was not on top of things on the core side. It is true that it's just terrible that v18.0.2 isn't out yet. I just had a call with the core payment chain devs. v18.0.2 will be out on tomorrow. v18.1 will be have a Testnet release on Monday. (Infra might deploy it on Tuesday).

 

[qwizzie]

I am concerned about the negative feedback here. But I am also concerned that people for some reason think that there is some ill motivation at play. My role, and DCG's role is to serve the network. My incentives are that the Dash network does well. I am here in good faith to try to explain why a certain system might improve things, but I am not here trying to force anything down anyone's throat. I will do my best to respond to questions and rectify some things that were said in error.

So far the results of the poll inside DCG (it's the weekend):

All nodes running it : 0 votes.
4k collateral: 3 votes
10k collateral: 0 votes
4 or 10k collateral (doesn't matter): 2 votes
All nodes or 4k collateral: 1 vote
All options work for me: 1 vote

Ok, that does indeed establish censensus for the High Perrformance Masternode solution among the Dash Platform team so far (mostly for the 4K it seems)
Thank you.

Here's the thing, this change is somethings like 15 lines of code. We'll spend 1 hour on Monday writing it. I'll time one dev to see, so we can dispel any thoughts that it might delay anything.

With Glenn's (our ex CFO) departure I was forced to spend a considerable amount of time dealing with things like actually paying people, changing systems from Glenn to me and or other management. This was very time consuming on top of coding and a lot of other things. I'm not really trying to excuse myself, however there are only so many hours in a day, so I just was not on top of things on the core side. It is true that it's just terrible that v18.0.2 isn't out yet. I just had a call with the core payment chain devs. v18.0.2 will be out on tomorrow. v18.1 will be have a Testnet release on Monday. (Infra might deploy it on Tuesday).

Please also check how this affects voting in our governance model (4 votes instead of 1).
Looking forward to the release of the v18.0.2 hotfix on Dash Mainnet and hopefully a somewhat timely release of v18.1 later on.

 

[QuantumExplorer]

Why this discussion even takes place?

There is no reason to discuss this HIGHLY theoretical matter.
There is no platform in place.
There is no dapps in place.
There is no confirmed problems with the platform performance.
There is no data in place, confirming necessity to implement different type of nodes.

Don’t waste your time for the discussion that makes no sense at this moment. Focus your efforts on delivering platform to mainnet, using the existing network architecture.

Let's imagine just for a second that Platform were to go down taking down all nodes with it. Chainlocks would fail, IS would fail, Coinbase would no longer process deposits... This could be catastrophic. Most blockchains have glitches when they are released. So if I just release and see and then something bad happens, pitchforks will be out. I am proposing a high value extremely low cost option that allows us to release with the utmost safety.

 

[qwizzie]

Let's imagine just for a second that Platform were to go down taking down all nodes with it. Chainlocks would fail, IS would fail, Coinbase would no longer process deposits... This could be catastrophic. Most blockchains have glitches when they are released. So if I just release and see and then something bad happens, pitchforks will be out. I am proposing a high value extremely low cost option that allows us to release with the utmost safety.

Does this mean if masternode owners choose the 1K option (Dash Plaform on all nodes), there is actually a security risk or safety issue ?
I thought this topic is all about having lower fees / higher TPS or not, not about having an actual security risk or safety issue when proceeding as orginally planned.

Let me put this bluntly : If masternode owners vote for the 1K solution, is there a safety issue then at play ?
A safety issue different from any normal large Dash software update with a hard fork / spork in it ?

 

[QuantumExplorer]

Does this mean if masternode owners choose the 1K option (Dash Plaform on all nodes), there is actually a security risk or safety issue ?
I thought this topic is all about having lower fees or not, not about having an actual security risk or safety issue when proceeding as orginally planned.

Let me put this bluntly : If masternode owners vote for the 1K solution, is there a safety issue then at play ?
A safety issue different from any normal large Dash software update with a hard fork / spork in it ?

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.

 

[qwizzie]

This just shows how important it is to do a Dash Platform security audit. Which was orginally planned and then later scrapped by DCG due to shortage of funding / reallocating that Dash Platform security audit funding to DCG Infrastructure.

Maybe we should rethink that DCG decision to not do a Dash Platform security audit.
Doing a Dash Platform security audit, would make the Dash Platform launch inherently more safe.

I am pretty sure if DCG puts out a request for funding of a Dash Platform security audit, it would meet little resistance.

One could even say that by not doing a Dash Platform external security audit, the responsebility in case of a major network threathening bug popping up at launch, will indeed rest solely on the Dash Platform team / DCG, regardless which solution we vote on.

 

[QuantumExplorer]

"reallocating that Platform security audit funding to DCG Infrastructure" -> Well it mostly went to the core audit. Which basically didn't reveal any security flaws that we didn't already knew existed (2 minor issues, we will get around to fixing them).

The reason why I don't think it's a good idea at this point to do a security audit of platform is that it will cost an arm and a leg, and will most likely reveal nothing. There are undoubtably flaws, but to find them you need the best. The best are running the blockchain projects, not doing audits. Frankly put I do not think an external team putting in a few hours here and there will be able to find stuff our team hasn't. Which is what happened in our core audit, we knew of all issues that they "found".

 

[qwizzie]

The difference between Core and Platform is that Core has been externally audited before, has been thoroughly analyzed over the years, has had developers who forked Dash chiming in from time to time on Github, while Platform consists mostly of new code that has never been audited before and does not get much attention from outside developers (i am not even sure they know where to find it).

Even Ethereum had their large update to Proof of Stake externally audited. Most projects externally audit their own very large updates that have such instrumental changes to their project.

 

[QuantumExplorer]

We are going to have each team rotate and review code that they never had seen before. I personally think this will actually work better than an external security audit, mostly because our teams will care more, whereas most external auditors are employees working on multiple projects at once. Passion coupled with intelligence goes farther than doing things to make things "look" better. An external audit imo would just give a false sense of security if nothing was found.

A better security model is being able to prove mathematically that nothing can go wrong. Which is what we are trying to achieve for example with the sum trees (A Dash invention) which will make inflationary bugs pretty much impossible.

 

[qwizzie]

We are going to have each team rotate and review code that they never had seen before. I personally think this will actually work better than an external security audit, mostly because our teams will care more, whereas most external auditors are employees working on multiple projects at once. Passion coupled with intelligence goes farther than doing things to make things "look" better. An external audit imo would just give a false sense of security if nothing was found.

A better security model is being able to prove mathematically that nothing can go wrong. Which is what we are trying to achieve for example with the sum trees (A Dash invention) which will make inflationary bugs pretty much impossible.

Why not do both ?

Do an internal security audit through internal team rotation
Do an external security audit through a third party ?

I really don't understand the hesitance to doing an external security audit of Dash Platform, are the devs that confident that they will find all the bugs ?
To me it comes across as overconfidence in the team's own capabilities of finding all the bugs and underestimating possible bugs at launch they simply did not think of.

There was a reason that a Dash Platform security audit was initially planned, did that reason suddenly became obsolete ?
Its just weird in my eyes, the motivation of DCG for not doing a Dash Platform external security audit.

Anyways with DCG not willing to do a Dash Platform external security audit, it makes any possible safety or security issue at launch much less of an issue for masternode owners to take into consideration, for any of the three solutions they will have to vote over.

It will automatically fall under the DCG responsebility, because DCG explicitely did not want to do an external security audit of Dash Platform.

 

[QuantumExplorer]

The hesitance is because the best quote we got for a partial review was 120k USD. That's about 3k Dash. Second factor is that takes a lot of time to find the right firm, make sure they are up to the task, then have many many calls to make sure they understand things. This all introduces delay, and imo for nothing, as we are better served with internal audits + bounties for finding issues. I basically don't want to waste time and money.