区块链必读文：《Vitalik Buterin : 去中心化的真正含义》

“去中心化”这个词是在加密经济学中见到的最多的一个词之一，也是通常被视为到底是不是区块链的依据。然而这个词，也可能是被人们定义的最不恰当的一个词。数千小时的投入研究和价值数十亿美元的哈希算力都被用来试图实现去中心化，并保护和提高去中心化的程度。当人们讨论协议并变得开始激烈时，非常常见的是，一个协议（扩展协议）的支持者会声称对方的协议提案是

但是，“去中心化”这个词到底意味着什么，常常会有很多的混淆。比如说，下面这三个完全没有帮助，但是却太常见的三个图表：

现在，让我们来看看Quora上的问题“分布式和去中心化的区别到底在哪里？”的两个不同回答。第一个回答实际上是在机械地复述上面的图表，而第二个回答则截然不同，他说：“分布式意思是说，并非交易的所有过程都在同一个地点处理，而去中心化意思是没有任何的单一个体可以对交易的处理进行控制。”与此同时，在以太坊问答社区“Ethereum stack exchange”上最顶部答案给出了和上图非常类似的图表，只是“分布式”和“去中心化”的位子换了。显然，这个澄清和说明一下是很有必要的。

关注IBC商学院微信公众号，免费领取68份学习资料

去中心化的三种类型

当人们在讨论软件的去中心化时，他们实际上在讨论的，是三个独立的中心化/去中心化的轴。在某些情况下很难看的清如何在没有另一个的情况下，能判定现在的这个是中心化还是去中心化的。一般来说，中心化和去中心化是互相独立的，这三个轴如下：

1. 架构上的（去）中心化—这个系统是由多少个计算机组成的？这个系统可以容忍多少台计算机在任意一个时间崩溃后还能继续运行？
2. 政治上的（去）中心化—有多少的个人和组织能最终控制组成这个系统的电脑？
3. 逻辑上的（去）中心化—系统呈现和维护的接口和数据库结构像是一个单一的整体呢？还是非结构群体？一个简单的启发是：如果你把这个系统的使用方和提供方一分为二，他们还能作为完全独立的单元进行运行吗？

关注IBC商学院微信公众号，免费领取68份学习资料

我们可以尝试将这三个维度都放在一张图表中说明：

请注意，这图表中很多位置的内容还有待争议，但是让我们尝试着理解一下：

1. 传统的公司在政治上是中心化的（一个CEO），架构上是中心化的（一个总部），逻辑上也是中心化的（你不能真正意义上把他们砍成两半）。
2. 民法依赖于一个权利集中的立法机构，而普通法则是由许多个别的法官做出来的先例而来。民法现在有一部分架构上面的去中心化，因为有很多的不同法院存在，并且也有自行决定的自由，但是普通法却更去中心化。无论是民法还是普通法，在逻辑上来看，他们都是中心化的（法律就是法律）。
3. 语言在逻辑上是分散的：Alice和Bob之间说的英语和Charlie和David之间说的英语不需要一直。没有一种语言的存在需要需要集中式的基础设施，并且英语的语法规则并不是由单一的个人所创造或控制的（然而世界语是最初由Ludwig Zamenhof发明的，现在世界语逐渐的演进更像是一个活跃的语言，没有权限）。
4. BitTorrent和英语一样，在逻辑上是分散的、去中心化的，但类容传送网络和他类似，却是由一个单一的公司所控制。
5. 区块链在政治上是去中心化的（没有人能控制他），在架构体系上也是去中心化的（没有基础设施的中心故障点),但是在逻辑上是中心化的（有一个共同认可的状态，并且系统表现的像一个单一计算机）。

很多时候，当别人在谈论区块链的优点时，他们描述的是拥有一个

架构上的分散化往往导致政治上的集中，但也不一定——在正式的民主体系中，政客们在一些会晤室见面并投票，但是这个房间的维护者并不能够获得大量的决策权改变结果。在计算机化系统中，架构上而不是逻辑上的去中心化可能会发生，如果有一个在线社区为了方便而使用了一个权利集中的论坛，但是如果有一个广为接受的社会契约却遭到论坛的拥有着恶意的破坏的话，那么这个论坛里的所有的人都会离开去另外一个论坛（这个社区是由一群在其他论坛看到审查制度可能在实践中执行的一群反抗的人组成）

逻辑的中心化使得架构上的去中心化更加困难，但也不是不可能-可以看到，分散的共识网络已经被证明有用了，但却比维护BitTorrent更困难。逻辑集中化使得政治分权更加困难-在逻辑集中化系统中，更难通过简单的

