如何讓中本聰共識更牛

新的基礎設施涌現出新的技術，而新技術中所帶來的慾望則孕育着技術的自否認。原有的基礎設施終因沒法再知足慾望所需而被遺棄，在新的技術與慾望的共同推進下實現變革。

人類自己就是在不斷迭代的環境中自我進化，不斷適應新的技術和掌握新的技能，若沒法學習和成長，天然被淘汰。而技術自己也是，若技術沒法跟上時代發展的步伐，技術自己也會被超越，被淘汰。

公鏈和圍繞公鏈造成的生態就如同一個社會體系，不少時候整個社會不是不想快速前進，而是須要一個保守的方式，以穩定和安全爲第一優先級，儘可能用最小化的變更完成對新狀況的適應。

咱們必須認可區塊鏈是相似硬件的軟件，回顧這項技術並不長的歷史，咱們已經明顯感覺到它這一項弱點：每一次分叉都是對整個社區的一種衝擊。好比，以太坊從 2015 年至今，經歷了三次分叉：

• Homestead 分叉，經過了 3 個 EIP；
• Byzantium 分叉，經過了 8 個 EIP；
• Constantinople 分叉，經過了 5 個 EIP。

而 GitHub 中的正在討論的 EIP 還有上千個。

每次分叉都是在千萬個需求中艱難地作抉擇，找到當下最必要的幾個需求作出改進，並在社區進行大規模的探討。以太坊的核心開發者要清楚智能合約平臺目前面臨的狀況，調查開發者們的需求，評估每個協議改進對以太坊自己的影響；並且在一個開源的體系中，每一次改進都會有諸多的安全問題。如最新的君士坦丁堡分叉，SSTORE 指令的改進在最後關頭被 ChainSecurity 團隊發現漏洞，是一個本來不會出現、可是改進以後牽扯到其餘代碼帶來的可重入漏洞問題。對於一個如此龐大的開源生態，在不斷權衡升級的利弊以後，你還不得不在升級以前在測試網反覆進行測試來確保安全性，確保任何指令不會因爲本次對代碼的修改形成其餘後果。

可是現實狀況就是，技術是不斷進步的，不斷會有新的硬件設施、軟件技術，會有全新的需求，要求區塊鏈協議作出必定的改進。最理想的方式是區塊鏈可以足夠的底層、足夠靈活、足夠簡單，在須要升級的時候可以儘量避免過多的變更。

協議是否可以自我調整？

若協議可以自動適應環境的變化，擁有某種相似自我進化的能力，是否可以極大程度改善這一點？在這其中，共識的設計關係到網絡和計算能力，是其中關鍵的一個部分。

比特幣是目前運行最久的區塊鏈，已經運行了十年，而十年前和十年後，帶寬水平發生了巨大的變化。

如同上圖中這個研究所指出的，連接到網絡中的比特幣 IPv4 節點在 2016 年時帶寬中位數爲 33 Mbit/s，在 2017 年 2 月，這個數字達到了 56 Mbit/s。而比特幣的最大吞吐量至今沒有太大的改觀。

那是否有能力來讓共識算法可以根據環境調節本身的吞吐量，而不須要經過分叉等方式進行升級呢？這裏有兩個規律咱們須要去了解，雖然規律是對歷史的總結，可是某種程度上咱們能夠用這些規律預測將來。

你們熟知的摩爾定律 Moore’s Law
也就是集成電路性能18-24個月翻倍，一樣的，存儲器也是遵循一樣的規律。也有表述稱每一年增加 60%。

以及你們不必定知道的 Nielsen’s Law
這是一個和帶寬水平有關的定律，大體意思是用戶的帶寬每一年增加 50%。

相對於摩爾定律每一年 60% 的計算速度增加速率，帶寬增加速率慢大約 10 %。

圖片來自：Nielsen Norman Group https://www.nngroup.com/artic...

上圖是 1983 年到 2018 年帶寬的變化曲線，注意豎軸是 Log10，因此咱們也可以看到帶寬的增加也是指數形式增加的。

在張韌博士以前的分析中 1，咱們知道衡量區塊鏈共識協議的一個標準是帶寬利用率。帶寬提升，是節點間通訊水平的提高，意味着共識會更加高效。

而共識協議是一開始就寫死的，若是須要修改則進行分叉。比特幣、以太坊若是須要根據網絡狀況提升本身的吞吐量，須要的是開發者對網絡狀況進行估計，權衡效率和安全，而後採用一種保守的方案對協議進行升級。

升級又是一件痛苦的事情，最好的狀況是：設計一種共識機制可以根據帶寬水平的提高「自我進化」，來適應帶寬增加帶來的變化。

如何設計能夠自我調整的共識協議？

那麼咱們須要去思考，有沒有一個區塊鏈可以感知的指標，同時這個指標可以體現當前網絡的狀況。根據這個指標協議可以動態調節本身的吞吐量？

在 PoW 共識協議的研究中，有一個很重要的概念是孤塊。

百度百科的定義是：在比特幣協議中，最長的鏈被認爲是絕對的正確。若是一個塊不是最長鏈的一部分，那麼它被稱爲是「孤塊」。一個孤立的塊是一個塊，它也是合法的，可是發現的稍晚，或者是網絡傳輸稍慢，而沒有能成爲最長的鏈的一部分。在比特幣中，孤塊沒有意義，隨後將被拋棄，發現這個孤塊的礦工也拿不到採礦相關的獎勵。

