Proposal “Evo-Accelerated-Release-Schedule“ (Closed)Back
| Title: | Evo Accelerated Release Schedule |
| Owner: | quantumexplorer |
| One-time payment: | 1 DASH (24 USD) |
| Completed payments: | no payments occurred yet (1 month remaining) |
| Payment start/end: | 2024-06-09 / 2024-07-09 (added on 2024-06-11) |
| Final voting deadline: | in passed |
| Votes: | 460 Yes / 222 No / 21 Abstain |
Proposal description
Proposal Overview:
Recently, there have been many calls from community members upset that Platform has still not been delivered to Mainnet. While we are doing our best effort to release as soon as possible we also understand the frustration of community members that have been waiting for this for a very very long time.
This proposal is for an accelerated release schedule. I would like to be clear that we have never been in a position to make the proposal I am about to make but we are now. If this proposal were to pass we would cut not only things that were non essential, but also some features that currently exist or are very close to being done but that need more testing. We would also cut down our self review time.
One thing that everyone should understand while reading this proposal is that our code quality is very high, but on 600k to 1 Million lines of code, it is almost impossible for there to be no issues. The more time we spend on trying to find them the more diminishing returns we will get. This means that we will find many issues in the first month, then less issues in the second and so forth. Decreasing the review time will potentially leave more issues to be found while on Mainnet.
One can see such a release as a Mainnet Beta.
By doing this we could release the project in middle July and hopefully see an activation by Masternodes a few weeks later. Before release we would work heavily on chain halt recovery mechanisms to make sure that we can quickly recover from a chain halt.
The benefits of this proposal passing:
The issues with this proposal passing:
After the initial launch our main priority after stabilization would be state sync and withdrawal activation, then additional reviews and fee improvements.
I would like to emphasize that DCG is striving to best serve the wishes of our community. It is far from known to me if the majority want a safe and slower approach or a more aggressive approach that is laid out in this proposal.
As this is not a monetary proposal, DCG will follow the wishes of 2/3rds of the voting network. Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.
If this proposal does not pass by a long margin we will continue our previous plan and release with withdrawals and state sync completed, and with our self reviews completed.
If we see that the network is more evenly split we will try our best to find a compromise solution that we will present each month. Like this as time goes forward and as more and more features get more stable (withdrawals/state sync/documentation…) we can release once we have buy-in from 2/3rds of the voting network.
If you have any questions, please direct them to quantumexplorer at dashcentral or on discord.
Recently, there have been many calls from community members upset that Platform has still not been delivered to Mainnet. While we are doing our best effort to release as soon as possible we also understand the frustration of community members that have been waiting for this for a very very long time.
This proposal is for an accelerated release schedule. I would like to be clear that we have never been in a position to make the proposal I am about to make but we are now. If this proposal were to pass we would cut not only things that were non essential, but also some features that currently exist or are very close to being done but that need more testing. We would also cut down our self review time.
One thing that everyone should understand while reading this proposal is that our code quality is very high, but on 600k to 1 Million lines of code, it is almost impossible for there to be no issues. The more time we spend on trying to find them the more diminishing returns we will get. This means that we will find many issues in the first month, then less issues in the second and so forth. Decreasing the review time will potentially leave more issues to be found while on Mainnet.
One can see such a release as a Mainnet Beta.
By doing this we could release the project in middle July and hopefully see an activation by Masternodes a few weeks later. Before release we would work heavily on chain halt recovery mechanisms to make sure that we can quickly recover from a chain halt.
The benefits of this proposal passing:
- Platform will be released three weeks after this proposal passes.
- We will move more quickly to an iterative release cycle.
The issues with this proposal passing:
- The likelihood of Platform actually having an issue that would cause the chain to halt is higher, my personal estimate is that this chance of chain halt would increase from about a third chance to two thirds chance within a month of release.
- Evonode operators would need to be very attentive and upgrade asap as soon as new releases happen.
- We might see urgent bug fix releases outside of the scheduled release cycle, which would require evonode operators to react in a timely manner, and might be seen as chaotic.
- We would disable withdrawals from Platform until I personally have reviewed every line of code there (something that I was previously planning to do before release). Enabling them would mean a new release (DCG can not enable or disable, only the network can do that through a version upgrade).
- We would set fees higher and more conservatively to lower the chance of attacks on the network as we will not actually know what the ideal fees are.
- The state sync feature is almost done, but almost is not done. In this accelerated release schedule there would be no state sync, new nodes would have to “catch up” which could lead to nodes needing multiple days to sync, even after just a few months, but only in the case of high usage.
- There would be no fungible token support for MVP, which are needed for stable coin support. This was not something that was in the roadmap for pre-mainnet, but something we were still vying for if we were able to do it.
- Documentation will not be as complete.
- Because of sum trees, the likelihood of loss of funds in the system itself is extremely low (except for social attacks and scams that obviously can not be prevented at the protocol level).
- We would still have NFT support.
- All the advanced features of Platform that we have been talking about for years would still be there (absent the ones mentioned above).
- We would still have masternode voting and the features needed for Dashpay to work properly.
- We would still have an iterative approach for data contract release. Dashpay data contract would be set to activate 1 or 2 weeks after Platform activation.
- The RS-SDK will be released as a beta.
- The JS-SDK will be usable as an alpha.
After the initial launch our main priority after stabilization would be state sync and withdrawal activation, then additional reviews and fee improvements.
I would like to emphasize that DCG is striving to best serve the wishes of our community. It is far from known to me if the majority want a safe and slower approach or a more aggressive approach that is laid out in this proposal.
As this is not a monetary proposal, DCG will follow the wishes of 2/3rds of the voting network. Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.
If this proposal does not pass by a long margin we will continue our previous plan and release with withdrawals and state sync completed, and with our self reviews completed.
If we see that the network is more evenly split we will try our best to find a compromise solution that we will present each month. Like this as time goes forward and as more and more features get more stable (withdrawals/state sync/documentation…) we can release once we have buy-in from 2/3rds of the voting network.
If you have any questions, please direct them to quantumexplorer at dashcentral or on discord.
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
IMHO it was all very clear. And it seems, that qwizzie was the only one, who had difficulties, or not?
To those that voted no on this proposal, I would like to say that I hear and share your strong desire to have a clean release and activation that does not result in a chain halt. I will take this into consideration as best I can with the blog post tomorrow.
It would have been far better and far more easy to understand for everyone, if simple majority voting was used on both measuring 2/3 support of the voted network and on simple majority voting 2/3 support of only Evonodes.
That would mean :
yes votes of Masternodes / yes+no voted Masternodes (voted netwerk) : around 68%
yes votes of Evonodes / to yes+no voted Evonodes (voted netwerk) : around 68%
Instead we now have this very complicated ruling where QE does :
yes votes of Masternodes + yes votes of Evonodes x4 / yes masternodes + no masternodes + yes masternodes x4 + no evonodes x4 (voted network) : around 68%
yes votes of Evonodes compared to yes+no voted Evonodes (voted netwerk) : around 68%
(scroll all the way to the end, and then go up untill you see 'use extended comparison between method 1 and method 2 with the numbers and percentages'
This shows why QE should not have mixed weighted voting with simple majority voting and more importantly shows why using simple majority voting on masternodes and evonodes (so two seperate groups, each representing its own voted network), is really the better way in this case.
Stop calculating the POSE_BANNED masternodes in the electorate.
Source: https://mnowatch.org/votethenumbers/votethenumbers3/calc3.php?proposals%5B%5D=Evo-Accelerated-Release-Schedule
Report: the_results_dashd_2024-06-21-14-41-47.html.csv
* count yes votes of masternodes and compare them to total of voted masternodes (yes+no votes)
* count yes votes of evonodes and compare them to total of voted evonodes (yes+no votes)
However yesterday pmbf posted on Discord a different interpretation of the proposal text
"2/3rds of the voting network": ALL nodes
"2/3rds of voting Evonodes": only Evonodes
*** Which QE gave a point up to ***
This would mean that the yes votes of evonodes are getting counted twice, 1x in all nodes and 1x by only counting yes votes of evonodes. This will completely change the weighing of the yes votes of Evonodes and also gets you a much higher percentage for yes votes for Evonodes from the start.
My script currently is set to fetch the current votes as follows :
Total count of voted Masternodes : 243
- Yes: 159 (simple vote majority : 65.43%)
- No: 84
- Abstain: 13
Total count of voted Evonodes : 91
- Yes: 65 (simple vote majority : 71.42%)
- No: 26
- Abstain: 2
However if QE indeed count the yes votes of Evonodes twice, that would change it to :
ALL voted nodes (Masternodes+Evonodes)
Total count of voted Masternodes + Evonodes : 243 + 91 = 334 total voted nodes
159 yes votes from Masternodes + 260 yes votes of Evonodes (65*4) = 419 yes votes in total
Percentage : 334/419*100 = 79.7%
Only Evonodes : 71.42%
As I read it, the two ways of counting were as a group (MNO plus EvoMNOs require 2/3 simple majority ) and EvoMNOs needing to achieve 2/3 simple majority. The reason being that QE did not want to strong arm half of the network (the EvoMNOs) into forgoing payments for a possibly substantial amount of time.
We need enough EvoMNOs to upgrade and run despite the fact that they won’t get paid for 6+ weeks to an unknown number of weeks. So we need to see willingness of the EvoMNOs to go for this.
votes from regular 1K Nodes will most likely not even count for this proposal.
the silence of QE is not exactly helpful either.
this proposal will only consider votes from 4K Evonodes, and it requires 2/3 as in YES/(YES+NO) in order to be approved.
How do you translate that to '1K Nodes most likely not even count' & 'only consider 4K Evonodes' ?
Actually after thinking about it a bit, that should just be :
This will completely change the weighing of the yes votes and has an affect on the percentage.
(159 + 4 * 65) / (243 + 4 * 91) = 69%
Count of YES votes: 159 + 4 * 65
Count of ALL votes: 243 + 4 * 91
If you do 4*91 you are saying that instead of 91 evonodes casting a vote, now suddenly 364 Evonodes casted a vote. That is simply incorrect. You can't multiply the 91.
Divide and conquer.
Quantumexplorer by continuously using the divisive election method, he drives people away from the community and will eventually end up voting only himself.
More info about the difference of the inclusive and the divisive election methods can be found here:
https://www.dash.org/forum/index.php?threads/pre-proposal-would-you-like-this-proof-of-individuality-to-be-implemented-in-dash.15946/page-6#post-235992
When he eventually proposes a switch to 10K "HPMN"s, he will likely pull the same shit again and exclude 1K nodes.
On the plus side, the more bullshit he spouts as a dao influencer, the deeper the whole he makes for himself.
June is here and that announcement is now a proposal to "accelerated release schedule". It's a verifiable fact and not some weird out of context statement. The PO literally said this.
By creating this proposal, the PO is diluting blame to MNOs for the upcoming chain halts, that were never previously declared on a balance of probability.
Indeed, whatever the rules are for this passing, it is the POs rules without reaching consensus as written in the computer code of the dashd daemon. More so, said code is managed by DCG for whom the PO represents.
This all makes me very worried about his statement of enabling withdrawals within 6 weeks after activation of Platform on Mainnet.
Trust has been broken and needs to be rebuild.
First step to rebuilding that trust :
* actually release on 29th of July 2024
* actually enable withdrawals within 6 weeks after activation of Platform on Mainnet
* make Core & Platform release cycles shorter and deliver on what is suppose to be in those releases.
We have 100 people.
He uses the 2/3 divise election method.
33 of them are disatisfied and leave the community .
Then he uses again the 2/3 divise election method.
22 of them are disatisfied and leave the community .
Then he uses again the 2/3 divise election method.
15 of them are disatisfied and leave the community .
So after 3 times the divise election method has been used, how many people remain?
Only 30!!!!
Thats what quantumexplorer is doing to the Dash community, and the stupid masternodes tolerate him.
It needed 66.66% and it got 66.42%.
https://mnowatch.org/votethenumbers/votethenumbers3/calc3.php?proposals%5B%5D=Evo-Accelerated-Release-Schedule
Electorate = 3434 potential votes (Regular and Evo MNOs)
ValidVotes = 685
Voting participation = 19.94 %
---VOTING RESULTS (depends on which among the below election methods you prefer.)---
( VOTED_NO=0, VOTED_ABSTAIN=1 and VOTED_YES=2)
---Divisive Election Methods---
Most Voted Number = 2 (or 2 base3) was voted by 455 votes ( 66.42 % of the valid votes )
---Inclusive Election Methods---
Median Average = 2 (or 2 base3)
Mean Average = 1.35
https://mnowatch.org/queries/query3/query3.php?iphash=iwashikujira
Billions of dollars were spent on this, and for this huge amount the robot could at least crawl. With a stick in the ass, but crawling.
The developers spent a fantastic budget, everything is great ;)
So, we ask you, the platform developers, to release it as soon as possible, in June-July, even if the platform is on crutches and with a stick in its ass.
We want to see at least some result.
DCG has historically wiped platform data and started the platform chain from scratch when there are issues. That's what concerns me the most. We can't do this on mainnet. I'm assuming that DCG knows how we can recover from chain halts or other issues without losing any data, otherwise they wouldn't have submitted this proposal.
I feel the benefits of moving to mainnet on this schedule outweigh the risks. The only people I know of that are looking at Dash Platform right now are our own (mostly funded) developers who know of and can work with Platform instability. Regardless, the best way to improve reliability is to move to mainnet.
It's good that DCG submitted this proposal. They're giving us a firm and explicit launch date via an official proposal. I think that's a first; they must feel confident that the worst case scenario is manageable. Let's take the offer!
Once Evo goes mainnet and the kinks have been worked out (and price improves), you can start building out your product management vision/goals.
* incomplete (missing enabled withdrawals and statesync)
* likelihood of Platform actually having an issue that would cause the chain to halt is much higher (2/3 instead of 1/3) within a month of release !!
* has severe revenue implications for Evonodes specifically (who will not have access to 75% of their masternode rewards for an uncertain time period). The promise of enabling withdrawals within 6 weeks after activation of Platform contains zero certainty, i could easily see withdrawals enabling getting delayed beyond 6 weeks, specially with a Platform stabilization period in play now.
Most of the above can be avoided by just waiting 1 month, after which QE will make a new decision proposal with enabled withdrawals and maybe state sync as well (although the last one is appearently not that essential during the first phase of release, activation, bugfixing and Platform stabilisation).
Lets all remember how we got to this point, where after all this time Dash Platform is still not quite complete after three long years under new leadership and who exactly are responsible for that. We could not show progress for 3 years to potential partners, one month will not matter.
If this proposal does not pass, don't blame Evonode owners, blame DCG.
It's never just one month.
"I could easily see withdrawals enabling getting delayed beyond 6 weeks"
You always have the option of turning your EvoMN to a regular MN temporarily if you need the rewards to pay for your everyday things. Yes, it wouldn't have as high an APY but this sacrifice may be needed to get Evo done. We should see better incentives and pressures to get things done faster once we're in mainnet.
It is a feature to be integrated into a new Core update that will handle :
* Masternode Reward Location Reallocation (a large portion of the masternode rewards will be moved to Platform and distributed as credits among Evonodes)
* Enhanced hard fork implementation (this will affect Dash next hard fork)
Maybe during the next two-weekly Sprint review the Core team / Pasta can discuss this specific feature with more details.
How was a July release ever even a realistic estimate for Platform release, when withdrawals needed at least 6 weeks of review, could never be publicly tested on Testnet before (as it never was part of the testing phase) and there was also talk about needing 1 month additional time to fully test Platform on Testnet by QE himself (to trie to break it himself).
I have lost all confidence in any estimate from DCG with regards to a timeline when it comes to Platform, including the estimate of withdrawals getting enabled within 6 weeks after activation of Platform.
Also while you say: "is still not quite complete after three long years under new leadership". Why don't you ask an AI based on the amount of code we now have and the resources we had if we have done a good job. We didn't have unlimited resources like some bigger projects. I couldn't hire ten 300k/year devs. I hired new faces with the resources we had, and we built a very innovative project, and this only the beginning.
In the end I actually think that you are mistaken when you think we did a bad job. The price is not great I agree, but what has been built is great.
Yeah, let's not just not blame anyone. The price of dash is currently 24.23 USD but that's just one more thing to conveniently ignore. If you'd had concentrated on "digital cash" the price of dash could of been much higher and paid for the devs you claim not to afford. How do I know this? - because this price low can't be any f*ing worse. I'll correct that, I maintain my original prediction of 14 USD. What can you afford to maintain at 14 USD?
You say you have no control of the price yet remain the mouthpiece for DCG, bringing "decision" proposals while inventing your own rules for each. That is not the definition of a dao, it's the output of a company describing their product as a "protocol" when it's not.
Want to prove me wrong? - then show me a fully independent evonode daemon.
Unfortunetely MNO's patience have by now completely ran out (totally understandable). We will see if Evonode owners can stretch their patience with one more month, or if they feel the same as MNO's.
That being said, I'm in favor of releasing as soon as possible. I believe that every day that passes without a release of some kind affects our reputation and price in a negative way.
Something else to note is that for eMNs they will be paid once per cycle on the L1 chain, however, 3/4 of their payment will be held on Platform with no ability to withdraw for the first month or so, until that code is activated in a future release.
Also, I spoke with QE and to clarify the voting, it needs a 2/3 majority calculated as (YES/(YES+NO)), key things to note is a vote to ABSTAIN is same as no vote at all. A NO vote does not negate a YES vote. The proposal does not have to reach 'funding' in order to pass. However, I am not clear if both regular MN and eMN need to hit 2/3, or if it is just the eMN votes that count, anyway, check out qwizzie's forum post with a nice script to create the tallies on the fly.
Another thing, in case this proposal fails, it does not mean Evo will be delayed for months on end, either way, we release in July or August, what changes is just how functional the expedited release is and how great the chance is it has a bug that causes the chain to stall.
Also, note that as yet DCG have not tested network upgrades on testnet yet, to date, they always wiped and started over, this remains to be done and we don't know for sure that the network will be able to smoothly upgrade once activated, it might be worth testing that before release.
Only votes of 4K Evonodes will be considered and it can only be approved by a majority of 2/3 of voting 4K Evonodes, regardless whether it reaches the funding threshold or not. For sure the strangest of all proposals so far.
If 1K Evonodes do not reach 2/3 support : proposal does not pass
If 4K Evonodes do not reach 2/3 support : proposal does not pass
'As this is not a monetary proposal, DCG will follow the wishes of 2/3rds of the voting network. Because Platform activation would require 2/3rds support from Evonodes, we will also need 2/3rds of voting Evonodes in support as well to see this proposal as passing.'
Looks like we can check for ourself how Masternodes and Evonodes are currently voting and how close to 2/3 support each one is, through the Dash Core wallet - Console.
gobject list : you get a list of all active proposals with their hash
gobject getcurrentvotes hash : you get all the current votes of a specific proposal, if it end with 1 it is the vote of a Masternode, if it end with 4 it is the vote of an Evonode.
To get the current votes of this specific proposal :
gobject getcurrentvotes 615d8a6d4edafdcee65ff16ab9c7bacef6f5d1b1096466c0957f0441287dcc90
Currently 21 Evonodes voted so far with 4 votes. With 13 yes votes and 8 no votes.
(Evonodes are a smaller group, more easy to count votes)
It only becomes clear if there is also 2/3 support among Evonodes for this proposal, once the voting deadline has passed (9 days from now). Most of the voting happens in the last few days of the voting deadline.
See : https://www.dash.org/forum/index.php?threads/shell-script-to-fetch-masternodes-and-evonodes-current-voting-on-a-certain-proposal-through-dashmate.54991/
https://www.dash.org/forum/index.php?threads/shell-script-to-fetch-masternodes-and-evonodes-current-voting-on-a-certain-proposal.54991/#post-238678
The script on post 1 can be used for normal budget proposals with super majority (yes-no)
There are NO governance proposals, none of the dash software recognizes such thing. All proposal payments _require_ a minimum monetary dash output greater than zero.
The rules for proposal payments and the rules YOU manufacture for changes, are not the same or coherent.
I promise you, the day you face a jury is the day I will personally be present in the public gallery, anywhere on earth.
If you believe your previous vote buying has gone unnoticed / forgotten, you are sadly wrong.
Gullible MNOs will vote NO or YES, but the smart ones will either ABSTAIN, DELETE, or simply ignore this proposal entirely.
Not willing to renounce to 75% of the Rewards of my Evonode for an extended period of time.
We don´t even know, what will happen to the 37.5% of Block Rewards reserved for Evonodes, while nothing will be paid out.
Voting NO was never easier.
Because if its the latter, question remains what happens to all the funds (37.5% of Block Rewards) in the Evo-Pool.
If the Evo-Pool itself wouldn't be enabled, it would still suck BIG TIME as it would mean Evonodes would basically earn the same amount like regular Nodes only from Core.
The Credits can only be withdrawn for dash, once withdrawals are enabled. QE mentioned this would happen within 6 weeks after activation of Platform. I suspect it will be longer.
Better to have Platform activation with withdrawals enabled (the next decision proposal next month), then having to wait for withdrawals to get enabled after activation of Platform on Mainnet.
1) If we take the "a safe and slower approach" for another 3-4 months it may not matter if the difficult market conditions for Dash continues. Getting some good news *could* do wonders.
2) Platform devs can start fixing issues right away and take a more iterative real-world approach to making our tech better. Right now it's all theoretical.
3) If you leave it up to the slow approach, we may not get Evo by the end of the year and you know that doesn't sound crazy to say after all these years.
It's the opposite of what a lot of large holders would think IMO. You're actually protecting your investment with the accelerated approach rather than risking it to more delays. Almost every project runs into issues soon after launch but at least we're actually delivering something.
QE mentioned if this decision proposal does not pass he could introduce a new decision proposal next month, which would include enabled withdrawal.
Quoting QUE:
'If this proposal fails, I will make sure to make another proposal for activation one month later, in that one withdrawals will already have been reviewed. This is an accelerated release schedule, so I needed to cut everything I wasn't sure of.'
Something to keep in mind.
Now let me be clear, I'm living off my payouts. I have a roof over my head, but I have to pay for the server and my food with Dash. I'll go on an extended fast if I have to. This is going to hurt me when it goes down, but I'm all for it. Lets get this show on the road like we're all 21 years old again!!!
I was thinking the MN voting relies on the L1 Core chain, i am confused.
You’ll see the issues much earlier on Mainnet, than on Testnet.
Just keep up your good communication.
Voting yes.
There is no winning here. It will be an absolute disaster if we release early, and it's already an absolute mess if we don't release ever. DCG has bitten off more than they can chew, and have been consistently unable to deliver and unable to properly scope the project.
I can say right now that there is a high chance that we will have a chain stall. People should expect it if this proposal passes. But a chain stall is not the end of the world. Most blockchains had them when they started, it's hard to name one that didn't.
In April 2024 you said, "If I would guess I would think we would be releasing in June. In about a month from now I will announce the official release date.''
Your "announcement" is now a proposal to deliver with a greater chance than not of a chain halt on Platform, plus your other stated shortcomings. Not least that you previously challenged me over high fees, and now fully justifying higher fees due to security concerns.
You put this proposal to an audience of MNOs that may not be technically competent to understand it, including multiparty masternodes such as Crowdnode.
2 : Enabling Withdrawals (new Platform version)
3 : Introducing Statesync (new Platform version or maybe released together with Withdrawals)
I am a little worried that step 1 and 2 could take quite a lot of time, financially impacting Evonode owners / operators who rely on those rewards.
Quoting QE : 'If we released without withdrawals, we would have them within 6 weeks after activation, as having them would be probably the top priority along state sync support. (Once again the feature is written, just needs a crazy thorough audit from me).'
Which to me translates to 6 weeks (or longer) of not being able to convert credits to dash. This will severly impact Evonode owners / operators that financially depend on those masternode rewards, as they will effectively only have access to a small portion of their masternodes (from L1, not L2) until feature Withdrawals get enabled.
I rather support a decision proposal that contains withdrawals enabled, so it won't mess up my masternode operations financially and leave me financially in a dire spot. So unfortunetely i think this will force me to vote no.
If another decision proposal emerge next month that does have the feature Withdrawals enabled, i will reconsider it. Depends by then on how much it will accelerate things for DCG.
* within 6 weeks after release, should be within 6 weeks after activation
* access to a small portion of their masternodes (from L1, not L2), should be access to a small portion of their masternode rewards (from L1, not L2)
How do you differentiate between normal masternodes that voted and evonodes that voted, to determine that those evonodes that voted reached 2/3 ?