去中心化的三个原因

接下来这个问题是，为什么去中心化会有用？通常会有以下几个观点：

1. 容错力：去中心化的系统不太可能意外失效，因为他们依赖于很多独立的组件，而这些独立的组件不太可能一起意外失效。
2. 抗攻击力：去中心化的系统使得被攻击破坏和操控的成本更高，因为他们缺少敏感的中心点，而中心点则容易被比周围经济系统规模更低的成本攻击。
3. 防勾结串通：去中心化系统中参与者更难以牺牲其他参与者为代价而密谋使他们自己获利。而不得不说的是，公司和政府的领导者们密谋做一些利于自己而伤害公民、客户、员工和公众，这是常常发生的事情。

所有的三个论点都是重要和有效的。但是一旦当你开始考虑决定协议的时候，这三个论证都会导致一些有趣和不一样的结论。让我就一个一个的展开这些论证。

关于容错力，核心论证点很简单。什么会不太可能发生：一台计算机出现故障？还是十台计算机中有五台计算机同时出现故障？这个原理是毋庸置疑的，在现实生活中的很多情形中也可以用的到，包括喷气机发动，备用发电机，特别是在诸如医院，军事基地的基础设施，投资组合多元化的地方,当然还有，计算机网络。

然而，这种有效同时也很重要的去中心化，有时远不如一个偶尔用来预测的数学模型的灵丹妙药。原因就是共模故障。当然，四个喷气发动机比起一个喷气发动机来看更不容易出故障，但如果说这四个喷气发动机都是同一个工厂制造的呢？而且这四个喷气发动机都是被同一个不合格的员工制作的呢？

今天的区块链能有效设防共模故障吗？没有必要，可以参考以下场景：

1. 区块链的所有节点都在相同的客户端软件运行，这个客户端软件居然有一个错误。
2. 区块链的所有节点都在相同的客户端软件进行，这个客户端软件的开发团队居然都是社会腐败分子。
3. 提出升级更新协议的研发团队居然是社会腐败分子。
4. 在区块链的工作量证明中，70%的矿工在同一个国家，该国家政府决定为了国家安全的考虑抢占所有的采矿场。
5. 大部分的采矿硬件是由同一家公司建造的，这家公司被贿赂或者被强迫开了一个后门，允许这个硬件被随意关闭。
6. 在区块链权益证明中，70%的利率货币在同一个交易所中。

从容错能力的去中心化的整体观点会看到所有这些方面，并会想如何最小化这些问题。那么从这可以看出，一些结论自然是显而易见的；

