A crypto protocol (that is, the institution of blockchain economies, a set of rules that constrain and motivate participants in the crypto network) is born with a center, and it is neither feasible nor necessary to get fully decentralized. A crypto protocol starts with a group of people doing mechanism design, software development, deployment and then operation. The incentive in a token is to motivate service providers (generalized miners) to provide network services with competitive price and/or transaction cost. Network effects are built around protocol and participations reach consensus upon it. Basically, any crypto protocol is implemented by computer software, the protocol needs optimization, and the software inevitably has bugs. Upgrades just like evolution, which is the only way for protocols to survive and prosper. Off-chain governance needs some kinds of central authority to elaborate upgrades of protocol and give a green light on them. For on-chain governance, I will discuss later and the conclusion is no different. Bitcoin Core and the Ethereum Foundation are the centers of Bitcoin and Ethereum, and Bitmain and CSW are the centers of BCH and BSV.

 

The essence of crypto protocol governance is forkability, not decentralization. Forkable means that the center can be replaced. Or, once the consensus is broken, a new center can be formed, and hopefully with no barriers. Forkability restricts choices space of the center so that it should work based on consensus. Once the center makes a choice that violates consensus (or some participants think so), a new protocol instance could be forked out and a new center formed.

Forking is an efficient way of evolution for crypto protocols. Biological evolution is about mutation in DNA replication, and sexual reproduction of genetic recombination makes the possibility of mutation more abundant and the success rate is higher. Crypto protocols also mutate during the fork. Unlike bio-evolution random trial and error, crypto protocol variability is a result of deliberate efforts. Each fork gives birth to a new protocol species. The new protocol will inherit all data and a fraction of participants from the original chain. The network effect does not have to start from zero, therefore significantly lowering the trial and error cost.

The highly forkable protocol should lead and even force the miners to choose their position quickly and explicitly. For example, in the Ethereum Casper miners couldn’t mine on both chain after a fork, or their staking will be slashed by both chain. Therefore, the miners face a one-time selection, similar to voting in the prediction market. Miners with clear perspectives use “money” to support their choice while others who don’t make their mind can suspend mining (bear mining revenue loss), wait until the winner to emerge (mainly by token market price comparison), and then they can choose to mine the winner fork. Once mining begins, the cost of the retreat will be extremely high. So we should expect the winner will emerge relatively quickly, perhaps in weeks. The winner inherits most of the network effects of the original network while the loser takes few. DApps, tools, and facilities (exchanges, wallets, blockchain browsers, etc.) will also follow the winners, and the forking will not disturb users much.

 

PoW allows the miners to ride the wall, and the miners distribute computing power based on the tokens market price and the difficulty of mining. In order to gain support from the computing power, the new center and the old one both have the incentive to manipulate the price on the secondary market and even launch 51% attacks. If both sides have enough supporters and resources, the two chains will co-exist and interfere (such as 51% attacks possibility) with each other for a long period of time. DApps, tools, and facilities may choose to support one of them or both, in any case, leave confusion to users.

Some protocols seem to be forkable, but actually impracticable. For example, on chain forked out from DPoS protocol, the supernodes remain. I don’t know how to form a new center in this situation, but reasonable to assume it is costly and cumbersome. And even succeed, it only replays the young man and dragon show, and nothing to prevent the young man from becoming a new dragon.

Most of DApps, if not all of them, are unforkable. Because in most of DApps, only part of the data and logic are resident on a public blockchain, other data and logic are in proprietary servers. Any forking attempt cannot replicate the full state of the DApp. Moreover, Ethereum, EOS and other public chains do not provide a reliable and convenient way to completely copy the smart contract status from the outside. From forkability prospective, most DApps do not belong to so-called open networks.

 

In Chris Dixon’s Why Decentralization Matters, he clearly stated:

… Cryptonetworks use multiple mechanisms to ensure that they stay neutral as they grow, preventing the bait-and-switch of centralized platforms… Decentralized networks can win the third era of the internet for the same reason they won the first era: by winning the hearts and minds of entrepreneurs and developers…

I suggest entrepreneurs and developers should check the forkability status of crypto networks before putting any serious resource and effort into them. Always stay alarmed on any attempt to downgrade forkability.

For the crypto protocol developer teams, they shouldn’t restrain themselves from either influencing or contributing positively to the community. Instead, they should make a commitment to forkability, and understand its implication to their protocol design and other activities. That way they can participate fairly in the construction of the blockchain economy and share risks and success fairly with other participants.

For crypto protocols which incorporate on-chain governance, such as Decred, the foundation and core development team remains central. The major obstacle of on-chain governance is that most network participants are more accustomed to voting with their feet rather than hands, or implicitly rather than explicitly. Then it is quite difficult to set a proper majority threshold for protocol upgrade voting. If the threshold is too low, any proposal even if the unfair ones from the core team is easy to pass, considering that they(including foundation) usually own or directly affect some of the ballots. If the majority threshold is too high, some urgent patch may be blocked by low turnout and a controversial proposal may be deadlocked. In this case, there are two ways to form a new center, both need a new dev team. The first one is to submit a proposal to replace the one from the core team. The second way is to fork, say let the participants vote with their feet instead of using their hands, which is cheaper and more feasible. So as long as sound forkability ensured, on-chain governance is not necessities.

The original version of this piece was written in Chinese and published on Naissence Project Core Wechat Channel.

Special thanks to Deming Zhu of SUSY Labs ([email protected]) for contributions to review and polish this article.

This article does not constitute any investment advice. Thinkers predict the future while investors predict each other.