更好的中本聰共識—淺談CKB共識

買賣虛擬貨幣
導讀本文是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共識中區塊的資料結構:

•區塊頭(header)中放置區塊的元資訊
•區塊確認區(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共識的最新進展和發現。

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;