1. 实现多方竞争关系是至关重要的
2. 协议升级背后的技术考量的知识必须是民主化的，这样更多的人可以更加自然的参与研究讨论和批评一些明显不良的协议变化。
3. 核心的开发和研究人员应该由多个公司或组织雇佣（或者可以找来许多的志愿者来填充）
4. 挖掘算法应该以最低程度的中心化思路去设计。
5. 理想情况下，我们使用权益证明的方法来完全摆脱硬件的中心化风险(当然我们也要非常小心由于使用了权益证明而可能带给我们的新的风险）。

需要注意的是，初始形式的容错要求在架构上是去中心化的，但是你想，社区的容错能力一旦控制着协议的持续发展，那么可以看出，政治上的去中心化也是非常重要的。

现在，让我们来看看抗攻击能力。在一些纯粹的经济模型中，即使去中心化完全不重要，你也可以得到你想要的结果。如果你创造出一种协议，验证器保证会在51%的攻击（即最终性回归）发生时让你损失5000万美元，那么这个验证器是被一家公司控制还是被一百家公司控制就不是那么重要了。5000万美元的经济安全保证金是5000万美元的经济安全边际成本。事实上，为什么中心化甚至能够最大化这种经济安全的概念是有着很深层次的博弈论的（现有区块链的交易模型反映了这个观点，因为包含在区块中的交易通过矿工/区块申请人实际上也是一种流转的独裁做法）。

然而，一旦你采用了更加丰富的经济模型，特别是承认强制性存在的可能的那种（或者更温和的那种比如定向的针对节点的DOS攻击），去中心化就变得更加重要了。如果你威胁一个人的生命安全，那么5000万美元也就变得对他们来说不再重要了。但是如果5000万美元在十个人中间传播，那么你必须威胁10倍的人数，并且要同时期的做这件事情。一般来说，在许多情况下，现代世界的特点有着攻击/防御的不对称性，有利于攻击者—一幢花费1000万美元的大楼可能会被花费10万美元不到就摧毁了，但攻击者的杠杠往往是亚线性的：如果说摧毁一个花费1000万美元的大楼只需要花费10万美元，那么一幢100万美元的大楼可能只需要3万美元的成本就可以摧毁了。更小的成本给出了很好的比率。

这种推理会导致什么样的结果呢？首先，他强烈的推动了权益证明机制，超过了工作量证明，因为计算机硬件更容易被检测，调节和攻击，而硬币则更容易被隐藏（权益证明机制也因为其他某些原因更容易抵抗来自其他节点的攻击）。其次，他也支持广泛分布的开发团队。第三，当在设计共识协议时，他也会暗示需要同时考虑经济模型和容错模型。

最终，我们可以得到三个论点中最复杂的一个，防勾结串通。串通这个行为很难定义，可能唯一真实有效的表达方法是说“我们都不喜欢的结合”。在现实生活中很多情况下，最理想的情况是每个人之间的协调配合都很完美，但是如果一个人可以协调配合但是其他人不行，那么就是很危险的了。

一个简单的例子是反托拉斯法，为了使市场一方的参与者更难聚集在一起设置监管上的障碍，行动上像一个垄断者以牺牲市场另一方参与者的利益和社会福利，来获得外部的利益。另一个例子是美国候选人和超级PAC之间协调的规则，尽管在实践中被证明难以实施。一个更小的例子是一些象棋比赛中。为了防止两个玩家在比赛中进行很多次游戏试图提高其中一个玩家分数的规则。无论你在哪，成熟机构防止不必要的协调的尝试无处不在。

在区块链协议的情况下，共识背后的数学和经济推理通常依赖于至关重要的不协调选择模型。或者假设说，一款游戏由许多小的可以独立做出决定的角色组成，如果一个角色在工作量证明中获得了超过1/3的矿力，那么他就可以通过私自采矿来获得巨大的利润。但是，我们真的可以说，当90%的比特币的矿力非常的好以至于他们能够出现在同一会议上，这未经协调的选择模型真的是现实的吗？

区块链倡导者也指出，区块链更加的安全，因为他们不能够跟着自己的想法随意改变他们的规则。但是如果说软件和协议的开发者们都为同一家公司工作，或者说是一家人坐在一个屋子里，那么上面这个安全也就不一定能保证了。总的来说，这些系统不应该是被一方单独垄断的。因此，你可以很确定地表示，区块链会更加的给予安全性如果参与方之间都不是协调的关系。

当然，这也显示出了一个根本的驳论。许多的社区，包括以太坊，经常被称赞说有着强壮的社区精神，并且能够很快反应协调实施，发布和激活分叉，在六天内解决服务器拒绝访问的问题。但是我们该如何促进和提高这种积极的协调能力，同时防止坏的矿工反复的协调51%的攻击，使他人陷入困境的“不良协调”呢？

有三种方式来回答这个问题：

1. 不用考虑太多不良的协调问题，反而，应该更多的尝试构建可以抵制他的协议。
2. 尽力找到一个好的媒介允许协议有足够多的协调演进和前进，但这个协调没有足够多到可以发起攻击。
3. 尽量学会区分什么是有利的协调什么是不利的协调，并且尽量使有利的协调更容易，不利的协调更困难。

第一种方式大部分是Casper设计的理念，然而，他本身是不够的，因为单靠经济本身并不能处理好另外两个方式中关于去中心化的考量。第二种方式则在程序开发上难以明确地进行，尤其是长期的开发工作，经常会出现开发不明确的意外。比如说，比特币的核心开发人员经常说英语，而矿工们大部分都说汉语，这就是一个美丽的意外。因为它创造了一种“两院制”管理办法，使协调更加困难，有利于降低同一模型生产的风险，因为英语和中文社区会因为距离和沟通上的困难而产生分歧并且争论一番，因此不太可能会两方会赞成同样的错误。

第三个就是社会挑战，在这方面的解决方案可以有：

1. 社会干预会试图提高参与者对区块链社区的忠诚度以防止市场一方的玩家只对自己这一方的人忠诚。
2. 在同一背景下提高各方市场参与者之间的沟通，让他们清楚，验证方，开发者和矿工都是处于同一阵营的，所以他们之间必须协调好来维护自己的利益抵抗其他的阵营。
3. 以减少鼓励验证方/矿工发展成为一对一的“特殊关系”，减少中心化的传递网络和其他类似的超协议机制的方式来设计这个协议。
4. 明确清楚这条协议的基本属性应该有哪些，什么事情是不应该做的，或者什么事情是只有在极端情况下才可以做的。

第三种去中心化，是以避免不希望发生的协调的去中心化，恐怕这也是最难实现的，权衡取舍是无法避免的。也许最好的解决方案是极度的依赖一个被保证是非常去中心化的一个小组，那就是：协议的用户。

英文原文

The Meaning of Decentralization

by Vitalik Buterin

The Meaning of Decentralization

“Decentralization” is one of the words that is used in the cryptoeconomics space the most frequently, and is often even viewed as a blockchain’s entire raison d’être, but it is also one of the words that is perhaps defined the most poorly. Thousands of hours of research, and billions of dollars of hashpower, have been spent for the sole purpose of attempting to achieve decentralization, and to protect and improve it, and when discussions get rivalrous it is extremely common for proponents of one protocol (or protocol extension) to claim that the opposing proposals are “centralized” as the ultimate knockdown argument.

But there is often a lot of confusion as to what this word actually means. Consider, for example, the following completely unhelpful, but unfortunately all too common, diagram:

Now, consider the two answers on Quora for “what is the difference between distributed and decentralized”. The first essentially parrots the above diagram, whereas the second makes the entirely different claim that “distributed means not all the processing of the transactions is done in the same place”, whereas “decentralized means that not one single entity has control over all the processing”. Meanwhile, the top answer on the Ethereum stack exchange gives a very similar diagram, but with the words “decentralized” and “distributed” switched places! Clearly, a clarification is in order.

Three types of Decentralization

When people talk about software decentralization, there are actually three separate axes of centralization/decentralization that they may be talking about. While in some cases it is difficult to see how you can have one without the other, in general they are quite independent of each other. The axes are as follows:

Architectural (de)centralization — how many physical computers is a system made up of? How many of those computers can it tolerate breaking down at any single time?

Political (de)centralization— how many individuals or organizationsultimately control the computers that the system is made up of?

Logical (de)centralization— does the interface and data structuresthat the system presents and maintains look more like a single monolithic object, or an amorphous swarm? One simple heuristic is: if you cut the system in half, including both providers and users, will both halves continue to fully operate as independent units?

We can try to put these three dimensions into a chart:

Note that a lot of these placements are very rough and highly debatable. But let’s try going through any of them:

Traditional corporations are politically centralized (one CEO), architecturally centralized (one head office) and logically centralized (can’t really split them in half)

Civil law relies on a centralized law-making body, whereas common law is built up of precedent made by many individual judges. Civil law still has some architectural decentralization as there are many courts that nevertheless have large discretion, but common law have more of it. Both are logically centralized (“the law is the law”).

Languages are logically decentralized; the English spoken between Alice and Bob and the English spoken between Charlie and David do not need to agree at all. There is no centralized infrastructure required for a language to exist, and the rules of English grammar are not created or controlled by any one single person (whereas Esperanto was originally invented by Ludwig Zamenhof, though now it functions more like a living language that evolves incrementally with no authority)

BitTorrent is logically decentralized similarly to how English is. Content delivery networks are similar, but are controlled by one single company.

Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)

