Blockchain governance considerations
One of the most interesting recent trends in blockchain governance is the rise of on-chain coin holder voting as a multifunctional decision-making mechanism. Sometimes the vote of coin holders is used to determine who will operate the supernodes that run the network (such as EOS, NEO, Lisk and DPOS in other systems), and sometimes the protocol parameters (such as Ethereum gas limit) are also voted on. And directly implement the agreement to upgrade the wholesale (such as Tezos). In all these cases, voting is automatic-the protocol itself contains all the logic needed to change the verification assembly or update its own rules and will do this automatically based on the voting results.
Explicit on-chain governance is often touted as having several major advantages. First, unlike the highly conservative philosophy advocated by Bitcoin, it can develop rapidly and accept necessary technological improvements. Second, by creating a clear decentralized framework, it avoids the perceptible pitfalls of informal governance, which is considered too unstable and prone to chain breaks, or tends to be too de facto centralized-the latter and 1972 The famous essay “Unstructured Tyranny” in 2009.
To quote the Tezos documentation:
Although all blockchains provide financial incentives to maintain consensus on their ledgers, no blockchain has a strong on-chain mechanism to seamlessly modify the rules governing its agreement and reward agreement development. As a result, the first-generation blockchain authorized a de facto, centralized core development team or miners to make design choices.
Yes, but why make [minority split] easier? Splitting will destroy the network effect.
On-chain governance for the selection of validators also has the following advantages: it allows networks with high computational performance requirements to be imposed on validators without introducing economic centralization risks and other similar traps that appear in public blockchains (such as validators). Dilemma).
So far, in general, on-chain governance seems to be a good bargain…what’s wrong?
What is blockchain governance?
First, we need to more clearly describe the process of “blockchain governance”. Generally speaking, there are two informal governance models. I call them the “decision function” view of governance and the “coordination” view of governance. The decision function view treats governance as a function(X1 piece, X2...Xn)→ÿ, The input is the wishes of various legitimate stakeholders (senators, presidents, property owners, shareholders, voters, etc.), and the output is the decision.
The decision function view can often be used as an approximation, but it is obviously easy to get to the edge: people can and do break the law and escape the law often, sometimes the rules are ambiguous, sometimes revolutions-all three of them, at least at some times, the possibility is one A good thing. Normally, even the behaviour inside the system is affected by the incentives generated by the possibility of actions outside the system, which is at least sometimes a good thing again.
On the contrary, the coordination model of governance regards governance as something that exists in layers. In the real world, the lowest level is the laws of physics itself (as geopolitical realists say, guns and bombs). In the blockchain space, we can further abstract and say that this is everyone The ability to run anything They want to own the software as a user, miner, stakeholder, verifier, or any other kind of proxy allowed by the blockchain protocol. The bottom layer is always the final decision layer. For example, if all Bitcoin users wake up for a day and decide to edit their client’s source code and replace the entire code with the Ethereum client to monitor the balance of a specific ERC20 token contract, then this means that the ERC20 token is Bitcoin. The ultimate control of the bottom layer cannot be stopped, but the actions people take on this layer may be affected by the upper layer.
The second (and crucial) level is the coordination agency. The purpose of the coordination agency is to establish contact points around how and when individuals should act to better coordinate their behaviour. Whether in blockchain governance or real life, there are many situations. If you only act in a certain way, you will get nothing (or worse), but if everyone acts together, you can achieve expectations the result of.
Powerful claim: This concept of coordination signs covers all the meanings of what we call “governance”; in the absence of coordination games (or more generally, multi-equilibrium games), the concept of governance is meaningless.
In the real world, military orders issued by general orders act as signs, while in the blockchain world, the simplest example of such signs is a mechanism that can tell people whether a hard fork is “occurring.” Coordinating agencies can be very formal or informal and usually give vague suggestions. Ideally, the marker will always be red or green, but sometimes the marker may be yellow or even holographic, green for some participants and yellow or red for others. Sometimes this is also a sign of multiple conflicts.
Therefore, the key issues of governance become:
- What should be the first layer? That is, what functions should be set in the initial agreement itself, and how does this affect the ability to make formulaic (ie, similar decision-making functions) agreement changes and the ability levels of different types of agents to act in different ways?
- What should be layer 2? In other words, which coordinating agencies should be encouraged?
The role of coin voting
Ethereum also has a history of coin voting, including:
- DAO proposal voting: https://daostats.github.io/proposals.html
- DAO Carbonvote: http://v1.carbonvote.com/
- EIP 186/649/669 Carbonvote: http://carbonvote.com/
All three are examples of loosely coupled coin voting or coin voting as a layer 2 coordination mechanism. Ethereum does not have any examples of tightly coupled coin voting (or coin voting as a function within the layer 1 protocol), although it does have an example of tightly coupled miner voting: miners’ voting rights on gasoline limits. Obviously, tightly coupled voting and lose voting are competitors in the field of governance mechanisms, so it is worth analyzing: What are the advantages and disadvantages of each vote?
Assuming zero transaction costs, and if used as the only governance mechanism, the two are obviously equivalent. If a loose vote indicates that change X should be implemented, it will become a “green sign” encouraging everyone to download this update. If a few people want to rebel, they will not download the update. If the tightly coupled voting implements change X, the change will happen automatically, and if the minority wants to rebel, they can install a hard fork update to cancel the change. However, a hard fork will incur non-zero transaction costs, which can lead to some very important differences.
A very simple and important difference is that tightly coupled voting will generate default values, which is conducive to the adoption of the will of the majority of people in the blockchain and requires the minority to make great efforts to coordinate the hard fork to preserve the existing properties of the blockchain. , While loosely coupled voting is just a coordination tool, and users still need to actually download and run the software that implements any given fork. However, there are many other differences. Now, let’s discuss some of the arguments against voting and analyze how each argument applies to the first-tier voting and the second-tier voting.
One of the main criticisms of the token voting mechanism so far is that no matter where you try it, their voter participation tends to below. The voter participation rate of DAO Carbonvote is only 4.5%:
Also, the distribution of wealth is very unequal, and the result of these two factors is best described by this graph created by critics of the DAO branch:
EIP 186 Carbonvote received approximately 2.7 million ETH votes. The voting situation of DAO’s proposal has not improved, and the participation rate has never reached 10%. It’s not sunny outside of Ethereum. Even in the social-centric Bitshares system, the highest representative in the approval vote only got 17% of the voting rights in the voting, and 30% of the voting rights in Lisk, although we will discuss these systems themselves later Other issues.
Low voter turnout means two things. First, because it is difficult to reflect legitimacy, voting is difficult because it can only reflect the views of a small number of people. Second, only a small percentage of all coins can control voting. These problems exist regardless of whether voting is tightly coupled or loosely coupled.
Game theory attack
In addition to the “big hackers” that have attracted widespread media attention, DAO has many much smaller game theory vulnerabilities; these vulnerabilities can lead to DAO vulnerabilities. This article by HackingDistributed gives a good summary of them. But this is only the tip of the iceberg. Even if all the details of the voting machines are implemented correctly, the voting mechanism usually has a big flaw: in any vote, the probability that any given voter will have an impact on the outcome is very small, so the individual’s motivation is each vote It is almost trivial that the person must vote correctly. If everyone has a small share of the size, their motivation to vote correctly is a trivial square. Therefore, spreading relatively small bribes among participants may be sufficient to influence their decisions, perhaps in a way that they collect may disagree with.
Now you might say that people are not evil selfish profit maximizers. They will not accept a bribe of 0.5 dollars and vote for Josh Arza for 20 million dollars, simply because the above calculations show that their personal chances of influencing anything are very high. Small; on the contrary, they will selflessly refuse to do something evil. There are two responses to this criticism.
First, there are many ways to make “bribery” reasonable. For example, exchanges can provide interest rates for deposits (or even more ambiguous, use the exchange’s own funds to build good interfaces and functions), and exchange operators can use large deposits to vote as needed. Exchanges profit from the chaos, so their motives are clearly inconsistent with users and coin holders.
Secondly, what is even more outrageous is that, in practice, it seems that people (at least in their capacity as holders of encrypted tokens) are profit-maximizing people and do not seem to see the evil or selfishness of taking bribes or taking bribes. As “Annex A”, we can take a look at Lisk’s situation. The representative pool seems to have been successfully captured by the two main “political parties”, which explicitly bribed coin holders to vote for them and also demanded Every member of the pool votes for all others.
Here, please note that there is a key difference between tight coupling and loose voting. In loosely coupled voting, bribery or direct bribery can also be offered, but if the community agrees that a given proposal or a set of votes constitutes a game theory attack, then they can agree to ignore it in society. In fact, this has already happened-Carbonvote contains a blacklist of addresses corresponding to known exchange addresses and does not count votes for these addresses. In tightly coupled voting, it is impossible to create such a blacklist at the protocol level, because agreeing who is part of the blacklist is itself a blockchain governance decision. However, because the blacklist is a part of the voting tool created by the community, the voting tool only indirectly affects the agreement changes, so voting tools that contain bad blacklists can be rejected by the community.
It is worth noting that not all tightly coupled voting systems in this section will quickly succumb to the prediction of bribery attacks. Many people can survive for a simple reason: the founders or foundations of all these projects have large killers, and these people are interested in the success of the platform, are not susceptible to bribery and hold large concentrations of sufficient funds. mover. The outcome of most bribery attacks. However, although this centralized trust model can be used in some cases in the early stages of the project, it is obviously not sustainable in the long run.
Another important objection against voting is that coin holder is only a class of users and may conflict with the interests of other users. In the case of a pure cryptocurrency like Bitcoin, the use of the store of value (“idle”) and the use of the medium of exchange (“buy coffee”) will naturally conflict, because the prize security of the store of value far exceeds that of the medium of exchange For use cases, it pays more attention to usability. When using Ethereum, the conflict is more serious, because many people have nothing to do with Ethereum because of Ethereum (see: crypto kitty), and even have nothing to do with generally valuable digital assets (see: ENS).
Also, even if coin holders are the only relevant category of users (one might think that this is the case in cryptocurrencies, where a social contract has been established to become the next digital gold, and nothing else), coin holding People’s vote still presents wealthy coin holders with a greater voice challenge than everyone else, which opens the door to the centralization of ownership, which leads to unhindered centralization of decision-making. Or in other words…
And, if you want to check out a project that seems to take all these shortcomings into account at the same time, check out: https://btcgeek.com/bitshares-trying-memorycoin-year-ago-disastrous-ends/.
This criticism also applies to tightly coupled and loosely coupled voting. However, loosely coupled voting is more suitable for a compromise solution that alleviates its underrepresentation, which we will discuss later.
Let’s take a look at the existing field experiments. We have a tightly coupled vote on Ethereum (oil limit). The following are the changes in gas restrictions in the past two years:
You may notice that the overall feel of the curve is a bit like another chart that you may be very familiar with:
Basically, they all look like magic numbers. They were created by a group of fairly concentrated guys sitting in the room and renegotiated repeatedly. What is going on in the first situation? Miners usually follow the direction favoured by the community, and community development itself is measured by social consensus assistance, similar to the way to promote a hard fork (support from core developers, Reddit support, etc.); in Ethereum, gas limits It has never caused enough controversy, and nothing is needed. As serious as coin voting).
Therefore, if voters do not have the technical knowledge, but only obey a dominant tribe of experts, it is not clear at all whether voting can truly decentralize power. This criticism again applies to tightly coupled and loosely coupled equal voting.
Update: Since this article was written, Ethereum miners seem to have managed to increase the gas limit from 6.7 million to 8 million, without even discussing it with core developers or the Ethereum Foundation. So there is hope; but to achieve this, a lot of hard community building and other hard non-technical work is required.
One method that has been proposed to reduce the risk of out-of-control and bad governance algorithms is the “digital structure”, which mathematically specifies the expected attributes of the agreement, and requires any new code to be changed, accompanied by computer verifiable proof To prove that they satisfy these properties. . At first this seemed like a good idea, but I think it should also be sceptical.
Generally, it is a very good idea to have specifications on protocol properties and have the functions of these specifications serving one of the coordination signs. This allows us to include the core properties of protocols that we consider to be very important and valuable and makes them harder to change. However, this is exactly what should be implemented in loosely coupled (ie second layer) rather than tightly coupled (first layer) form.
Basically, any meaningful specification is actually difficult to express completely. This is part of the complexity of the value problem. This is true even for something as clear as the limit of 21 million coins. Of course, you can add a line of code assert total_supply <= 21000000, and then add a comment around it “Don’t delete at all costs”, but there are many ways to accomplish the same thing. For example, imagine that a soft fork adds a mandatory transaction fee that is proportional to the value of the coin * the time since the last time the coin was sent. This is equivalent to demurrage, which is equivalent to deflation. One can also implement another currency called Bitcoin, adding 21 million units and adding a feature. If a bitcoin transaction is sent, the miner can intercept it and ask for bitcoin instead of giving the receiver bitcoin; this Will quickly force Bitcoin and bitcoins to replace each other, thereby increasing the “total supply” to 42 million without having to jump out of that line of code. “Soft” specifications like “do not interfere with application state” are even more difficult to enforce.
We want to be able to say that changes to agreements that violate these guarantees should be viewed illegally-there should be a coordinating body, the red flag of Poland-even if they are approved by voters. We also hope to be able to say that it is a letter of compliance, but the blatant agreement change violates its spirit, and the agreement change should still be regarded as illegal. The existence of norms at layer 2-in the minds of people in the community, not in the code of the protocol-can best achieves this goal.
Strive for balance
However, I don’t want to say that coin voting or other clear plans like on-chain voting have no place in governance. The leading alternative seems to be the consensus of the core developers. However, the failure mode of the system is controlled by “ivory tower intellectuals” who are more concerned with abstract philosophies and solutions. These technologies and solutions are used in actual daily problems (such as user Experience), technically impressive. In my opinion, transaction fees are also a real threat worth taking seriously.
So how do we solve this problem? Well, first of all, we can pay attention to the words of slate star codex in the context of traditional politics:
The rookie error is: You see that some parts of the system are Moloch [that is, so you will say: “Well, we will put it under the control of other systems to fix it. We will write on it by writing in bright red” Do not become MOLOCH” to control this other system marker.”
(“I see that capitalism is sometimes misplaced. Let us put it under the control of the government to solve it. We will solve it by only letting noble people serve as senior Position to control the government.”)
I won’t assert that there is a good choice, but occasionally free choice is a neoliberal choice-find several elegant systems that are optimized according to different criteria, roughly in line with human happiness To match, make them counterbalance and balance each other in the structure, hope that they mess up in different places like the Swiss cheese model, hope that there are enough personal freedom around them so that people can withdraw from any system that is too terrible and let the culture Evolve to complete the rest.
In blockchain governance, this seems to be the only way forward. The blockchain governance method I advocate is “multi-factor consensus”, in which different coordination signs and different mechanisms and groups will be polled, and the final decision depends on the common result of all these mechanisms. These coordination signs may include:
- Roadmap (ie, a collection of ideas about the direction of the project that was broadcast earlier in the history of the project)
- Consensus between core development teams
- Coin holder voting
- Users vote through some kind of anti-echo voting system
- Established specifications (for example, no interference with the application, 21 million coins limit)
I think that coin voting is very useful as one of several coordinating bodies to decide whether to implement a particular change. This is an imperfect and unrepresentative signal, but it is a signal against Sybil-if you see 10 million ETH voting for a given proposal, you can’t simply say “Oh, that’s a fake Social media account hired Russian trolls” to refute. . This is also a sign of complete disconnection from the core development team, and it can be used as a check if needed. However, as mentioned above, there are good reasons why it should not be the sole coordinating body.
What underpins everything is the main difference from the traditional system that makes the blockchain interesting: the “layer 1” that underpins the entire system is to require individual users to agree to any protocol changes, and its freedom and credibility threaten to “fork” If someone tries to forcibly change what they think is hostile.
In some limited circumstances, tightly coupled voting is also a possible-for example, despite the flaws, the ability of miners to limit voting on natural gas is a feature that has proven to be very beneficial in many situations. The risk of miners trying to abuse their power may be much lower than the risk that any specific gas limit or block size limit hard-coded by the protocol on day 1 will eventually cause serious problems. In this case, letting miners vote to limit gasoline is a thing Good thing. However, “allowing miners or validators to vote on certain parameters that need to be changed quickly from time to time” is far from giving them arbitrary control over the protocol rules, or allowing voting to control verification and these broader visions. The potential for chain governance is even greater.