你應該反問：你系統遇到的 瓶頸 是什么?數據?共識?還是執行?

 

1. 數據 ：數據是將所有指令傳輸給所有狀態機副本的載體。舉個例子，如果一個 區塊包含 1MB 的指令 ，那么你就需要把 1MB 的數據發送給所有負責驗證的副本。顯然，這種情況下，系統的 通道容量 (帶寬)是系統可拓展的瓶頸。

 

2. 共識 ：指令到達本地之后，狀態機們就會參與共識協議(就像這里所討論的 部分同步 或者 同步協議 )。舉個例子，如果一個共識協議需要兩次消息往返，而參與驗證的狀態機分布在全球各地，那么，這里明顯的瓶頸在——由光速和地球大小而導致的 延遲 。

 

3. 執行 ：指令到達、共識在指令排序上達成共識后，副本需要執行指令。 執行引擎 是一個接受舊狀態并應用指令來計算新狀態(并計算輸出)的函數。又舉個例子，如果執行需要許多密碼學計算，那么很明顯啦，這里的瓶頸就是副本要重復執行的密碼學計算。

 

需要注意的是，這三個瓶頸不是追求一種折衷，也不是兩難的困境，也不是 三難困境 。它們是彼此獨立的。所有狀態機復制系統的可拓展能力都受到這三種因素的限制(而且像木桶原理一樣，受制于其中條件最差的那一個)。本文將介紹一些解決這些瓶頸的方案。

 

1. 從數據上提高可拓展性

 

更好的網絡解決方案

 

對比特幣等密碼學貨幣而言，擴展吞吐量的能力取決于減少延遲——因為某個礦工挖出的區塊需要經過一定的延遲才能傳播給所有其他礦工。像 FIBRE 、 Falcon 、 bloXroute 這些系統會通過使用 專用通道 (pipelining)來降低延遲，并使用 前 向 糾錯碼 (foward error correction code) 來傳播區塊。提高數據可拓展性的另一個辦法是通過 內容可尋址網址(content addressable network) 來發現對等節點并訪問內容。具體可參考 Kademlia ，它不僅啟發了以太坊的 RLPx編碼規范，并在 libp2p 上得到了推廣。

 

把數據遷移到 layer-2

 

另一種思路是，既然瓶頸源于需要復制所有指令到所有狀態機，那我不復制不就完啦!像 Lightning 、 Plasma 和其他 Layer-2 解決方方案都是如此——把中間命令傳播給一個較小的半公開團體以減少數據復制、定期向整個系統報告總結(詳情可看我們關于 支付 通道的文章)。自然而然地，這種方法的不足在于：不復制所有數據會造成數據的可用性問題(data availability problem)。而安全性依賴于每個擁有數據的半公開團體內至少有一個誠實參與者能及時地作出反應。

 

2. 從共識上提高可拓展性

 

吞吐量和延遲之間的權衡

 

有人將每秒處理交易數( TPS )作為衡量協議可拓展性的標準。TPS 是對吞吐量的度量，人們存在一個誤解——以為對它單獨優化就可以實現共識可拓展性。共識可拓展性的解決方案必須同時關注 吞吐量 和 確認時延 這兩個因素。

 

通過 成批處理 來提高共識的吞吐量(但提高延遲)很簡單：只需要一天一次，而不用每隔幾秒一次，就可以讓人們就被批處理的所有數據的哈希值達成共識。顯然，由于一天只達成一次共識，成本會被分攤，僅就吞吐量而言，共識過程就不再是阻礙實現拓展性的瓶頸了。顯然，批處理雖然能提高共識協議的吞吐量，但也會提高交易確認的時延，并不是什么擴展共識協議性能的萬靈丹。

 

PBFT journal version 一文充分地討論了 BFT 狀態機復制的延遲和吞吐量。

 

對基于 Nakamoto Consensus 的協議而言，有很多協議都試圖增加吞吐量及時延，如： Bitcoin-NG 、 Fruitchains 和 Prism 。

 

性能和安全性之間的權衡

 