Many times when people talk about the virtues of a blockchain, they describe the convenience benefits of having “one central database”; that centralization is logical centralization, and it’s a kind of centralization that is arguably in many cases good (though Juan Benet from IPFS would also push for logical decentralization wherever possible, because logically decentralized systems tend to be good at surviving network partitions, work well in regions of the world that have poor connectivity, etc; see also this article from Scuttlebotexplicitly advocating logical decentralization).

Architectural centralization often leads to political centralization, though not necessarily — in a formal democracy, politicians meet and hold votes in some physical governance chamber, but the maintainers of this chamber do not end up deriving any substantial amount of power over decision-making as a result. In computerized systems, architectural but not political decentralization might happen if there is an online community which uses a centralized forum for convenience, but where there is a widely agreed social contract that if the owners of the forum act maliciously then everyone will move to a different forum (communities that are formed around rebellion against what they see as censorship in another forum likely have this property in practice).

Logical centralization makes architectural decentralization harder, but not impossible — see how decentralized consensus networks have already been proven to work, but are more difficult than maintaining BitTorrent. And logical centralization makes political decentralization harder — in logically centralized systems, it’s harder to resolve contention by simply agreeing to “live and let live”.

Three reasons for Decentralization

The next question is, why is decentralization useful in the first place? There are generally several arguments raised:

