Updates: How to deploy changes to the particular software running on each node that allows each node to function correctly.
Governance: How changes to the meaning of ‘correct functioning’ are proposed, discussed and implemented.
I’m hoping this topic can be a place to explore existing work on these areas and see what has worked pretty well and what has not worked well / lessons learned.
Dash
https://docs.dash.org/en/stable/introduction/features.html#decentralized-governance
Dash uses 10% of the block reward to fund its own development.
The Decentralized Governance by Blockchain (DGBB) system allows each masternode to vote once (yes/no/abstain) for each proposal. If a proposal passes, it can then be implemented (or not) by Dash’s developers.
Sentinel is an autonomous agent for persisting, processing and automating Dash governance objects and tasks.
Whitepaper on the treasury system, ie the governance system for dash:
Some insights of how the treasury may be improved
https://www.dashnation.com/media/news/breaking-down-dashs-treasury-adjustment-options/
“… miners were being paid too much based on what they are providing the network. Because of Dash’s technological advancements on the masternode side with Chainlocks and chained InstantSend, the security provided by the miners, while important, was not worth the 45% they were being paid by the network.
In a vote that passed handily, the Dash network voted to gradually reallocate the block reward away from the miners and toward the masternodes. A current 50-50 split after the treasury is paid out will become 60-40 in favor of masternodes over a period of a few years.”
List of proposals for how to spend the 10% budget (also has a link to past proposals):
https://www.dashcentral.org/budget
5325 dash budget per month ($385K USD approx).
2663 dash per month ($192K USD approx) for core group compensation (50% of total).
Pretty interesting to see the list of things that are proposed and funded. Some marketing. Some dev. Some legal. Mostly around 50 to 500 dash per proposal.
Experience of this model from a game developer:
“we were a little disappointed with the amount of feedback we received, with only a handful of responses which made valid points about the direction of Dash in general but ultimately weren’t particularly useful or relevant to our specific case.”
Shows that having a system of governance is one thing, but having people engaged with it is another. Governance needs participation to work well.
My first impressions of dash governance: The 10% levy is higher than I would have thought viable, but it seems to work pretty well, better than I would have expected. They seem to have learned a bit about the pros and cons of their approach (see dashnation.com link above) and are able to act on changes pretty efficiently.
One question I have is that governance is often better when it’s slow; it’s meant to be a series of deliberate well-considered acts and undoing a poor decision can be quite difficult. Does this model allow too much speed? It seems crazy to say ‘more sand in the gears please’ but some friction maybe acts as a necessary rate limiter and quality filter. Not sure where the balance lies on this. From the looks of it dash governance isn’t under any stress, but I wonder if that’s because of the strength of their governance system or if it’s just going smoothly for some other reason.
I’m not especially familiar with dash so if anyone has any more insight I’d be keen to hear it.
Any other networks with useful lessons around governance or network upgrades please post it here. I’ll keep trying to add more as time permits.
Bitcoin protocol forks/upgrades is an obvious one to cover.
I’d like to cover some approaches to staggered updates and rollbacks in traditional web apps (any tips?).
Anyone know any networks where nodes are forced to update (ie not operator initiated updates)?
What else?
) would probably be up to answer a couple of questions on Twitter.