電子發燒友App
導讀
本文是Rebase社區的Harry在《全名挖礦月》Nervos專場活動上做的分享。
比特幣共識也稱為中本聰共識（Nakamoto Consensus），經歷了10年的運行證明了它的安全性和眾多優點，不過中本聰共識也因為它的吞吐量不高一直飽受詬病。CKB共識是中本聰共識的改進版，通過三大創新，在不妥協安全性的前提下，實現了吞吐量的提升，并解決了自私挖礦的問題。
中本聰共識的優點
1.安全性高
中本聰共識經歷了很多的攻擊，仍然穩定運行了十年。而且，目前沒有任何一個工作量證明機制整體超越中本聰共識。其它的協議要么有很強的安全假設，要么會引入新的攻擊。
?安全假設： 比如使用PoS的Algorand要求持有Token的人時刻保持在線來接收消息。
?新的攻擊： PoS的Nothing-at-stake Attack，Long-range Attack，這些攻擊在PoW中是不存在的。
2.帶寬利用好
在帶寬利用方面，我們可以用一個簡單的模型來衡量共識協議的吞吐量。
最左側藍色的部分是用來同步最終確認交易的帶寬比例，這部分是真正的TPS；中間紅色部分是被共識協議“浪費”的帶寬比例；最右側白色部分是未被利用的帶寬。
在帶寬一定的情況下，想要提高 TPS，能夠做的只有兩件事：
1）降低共識協議“浪費”的帶寬比例
2）降低未被利用部分的帶寬比例
為了加快區塊的傳播，中本聰共識使用了Compact block relay，Compact block中包含：
?80字節的區塊頭
?短交易id
?預測的發送方有而接收方沒有的交易
最終1MB的區塊只需要廣播13KB的區塊消息，節約傳輸的每一個字節。在這一點上，中本聰共識已經做得非常好了，沒有被共識協議浪費什么帶寬。
其它很多協議，它們將珍貴的帶寬資源浪費在成員間的通訊上，比如Algorand用一個大小為300KB的區塊證書來向用戶證明一個區塊被提交。
3.通用性好
中本聰共識可以確保在區塊生成時就能確定全局交易順序，這是和智能合約的編程模型相兼容的。而很多其他拓撲結構的替代協議要么放棄全局交易順序，要么需要經過很長的時間才能確認，這極大地限制了其效率上的提升或者功能上的豐富。
中本聰共識哪些地方可以改善
1.帶寬利用不足
在比特幣隔離見證（Segwit）之后每個區塊對應的數據增加到了4MB（1MB區塊+3MB隔離見證數據）；比特幣的IPv4 節點帶寬中位數在 2016 年時是33Mbit/s，在 2017 年 2 月，這個數字達到56Mbit/s，是2016年的1.7倍。帶寬增加了，而比特幣網絡的吞吐量卻沒有增加。
我們可以想到，如果能夠根據帶寬狀況來動態調節吐吞量就好了。
2.激勵問題
中本聰共識中，自私挖礦是有利可圖的，自私挖礦會增加孤塊率，使得正常的出塊數量減少。在下一個難度調整周期，協議會認為挖礦難度太高，會降低挖礦難度，結果會使自私挖礦一方在單位時間內挖到的幣增加，從而獲得比正常挖礦更多的收益。
我們可以想到，如果可以避免自私挖礦就好了。
更好的中本聰共識——CKB共識
為了解決中本聰共識遇到的問題，CKB共識帶來了三個創新：
?兩步交易確認： 降低孤塊率
?動態調整區塊間隔和區塊獎勵： 更好的利用帶寬
?難度調整考慮所有區塊： 防止自私挖礦
結果帶來了幾個方面的提升：
?性能提升
?安全提升
?公平性提升
后面我們一一解讀。
兩步交易確認
前面提到，在帶寬條件一定的情況下，中本聰共識已經對帶寬進行了非常好的利用，所以提升中本聰共識的吞吐量只能做兩件事：
?更大的區塊
?更小的出塊時間
更大的區塊導致了在區塊廣播是需要更多的傳輸時間，在這個過程中，其它的礦工就有更大的可能發現一個區塊，導致這個區塊成為孤塊；更小的出塊時間相當于降低了出塊難度，讓發現區塊更容易，也容易導致孤塊率的增加。當孤塊率高到一定程度，上面兩個方法都不能讓吞吐量繼續增加。
而且孤塊還會對網絡的安全和性能產生很大的影響。
安全方面，如下圖，孤塊率高會導致攻擊者可以以遠低于51%的算力構造出一條最長的鏈。
性能方面，孤塊會占用帶寬資源，影響網絡吞吐量。
從上面的分析，要想打破吞吐量的限制，就需要降低孤塊率。
那如何降低孤塊率呢？
孤塊的出現是因為區塊廣播的延遲，而區塊廣播的延遲主要是因為同步Fresh Transaction（發送方有而接收方沒有的交易）。
CKB共識采用兩步交易確認來緩解這個問題。下圖是CKB共識中區塊的數據結構：
?區塊確認區（commitment zone）中是確認的交易
?提案區（proposal zone）中會放置交易id，用于n個高度后的區塊的確認
?叔塊頭（uncle headers）和叔塊提案區（uncles‘ proposal zones）會放置叔塊的相關信息
每個礦工只允許打包前面h-m到h-n之間提案區以及叔塊提案區的交易。
從上圖中可以看到，當前高度為h（Height： h）的區塊只能打包從window區域內（h-m到h-n）挑選出的提案區交易，叔塊提案區的交易也可以進行打包。這就保證了礦工總是有足夠的交易可以打包，從而消除了同步Fresh Transaction帶來的區塊廣播的延遲，最終降低孤塊率。
而且因為在compact block中已經包含了所有已確認交易的id，礦工在新區塊中不會將這部分交易包含進來，讓礦工可以很容易的為交易確認做貢獻，并獲得手續費。
動態調整區塊間隔和區塊獎勵
通過設定一個固定的孤塊率，在下一個難度周期（Epoch）動態調整難度。
如果孤塊率低于設定值，說明網絡可以處理更多的交易，在下一個難度周期可以繼續降低難度，這個時候出塊時間將會降低，吞吐量會增加，區塊獎勵會相應減少。
反過來，如果孤塊率高于設定值，說明網絡處理不了這么多交易，在下一個難度周期應該提高難度，會使出塊時間增加，吞吐量會下降，區塊獎勵也相應增加。
在CKB區塊瀏覽器（https://explorer.nervos.org/）中，我們可以通過區塊的信息來部分驗證上面提到的過程。
從上圖中可以看到，一個區塊包含了以下信息：
?Epoch： 0 — 當前的難度周期序號為0
?Epoch Start Number： 0 — 當前Epoch開始的區塊高度（block height）為0
?Epoch Length： 1250 — 當前Epoch包含了1250個區塊，也就是區塊高度從0到1249
?Difficulty： 37522 — 當前Epoch難度值為37522
?Block Reward： 1000 CKB — 每個區塊的獎勵為1000 CKB
?Uncle Count： 0 — 叔塊數量為0
這些信息在當前Epoch 0中的1250個區塊中都是相同的。
在下一個Epoch，也就是從區塊高度為1250開始，挖礦難度值有一定的變化（如上圖）：
?Epoch： 1 — 當前的難度周期序號為1
?Epoch Start Number： 1250 — 當前Epoch開始的區塊高度（block height）為1250
?Epoch Length： 838 — 當前Epoch包含了838個區塊，也就是區塊高度從1250到2088
?Difficulty： 75044 — 當前Epoch難度值為75044
?Block Reward： 1491.64677805 CKB — 每個區塊的獎勵為1491.64677805 CKB
?Uncle Count： 0 — 叔塊數量為0
Epoch 1相對于Epoch 0難度值變大，導致吞吐量（區塊數量）減少，區塊獎勵增加，但是Epoch的獎勵總和沒有變化：
Epoch 0： 1250 * 1000 CKB = 1，250，000
Epoch 0： 838 * 1491.64677805 CKB = 1，250，000.0000059
通過以上的信息可以觀測到由于孤塊率的變化引起的Epoch難度值的調整。但由于目前還無法知道整個Epoch的孤塊率是多少，所以無法觀測到孤塊率對于Epoch難度調整的影響的很直觀的聯系。
防止自私挖礦
前面提到，中本聰共識中自私挖礦是有利可圖的，研究發現是因為網絡難度的調整只考慮區塊數量這一個維度。那CKB是如何解決這個問題的呢？
在CKB共識中，下一個Epoch的難度調整不只是計算已確認區塊的數量，還會將孤塊以及叔塊考慮進來，因此攻擊者不能使用自私挖礦的方式來使得網絡降低難度，所以也不能使用同樣的算力獲得更多的收益，最終自私挖礦在CKB中變得無利可圖。
最后
最后再強調一下CKB共識的優點：“CKB共識是中本聰共識的改進版，通過三大創新，在不妥協安全性的前提下，實現了吞吐量的提升，并解決了自私挖礦的問題“。但CKB共識還是一個新生事物，需要時間的驗證，我們也會持續的關注CKB共識的最新進展和發現。
工商網監
評論