Fault tolerance— decentralized systems are less likely to fail accidentally because they rely on many separate components that are not likely.

Attack resistance— decentralized systems are more expensive to attack and destroy or manipulate because they lack sensitive central points that can be attacked at much lower cost than the economic size of the surrounding system.

Collusion resistance — it is much harder for participants in decentralized systems to collude to act in ways that benefit them at the expense of other participants, whereas the leaderships of corporations and governments collude in ways that benefit themselves but harm less well-coordinated citizens, customers, employees and the general public all the time.

All three arguments are important and valid, but all three arguments lead to some interesting and different conclusions once you start thinking about protocol decisions with the three individual perspectives in mind. Let us try to expand out each of these arguments one by one.

Regarding fault tolerance, the core argument is simple. What’s less likely to happen: one single computer failing, or five out of ten computers all failing at the same time? The principle is uncontroversial, and is used in real life in many situations, including jet engines, backup power generators particularly in places like hospitals, military infrastructure, financial portfolio diversification, and yes, computer networks.

However, this kind of decentralization, while still effective and highly important, often turns out to be far less of a panacea than a naive mathematical model would sometimes predict. The reason is common mode failure. Sure, four jet engines are less likely to fail than one jet engine, but what if all four engines were made in the same factory, and a fault was introduced in all four by the same rogue employee?

Do blockchains as they are today manage to protect against common mode failure? Not necessarily. Consider the following scenarios:

All nodes in a blockchain run the same client software, and this client software turns out to have a bug.

All nodes in a blockchain run the same client software, and the development team of this software turns out to be socially corrupted.

The research team that is proposing protocol upgrades turns out to be socially corrupted.

In a proof of work blockchain, 70% of miners are in the same country, and the government of this country decides to seize all mining farms for national security purposes.

The majority of mining hardware is built by the same company, and this company gets bribed or coerced into implementing a backdoor that allows this hardware to be shut down at will.

In a proof of stake blockchain, 70% of the coins at stake are held at one exchange.

A holistic view of fault tolerance decentralization would look at all of these aspects, and see how they can be minimized. Some natural conclusions that arise are fairly obvious:

It is crucially important to have multiple competing implementations.

The knowledge of the technical considerations behind protocol upgradesmust be democratized, so that more people can feel comfortable participating in research discussions and criticizing protocol changes that are clearly bad.

Core developers and researchers should be employed by multiplecompanies or organizations (or, alternatively, many of them can be volunteers).

Mining algorithms should be designed in a way that minimizes the risk of centralization

Ideally we use proof of stake to move away from hardware centralization risk entirely (though we should also be cautious of new risks that pop up due to proof of stake).

Note that the fault tolerance requirement in its naive form focuses on architectural decentralization, but once you start thinking about fault tolerance of the community that governs the protocol’s ongoing development, then political decentralization is important too.

Now, let’s look at attack resistance. In some pure economic models, you sometimes get the result that decentralization does not even matter. If you create a protocol where the validators are guaranteed to lose $50 million if a 51% attack (ie. finality reversion) happens, then it doesn’t really matter if the validators are controlled by one company or 100 companies — $50 million economic security margin is $50 million economic security margin. In fact, there are deep game-theoretic reasons why centralization may even maximizethis notion of economic security (the transaction selection model of existing blockchains reflects this insight, as transaction inclusion into blocks through miners/block proposers is actually a very rapidly rotating dictatorship).

However, once you adopt a richer economic model, and particularly one that admits the possibility of coercion (or much milder things like targeted DoS attacks against nodes), decentralization becomes more important. If you threaten one person with death, suddenly $50 million will not matter to them as much anymore. But if the $50 million is spread between ten people, then you have to threaten ten times as many people, and do it all at the same time. In general, the modern world is in many cases characterized by an attack/defense asymmetry in favor of the attacker — a building that costs $10 million to build may cost less than $100,000 to destroy, but the attacker’s leverage is often sublinear: if a building that costs $10 million to build costs $100,000 to destroy, a building that costs $1 million to build may realistically cost perhaps $30,000 to destroy. Smaller gives better ratios.

What does this reasoning lead to? First of all, it pushes strongly in favor of proof of stake over proof of work, as computer hardware is easy to detect, regulate, or attack, whereas coins can be much more easily hidden (proof of stake also has strong attack resistance for other reasons). Second, it is a point in favor of having widely distributed development teams, including geographic distribution. Third, it implies that both the economic model and the fault-tolerance model need to be looked at when designing consensus protocols.

