Zilliqa 的設計構思 第3部分：使共識更有效

2018年2月5日

Zilliqa博客發佈，Rita譯

歡迎加入咱們的社區，向咱們提問並獲取最新（但願也是最棒的）資訊！

Nakamoto共識協議（或PoW）不理想以及爲何Zilliqa須要一個不一樣的共識協議。Zilliqa使用的共識協議被稱爲實用拜占庭容錯（PracticalByzantine Fault Tolerance），簡稱pBFT，該協議具備計算成本低、在低能耗的狀況下便可賦予交易最終性、提出下個區塊無需確認等多個優勢。

然而，卡斯特羅和利斯科夫（Castroand Liskov）在其論文（連接https://dl.acm.org/citation.c...）中設計的經典pBFT 只有在共識組（在Zilliqa中指一個分片）較小時，例如少於50個節點，才具備較高的通訊效率。當共識組變大，節點之間的通訊成本將驟升從而成爲效率的障礙。而咱們此前的文章提到，Zilliqa中任何分片都必須有至少600個節點才能確保其中拜占庭節點（即惡意節點）的比例低於三分之一的機率很是低。

本文是此係列文章的終篇，咱們將討論經典pBFT協議對通訊的要求有多高以及咱們如何使用多重簽名的方法來下降這個要求。

在本文中，咱們將用n來表示共識組的大小， Zilliqa中n假設等於600。

pBFT的通訊成本

在此前提到的論文中，經典pBFT要求每一個節點與全部其餘節點通訊共享協議消息，從而對系統狀態達成一致。這意味着每一個節點都必須發送n條消息，所以總的通訊數量爲n2，這一通信成本是很高的。

認證消息的成本

此外，在拜占庭網絡中僅僅發送消息是不夠的。特別是在一個公開的拜占庭網絡中，當節點A接收到來自節點B的消息時，A必須肯定該消息確實由B發送，且該消息在傳輸過程當中未被修改，沒有這種保證，節點就很難確保消息的真實性，由於黑客能夠在中間環節修改消息並給節點提供不正確的信息。

一種驗證消息傳輸的解決方案是在A和B之間生成保密的密鑰，而後可使用該密鑰爲每一個傳出的消息生成「標籤」。因爲只有A和B知道密鑰，因此標籤只能由A或B生成，從而他們能夠驗證消息的來源。

消息認證碼（MessageAuthentication Code，簡稱 MAC）是能夠生成這種標籤的加密方法。構建MAC的一種可能方式是使用加密散列函數（cryptographichash function），該函數將密鑰和消息做爲輸入並生成標籤做爲輸出。

下圖顯示了發送者和接收者使用MAC的方式。發送者用消息和密鑰經過MAC生成標籤，並將其與消息一塊兒發送給接收者。接收者再次計算MAC獲得一個標籤，將之與收到的信息進行比對，確認二者是否吻合，如吻合則該消息未被篡改。

然而，MAC和大多數對稱密鑰方法的問題在於，若是咱們有n個節點，每對節點都須要一個密鑰。所以，若是咱們有n個節點，總共須要n（n-1）/ 2個密鑰。

那麼MAC的通訊成本究竟是多少？若是咱們在網絡中有4個節點A、B、C、D，當A要向整個網絡即向B、C、D發送消息時，A要建立3個不一樣的標籤由於A與B、C、D分別有不一樣的密鑰。如今，假設A用B做爲中繼（relay）將標籤傳送到C和D，那麼A將須要向B發送3個標籤（參見下圖）。B在收到它的標籤後，用C做爲中繼將A的標籤轉發給C和D時，它只會向C發送2個標籤。以此類推，使用這種簡單的基於中繼的廣播機制分發的消息總數爲3 + 2 + 1 = 6。

此圖顯示出一條消息在網絡中傳輸的方式。三種不一樣的顏色顯示出A建立的三個不一樣的標籤，A先將三個標籤發送給B，B再將兩個標籤發送給C，最後C轉發最後一個標籤給D。

對於具備n個節點的網絡，若是咱們使用MAC，則以標籤形式發送的消息總數爲：（n-1）+（n-2）.. + 1 = n（n-1）/2。