有人建議在更小的狀態機副本小組內達成共識，以優化共識過程的性能。降低驗證狀態機小組的規模的確可以提高性能，但這是以降低降低安全性為代價的。所以，真正的挑戰在于不減少參與狀態機的數量同時提高共識過程的性能。

 

提高 共識協議的復雜性 有望魚和熊掌兼得，例如：減少輪數，或者說 改變消息傳遞的復雜度，使呈平方級增長的消息數量可以變為線性增長。本文討論了一些 部分同步 中的協議改進和 同步 中的協議改進。

 

可拓展性和適應性之間的權衡

 

基于 PBFT 視圖范式的共識協議容易受到攻擊者的適應性攻擊(adaptive attack)。共識協議的安全性不僅和攻擊者的規模(由狀態機副本總數決定)相關，而且和對手的 適應性 能力 相關。

 

處理適應性對手的協議通常會導致更高的成本，也會在可拓展性上遇到更大的難題。 Algorand建議用基于輪次的密碼抽樣來拓展拜占庭共識，使其免受適應性攻擊者的攻擊。這種方法的 模擬結果 看起來很不錯。適應性對手可以使用 拒絕服務攻擊 (Denial-of-Serivice attack)來阻止系統推進。 HoneyBadger 提出了第一個實用的 異步 BFT 協議——該協議在不做任何時序假設的情況下，也能保證活性。

 

避免對所有命令進行全排序

 

如果所有指令都相互依賴，那么除了對所有指令進行 全排序 外，別無他選。但是在許多工作負載中，指令不會彼此依賴和彼此干擾。舉個例子，在某些情況下，A 給 B 支付的指令和 C 給 D 支付的指令就不會相互干擾;在這種情況下，我們沒有必要浪費昂貴的共識資源為這兩筆指令進行內部 排序，沒有理由讓它成為系統的瓶頸。在 epaxos 非拜占庭模型中就采用了這種(不在所有時候都搞全排序的)辦法。像 Avalanche 和其他 基于 DAG 的 協議 ，會通過允許并發提交互不干擾的指令來增加共識的吞吐量。

 

分片

 

抽象一點來看， 分片 是對狀態和狀態機副本集合進行 分區 。每一分片控制狀態的某個部分，且共識過程是由驗證狀態機總體的某個部分來完成的。這當然也需要一些跨分片交互機制。以太坊的 “Sharding FAQ” (編者注：中譯本見文末)資源正是一個很全面的資源。

 

分片是并行化處理 數據、共識 和 執行 這三大瓶頸的方法。實現數據和執行并行化的關鍵在于工作負載的低 狀態競用 (contention)。從共識的角度來看，分片本質上就是在性能和安全之間取舍：不是用所有狀態機副本去保障一個狀態，分片技術創建了多個分區，每個驗證者副本會各自保護它們自己的分區。

 

(如果狀態競用程度較低)劃分許多分區會顯著地提高性能。但是，因為每一分區的驗證狀態機都變得更少，安全性自然就降低了。

 

想了解使用分片技術，請參閱 Omniledger 和 Ethereum 2.0 。以太坊 2.0 計劃將每個分區的低安全性和全局鏈的高安全性結合起來。就像 Layer-2 方案一樣，低安全性的分片可以定期上傳自己的狀態到高安全性的全局鏈上，并將狀態更新確定下來。這也是在安全性和延遲之間取舍——想獲得高安全性，就得等待全局鏈的周期性敲定。

 

3. 從執行上提高可拓展性

 

共識和執行的分離是狀態機復制系統的基本架構設計之一(可參見 Base 20013 )。分離的好處可參見 Yin et al 2003 。在傳統的狀態機復制系統(SMR)中，命令不僅要復制并傳播到所有副本，還得在所有副本上執行。

 

在很多系統中，可拓展性的瓶頸是 執行 指令的成本。對 SMR 系統的一種主要拒絕服務攻擊工段是發出合法的命令，讓整個系統浪費時間在執行上(詳情請參閱： 例 1 和 例 2 )。很多系統通過設計 領域 專用 語言 來(Domain Specific Language)避免攻擊。比特幣用 比特幣腳本 ，小心翼翼地限制每筆交易的計算復雜性。以太坊用 gas 機制 來限制執行的復雜性，并用效率來激勵人們對 Gas 的使用。

 