Finally, we can get to perhaps the most intricate argument of the three, collusion resistance. Collusion is difficult to define; perhaps the only truly valid way to put it is to simply say that collusion is “coordination that we don’t like”. There are many situations in real life where even though having perfect coordination between everyone would be ideal, one sub-group being able to coordinate while the others cannot is dangerous.

One simple example is antitrust law — deliberate regulatory barriers that get placed in order to make it more difficult for participants on one side of the marketplace to come together and act like a monopolist and get outsided profits at the expense of both the other side of the marketplace and general social welfare. Another example is rules against active coordination between candidates and super-PACs in the United States, though those have proven difficult to enforce in practice. A much smaller example is a rule in some chess tournaments preventing two players from playing many games against each other to try to raise one player’s score. No matter where you look, attempts to prevent undesired coordination in sophisticated institutions are everywhere.

In the case of blockchain protocols, the mathematical and economic reasoning behind the safety of the consensus often relies crucially on the uncoordinated choice model, or the assumption that the game consists of many small actors that make decisions independently. If any one actor gets more than 1/3 of the mining power in a proof of work system, they can gain outsized profits by selfish-mining. However, can we really say that the uncoordinated choice model is realistic when 90% of the Bitcoin network’s mining power is well-coordinated enough to show up together at the same conference?

Blockchain advocates also make the point that blockchains are more secure to build on because they can’t just change their rules arbitrarily on a whim whenever they want to, but this case would be difficult to defend if the developers of the software and protocol were all working for one company, were part of one family and sat in one room. The whole point is that these systems should not act like self-interested unitary monopolies. Hence, you can certainly make a case that blockchains would be more secure if they were more discoordinated.

However, this presents a fundamental paradox. Many communities, including Ethereum’s, are often praised for having a strong community spirit and being able to coordinate quickly on implementing, releasing and activating a hard fork to fix denial-of-service issues in the protocol within six days. But how can we foster and improve this good kind of coordination, but at the same time prevent “bad coordination” that consists of miners trying to screw everyone else over by repeatedly coordinating 51% attacks?

There are three ways to answer this:

Don’t bother mitigating undesired coordination; instead, try to build protocols that can resist it.

Try to find a happy medium that allows enough coordination for a protocol to evolve and move forward, but not enough to enable attacks.

Try to make a distinction between beneficial coordination and harmful coordination, and make the former easier and the latter harder.

The first approach makes up a large part of the Casper design philosophy. However, it by itself is insufficient, as relying on economics alone fails to deal with the other two categories of concerns about decentralization. The second is difficult to engineer explicitly, especially for the long term, but it does often happen accidentally. For example, the fact that bitcoin’s core developers generally speak English but miners generally speak Chinese can be viewed as a happy accident, as it creates a kind of “bicameral” governance that makes coordination more difficult, with the side benefit of reducing the risk of common mode failure, as the English and Chinese communities will reason at least somewhat separately due to distance and communication difficulties and are therefore less likely to both make the same mistake.

The third is a social challenge more than anything else; solutions in this regard may include:

Social interventions that try to increase participants’ loyalty to the community around the blockchain as a whole and substitute or discourage the possibility of the players on one side of a market becoming directly loyal to each other.

Promoting communication between different “sides of the market” in the same context, so as to reduce the possibility that either validators or developers or miners begin to see themselves as a “class” that must coordinate to defend their interests against other classes.

Designing the protocol in such a way as to reduce the incentive for validators/miners to engage in one-to-one “special relationships”, centralized relay networks and other similar super-protocol mechanisms.

Clear norms about what the fundamental properties that the protocol is supposed to have, and what kinds of things should not be done, or at least should be done only under very extreme circumstances.

This third kind of decentralization, decentralization as undesired-coordination-avoidance, is thus perhaps the most difficult to achieve, and tradeoffs are unavoidable. Perhaps the best solution may be to relyheavily on the one group that is guaranteed to be fairly decentralized: the protocol’s users.

IBC商学院，技术+智慧 赢未来

IBC商学院作为全球区块链技术交流平台，拥有区块链领域的博士、专家的强大师资力量。在这里你可以得到区块链最新资讯，学习区块链知识、区块链技术编程以及区块链项目投资，财富建立于智慧之上！

閱讀更多 IBC商學院 的文章

關鍵字: 软件 政治 必读