|
|
|
# Competition Analysis
|
|
|
|
|
|
|
|
## Dash 0.12.2
|
|
|
|
|
|
|
|
[Dash 0.12.1+](https://github.com/dashpay/dash) (Sentinel) seems to have fixed some design flaws of pre-sentinel governance (the one we're using), especially in budget finalization part. Some of the design decisions they made are pretty nice and are worth replicating (some others are not). There is little documentation; clearly Evan Duffield & Co have an idea of where they're going and how they will get there, but they don't share that with general public.
|
|
|
|
|
|
|
|
Sentinel update involved moving a part of governance logic into [a set of python scripts](https://github.com/dashpay/sentinel) than are executed by timer on masternodes. Benefits and intentions of this decision are not clear, but as a side effect it made analyzing algorithm by reading code much more difficult.
|
|
|
|
|
|
|
|
Although it's infeasible to merge it directly into our codebase, still there are some improvements over pre-Sentinel governance we might want to adopt:
|
|
|
|
|
|
|
|
* Finalized budget is submitted by a masternode, which kind of ensures that *at least one masternode* agrees on this budget
|
|
|
|
* Finalized budgets are submitted every new block (approx. every 2.5 minutes) by a new masternode (it's not certain though - see above regarding the difficulties of understanding current Dash code)
|
|
|
|
* Finalized budget submission does not require burning money (again - not certain)
|
|
|
|
* Superblock payments are done in a single block ([example](https://chainz.cryptoid.info/dash/block.dws?000000000000000f8b282e64c13fb83c0b41045f025d8d9df28d27c005fd3ca2.htm))
|
|
|
|
|
|
|
|
## PIVX
|
|
|
|
|
|
|
|
[PIVX](https://github.com/PIVX-Project/PIVX) is basically a pre-sentinel Dash, there's nothing interesting or useful there. They did replaced mining with PoS though.
|
|
|
|
|
|
|
|
## Bitcoinocracy by BitcoinCash
|
|
|
|
|
|
|
|
[Bitcoinocracy](https://vote.bitcoin.com/) is a kind of a governance for BitcoinCash. In its essence it's a centralized discussion platform were you can vote with your wallet. It's more of a public opinion poll than governance, it does not distribute money and does not enforce decesion with blockchain. Still, it's simple and efficient
|
|
|
|
|
|
|
|
From the technical side it's just a [Rails web app](https://github.com/arsenische/bitcoinocracy)
|
|
|
|
|
|
|
|
## SmartCash
|
|
|
|
|
|
|
|
SmartCash also has a governance, [SmartCash Voting](https://github.com/SmartCash/SmartCash-Voting), but it's effectively just Bitcoinocracy rebranded
|
|
|
|
|
|
|
|
## Decred
|
|
|
|
|
|
|
|
Decred is a cryptocurrency based on Go implementation of Bitcoin, so naturally (not unlike ourselves) it shares some of its protocol with Bitcoin. However, it has PoS on top of mining, development subsidy (10% of new coins) and a nice looking wallet.
|
|
|
|
|
|
|
|
So far Decred hasn't have a working blockchain-based governance system. **Once a year** their budget is distributed on a number of proposals. Budget distribution is totally manual and centralized, it relies on proposals discussed on forum (also opinion-poll-like solution) with the development team being an arbitrator.
|
|
|
|
|
|
|
|
At the moment they're working on a system called [Politeia](https://github.com/decred/politeia), which is still work in progress. It is intended to be their future governance. There are not much details about it, although the source code is available and is constantly evolving. It is supposed to be wired into their blockchain somehow and relies on their [timestamping service](https://github.com/decred/dcrtime) (also work in progress).
|
|
|
|
|
|
|
|
Apart from Politeia, they do have a functional system that allows stakeholders to vote for important decisions, but it has nothing to do with proposal funding. It has to do with **consensus**. Here how it works:
|
|
|
|
|
|
|
|
* Blocks on the blockchain are still generated by miners, but there is an extra PoS validation step
|
|
|
|
* In order to participate in PoS coin holders must buy tickets. Anyone can buy as many tickets as they want
|
|
|
|
* When a block is generated, several random tickets are called to vote. The nodes that the tickets belong to will validate the block and vote "yes" or "no" (or "abstain")
|
|
|
|
* After the ticket has voted it is no more (it has ceased to be, it is an ex-ticket) and its price is refunded to the owner with a small reward on top
|
|
|
|
|
|
|
|
Now, the most interesting thing: when there is an update that changes consensus rules in a non-compatible way, **the same voting mechanism is used** to activate the update:
|
|
|
|
|
|
|
|
* A proposal for a change is published before the update for the community to read
|
|
|
|
* When an update is rolled out, the new consensus rules are not activated
|
|
|
|
* Those who in favor of the new rules can pre-configure their nodes to vote "yes", those who against can pre-configure them to vote "no". Those who don't give a f##k do nothing, and their nodes default to voting "abstain"
|
|
|
|
* If after a certain period of time 75% of the nodes which did not abstain voted "yes" - the new consensus rules are activated
|
|
|
|
|
|
|
|
This is quite an elegant solution for consensus rules change management. We, following Dash, use spork keys for that and they just look ugly and centralized in comparison.
|
|
|
|
|
|
|
|
## Sovereign by Democracy Earth Foundation
|
|
|
|
|
|
|
|
[Sovereign](https://github.com/DemocracyEarth/sovereign) is a blockchain-based project by [Democracy Earth Foundation](https://www.democracy.earth/) which is developed specifically as a voting platform and nothing else.
|
|
|
|
|
|
|
|
There is an opensource whitepaper on Github: https://github.com/DemocracyEarth/paper
|
|
|
|
|
|
|
|
The project is still work in progress, and probably we won't be able to use it directly, but it deserves a closer look and additional research.
|
|
|
|
|
|
|
|
# Conslusions and Next Actions
|
|
|
|
|
|
|
|
1. There have been many *very* different and rather vague ideas of what we ideally want of our governance. Now we need to come to a shared, more specific vision of that ideal governance. Then we will need to ask ourselves: what are some relatively easy steps that will bring us the closest to that vision?
|
|
|
|
2. There are already a pool of issues on Gitlab which we might want to look at and prioritize. And totally add some new ones
|
|
|
|
3. There are not much functional governance systems out there, and even the most mature one, Dash, is still an eternal work in progress:
|
|
|
|
* The good thing about it is that we have a chance to be in the frontline of developing something exciting and revolutionary
|
|
|
|
* The bad thing is that we have almost no-one to copy from (although, if we sit on our asses and theoritize long enough, soemone will definitely appear) |
|
|
|
\ No newline at end of file |