并行化執行

 

讓狀態機并行化執行也是一種提高執行能力的方法。當在區塊中的大部分命令無狀態競用(相互獨立，或者說可互換順序)的情況下，這個方法是有效的。它的主要思想是設想一種在無競用的條件下并行執行、在有競用時維護安全性的協議，用該協議模擬出連續執行的結果。詳情請參看 Eve 2012 、 Dickerson、 Gazzillo、 Herlihy、 Koskinen 2017 和 Saraph 和 Herlihy 2019。

 

不在 SMR 內執行，使用經濟激勵和錯誤性證明來驗證(optimistic rollups 類型)

 

在這類解決方案中，指令作為數據提交到 SMR 內，但是執行不是由驗證狀態機副本完成的。狀態機副本僅充當 數據可用性 層。

 

不用副本來執行指令，而用經濟激勵機制——玩家可以通過 發布債券 來成為執行者。鎖定了保證金的執行者都可以提交執行結果，而其他人可以通過提交錯誤性證明來舉報執行人提交了不正確的執行結果。如果這份錯誤性證明是正確的，執行者將受到 懲罰 ，而提交者將得到部分獎勵。如果挑戰者在錯誤性證明上說謊，那他的保證金就會大幅罰沒。

 

實現高效挑戰的協議起源于 Feige Kilian 2000 ，而 Canetti, Riva, Rothblum 2011 沿著這條道路推進，最終演化成采用鏈上激勵的 TrueBit Teutsch, Reitwießner 2017 和 Buterin’s Off-Chain Oracles 。如今，這種方法在名為 optimistic rollups 的方案中中得到進一步發揚(詳情可參看 merged consensus 、 Adler, Mikerah、Quintyne-Collins 、 Al-Bassam、Sonnino、Buterin 和 LazyLedger )。

 

不執行、用簡潔的證明來驗證(zk rollups 類型)

 

在本方案中，指令同樣作為 數據 提交到 SMR 中，執行同樣不關驗證狀態機副本的事。副本只是作為指令的數據可用性層。

 

不同于用挑戰游戲和錯誤性證明來驗證執行結果，利用 簡潔的非交互式證明 也是可以的( PCP 、 Groth 10 、 Groth 16 、 Ben-Sasson、Chiesa、Tromer、Virza 2013-2019 和 survey)。這些密碼學技術允許驗證者生成非常短的證明，同時對這些證明的驗證在密碼學上具有高度的可靠性和完整性。執行(和證明生成)只能由同一實體完成。有了簡潔證明后，驗證狀態機副本只需要驗證簡潔證明，而不需要重新執行長交易。 Zexe 用這個方法來建構了基于 nano-kernel 的證明系統，人們因此可以在 UTXO 中實現隱私交易。

 

Buterin 論述 zk-roll-up 的文章和 Ben-Sasson 的 podcast 強調了這種拓展交易處理量的方法。詳情請查看 Buterin 的 視頻 ，進一步去了解如何將隱私(零知識)添加到簡潔的證明中(zk zk rollups)中。

 

這種簡潔的證明有很多好處：驗證證據正確性的成本非常低。而短處在于構造指令執行的證明通常比單單去執行指令的成本要高得多。還有一個壞處在于這些協議增加了大量的復雜性。此外，某些協議還需要繁復的受信任初始設置 儀式。

 

點擊即可查看近期 optimistic and zk rollups 的 調查/比較 (編者注：中譯本見文末)。需要注意的是，以上介紹的方法意在克服執行可拓展性的瓶頸，而不在改變 數據可拓展化的瓶頸 。

 

感謝

 

我們想借此機會感謝 Ling Ren、Kartik Nayak、 Alin Tomescu、 Pratyush Mishra、Louis Guthmann 和 John Adler。感謝他們給本文提供了富有教益的反饋。