PDF name Dash Governance System - Dash Core Team Response.pdf
...
Note: the purpose to this article is to provide an official response and clarification to the report "Dash Governance System: Analysis and Suggestions for Improvement" published by “The Veritas Team” - Dmytro Kaidalov, Andrii Nastenko, Oleksiy Shevtsov, Mariia Rodinko, Lyudmila Kovalchuk, and Roman Oliynykov on https://iohk.io/research/library/#NSJ554WR
Table of Contents
Acknowledgement
We wanted to recognize and thank the Veritas Team for its professional assessment. The depth and quality of their assessment clearly required significant investment of time and talent both to sufficiently understand the functioning of the system, but also to craft the report content. The Dash core team is pleased they found Dash’s governance system to be of sufficient sophistication to warrant such research.
...
The Dash core team deeply appreciates the thorough review of the Dash Governance System and unreleased 12.1 code performed by The Veritas Team (https://iohk.io/research/library/#NSJ554WR), hereafter referred to as the “Veritas Report”. Its contents can be helpful in improving the system and helps facilitate discussion on the merits of various governance approaches and systems.
...
Note that there have been multiple versions of the Veritas Report posted to the IOHK.io website, with different section numbering. In the Veritas Report document as it appears upon the issuance of this report, the section numbering is inconsistent between the table of contents and the body of the report. For the purposes of this response, we refer to the numbering as it appears in the body of the report, to allow easier reference when reading the suggested weaknesses and our response. Should the Veritas Team continue to edit their report and change the section numbering, be aware that this section refers to the section entitled “Weaknesses”.
4.1. Superblock Validation Attack
>Modeling an attack:...
>At this moment the finalized budget F1 is no longer valid for the superblock S1. All honest nodes will therefore reject S1 and all further blocks.
...
It is certainly possible to include all information needed for blockchain validation including the votes directly in the blockchain. However, since there is no known attack vector associated with the current system using reasonable assumptions, such a change remains a low priority.
4.2. Multiple Voting
This was reported to Dash and fixed prior to the issuance of the report, and we thank the Veritas Team for finding the bug. It was resolved in PR1135.
4.3. Discarded Votes
If corresponding superblock is in the blockchain already, this wouldn’t affect the functioning of the system (see 4.1). If the corresponding superblock is in the future, another finalized budget would be payed in next superblock which is by design. This is also therefore not a confirmed issue.
4.4. Masternode Voting Incentives
True, there is no direct incentive to vote. However as masternode owners are significantly invested in the success of the network, and these operators should care about their investments (i.e., they have indirect incentive to make sure that the right decisions are made by the network), we believe these indirect incentives are sufficient to ensure robust debate and accountability.
...
We will discuss potential approaches to governance from a philosophical and practical standpoint that could provide for the needed scale and expertise to deliver the best outcome for Dash investors. We certainly agree that each masternode operator spending exorbitant amounts of time and independently contracting the needed experts to properly evaluate each proposal would be inefficient and likely lead to ineffective decision-making or non-participation. Indeed, many investors already express voter fatigue.
4.5. Voting Representation
>As a result, Dash has a system where all decisions are made by a limited set of specific actors. The opinion of the rest of the Dash citizens (miners, regular users) is not considered.
...
To be clear, we view miners as one of the many “vendors” who are paid to provide the network with a service, albeit important ones. We currently view our users as our “customers”, though we intend to provide an avenue toward ownership in the future (which we will discuss in greater detail below).
4.6. Voting Delegation
Voting Delegation is contemplated in the design of 12.1. However, any changes to DGS (other than technical improvements like combining the multiple superblocks into one superblock each month, which we did include in 12.1) needs to be approved by the masternodes, rather than implemented directly by the project’s leadership.
4.7. Decreasing Treasury Fund
This criticism is true of the current system. However, at this early stage of development, transaction fees are insignificant, and implementing the 45/45/10 split including the transaction fees requires a fair amount of effort. We anticipate adding the ability to allocate a portion of fees to the treasury at a later date once other higher-priority development efforts are complete.
In the meantime, it only requires 7% growth of the dash/usd rate per year to simply stay at current budget value, and Dash has historically outpaced this rate of growth by a wide margin.
4.8. Flexibility of Treasury Monetary Policy
>Unspent money from a previous cycle can’t be transferred to the next cycle, and any funds unspent are simply never created (which has a similar effect to burning funds).
...
If the Dash community grows, the value of each coin would likely grow in direct proportion. We anticipate any network funding needs are either fixed costs, or at worst grow linearly with demand, so it’s unlikely that network growth would be the culprit for future funding shortfalls. If anything, network growth should provide budget pressure relief.
4.9. Code Review
We thank the authors of the report for their review. The code is being actively developed so expect more bugs to be identified, especially for any brand new code. Message propagation bugs have constituted the most time consuming to resolve, but over 85% of the root causes have now been identified and resolved as of this writing. As always, we welcome everyone to help us to find and squash bugs and make our code base as stable and robust as possible before release.
...
In this section we will address the merit of various proposed solutions contemplated by the Veritas Team not otherwise addressed above.
6.2.1. Flexible Participation Requirements
We agree, and an even more flexible one than the one proposed is already on the roadmap. Evolution “savings accounts” are effectively decentralized masternode shares, which will support much smaller investments that earn a return. We have publicly referred to these participants as “owners of a mutual bank”. Mutual banks are financial entities in which the customers are also the owners.
6.3. Implementation of Delegation with Liquid Democracy
We agree, but this is far from the only model which can address scaling and expertise requirements while maintaining decentralized control and authority over the system. The possibilities are too wide-ranging to list, but differing models will require evaluating the inherent trade-offs involved. It is not clear that the proposed solution is the best of all alternatives.
6.4. Assigning Categories to Each Funding Proposal
We strongly disagree with this model on the basis of practical experience. On the surface, this sounds like a logical and effective solution. However, as the authors point out “there are no universal experts” and unfortunately, proposals are extremely unlikely to fall neatly into anything resembling the example provided, especially as the network grows. Additionally, effective decision-making requires coordination across the “silos” proposed.
...
Consider also the effectiveness of decision-making in silos. Most decisions require a strategy and coordination across functions. For example, imagine the development team approves a grand new service, yet the infrastructure team decides against expansion of its web server capacity needed to handle the change, and the marketing team decides to double-down on marketing existing services. This is obviously far from ideal and separate committees making decisions independently doesn’t facilitate the coordination required to compete effectively long-term. Networks that embrace a fragmented decision-making framework are likely to be outperformed over time by networks that embrace a coordinated strategy framework.
6.5 Introduction of Paid Expert Roles
A person who is paid to provide their judgement and expertise and make recommendations and act in the best interest of the network sounds an awful lot like an employee to us. There doesn’t seem to be any improvement in decision-making outcomes in the model proposed over a more traditional “employee” model. However, we do see complications:
...
That said, we do see a need for panels of experts for very deep research into specific topics that exceed the scope or capabilities of the organization(s) and individuals supporting the network. This may be because the need for these experts is not permanent (one-time questions), addresses a cross-disciplinary question (brings together diverse backgrounds for a stated purpose), requires concentrated/prolonged research in new fields (and don’t want to take experts away from existing duties), or requires independence from the organization itself (e.g., recommendations about compensation changes).
6.6 Expanding List of Voting Entity Types
We do not share the view that voting rights are best allocated to all involved parties. We believe the masternode operators - with an ownership mindset - are most effectively positioned to make decisions in the best interest of a healthy system. The Veritas Team points to the potential “conflicts of interest” of these owners as a flaw, envisioning “a usurpation of cryptocurrency control. This, in turn, can lead to a loss of other participants’ interests, leading them to leave the system and destroying the cryptocurrency itself.” That simply hasn’t happened yet, and for the free-market reasons described in section 4.5 above, we believe it is extremely unlikely heavily invested masternode owners would behave recklessly enough to destroy their own investment.
...