An alternative to consider:
1. Make running platform services optional
2. Require collateral lockup
to run a platform masternode.
3. Maintain 1,000 DASH collateral
requirement for all
- 1,000 DASH for core masternodes (as current/normal)
- 1,000 DASH locked
for platform masternodes (see below for lock time considerations)
4. Launch conservatively
and limit participation
(do a beta launch)
- high initial lock time period (e.g. 1 year)
- low initial platform node allocation (e.g. 10% of masternode allocation)
5. Refine over time
- observe data (costs, performance, stability, which nodes have upgraded, etc)
- fix bugs and adjust consensus variables until dialed in:
- decrease lock time period (e.g. to 6 months) to increase node count (e.g. to 400 nodes)
- increase platform allocation (e.g. to 20%) to increase node count (e.g. to 600 nodes)
(numbers not set in stone, just for illustration)
View attachment 11467
1. Increasing collateral requirements is coming out of nowhere and it seems many MNOs don't like the idea
- Some don't like being denied the opportunity to operate
the very thing they've been waiting for and supporting
for many many years.
- Some don't like it because it sets up an "elite" class
above normal masternode owners, even if they can
be a part of the new class.
- Some don't like it for security reasons
(more on that below).
2. This solution satisfies the main stated goals
of the "high performance masternode" proposal:
- It reduces platform costs
by lowering the platform node count.
- It gives platform node operators the financial incentive/ability to operate high performance nodes
- In the case of a catastrophe, platform nodes won't take down the payment network
, since node count is limited.
- It can mitigate the risk of multiple platform nodes dropping off
with staggered time locks.
3. It is arguably more secure
than the "high performance masternodes" proposal
- We can fine tune the node count as high as we want
, in an easier way than adjusting allocation requirements.
- Requiring locked collateral reduces the risk of centralized exchanges
(e.g. Binance) and 3rd party custodial operators operating many platform nodes. 3rd party custodians likely can't lock their customers' funds. This would likely increase the number of entities
operating platform nodes. Entity count is far more important than node count for security.
- Other large whales (besides 3rd party custodians discussed above) would likely not lock up all their funds either. They would probably either stagger their collateral locks, or simply operate a mix of normal and platform nodes to maintain liquidity of some portion of their stash.
4. It is more "fair"
, by making operating a platform node financially accessible (or at least far more so). Even though "fairness" is subjective and not measurable, it's still one of the most important factors in terms of how the project is viewed.
5. It is more conservative
. Dash has always had a 1,000 DASH masternode collateral requirement. Adding locking is a less "heavy handed" change than 4x-ing or 10x-ing the cost to run a masternode.
5. This would give the whole network
(not just platform nodes) more economic security and certainty
because we would have hard data about a portion of Dash that is actually
locked (not just collateralized in masternodes) for any given time (now and into the future). This could bring more investor interest
to Dash in the same way this does for vesting (locking) schedules for tokens and traditional equities.
6. In addition to the increased quantity
and diversification of entities running platform nodes discussed in item 3 above, locking would also increase the quality of entities
running platform, since only the most committed (not just the richest) node operators will be willing to lock their collateral. The whole point of security considerations is to prevent attacks from bad
actors. If you can reduce the number of bad
actors in your node set then lower count is not necessarily lower security - it can actually yield higher security. MNO quality > MNO quantity.
One concern with this is: will MNOs be willing to lock their collateral
, or will they be just as upset with that new requirement as they are with the increased collateral requirement? A few days ago I created a poll on Discord
to assess this willingness, and I think the numbers speak for themselves:
View attachment 11468
So, should we explore this idea more? I'm not fully convinced it's the best option, but I think it's worth fleshing out, to possibly include it in next month's proposed options.
For the record, I'm more in favor of the 4k or 10k collateral platform node options than requiring all masternodes to run platform, so big thanks to Sam and DCG for bringing up and discussing this difficult decision.
Also, I plan to chat with @virgile
about security calculations. I've looked at the modifications he made to my original model (screenshot above), and they mostly make sense to me, but I need a couple clarifications before I can model my proposed solution in a similar way that he did for DCG.