Overview of blockchain system governance: how to design a governance mechanism to ensure the long-term development of blockchain?

Source ｜ Medium

Compilation ｜ First Class (First.VIP)

The blockchain code base is updated every time. In order to update the blockchain code, various interest groups, such as users, core developers, and full-node providers (also called miners in the Bitcoin system), need to reach consensus on what needs to be retained and what needs to be changed. But this is not easy, because there are often conflicts of interest between these stakeholders. To address these issues, each blockchain project has a governance system to coordinate conflicts between participants and align their motivations with the healthy development of the blockchain system.

Generally speaking, the blockchain governance system is divided into two types:

• Read an article about the cryptocurrency smart wallet ecological forerunner
• BT Group Vodafone exits Libra Association
• Viewpoint | Is the BNB that Binance destroys every quarter really tied to profits?

One is an off-chain governance system like Bitcoin and Ethereum; the other is an on-chain governance system like Cosmos and DFINITY. The difference between the two is whether voting is conducted and recorded on the blockchain ledger.

In the off-chain governance system, core developers can submit protocol updates to official repositories (such as Github) through formal improvement proposals (such as Bitcoin improvement proposals, Ethereum improvement proposals). Users and full node providers can post opinions on community forums and social media such as slack channel, Telegram and Twitter. If most of the interest groups agree to the protocol update, the blockchain protocol will undergo code changes. If they can't reach a consensus, core developers can retract the proposal or still implement the protocol change. However, the latter usually leads to hard forks (such as Ethereum and Ethereum Classic born in 2016 due to hard forks, and Bitcoin and Bitcoin Cash in 2017), because some full-node providers may not adopt Protocol change. Because core developers and full-node providers have much more power in decision-making than ordinary users, off-chain governance systems are often criticized for violating the spirit of decentralization.

In recent years, with the development of PoS blockchain projects, a more decentralized form of governance, on-chain governance, has gradually begun to emerge. PoS projects usually require collateralized tokens to obtain voting rights. Therefore, users can mortgage source tokens in the system and obtain voting rights for protocol updates. Compared with the uncertainty of the off-chain governance system, the decision-making turnaround time of the on-chain governance system is shorter. In addition, the on-chain governance system is more transparent, and voting rules are set in advance and notified to the public in advance. Decision-making is not under the control or involvement of a central entity. In addition, because voting rules are embedded in the system code, protocol updates are automatically implemented after the proposal is approved, which can largely prevent a hard fork.

The following will explore the typical design issues of on-chain governance systems from a deeper level.

 

On-chain governance design

 

What proposals can be submitted?

The proposal can be any relevant topic, such as freezing tokens stolen by hackers, changing parameters, punishing malicious full-node providers, etc.

How do I submit a proposal?

To submit a proposal, at least the minimum number of tokens required for the governance system is mortgaged. To encourage high-quality proposals, if the proposal is adopted, the mortgage tokens will be returned and additional rewards may be obtained (rewards may come from newly minted tokens or foundation contributions). If the proposal is not accepted, the mortgage tokens will be returned without additional rewards. If the proposal is considered a junk proposal, the mortgage token will be deducted.

Which proposals are prioritized for voting?

Users can support various proposals by mortgage tokens. The proposal that gets the most mortgage tokens can be voted on first. After the proposal is passed, the token reward will be distributed to the initiator of the proposal (such as 50%) and supporters (such as 50%, which is proportional to the number of mortgage tokens). Keep in mind that proposals with less relevant topics attract fewer supporters and vote later. Since mortgage tokens can only be returned to the holders after the voting is over, proposal sponsors and supporters will face the opportunity cost of pre-stored tokens. However, this design can prevent the proliferation of spam proposals. Alternatively, the system can set the minimum amount of mortgage tokens required for a proposal to reach the voting stage (similar to the "We the People" White House petition website).

How to get voting rights and maintain voting privacy?

In order to obtain voting rights in the governance system, users need to stake their tokens in the system for a period of time. This will affect the vital interests of users, and thus encourage them to vote rationally. Homomorphic encryption is one of the mainstream methods to protect the privacy of voting. Because the vote is encrypted, only voters who have the private key can view their vote. All ballot papers will be aggregated and counted after the voting. Only the final result will be decrypted and made public.