採用公鑰密碼學提升效率

由於驗證消息上的簽名也能夠確保該消息確實是由合法的發送者簽發的，所以MAC實際上能夠用數字簽名來替代。卡斯特羅和利斯科夫之因此沒有使用數字簽名是由於，當時計算MAC比生成數字簽名計算量便宜得多。現在，數字簽名的計算量已經至關便宜。

並且，公鑰密碼學自身有不少優勢。爲了理解這一點，咱們繼續使用前面的例子。如今，咱們假設A、B、C、D節點使用數字簽名。所以當A發送消息時，它將簽署消息並由此產生簽名。請注意，A在這裏不須要建立三個簽名，只有一個就夠了。而後簽名被髮送到下一個節點B，B在此只收到一條消息和相應的簽名，B再發給下一個節點C。以此類推，在每一個節點，只有一個簽名被轉發，在這種狀況下分發的消息總數將爲1 + 1 + 1 = 3。

使用數字簽名的傳輸模式時。A只須要爲每一個消息生成一個簽名。

對於具備n個節點的網絡，若是咱們使用數字簽名，則所傳遞的消息總數將爲：1 + 1 +1 …(n-1)次= n-1。

最近有篇學術論文提出了用數字簽名取代MAC的想法

連接：

https://www.usenix.org/confer...

使用數字簽名而不是MAC將發送消息的數量從二次方數量級減小到線性，當n很大時這種減小會產生重要影響。以600個節點爲例，其中傳播的消息數量能夠從17.97萬減小到599。

使用多重簽名方案減小每一個消息的大小

講到這兒，你應該相信使用數字簽名比MAC能更好地減小網絡中需傳輸消息的數量了吧，那麼接下來就讓咱們用數字簽名來替換傳統pBFT協議中的MAC。

如今的問題是，咱們是否找到比數字簽名更好的方法呢?答案是確定的!數字簽名確實還有必定的改進空間，咱們會在將來的博客中更多地介紹這個內容。如今先讓咱們看一下數字簽名有哪些能夠改進的地方。

咱們知道，pBFT賦予了交易最終性，這意味着一旦交易被提交到區塊鏈，那麼它就是最終的了且不會有臨時分叉，所以不須要確認。交易之因此有最終性是由於，pBFT協議自己已要求每一個區塊必須由共識組中的絕對多數誠實節點簽署。每一個誠實的節點經過簽名確認它已經驗證了塊的內容，確保交易有效。而在基於PoW的共識中，每一個節點均可以生成一個區塊，而網絡的其餘節點或接受或拒絕它，這就會致使臨時分叉的產生。

具體的簽名方法是：每一個節點簽署一個區塊，而後將簽過名的區塊轉發到網絡的其他部分，以後其他節點都將本身的簽名附加在這個區塊上，最終在普遍傳播後，這個區塊就會得到絕大多數誠實節點的簽名。若是網絡中的每一個節點(包括惡意節點)都對該區塊進行簽名，那麼區塊的簽名數量爲n，在這裏咱們就須要引入多重簽名的概念了：多重簽名是一種密碼術語，指的是把一條信息上的n個節點簽署的n個簽名整合到一個大小固定的簽名上。

簡化的多重簽名如何工做

在介紹細節以前，讓咱們先了解一下背景：在多重簽名方案中，咱們有n個簽名者，每一個簽名者都有一對密鑰(公鑰和私鑰)、一個驗證簽名的驗證者和一個彙總各方「簽名」的聚合者(aggregator)。爲了便於理解，咱們如今簡單假設全部節點都是誠實的，而且會配合簽署消息。

驗證者在檢驗彙總後的簽名時，會檢查全部簽名者是否都正確地簽了名。僅當驗證者確認全部簽名者都正確地簽了名以後，驗證纔算經過，反之則驗證失敗。

接下來讓咱們深刻細節，請作好準備，由於這有些偏技術性。

