header-langage
简体中文
繁體中文
English
Tiếng Việt
한국어
日本語
ภาษาไทย
Türkçe
Scan to Download the APP

The importance of on-chain governance from the perspective of fork issues

2020-11-29 15:00
Read this article in 13 Minutes
Compared with the Internet era where traffic is king and values are above platforms, the Web3.0 era may be more inclined towards community ecology, which will bring about a new market ecology that changes the relationship between enterprises and users.
Original source: WebX Labs


The decentralized community bound by Web3.0 disperses power and gives every member of the ecosystem the right to exercise their demands. It is precisely the full expression of this free opinion that makes free ideas or interest disputes emerge in an endless stream. Take Bitcoin, the first application of blockchain, for example. Its initial design model is popular, but with continuous development, people are dissatisfied with its expansion capacity and block size design. Then the urgency of solving this problem becomes more and more intense, and some people begin to move. They set up their own schools by modifying the code, creating a lot of products other than Bitcoin.


We can see that this behavior, which we call fork, not only continues some basic consensus of Bitcoin through technical improvement and optimization, but also breaks through the ceiling proposition of Bitcoin design. Most importantly, this "hostile" and "synergistic" relationship of open source competition actually stimulates the potential for internal change in the project to a certain extent.


Forks that have gone astray


Forks are, to a certain extent, a reflection of the original intention of the classical Internet, guaranteeing the rights of users. There have been many milestone fork events in history, but overall, these events often led to repeated failures of the project, and the original intention of the fork has long been forgotten. How to deal with the contradiction between efficiency and equal rights is a unique problem under the Web3.0 structure, a governance problem.


The recent BCH fork originated from the internal conflicts in the community caused by IFP, and the results were quite radical, with the first "double hard fork" drama. So, what is a double hard fork? The most popular understanding is to abandon the main trunk BCH and directly fork into two chains, BCHN (Bitcoin Cash Node) and BCHA (Bitcoin Cash ABC).


For this refreshing "innovative" hard fork, some people even joked, "If the BCH fork is effective this time, then when more coins are going to hard fork in the future, at the same time, there will be a "double hard fork", Double (double fly), or even Triple (triple fly). "This also implies that the "forever soft fork" technical route established by Bitcoin will exist in name only, and BCH will also be seriously damaged in such hard fork upgrades and will no longer be as glorious as before.


According to conspiracy theories, behind traditional governance methods like BCH, there is an unspeakable sense of "manipulation". Off-chain governance uses the so-called rough consensus (a concept derived from open source engineering) to express group consciousness. In essence, the core maintainers of the code base discuss rather than vote, and believe in the possibility of reaching a consensus through discussion. When this consensus is arbitrarily considered to have been reached, the core maintainers will arrange software upgrades.


But the problem is that some technical political disputes cannot be resolved by rough consensus in the end. In extreme cases, not only is there no rough consensus on specific proposals, but the disputed camps no longer agree on how to reach future agreements. This leads to controversial hard forks - the creation of two independent blockchains that share a transaction history but diverge at a specific time. In addition to controversial hard forks, another problem faced by rough consensus governance is that proposals may be repeatedly raised without any formal way to reject or confirm them.


Most importantly, this rough consensus makes developers, miners, and users miserable. Whenever a fork war begins, miners responsible for maintaining the network face a choice problem. Miners need to consider many factors such as income or the power of the consortium before making a choice. This choice may sometimes be mixed with the necessity of not being abandoned; developers responsible for developing project products have to develop on the one hand, and worry that their beliefs will be subverted by miners' rights on the other hand. This is a tormenting journey for developers themselves; users are also confused in the battle of computing power. As for the party of power or victory, they will shout to themselves: "Uncooperative BCH mining pools, orphan blocks," or say, "After this new block, there will be no more victory declarations from troublemakers in the BCH community."


New governance methods are needed to move from off-chain to on-chain Web3.0


Whether we admit it or not, from the downward trend of BCH, we have already felt that the "hard" method of hard fork has brought irreversible negative energy. The deep-seated reason behind it is that this hard fork is a relatively disorganized, meaningless, and ineffective gimmick of redistribution of interests. Due to the lack of lasting centripetal force and cohesion, it is difficult to form a broader community consensus.


Especially in the era of Web3.0, community opinions and governance methods are very important. At the Web3 conference, Dr. Yaoqi Jia, technical director of Parity Asia, mentioned the importance of community governance many times. He pointed out: "The driving force behind the spiral rise of Web3.0 has never been the breakthrough of a single project, but the development of the entire system, including community, products, and governance. Web3.0 gives users more participation rights through product iteration, community participation, incentives, and governance.


So, how is this greater right to participate reflected in the Web3.0 stage? Let's take Polkadot's on-chain governance mechanism as an example (Polkadot's on-chain governance has always been praised by the community and projects).


The first stage is proposals, including public proposals submitted by project token holders, director proposals submitted by the council, proposals submitted as part of the execution of the previous referendum, and emergency proposals submitted by technical committee members.


The second stage is voting, which is conducted every 28 days, alternating between the DOT and the Council queues. Only one vote can be conducted in a period of time, unless there is an emergency, it can be conducted in parallel.


The final stage is the counting of votes, and the counting results are divided into three categories: positive voting rate deviation, negative voting rate deviation, and simple majority system. The positive and negative voting rate deviation means that the more or less the total number of votes, the more or less the number of votes in favor must be increased or decreased accordingly. The simple majority system means that the minority obeys the majority. During the counting stage, the 23 council members elected by monthly voting represent the interests of the majority.


Compared to traditional off-chain governance, Polkadot uses WebAssembly code stored on the chain, so that miner nodes can use new proposals without restarting, technically avoiding hard forks. Each stage of on-chain governance has a clear time, which avoids the risk of problems being shelved. In addition, every DOT holder can participate in Polkadot governance. The community governance power is in the hands of DOT holders, which is different from the centralization problem of off-chain governance decision-making in the hands of developers.


At present, the construction and management of this community are extremely important to the Web 3.0 network and applications. This "four-in-one" form that can cover developers, users, investors, and governors without major changes makes the form of Web3.0 more community-oriented. Through the proposal of more clearly pointed proposals and the implementation of the process that can be linked one by one, dangerous or malicious proposals cannot exist, and all stakeholders will contribute collective wisdom to the development of the ecosystem or community.


To date, there are already many on-chain governance projects. For example, Tezos proposed the "self-healing concept" in 2014. It describes itself as a self-modifying ledger and assumes that it can develop and upgrade without forks through formalized proposals, voting, and implementation. In addition, the application level, including the largest Compound, is seeking to use the principles of on-chain governance to determine the future course of action. The on-chain referendum of Polkadot's redenomination not long ago further demonstrated the charm of on-chain governance. Its practice of splitting the denomination on the public chain does not require token exchange or hard fork, which has brought an unprecedented attempt to other blockchains.


Admittedly, as a relatively "young" new governance method, it also faces problems that need to be solved, such as low on-chain voting rate, DOT staking big holders affecting voting results, etc., but the development of on-chain governance methods is for hard forks that can only quench "immediate thirst" but not long-term concerns. The solution is low-cost, will not consume ecological power, and decentralized methods are more conducive to the long-term development of the community. This is an effective means to resolve differences or better manage community development.


Original link



Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia

举报 Correction/Report
This platform has fully integrated the Farcaster protocol. If you have a Farcaster account, you canLogin to comment
Choose Library
Add Library
Cancel
Finish
Add Library
Visible to myself only
Public
Save
Correction/Report
Submit