區塊鏈必讀文：《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商學院 的文章

關鍵字: 軟件 政治 必讀