以比特幣爲例，一個在中國的礦工很幸運的在上個區塊出塊以後的 9 分鐘的時候挖到了區塊，而後他很開心地開始廣播這個區塊。可是這個區塊花了幾十秒仍是沒有廣播到美國的礦工，十分鐘的時候美國的礦工發現了一樣高度的區塊，也開始廣播。隨着兩個區塊經過比特幣的 P2P 協議不斷廣播開來，這時候你們會發現網絡裏有兩個相同高度的區塊，這時候比拼的就是全網算力的支持，一部分算力承認北美礦工的區塊，根據這個區塊所在的鏈進行挖礦，另外一個則在中國礦工所在鏈上挖礦，這時候就是產生了分叉，在隨後的幾個區塊競爭中，雙方陣營的礦工必然有一個先搶出塊權，成爲最長鏈，然後根據最長鏈原則，最後只能有一條最長鏈被全部礦工接受，結束分叉。另外一條被遺棄的鏈上面的區塊就是孤塊。

孤塊就是由於帶寬限制產生的延遲，礦工沒有收到新的區塊而本身出塊產生了競爭，而這個競爭必然帶來一方礦工的損失。而且短暫的分叉其實也是損害了網絡的安全性，這也是咱們應該避免的。若是咱們可以假設帶寬無限好，區塊出塊可以瞬間無縫廣播出去，那麼就不會存在這樣的競爭出現孤塊，沒有人損失，也不會產生安全上的問題。

而孤塊是區塊鏈可以感知的，咱們能夠用全網的孤塊率做爲指標，來評估目前網絡帶寬狀況。孤塊率低的時候意味着網絡狀況良好，沒有太多的出塊競爭，高的時候則表示網絡狀況太差，須要調高出塊難度，提升出塊間隔避免密集的出塊產生競爭。所以設置一個合理的孤塊率做爲指標，協議根據當前孤塊率，對比這個指標評估網絡狀況動態調節出塊難度會是一個不錯的選擇。

帶寬利用率是評估共識效率的重要指標。 在孤塊率較低的時候，這意味着網絡狀況良好，可以承載更多的吞吐量。所以這時候能夠下降出塊難度，下降出塊間隔，提升吞吐量，更好地利用網絡帶寬。

孤塊率較高的時候，意味着網絡狀況比較差，這時候能夠提升出塊難度，提升出塊間隔，下降吞吐量。

這樣，經過設定孤塊率調節吞吐量，隨着將來帶寬水平的提高，協議也可以根據網絡狀況的優化提升吞吐量來適應將來的發展和變化，在保證必定安全性的同時，充分利用網絡帶寬。

在 Nervos 共識研究員張韌的設計中，就是採用了這樣的設計思路。

張韌由於對 Bitcoin Unlimited 漏洞的研究，被 Blockstream 邀請實習，實習期間和 Pieter Wuille和Greg Maxwell 對目前全部的 PoW 共識機制做出研究。目前張韌在魯汶大學 COSIC 實驗室師從 Bart Preneel ，並和導師完成了研究論文《Lay Down the Common Metrics: Evaluating Proof-of-Work Consensus Protocols’ Security》，近期該論文被頂級會議 IEEE S&P 收錄。

在他的設計中，在每個難度週期根據網絡中的孤塊率（孤塊的信息會被打包到區塊中用於統計和計算）動態調節難度，從而調節出塊間隔。這個共識協議的設計在比特幣 Nakamoto Consensus （即中本聰共識）的基礎上進行修改，可以在不損失安全性的同時提升網絡的吞吐量 —— 咱們稱這個共識算法爲 NC-Max，咱們但願它可以突破 Nakamoto Consensus 的吞吐量極限。

固然細心的讀者可能會想到兩個問題：

出塊獎勵如何計算？

出塊間隔是變化的，出塊獎勵其實也是變化的。可是在一個難度調節週期，總出塊獎勵保持不變。

吞吐量提升以後，是否有存儲的問題？交易速度提升了，交易產生的存儲需求也會增長。

很巧的是，根據以前提到的 Moore’s Law 以及 Nielsen’s Law ，帶寬增加速度略慢於存儲水平的提高。所以，在帶寬提高、吞吐量提高的同時，計算能力和儲存能力會不斷跟上甚至超越，不會出現因爲 TPS 太高對計算能力的要求而須要更強的超級計算機，損失去中心化。

另外，在 NC-Max 的設計中，除了採用動態調整出塊間隔和區塊獎勵來提高帶寬利用率之外，還有兩個設計亮點：

• 採用兩步交易確認來下降孤塊率：交易首先會提交交易的編號（編號是完整交易的 hash
  值，和交易一一對應）在區塊的交易提案區進行共識，以後只有通過提案的交易才能完整發送，從而可以必定程度下降孤塊率
• 在難度調整的時候考慮週期中全部的區塊，包括孤塊，來抵禦「自私挖礦」攻擊

如感興趣，能夠查看《Nervos CKB 共識協議 NC-Max：突破 Nakamoto Consensus 吞吐量的極限》

目前，Nervos CKB 共識協議 RFC 已經發布，歡迎各位小夥伴提出意見和建議：https://github.com/nirenzang/...

該 RFC 草案由 Nervos 研究員張韌提交，暫命名爲 NC-Max，在比特幣的 Nakamoto Consensus 的基礎上，有三大創新：

• 經過兩步交易確認，下降孤塊率
• 動態區塊間隔和出塊獎勵，有效利用帶寬
• 在難度調整週期考慮全部的區塊來防止自私挖礦

本文做者：Ryan