Zilliqa設計思想詳細分析：第3部分

翻譯：雷諾

在我們之前的文章中，我們討論了為什麼Zilliqa需要一個不同的共識協議，以及為什麼經典的中本聰風格共識協議（PoW）不理想。

Zilliqa中使用的共識協議被稱為實用拜占庭容錯（Practical Byzantine Fault Tolerance），簡稱pBFT。該協議由於計算成本低具有多個優點，並因此產生小的能量足跡來提供交易終結，從而消除了確認的需要。

然而，卡斯特羅和利斯科夫在其原始論文中設計的經典pBFT只有在共識組較小時才具有通信效率，例如少於50個節點。當共識組變大時，節點之間的通信很快就會成為瓶頸，比如我們在Zilliqa中需要大約600個節點。別忘了Zilliqa中的任何共識組必須至少有600個節點才能確保（很可能）其中不足1/3的共識組是採用拜占庭協議。

在本系列的最後一部分中，我們討論經典pBFT協議對通信的要求有多高以及我們如何使用稱為多重簽名的方法來減少這個要求。

在本文的其餘部分，我們用n來表示共識組的大小。在Zilliqa的情況下，n可以假定為600。

pBFT的通信成本

pBFT要求所有誠實的節點對系統的狀態達成一致，因此需要節點彼此之間進行大量的通信。原始論文中描述的協議要求每個節點與每個其他節點通信以共享協議消息。這意味著每個節點必須發送n條消息。因此，總的通信要求是n2的數量級。

認證消息的成本

此外，僅僅通過拜占庭網路發送消息是不夠的。特別是，當節點A公開的拜占庭網路中從另一節點B接收到消息時，A必須確定該消息確實由B發送，並且該消息在傳輸期間未被修改。沒有這種保證，節點就很難確保消息的真實性，因為中間環節黑客可以在路由上修改消息並給節點提供不正確的信息。

一種驗證消息傳輸的解決方案是生成在A和B之間保密的密鑰。然後可以使用該密鑰為每個傳出消息生成標籤。由於只有A和B都知道密鑰，所以標籤只能由A或B生成。然後，標籤允許他們驗證消息的來源。

消息認證碼（MAC）是可以生成這種標籤的加密術語。構建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作為中繼，將他的標籤傳送到C和D，這樣A將需要向B發送3個標籤（參見下圖） 。同樣，當B需要將A的標籤轉發給C和D時，它可能決定使用C作為中繼。由於B已經收到了它的標籤，它只會向C發送2個標籤，以此類推。使用這種簡單的基於中繼的廣播機制分發的消息總數將為3 + 2 + 1 = 6。

一條消息在網路中傳輸的方式，它必須創建三個不同的標籤（採用不同的顏色）。它將三個標籤發送給B，然後將兩個標籤發送給C.最後，C轉發最後一個標籤給D。

對於具有n個節點的網路，如果我們使用MAC，則傳達的消息總數（以標籤形式）將為：n +（n-1）+ ... + 1 = n（n + 1）/ 2。

採用公鑰密碼學提高效率

MAC實際上可以用數字簽名來替代，因為驗證消息上的簽名也確保該消息確實是由合法的發送者簽發的。卡斯特羅和利斯科夫之所以沒有使用數字簽名，是因為當時計算MAC比生成數字簽名便宜得多。如今，數字簽名相當便宜。

而且，公鑰密碼學帶來了自身的好處。為了看到這一點，我們繼續前面的例子，用四個節點A，B，C和D.我們現在假設節點使用數字簽名。因此，當A發送消息時，它將簽署消息併產生簽名。然後簽名將被發送到下一個節點B。請注意，A不需要在這裡創建3個簽名，只有一個簽名就足夠了。所以，B只收到一條消息和相應的簽名。B然後將（消息，簽名）對轉發給下一個節點C，以此類推。在每一個節點，只有一個簽名被轉發。在這種情況下分發的消息總數將為1 + 1 + 1 = 3。

使用數字簽名的傳輸模式時。「A」只需要為每個消息生成一個簽名。

對於具有n個節點的網路，如果我們使用數字簽名，則所傳遞的消息總數將為：1 + 1 + 1 ...（n-1）次= n-1。

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

使用數字簽名（而不是MAC）將消息的數量從二次減少到線性。當n很大時，這種減少會產生重要的影響，以600個節點為例，其中傳播的消息數量可以從180,300減少到599。

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

