Poll: What is DASH's governance model?

[TroyDASH]

In light of some of the recent discussions surrounding the budget system and DASH's "identity", one topic that I think deserves to be thoroughly discussed (again!) is the DASH governance model. A few months ago when the masternodes voted on the block size increase, the network demonstrated that it can resolve the sort of damaging governance stalemates that continue to plague the Bitcoin network. Efficient and effective governance is one of the most exciting and revolutionary aspects of the DASH project.

However, just because we have had some successes, does not mean we should assume that our governance model is well-defined and poised for long term sustainability. I would especially like to explore the relationship between the masternodes and the core development team. Obviously, masternodes control where the budget payments go. And as we have seen, budget proposals have also been used to help determine the network consensus on proposed protocol changes. However, ultimately, is DASH a system where the core-devs are servants to the masternode authority? Or is the masternode collective more of a council to offer guidelines to the developers who have autonomous control without obligation to the masternodes?

Should protocol updates need to be approved by the masternode network before the devs roll out? What would happen if the majority of masternodes decide not to update to the latest version? Do the devs have the power to make the dissenting masternodes get left out of future budget payments even though the majority does not agree? I remember during the series of initial version 12 updates that happened in quick succession, the impression I got from the core team was that if a masternode does not update then they won't get paid, but would that still be true if the majority of masternodes refuse to update? If that is the case, then this could be an issue with our governance model.


I think that the power structure needs to be clearly defined, and then "clung to" as the credibility of DASH's system will eventually be tested. Without a clearly defined model, we could end up with a civil war reminiscent of Bitcoin's. DASH's governance for distributing block rewards right now is well defined, even though budgets may need improvement. However the governance for decision-making with regard to core development is implicitly defined at best.


A few case studies for this:
The budget prioritization thread: https://dashtalk.org/threads/prioritization-of-fiat-gateways.8457/
In this thread, the core devs have announced that all budgets will be reset in v12.1, essentially in order to make it easier for the core team to shuffle their budget funds and to maintain continuity of payments while doing so. Technically, even though I am sure many do agree that this might be the *easiest* way to get to what we want in this one instance, performing this unilateral action could be considered a violation of our governance. When DASH was in its infancy, unilateral actions by the devs are more understandable, but as DASH grows for the long term and has the masternode system, how much of this kind of thing should we allow? What will happen when a true test comes - will the devs attempt to railroad some things through even if they are controversial or not supported by the masternodes? Or conversely, if the masternodes vote for a certain course of action, what happens if the core devs don't agree?

The budget changes for v12.1 adding support for immutable contracts:
https://dashtalk.org/threads/budget-system-v2-transform-pr.7991/
And related discussion: https://dashtalk.org/threads/should-budgets-allow-for-irrevocable-contracts.8498/
In this instance, after the failure of the Terpin contract, Evan saw that this was a problem and proposed a fix by adding the capability to establish irrevocable multi-month contracts to the budget system. A budget proposal was voted on in favor, but rolled into the proposal was also a non-controversial reimbursement for Evan's previous budget submissions. I am curious why Evan would even ask for such a small reimbursement when he is already likely one of DASH's largest holders and there is already a core team budget. Regardless, since this was the only fix on the table at the time, and it was coming from Evan, and it was rolled in with a non-controversial reimbursement payment, it is no surprise that the proposal passed, and this was taken by the devs as confirmation that the masternode network approves of implementing irrevocable contracts. Although, reading through the threads it is clear that this is actually very controversial, and to my knowledge the devs have not been participating much in the discussions. It appears that unless we raise a big stink (which I have been trying to do), we are on track to have 12.1 released with this new functionality without really any further discussion with the core team.


"The spork" - from https://www.dash.org/spork/

In response to unforeseen issues with the rollout of RC3, the Dash development team created a mechanism by which updated code is released to the network, but not immediately made active (or “enforced”).

Communication is sent out to users informing them of the change and the need for them to update their clients. Those who update their clients run the new code, but in the event of errors occurring with that new code, the client’s blocks are not rejected by the network and unintended forks are avoided. Data about the error can then be collected and forwarded to the development team. Once the development team is satisfied with the new code’s stability in the mainnet environment – and once acceptable network consensus is attained – enforcement of the updated code can be activated remotely. Should problems arise, the code can be deactivated in the same manner, without the need for a network-wide rollback or client update.

Who holds the power of the spork? Technically this is something I do not understand myself (how it is implemented), but I can see where other coins would use this to claim that Evan holds supreme control. If he is the only one who can "spork", then I think it should be discussed at least.