How are voting rights / rewards calculated?

Voting rights increase with the number of mortgage tokens and the mortgage period. Voters can only receive token rewards by participating in voting. If token holders do not vote, collateralizing the tokens alone will not generate any revenue. Voting rewards provide incentives for voters to actively participate in governance.

How to delegate voting?

Voting is time-consuming and requires expertise in certain areas, so voters can delegate votes to others (such as cryptographers, economists, key opinion leaders, developers, foundations, etc.) Revocation (so-called mobile democracy).

Who can vote?

Ordinary voting subject: Anyone who mortgages tokens in the system can vote or delegate voting.

Random voting subject: randomly select a certain percentage of voters (such as 10%) for each proposal. This design facilitates multiple votes at the same time (scalable solution). Since the voting subject is smaller than the ordinary voting subject, each vote has a greater impact on the final result. As a result, selected voters are more motivated to vote and to vote with caution. But this flaw is that a small number of voters are likely to collude with each other. Therefore, the randomness of voter selection is the key to its success.

On the one hand, the number of voters should be as small as possible to reduce the voting costs of the electors (such as the time and resources spent on research proposals). On the other hand, there should be as many voters as possible to ensure that the voting results are more representative and in the interests of most token holders. One way to reduce the probability of unexpected results is to use an assessment vote. If the voting results are close (for example, in the range of 45% -55%), the system will randomly select another batch of voters, such as letting voters with multiples of 5 join the second round of voting. The final result depends on these two rounds of voting.

How to solve the problem of centralization of voting rights?

In real voting, rich people can manipulate elections by funding their favorite candidates / 傀儡, and funding their campaigns. The one-person-one-vote mechanism is highly vulnerable to this monetary effect. But in the face of emerging technologies, the current political system designed over the centuries has gradually shown its disadvantages. The Cambridge Analytica scandal is a good example of how social media users can be leveraged to influence voting results. Compared with the one-person-one-vote system in real life, in the blockchain governance system, large currency holders can purchase a large number of tokens by one-vote one-to-one tokens, thereby more easily turning the voting results into their favorite direction.

The first way to make voting rights more decentralized is to set flexible lock-in periods. Users can lock their tokens for a longer period of time to get more voting rights. For example, a user who locks 10 tokens for 10 months can have the same voting rights as a user who locks 100 tokens for 1 month (large coin holders). A longer lock-up period means that voters have a greater personal interest, so they are more concerned about the long-term development of the system than those who have a shorter lock-up period.

The second method is to replace the one-coin one-vote system with the one-account one-vote system. Voters can register for a voting account by filling out government-issued ID information. Registered users have 10 times the voting rights of unregistered users. In other words, users can still choose to vote anonymously without registering for an account. But compared to registered accounts, voting rights are greatly reduced. The system uses zero-knowledge proof technology to prevent user personal data from being misused. Voting rights increase non-linearly with the number of tokens locked in the account. For example, to get the right to vote for a unit, voters need to lock a token in their account. To get 10 units of voting rights, voters need to lock more than 10 tokens (for example, 100 tokens correspond to 10 units of voting rights, that is, a second vote). This design reduces the voting rights of large currency holders.

For example, a large holder of money can lock his 100 tokens in his registered account and get 10 units of voting rights (assuming a square root due to the concave voting rights). Or he can create 100 unregistered accounts, each account locked 1 token, but also only get 10 units of voting rights (the voting rights of unregistered accounts is reduced by 10 times). Compared with the 100-unit voting right he obtained in the one-vote one-vote mechanism, the voting rights of large currency holders are greatly restricted under this mechanism.

Privacy security issues of on-chain voting

Ring signature

Linkable ring signature is one of the most widely studied anonymous electronic voting encryption primitives. Rivest, Shamir, and Tauman proposed ring signatures in 2001, and later added one-time linkability as an improvement.

