Proposal “DCG-SUPPLEMENTAL-FEB24“ (Completed)Back
| Title: | Dash Core Group February Supplemental Funding Proposal |
| Owner: | quantumexplorer |
| One-time payment: | 612 DASH (17983 USD) |
| Completed payments: | 1 totaling in 612 DASH (0 month remaining) |
| Payment start/end: | 2024-02-09 / 2024-03-10 (added on 2024-02-13) |
| Votes: | 450 Yes / 16 No / 0 Abstain |
Proposal description
What does this specific proposal fund?
DCG reserves are slowly getting better but are still very low, this proposal aims to speed up recovery of a small buffer, so DCG can be in a more healthy position sooner.
How are things?
January was a very productive month, and things are looking up. On the platform side we just merged in some long time Pull Requests that had been haunting the team for a while ; Withdrawals are now merged in, and so are the chain lock verification PR and the Dash SDK one. These recent successes have revitalized the mood and energy of the team after the year end holidays.
What is left to do for Evolution/Dash Platform to be released?
We have work pretty much divided into many categories of work. Please understand the time required here are estimates. The work added here is also what we currently know of, and as testing is a dynamic process things might be added to this list as they are discovered. Also please note that some tasks can only be done by certain individuals on the team. Some team members are assigned to lower priority tasks because they are best suited to take on such tasks since putting them on the more complicated tasks would not give good results.
Consensus issues discovered:
Making sure that replaying state transitions can not take down the network (2 people for 4 days left of work - most work here already completed) Done
Implement multithread drive query solution (discovered during stress tests) (3 people for 2 weeks left of work)
Ask for all core information once for all state transitions in a block (discovered during stress tests) (2 people 3 days)
Bug in data contract queries (1 person 1 day) Done
Features left:
Masternode Voting (2 people for 7 days left of work - currently postponed till after issues are finished)
Fine tuning
Making sure that fees are set to values that represent costs to actual Evonode operators (3 weeks 2 people)
Internal code review (All the team 2 weeks)
Client side
Making sure that clients have properly integrated the Dash SDK (4 man/weeks left of work - mostly taken on by mobile team)
Testing
Additional stress tests (2 people 1 week)
Additional mechanisms for better testing (1 person 3 weeks)
Final testing of protocol upgrades (2 people 3 days)
Chain halt mitigation process (2 people 3 days)
Might be needed
State Sync (2 people 3 weeks) - We hope to be able to release without this.
Query fees (2 people 2 weeks) - We currently do not charge state transitions for lookup queries, since this is vastly inferior to other state transition costs we believe we can release without this feature.
Dapi rewritten in Rust (2 people 3 weeks) - Dapi is currently written in Javascript, it's only 14k lines of code (which is mostly boilerplate). Since it was never an expensive part of the system this was kept in Javascript, however it might prove too unreliable. Currently though we see it working well enough for release.
Did DCG start hiring again?
As previously mentioned in a past proposal we were looking for a new infrastructure engineer. I am pleased to note that we made that hire and are very excited to see what they can achieve.
We sadly had a departure in the GroveDB team and are looking to backfill that position. Right now that is the only hire we are looking to do, at least for the next 2 or so months.
How much of an impact do the supplemental proposals have?
A big impact. The supplemental proposals will aid our recovery and put us in a better position for growth sooner.
If you have any questions, please direct them to quantumexplorer at dashcentral.
Requested funding is as follows for the February 25th superblock:
DCG reserves are slowly getting better but are still very low, this proposal aims to speed up recovery of a small buffer, so DCG can be in a more healthy position sooner.
How are things?
January was a very productive month, and things are looking up. On the platform side we just merged in some long time Pull Requests that had been haunting the team for a while ; Withdrawals are now merged in, and so are the chain lock verification PR and the Dash SDK one. These recent successes have revitalized the mood and energy of the team after the year end holidays.
What is left to do for Evolution/Dash Platform to be released?
We have work pretty much divided into many categories of work. Please understand the time required here are estimates. The work added here is also what we currently know of, and as testing is a dynamic process things might be added to this list as they are discovered. Also please note that some tasks can only be done by certain individuals on the team. Some team members are assigned to lower priority tasks because they are best suited to take on such tasks since putting them on the more complicated tasks would not give good results.
Consensus issues discovered:
Making sure that replaying state transitions can not take down the network (2 people for 4 days left of work - most work here already completed) Done
Implement multithread drive query solution (discovered during stress tests) (3 people for 2 weeks left of work)
Ask for all core information once for all state transitions in a block (discovered during stress tests) (2 people 3 days)
Bug in data contract queries (1 person 1 day) Done
Features left:
Masternode Voting (2 people for 7 days left of work - currently postponed till after issues are finished)
Fine tuning
Making sure that fees are set to values that represent costs to actual Evonode operators (3 weeks 2 people)
Internal code review (All the team 2 weeks)
Client side
Making sure that clients have properly integrated the Dash SDK (4 man/weeks left of work - mostly taken on by mobile team)
Testing
Additional stress tests (2 people 1 week)
Additional mechanisms for better testing (1 person 3 weeks)
Final testing of protocol upgrades (2 people 3 days)
Chain halt mitigation process (2 people 3 days)
Might be needed
State Sync (2 people 3 weeks) - We hope to be able to release without this.
Query fees (2 people 2 weeks) - We currently do not charge state transitions for lookup queries, since this is vastly inferior to other state transition costs we believe we can release without this feature.
Dapi rewritten in Rust (2 people 3 weeks) - Dapi is currently written in Javascript, it's only 14k lines of code (which is mostly boilerplate). Since it was never an expensive part of the system this was kept in Javascript, however it might prove too unreliable. Currently though we see it working well enough for release.
Did DCG start hiring again?
As previously mentioned in a past proposal we were looking for a new infrastructure engineer. I am pleased to note that we made that hire and are very excited to see what they can achieve.
We sadly had a departure in the GroveDB team and are looking to backfill that position. Right now that is the only hire we are looking to do, at least for the next 2 or so months.
How much of an impact do the supplemental proposals have?
A big impact. The supplemental proposals will aid our recovery and put us in a better position for growth sooner.
If you have any questions, please direct them to quantumexplorer at dashcentral.
Requested funding is as follows for the February 25th superblock:
- 611 Dash ($16,802.5 USD @ $27.5 per Dash)
- 1 Dash Proposal fee reimbursement
Show full description ...
Discussion: Should we fund this proposal?
Submit comment
|
No comments so far?
Be the first to start the discussion! |
In the meanwhile have a look at the github feed:
https://github.com/dashpay/platform/issues
Too many bugs!!! But if you look to Assignee, nobody is assigned to solve them!
Wasting money through obscurity. A well known recipe.....
All code we write is open source and published to Github. The fact that we haven't gone through community issues yet is just a matter of priority. Eventually once we have something relatively stable we will definitely make sure all issues are closed.
Exactly. Community is not your priority. Your priority is to receive money from the community in order to implement whatever stupidity comes into your mind.
For awhile i thought that Docker / Dashmate was handling this much better (after all it only need to handle the memory of 1 instance), but now i am seeing the same kind problematic behavior (though it has not yet reached my swap) and i am just not sure if this is normal Ubuntu behavior or a possible memory leak.
I want to make sure there is no memory leak that could impact Evonodes that will already have a pretty high memory usage at that point.
It is not not mine.
https://forum.polkadot.network/t/slider-voting-system/6029
Why dont you label the pull requests depending on their type (bug, feature etc) and their severity (critical, minor etc) etc etc
Wasting money through obscure pull requests. A well known recipe of the developers who want to waste money.....
Look at the "Assignee" tab, nobody has been assigned to do something.
Finally, why dont you reveal the reward to whoever finished whatever pull request?
Thats your job, to provide transparent expenses, but you do nothing towards transparency.
Which among all these pull requests are really needed? Why dont you label them depending on their type (bug, feature etc) and their severity (critical, minor etc)
Wasting money through obscure pull requests. A well known recipe of the developers.....
As long as he refuses this transparency, his role against Dash becomes more and more suspicious.
There real suspicious whose role should be investigated is the masternodes that are supporing the platform stupidity.
https://mnowatch.org/the_results_dashd_2024-02-18-06-02-49.uniqueHashVotes.165.html?3=DCG
spirit, combine, ayver, DIFSHelpMall
If the Dash community succeeds to defund DCG, the DCG will sell the masternodes they use to control the community, and that way new wise people and proposals will appear that will make DAsh rise again.
You are smarter than that accusation.
In that case I rearrange my previous argument, and I say that some agent driven Masternodes DESIRE A BAD DCG TO RULE Dash, whether this DCG is the one Ryan Talor used to have or the current one.
These agent driven Masternodes who desire the destruction of Dash by hiring an incompetent DCG have a name: spirit, combine, ayver, DIFSHelpMall e.t.c.
For more info, search here:
https://mnowatch.org/latestlink_DashdUniqueHashVotes.html?3=DCG
Can devs at this point confirm that Platform testing did not produce breaking changes that require a protocol change from Core (v21) and if that is the case can devs finally tie the activation of Platform features (mn_rr fork) that are laying dormant in v20 to a specific minor Core update ? If not v20.1 then devs should at least be able to tie it to v20.2 ? If not, why not ?
In latest Platform and Core Dev Update, Ivan Shumkov mentioned that withdrawals (from Platform chain L2 to Payment chain L1) are currently limited to just 16 transactions in a Payment chain block (L1). Sam later mentioned that technically the max would be 16x16 = 256 transactions.The whole thing became a bit confusing to watch, as transactions limit in a block from L1 was initially confused by Sam with a dash amount limit per day from Platform (2.500 dash per day?).
See : https://www.youtube.com/watch?v=OVCQbMLvzxk&list=PLiFMZOlhgsYKwnv-81_fWLC0DSbDQ1fyc&index=1 (timestamp 22:36)
So what is it exactly ? 16 transactions in a L1 block or 16x16 (256) transactions in a L1 block ? What will be technically possible when Platform features get activated on Mainnet ?
And why is there appearently also a limit in place the first few months, with how much dash can be withdrawn from Platform (2.500 dash per day ?). To me does sounds and feels a lot like capital control measurements put into place with regards to how much can be withdrawn from Platform.
I really hope that 2.500 dash per day will indeed be lifted after a few months. I even wonder if such limitation should be in there in the first place.
For Withdrawals, we have 16 outputs per transaction (so 16 people can withdraw from one transaction), and 16 transactions per Platform block. Not Core block! Platform blocks happen around every 5 seconds, so this is about 256 withdrawals every 5 seconds. This is only the current limitation in our first version and we will increase this if it is needed. The limitation is there only because the operations are costly and having them be unbounded might introduce a ddos attack vector. I say might because we did not test this, we are instead trying to make these tradeoffs to get this out faster.
As for the withdrawal limit, this is only a temporary safeguard, we are not doing this for capital control but instead just as a precaution as a lot of code will make it to Mainnet at once. I believe this safeguard is better than if we had to revert the chain like Ethereum did, we will get rid of the safeguard asap.
IF NO EVO, WHAT ACCOUNTABILITY?