多重簽名方案基本上分兩步進行。在協議的第一步中，每一個節點將其公鑰發送給聚合者，聚合者根據公鑰的數學形式，經過簡單的加法或乘法將之聚合爲一個單一的公鑰。

例如，聚合公鑰= 公鑰_1 + 公鑰_2 + …+公鑰_n。

而後聚合者將聚合公鑰轉發給驗證者從而可使後者驗證聚合簽名，與此同時聚合者也將聚合公鑰發送給每一個簽名者讓全部人簽名。

在第二步中，聚合者啓動與每一個簽名者的交互協議（interactiveprotocol）。這個交互協議總分包含三個階段：

一、提交階段（Commit phase）：此階段每一個節點生成一些隨機內容並提交給交互協議。若是你不瞭解什麼是加密提交（cryptographiccommitment），那麼能夠經過這種類比的方式理解：每一個節點都祕密地擲骰子，而後將結果寫在一張紙上並將其放在一個盒子中鎖好，最後發送給聚合者。聚合者無權打開盒子。

二、挑戰階段（Challenge phase）：此階段聚合者首先使用加法或乘法將全部的提交聚合爲一個聚合提交，而後使用它以及聚合公鑰、消息生成一個挑戰，再將挑戰發送到全部節點。以後挑戰可用於確認全部節點都知道公鑰對應的私鑰。這與常規數字簽名的工做方式相似，即由簽名證實簽名人確實知道私鑰。

三、迴應階段（Response phase）：全部節點爲了應對挑戰會向挑戰發送私鑰進行迴應，以後聚合者將聚合全部的迴應。所以迴應可被視爲簽名者知道其公鑰對應的私鑰的證據。

所以，最後的聚合簽名其實是挑戰和聚合迴應的信息對，並能驗證第一步生成的聚合公鑰。

值得注意的是，聚合簽名的大小不取決於簽名者的數量，它是固定的。

圖中藍色的節點是聚合者。H是用於將消息m生成挑戰的密碼散列函數。聚合簽名就是R和S的信息對。R的大小等於Ri，S的大小等於Si的。僅在知道私鑰的狀況下才能生成有效的迴應。

當驗證者檢查聚合簽名時，它檢查的不是每一個單獨簽名者是否都正確地遵照協議，而是檢查全部簽名者做爲一個總體是否正確地遵照協議並知道私鑰。所以，驗證者作出的決定是全有或全無（all-or-nothing）。

目前一種比較流行的多重簽名方案是基於Schnorr數字簽名技術的並因爲一篇學術論文（連接https://arxiv.org/abs/1503.08768）獲得了關注，該論文在一些證人須要證實事件發生的背景下使用了這個技術。

結論

Zilliqa使用了近期一些學術論文中的技術來提升經典pBFT協議的效率。

本文的主要亮點是多重簽名協議將簽名數量從n減小到1，從而減小認定後的區塊的大小。

還有一些問題在這篇文章裏面沒有涉及，最重要的一個問題就是若是隻是絕對多數節點而不是全部節點對信息進行了簽名，那麼這個協議還有效嗎?須要對協議作出什麼樣的修改?另外，你以爲有什麼方法能夠攻擊這個簡單版的多重簽名?

要回答這些疑問，你能夠經過兩種方法：比較難的方法是閱讀 Zilliqa的技術白皮書，連接：

https://docs.zilliqa.com/whit...

而簡單的方法是經過咱們的社區向咱們提出這些問題。

咱們很高興地邀請​​您加入咱們的社區，與技術專家、金融業者和加密數字貨幣愛好者們一同探討！您能夠經過如下方式關注咱們的進展：

微博：https://weibo.com/zilliqa

微信公衆號：ZilliqaCN

Zilliqa中文社區聯盟:http://www.zilliqa.com.cn

關注咱們的推特：https://twitter.com/Zilliqa

經過郵箱訂閱咱們的新聞：http://zilliqa.us16.list-mana...

關注咱們的博客：https://blog.zilliqa.com/

Reddit:https://www.reddit.com/r/zilliqa

Slack：https://invite.zilliqa.com/

Gitter：https://gitter.im/Zilliqa/

電報羣：https://t.me/zilliqachat