Digital signatures usually assume that participants can be identified by a public key / key pair. The ring signature scheme allows any signer hidden in a random crowd (or a public key ring) to generate a ring signature without revealing which public key in the ring generates the signature. Therefore, it provides anonymity protection for true signers. But because the signature information is public, the scheme does not have voting confidentiality.

Because the ring signature hides the identity of the voter, the voter may vote for a candidate multiple times to increase the chance of winning for the candidate he supports. One-time linkability is designed to ensure that as long as a key in a ring is used twice, duplicate signatures will be linked, which will be judged as an illegal vote.

One-time linkable ring signatures can be constructed by a special kind of zero-knowledge proof, that is, member proof. Zero-knowledge proof is a protocol that enables a verifier to verify the correctness of a sentence without revealing information other than the sentence itself. For example, the zero-knowledge range proof scheme enables a verifier to prove that a secret integer belongs to a certain range (such as 0 ~ 1), but does not disclose which integer it is. That is, the verifier can be sure that the secret integer is binary after reading the proof without knowing whether the secret integer is 0 or 1.

Blind signature

Another closely related primitive is blind signing, which requires a registration phase controlled by the group administrator. Voting requires interaction between voters and administrators so that voters can get untraceable blank votes from administrators and vote in encrypted / blind form. Blind signatures ensure voter privacy, voting confidentiality, and one-time traceability. But voters need to use a threshold blind signature scheme to reduce group administrators' centralized power in the blockchain setting. (Note: "Threshold" here refers to the use of threshold encryption technology to replace a single group administrator with multiple administrators. As long as most administrators act honestly, the anonymity of voters and the confidentiality of voting can be guaranteed.)

Threshold homomorphic encryption

The encryption scheme converts plain text messages into random strings to protect their privacy. After the message is encrypted, if you want to perform any operation on the underlying message (such as summing), you must first decrypt the ciphertext. However, in some application scenarios, there may be situations where the person performing the operation does not want to know the underlying messages. For example, the counter only needs to know the total number of ballots, not who each ballot was cast to. Homomorphic encryption is a special encryption mechanism that allows anyone who has access to the ciphertext to perform the required operation in a homomorphic manner, which means that operations on the underlying message can be performed without decryption.

If homomorphic encryption is used to encrypt each voter's vote for a particular candidate or statement, the counter will be able to encrypt the final number of votes homomorphically without having to decrypt the ciphertext of each ballot.

Note, however, that malicious voters can replace binary voting by encrypting a larger positive (or negative) number, thereby increasing (or reducing) the chances of their (or their competitors) winning (or losing) their support. Therefore, electronic voting based on homomorphic encryption usually uses zero-knowledge range proofs, which can prove that secret numbers are binary, but do not disclose the exact content of the vote. But there is another problem. Any entity that has the private key of a homomorphic encryption scheme can decrypt all votes. Therefore, a threshold homomorphic decryption mechanism is needed to distribute the decryption right to the hands of various entities.

Mix network

The Mix network uses multiple independent servers to shuffle incoming encrypted votes and output plaintext votes. But it must be assumed that at least one of these hybrid servers has performed a secret ranking honestly to ensure the anonymity of voters.

More specifically, the Mix network usually uses layered encryption to encrypt the original vote under a series of public keys, each of which corresponds to an intermediate hybrid node. Each intermediate mixed node receives multiple ciphertexts, uses its secret key to remove a layer of encryption, and randomly arranges the messages and sends them to the next node. Therefore, as long as at least one hybrid node acts honestly, the anonymity of voters can be guaranteed to a certain extent. However, because all votes are sent to the counter in clear text, the Mix Network cannot guarantee the confidentiality of the votes.

The following table shows the pros and cons of these technologies:

Discuss questions

Blockchain projects are complex systems that have evolved over time. They are governed by rules and rules that define how they change. When designing governance rules, the following basic questions need to be kept in mind: how to define effective voters and their voting rights? Who can initiate a proposal? What proposals qualify for the voting phase? What is the quorum? How to define the voting results? How do I change the voting rules?

In the final analysis, the question can be summarized as: how to design a governance system that can ensure the long-term prosperity and development of blockchain projects? The secret of success is to ensure that the interests of most participants are aligned with the interests of the project.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!