These are the kinds of questions that need to be asked, decided and declared earlier rather than later, as a preventative measure so that the sh*t does not hit the fan at some point in the future. When it comes down to it, how much control does the dev team really have over decision-making in the network right now, and is this going to change as the DASH network grows? Regardless of what the answers to these questions are, if we don't ask them and establish the answers, then we risk a future power struggle.

I posted the poll to get the conversation moving, but the scope of this subject I think is even more broad than that. And, this is not meant to be a negative post at all. This is DASH, and being on the cutting edge of decentralized governance is our home turf. Let's take another step back, look at the whole picture and make sure our governance system is better than any other crypto could hope to achieve.

Thanks for reading --

 

[AndyDark]

the dev team is completely subservient to the MN network already, that happened last September. It's just given room to micromanage itself. But the network can pull the funding any time and hire a new dev team. If the core team went bad or started holding private meetings with Google and taking their money you can bet the Network might have something to say about it i'm guessing. That's all defined in the protocol and is the only way a project like this can claim to be decentralized I think. Credit to Evan for creating that and handing over control of his baby to the Network, not a single team in crypto has had the kahunas to do anything like that yet still claim they are decentralized.

 

[TroyDASH]

the dev team is completely subservient to the MN network already, that happened last September. It's just given room to micromanage itself. But the network can pull the funding any time and hire a new dev team. If the core team went bad or started holding private meetings with Google and taking their money you can bet the Network might have something to say about it i'm guessing. That's all defined in the protocol and is the only way a project like this can claim to be decentralized I think. Credit to Evan for creating that and handing over control of his baby to the Network, not a single team in crypto has had the kahunas to do anything like that yet still claim they are decentralized.

The protocol determines whether the devs get paid from the blockchain. Is that to be considered the same thing as control over the protocol? Suppose the core team budget becomes defunded. What happens if the core team still releases a new version and only 45% of the nodes update?

 

[ericsammons]

I think you raise some legitimate points, TroyDASH, but at the same time I think you are not trusting the Masternode owners enough.

For example, regarding the multi-month irrecovable contracts in 12.1, I agree with you that they are a bad idea, but at the same time it was put up to a vote that legitimately won. You can't complain about Evan adding the 50 Dash reimbursement to the proposal as the reason for it passing, as every MN owner could read the proposal and make the decision for themselves. (I, for example, voted against it even though I thought the reimbursement part was fine). I trust the MN owners to be able to read a proposal and make an informed decision.

In other words, our motto must be "The Masternodes have spoken, the case is closed."

At the same time, I was uncomfortable with the recent change in the use of the "public awareness" funds proposal, even though I thought the cause was a good one. It sets a bad precedent in my mind to redirect the use of funds for a previously-voted proposal. I do not question the intentions of those who proposed it, but as we are in the early stages of this governance model, I think we should be extra, extra careful of any precedents we set. For those familiar with American history, we must be like George Washington, who was extremely careful of his actions as the first President, as he understood that anything he did would be looked to as a model for future generations.

 

[David]

Troy,

I may be wrong on some of the technical details, but I'm 99% sure I'm right:

Masternodes control the entire Dash network. Any network activity that does not comply with the rules set by the masternodes (correct protocol version, enforcing MN payments, etc.) is automatically rejected. Non-complying blocks are rejected. Non-complying clients are forked from the network. Yes, even non-complying masternodes are forked off.

Here's how the update process works: Evan releases a major update which involves a protocol bump (minor updates usually do not require one). Masternodes begin adopting the new update. Once enough masternodes update (iirc, it's 75%), the new protocol version is enforced on the network. Any non-complying clients are kicked off.

If no super-majority is reached, then enforcement never happens and the update never becomes active...it's considered rejected by the network.

So yes, masternodes are in complete control every step along the way.

 

[Ryan Taylor]

The way this topic is being presented is very "adversarial" in the sense that the question posed is a continuum of "control" between two groups. I couldn't even take the poll because I don't think that's the proper framework to think about an issue like governance. Who has "control" over the government, voters or elected officials? Who has control over a corporation, the boards and executives or the shareholders? The answer depends on many things... over what timeframe?; over which aspects / decisions?

I think the appropriate way to think about it is
- What are the roles and responsibilities of the core team in Dash's model?
- What are the roles and responsibilities of the masternode owners in this model?
- What decisions are each group responsible for? How are those decisions made?
- For the different categories of decisions, how are potential conflicts of interest resolved?