到目前為止的論述應該讓你相信，使用數字簽名比使用MAC能更好的減少網路中所需傳輸消息的數量。那麼，我們現在該做什麼，...，好吧，讓我們做最應該做的就是用數字簽名替換傳統pBFT協議中的MAC。

現在的問題是，我們是否可以找到比數字簽名更好的方法嗎？答案是肯定的，還有一些改進的空間。我們將來的博客內容會涉及到這個問題！但是，讓我們先找到我們可以改進的地方。

我們知道，pBFT給交易提供了終結狀態，這意味著一旦交易被提交給區塊鏈，

就是交易的最終形態，臨時的分叉不會發生，因此不需要確認。交易的終結狀態的實現是因為pBFT要求每個區塊必須由共識組中的絕大多數的誠實節點簽署。通過簽名，每個誠實的節點確認它已經驗證了塊的內容並且交易是有效的。在基於PoW的共識中，一個節點會生成一個區塊，而網路的其他節點或者接受它或者拒絕它，這就會導致臨時分叉的產生。

考慮以下簽名方法，每個節點簽署一個區塊，然後將簽過名的區塊轉發到網路的其餘部分，然後每個節點都會附加自己的簽名在這個區塊上，並最終在充分傳播之後，這個區塊就會獲得絕大多數誠實節點的簽名。在最壞的情況下，網路中的每個節點（包括惡意節點）都對該區塊進行簽名，區塊的簽名部分的大小為n。這裡就需要引入多重簽名的概念了。

多簽名是一種密碼術語，用於將一個消息上的來自n方的n個簽名聚合成固定大小的簽名。

簡化的多重簽名是如何工作的？

在深入細節之前，讓我們先解釋一下背景。在多重簽名方案中，我們有n個簽名者，每個簽名者都有一個（公鑰，私鑰）密鑰對，一個驗證者來驗證最終簽名，一個聚合者扮演一個推動者的角色，匯總每個簽名者發送的「簽名」 。在這個簡單版的描述中，我們假設每個節點都是誠實的，並且會配合簽署消息。

當驗證者驗證匯總後的簽名時，驗證者檢查所有簽名者是否正確的簽署了簽名。簽名驗證只有在所有簽名人都正確簽名後才算成功。如果任何一個簽名者有錯誤的操作，則簽名驗證失敗。

我們現在準備深入細節。請做好準備，因為這會有一點偏技術性。

多重簽名方案基本上分兩步進行。在協議的第一步中，每個節點將其公鑰發送給聚合器。所有的公鑰然後被匯總生成一個公鑰。根據公鑰的數學形式，聚合的方式可以是簡單的加法或乘法。

例如，匯總公鑰=公鑰_1 +公鑰_2 + ...+公鑰_n。

然後可以將匯總的公鑰轉發給可以使用它驗證匯總簽名的驗證者。聚合器也要將需要簽名的消息發送給每個簽名者。

在第二步中，聚合器啟動與每個簽名者的交互協議。互動式協議分三個階段運行：

最後的聚合簽名是一個信息對（質疑，聚合響應），可以根據第一步生成的聚合公鑰來驗證。

請注意，聚合簽名的大小是恆定的，不依賴於簽名者的數量。

藍色節點是聚合器。H是使用消息m的並被用來生成質詢的密碼哈希函數。信息對（R，S）就是聚和的簽名 。R的大小與R_i相同，S的大小與S_i的大小相同。生成有效的響應需要知道私鑰。

當驗證者檢查聚合簽名時，它不檢查每個簽名者是否正確地遵守協議，它只檢查所有簽名者是否共同遵守協議並且可以證明他們擁有私鑰信息。因此，驗證者做出全有或全無的決定。

一種流行的多重簽名方案是基於Schnorr數字簽名技術的，這個技術因為一篇學術論文從而得到了關注，該論文在一些證人需要證明事件發生的背景下使用了這個技術。

結論

Zilliqa使用最近學術論文中開發的幾種技術來提高經典pBFT協議的效率。

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

還有一些問題在這篇文章裡面沒有涉及，最重要的一個問題就是如果只是大部分的節點而不是所有的節點對信息進行了簽名，這種情況下會發生什麼？協議還會生效嗎？需要對協議做出相應的修改嗎？

另外，你能想出一個可以攻擊簡單版的多重簽名的方法嗎？

如果你還有疑問可以通過兩個方法得到答覆。比較難的方法是可以閱讀 Zilliqa技術白皮書，簡單的方法是通過我們的社區渠道向我們提出同樣的問題。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！