吞吐量和延遲之間的權衡
有人將每秒處理交易數（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 方案一樣，低安全性的分片可以定期上傳自己的狀態到高安全性的全局鏈上，并將狀態更新確定下來。這也是在安全性和延遲之間取舍——想獲得高安全性，就得等待全局鏈的周期性敲定。
版權申明：本內容來自于互聯網，屬第三方匯集推薦平臺。本文的版權歸原作者所有，文章言論不代表鏈門戶的觀點，鏈門戶不承擔任何法律責任。如有侵權請聯系QQ：3341927519進行反饋。