A simple sliding scale of "control" does a really poor job of describing these complex questions. To me the basics are:
- The masternode owners decide which core team or project specific teams they want to fund
- The masternode owners may propose and vote on important issues to provide direction to the project (e.g., strategic priorities, critical decisions, etc)
- The core team is responsible for day-to-day management of the project, including broad decision-making authority similar to the executive staff of a company - if they fail to perform or heed the desires of the MN owners, they can be voted out in favor of a competing core team of developers and businesspersons.

So over the short-term, day-to-day decisions (for which the MN owners cannot be expected to understand and act upon quickly), the core team is clearly in control (by definition, day-to-day decision making needs to be delegated in this way... even within the core team itself delegation of authority is key to being nimble and responsive). However, over longer time periods, the MN owners control the network and can allocate resources away from poorly performing teams.

 

[Ryan Taylor]

the dev team is completely subservient to the MN network already, that happened last September. It's just given room to micromanage itself. But the network can pull the funding any time and hire a new dev team. If the core team went bad or started holding private meetings with Google and taking their money you can bet the Network might have something to say about it i'm guessing. That's all defined in the protocol and is the only way a project like this can claim to be decentralized I think. Credit to Evan for creating that and handing over control of his baby to the Network, not a single team in crypto has had the kahunas to do anything like that yet still claim they are decentralized.

This is an idealized view, but rarely does "subservient" work in practice. Any individual on the core team could build up a reputation in the community and decide they are willing to stake that reputation on a risky bet. You could imagine that Evan feels that a particular move might be unpopular with the masternode owners, except 1) he's studied this issue in depth and understands it well, 2) he's consulted with experts that agree with him, 3) he believes that the decision will pay off spectacularly if given the chance, and 4) once that happens the MN owners will be thankful he didn't shy away from an unpopular decision.

True leadership involves taking unpopluar - but well-informed - risks. I would expect nothing less from our leadership team. Hopefully, the "wins" will outweigh the "losses" and Evan will be rewarded. However, if he fails too frequently and has too few "right" calls, he would be voted out.

Personally, I would NEVER want a leader that thought he/she was "subservient" to the MN owners. I would rather see a true leader, willing to take intelligent calculated risks, leading this initiative.

 

[TroyDASH]

Troy,

I may be wrong on some of the technical details, but I'm 99% sure I'm right:

Masternodes control the entire Dash network. Any network activity that does not comply with the rules set by the masternodes (correct protocol version, enforcing MN payments, etc.) is automatically rejected. Non-complying blocks are rejected. Non-complying clients are forked from the network. Yes, even non-complying masternodes are forked off.

Here's how the update process works: Evan releases a major update which involves a protocol bump (minor updates usually do not require one). Masternodes begin adopting the new update. Once enough masternodes update (iirc, it's 75%), the new protocol version is enforced on the network. Any non-complying clients are kicked off.

If no super-majority is reached, then enforcement never happens and the update never becomes active...it's considered rejected by the network.

So yes, masternodes are in complete control every step along the way.

That is encouraging if that is the case. Can someone verify this or point to where I can find this information re: 75% approval before new protocol is effective? And is this immutable regardless of what the actual code changes are in the new protocol?

 

[UdjinM6]

I voted "Other" and here is why.

I like the answer to consensus question which was given by Andreas M. Antonopoulos few times in his talks already and he repeated it again few days ago in his new talk in Prague.

40:27
Quote: "There are 5 consensus communities in Bitcoin: there is developers, there is miners, there is exchanges, there is merchant processing and there is wallets. And they go together."

In Dash there are 6 communities now because there is also masternode(r)s but that doesn't change the fact that all of them still should go together. So none of them is subservient in the first place and I also doubt that you can compare their power in some way. They are just different sides of the coin.

With that being said, I wouldn't think of defunding some specific proposal as of a fact like you just "fired" developers or smth like that. Even though budget proposal is called "Salary for Dash core team" for whatever reason - it's not a salary actually (Evan is really bad at choosing names sometimes ), it's "a token of appreciation" which devs are glad to get of course but it's nowhere near a full-time job payment so you can't really take it into account as a primary incentive for them. It's more like the way for masternode(r)s to say "you are doing great, keep it up" or "nope, we are not satisfied" - you can't really stop devs from deving, it's their choice "to dev or not to dev" and no one's else. However if no one is willing to run the thing they are deving or no one is willing to show them some appreciation or maybe not that much(?) or <whatever else> - that's smth to consider. And that's, again, simply a signal to them that they might be on the wrong side of the consensus, not an order imo.

 

[David]

In this thread, the core devs have announced that all budgets will be reset in v12.1, essentially in order to make it easier for the core team to shuffle their budget funds and to maintain continuity of payments while doing so. Technically, even though I am sure many do agree that this might be the *easiest* way to get to what we want in this one instance, performing this unilateral action could be considered a violation of our governance.

Not really. The masternodes either update to the new version or they do not. If they do not, then things just continue as they are today. So the masternodes are always in charge, no matter what.

What will happen when a true test comes - will the devs attempt to railroad some things through even if they are controversial or not supported by the masternodes?

Then the masternodes will not update, and the new code will never go into effect.

Or conversely, if the masternodes vote for a certain course of action, what happens if the core devs don't agree?

This one is a little tricky. Everything is controlled by code, so if somebody wants to change something, they have to code the change and publish it. Then the masternodes chose whether to update. The tricky thing is this: somebody has to write the code.

For example, there was a poll a little while back about whether the algo should be changed in order to kill ASICs. It didn't pass, but it brought up a good question: who writes the code to do that? If the core team thinks it's a bad idea, they'll simply decline to write the code for it. Somebody else will then have to write it, and the masternodes will either update or not.

So in this case you're getting into a sort of Apple vs. FBI question: a person (or group) can't be forced to write code.

Although, reading through the threads it is clear that this is actually very controversial, and to my knowledge the devs have not been participating much in the discussions. It appears that unless we raise a big stink (which I have been trying to do), we are on track to have 12.1 released with this new functionality without really any further discussion with the core team.

I really think you are making a mountain out of a molehill. I'm not sure how long you've been around, but those of us that have been around for a couple of years know that Evan never does anything without considering every angle, nor does he do anything based on whim. This update still has to go to testnet before it can be published...why not wait and see what Evan has come up with before inciting a riot? He may not be as communicative as you'd like, but I guarantee he isn't stupid and that he has almost certainly considered the problems with immutability. Silence doesn't mean it's not already been taken care of...

I think you raise some legitimate points, TroyDASH, but at the same time I think you are not trusting the Masternode owners enough.

For example, regarding the multi-month irrecovable contracts in 12.1, I agree with you that they are a bad idea, but at the same time it was put up to a vote that legitimately won. You can't complain about Evan adding the 50 Dash reimbursement to the proposal as the reason for it passing, as every MN owner could read the proposal and make the decision for themselves. (I, for example, voted against it even though I thought the reimbursement part was fine). I trust the MN owners to be able to read a proposal and make an informed decision.

I agree. To say that masternode owners would vote "yes" to a major network change that they disagreed with just so they could give Evan 50 DASH...that's a little unlikely.

At the same time, I was uncomfortable with the recent change in the use of the "public awareness" funds proposal, even though I thought the cause was a good one. It sets a bad precedent in my mind to redirect the use of funds for a previously-voted proposal. I do not question the intentions of those who proposed it, but as we are in the early stages of this governance model, I think we should be extra, extra careful of any precedents we set. For those familiar with American history, we must be like George Washington, who was extremely careful of his actions as the first President, as he understood that anything he did would be looked to as a model for future generations.

But I think this is a great example of how the Core Team listened. A Core Team member (BabyGiraffe) quickly posted a proposal to officially poll the masternode network. The vote for redirecting those funds is almost unanimous: https://www.dashwhale.org/p/PA-reallocation

So you see--the Core Team is listening!

 

[TroyDASH]

You may be right about the 50 DASH. However, I still think the Masternodes were voting in favor of fixing the problem that happened with Transform-PR. I am tempted even now to put forward a proposal, something along the lines of, "To account for the possible events of X, Y, Z, should the masternode network be granted a way to revoke a previously-approved multi-month budget contract?" I am very confident that the result of a vote like that where the issue in question is more about *how* we fix the Transform-PR problem rather than *if* we fix it, would be quite different.

Also just to reiterate, I am not intending to criticize the core team here. But I think we should think way in advance and try to codify every possible governance issue from every angle. This would be similar to an organization formally adopting by-laws, a set of policies for how things are done. Some of these policies can be coded and enforced directly into the protocol (some already are), but also some of them perhaps can't. But if we have a set of governing rules that we can point to any time there is a potential conflict, it will go a long way towards fostering a continued healthy relationship among all parties.

The kind of thing I am envisioning here is a sort of amendable by-laws that are approved or amended by the masternode network via budget proposals, which are to govern how the network should act in every possible scenario related to governance. Should we establish a formal veto power where Masternodes agree in the by-laws that if a significant minority of nodes wants to delay a protocol update in order to debate a controversial issue, that nodes should wait a certain period of time before updating? Right now we have these basic up or down votes on projects and guidance, but the possibilities for decentralized governance are so much more than that, and we already have the tools to build it like a real organization.