摘要：本文將會簡要討論秘猿科技是如何對進行性能優化的。在區塊鏈中，的共識是一個連續的共識。預處理在傳統的類共識的區塊鏈中，共識和交易的處理都是串行的。在共識的過程中，是閑置的。減少不必要的消息。例如，在服務收到時，需要對其合法性進行驗證。

在前兩期中，秘猿小課堂給大家分享了構建高性能區塊鏈內核 CITA 背后的思考。這一期，我們深入研究 CITA 是如何進行性能優化，并且將交易處理的性能達到 15000 TPS量級

秘猿科技區塊鏈小課堂第 6 期
點擊關注秘猿科技在思否的技術社區吧～

在區塊鏈的設計中，有一個「不可能三角」的說法，即安全、去中心化、性能，這三者只能取其二。Nervos 是用分層設計來解決不可能三角問題。在底層 Layer1 里，CKB 就選取安全和去中心化，Layer2 選性能。Layer2 追求把性能做到極致，去中心化和安全由 CKB 來解決。

CITA 作為支持智能合約的區塊鏈框架，有非常良好的性能表現，交易處理的性能可以達到 15000 TPS[1]，非常適合作為 Layer2 的高性能區塊鏈解決方案。本文將會簡要討論秘猿科技是如何對 CITA 進行性能優化的。

傳統的公有區塊鏈往往采用整體式架構。因為需要考慮去中心化，就需要考慮節點可以在普通硬件上可以執行，而在架構設計上無法兼顧性能。CITA 作為專門面向企業用戶設計的高性能許可鏈（許可鏈可以是聯盟鏈，也可以是公有許可鏈），采用微服務架構，可以更好的利用服務器集群，而不是使用單一機器運行節點。這樣可以充分利用硬件的優勢，節點不再是一個物理概念，而是一個邏輯概念。

傳統的 PBFT 類算法中，一般使用三階段協議 prevote、precommit、commit ，以 Tendermint 為例。

Commit 階段主要是為了 Proposer 向其他節點再廣播一輪 BlockProof，使得所有節點統一投票。但是實際上在 Precommit 階段，各個節點已經收集足夠的投票，只是投票集合可能不一致。比如對于 ABCD 四個節點，A 可能收到 ABCD 的投票，B 只收到 BCD 的投票。由于投票屬于 Block 的一部分，也需要共識，為了保證節點統一投票，所以由 Proposer 再進行一輪廣播。

在 CITA-BFT 中，我們優化了 Commit 階段。在區塊鏈中，Block 的共識是一個連續的共識。所以，我們可以將當前 Block 的 Proof 放到下一個塊的 Proposal 中，這樣可以在下一個塊的 Prevote 階段對上一個 Block 的 Proof 進行統一，不再廣播共識后的 Block。

這樣做的優點有兩個：

減少了一輪消息的廣播，縮短了共識時間，并且減少了網絡的負擔。
傳統的 PBFT 類共識算法在 Commit 階段，如果 Proposer 發送掉線等情況，會需要額外的一輪進行共識，而在 CITA-BFT 則不會發生這種情況。

在傳統的 PBFT 類共識的區塊鏈中，共識和交易的處理都是串行的。在共識 Block 的過程中，Executor 是閑置的。共識完成之后，將新的 Block 發送給 Executor 處理，Consensus 等待 Executor 處理完之后才能進行新的高度的共識，此時 Consensus 模塊是閑置的。待 Executor 處理完 Block 之后，發送最新的 Status 之后，Consensus 才進行新高度的共識。

在實際的共識過程中，節點在 Prevote 階段收到 Proposal 并驗證之后，Proposal 就有很大可能變成最終 Commit 的 Block。在網絡情況正常的情況下，通常一輪共識即可完成當前高度的 Block，此時如果提前對 Proposal 中的交易進行處理，則在共識流程中的后半部分則和交易的執行是同時進行的。當 Executor 處理完之后，等待 Consensus 發送已經確認的 Block，此時 Executor 只需要判斷此 Proposal 是否是共識的 Block。如果是，則直接將處理結果進行 Finalize，并通知 Consensus 進行新高度的共識；如果否，則重新處理，這種情況和沒有預執行的流程是一致的。

這樣在多數情況下區塊都能提前處理，將交易處理的時間提前。即便在較壞情況下，進行多輪共識時，Proposal 也可以按照時間戳進行比較，打斷當前正在進行的預處理，執行更新的 Proposal。在最壞情況下，沒有收到 Proposal 或者收到錯誤的 Proposal，Executor 也和原來的共識流程相同，在收到 CommitedBlock 之后，進行交易的處理，并沒有任何性能上的損失。

在性能優化中，緩存是一種常見的手段，同樣在 CITA 中也存在大量緩存，來解決性能問題。

簽名驗證緩存。通常交易簽名的驗證比較耗時，對于已經驗證通過的交易，根據其 Hash 將驗證結果進行緩存。這樣如果節點再收到同樣的交易（可能是用戶重復發送或者從其他節點轉發）時，則可以命中緩存，減少驗證簽名的時間消耗。
區塊信息緩存。對于在交易處理過程中，或者用戶查詢操作中，經常會需要查詢 Block 或者 Transaction 等信息，可以將此類信息緩存，這樣能大大提高查詢的效率。
在交易處理過程中，需要從數據庫中讀取之前的 State，而 MPT 的查詢路徑比較長，需要多次 DB 的查詢，非常耗時。在 CITA 中，會將經常使用到 Account 進行緩存。
通過緩存技術，大大減少了交易驗證和處理的時間。

在微服務架構中，由于服務的拆分導致各個微服務之間消息通信比較頻繁，這樣消息中間件非常容易成為瓶頸。一方面，由于我們使用了微服務架構，消息中間件本身可以多帶帶部署，可以通過提高硬件能力進行縱向擴展，也可以通過集群的方式進行橫向擴展。

除此之外，我們還對微服務之間的消息進行優化，來提高微服務間通信的效率。

消息壓縮。例如在壓力比較大時，Block 中往往有上萬筆交易，這樣消息會非常大。因此我們采用了消息壓縮技術，在消息超過一定大小時，會對其進行壓縮，這樣減少消息中間件的壓力，同時也減少了傳輸量，提高了傳輸速度。
減少不必要的消息。例如，在 Consensus 服務收到 Proposal 時，需要對其合法性進行驗證。由于其可能包含大量交易，會導致傳輸量很大。因此在 Consensus 可以先驗證交易的 Hash 是否正確，再將 Proposal 的其他信息和交易的 Hash 發送給 Auth 模塊即可，而不用將整個交易發送給 Auth 模塊。
打包發送。將消息打包，也是一種比較常見優化手段。比如在 RPC 模塊中，需要將交易發送給 Auth 模塊進行驗證，在壓力比較大的時候單個消息發送則消息數量會非常大，此時 RPC 會將消息進行打包后再發送給 Auth 模塊，可以大幅度的減少消息的數量，從而減少消息中間件的負載，提高消息的發送速度。

在 Bitcoin 中，為了解決輕節點的交易驗證問題，引入了 MerkleTree。但是 Merkle Tree 的每個節點的產生都要計算一次 Hash，而 Hash 計算非常耗時。

大家注意到最后的葉子節點 Hc 是直接復制了 Hc。這樣是因為 Bitcoin 和 Ethereum 中交易是依次加入到 Merkle Tree 中，可以遞增地去構造 Merkle Root。比如節點當前的 PendingBlock 中有交易 TxA、TxB、TxC、TxD，當前的 Merkle Root 是 H(ABCD)。新交易來 TxE 來了之后，計算 H(EE)，再向上計算，這樣原有的 H(ABCD) 部分不用再計算。

當交易 TxF 來了之后，替換掉最右邊的 TxE，再依次向上計算 root，這樣只計算一部分就可以了。之前的 H(ABCD) 部分不用再重新計算。

在 CITA 中，交易會先經過 Auth 驗證進入交易池，然后由 Consensus 一次性選取交易打包后共識，最后再由 Executor 處理，同時將處理后的結果 Receipt Root 存入 header 中 。由于是先共識交易內容然后再計算交易的結果，所以 Block 中的交易的處理結果 Receipt Root 順序已經完全確定，不會再發生修改了。由此我們可以將所有 Receipts 一次性算出其 Receipt Root，而不用考慮其動態計算的過程。由此我們可以優化 Receipt Root 的計算。

對比 Bitcoin 和 Ethereum 中的 Merkle Tree，會發現由于沒有奇數節點的復制，節點 E 這里的 Hash 計算會減少。我們稱這棵樹為 Static Merkle Tree。

另外，在 Ethereum 中每筆交易都會產生新的 State Root，而 State Root 的計算又是非常耗時的。因此在 CITA 設計之初，交易計算完之后，只會將其狀態更新到 Account Model 中，而不會將其變更更新到 State 的 MPT 中。只有在整個 Block 計算完成之后，才會將所有的計算結果提交到 State 的 MPT 中并計算 State Root，這樣大大減少了 MPT 的操作和計算。在 Ethereum 最新的設計中也采用了同樣的方案。

當前 Bitcoin 和 Ethereum 都采用了 secp256k1 的簽名算法，在交易驗證中，簽名的驗證尤其消耗 CPU 資源并且耗時。CITA 支持多種簽名算法，默認采用 secp256k1。在筆者的電腦（Thinkpad 470p i7-7820HQ）上簡單的轉賬交易的簽名驗證速度大約為 3000 多每秒。Auth 模塊提供了交易的并行驗簽，這樣可以充分發揮硬件的優勢，提高系統的驗簽速度。

除此之外，CITA還實現了 Ed25519 簽名，相比 secp256k1 性能更好，并且在安全性方面也更有優勢，用戶可以根據個人需求選擇自己想要的簽名算法。我們性能測試的 15000 TPS 的數據指的是 secp256k1。

在軟件設計中，異步處理通常也是比較好的性能優化手段。除了前文提到的交易預處理，在 CITA 中的其他模塊中也存在一些這樣的設計。比如在 Executor 中，Block 執行完成之后，需要將最新的 State 保存到 DB，而一旦 State 狀態變更比較多時，此操作將比較耗時。由此，Executor 提前將 Status 發送給其他模塊，然后再到 DB 進行存儲。當然可能會在存儲失敗時導致異常情況，因此在 Conseneus 會保存最新的幾個 Block，來防止其他微服務內存儲失敗的特殊情況發生。

另外，CITA提供了批量交易的接口，用戶可以組裝多個交易數據，共享同一個簽名。這樣原來的多個交易就變成一個交易，減少交易存儲和簽名驗證，加快交易的處理，同時也降低了用戶發送交易的手續費。例如用戶 A 需要調用 N 個不同的合約，原來需要發送 N 筆交易，通過批量交易的方式，可以將合約調用的 data 按照既定格式拼裝在一起，然后再進行一次簽名發送到批量交易合約，合約再將 data 解析成多個合約調用。

當然批量交易只能算作一筆復雜的組合交易，只完成了一次正常交易的處理流程，因此在性能測試中只能算作一筆交易。CITA 在性能測試中并未采用此手段。

CITA 中絕大部分代碼是用 Rust 語言實現。Rust 語言的極小運行時，與 C 語言媲美的優異性能，也是 CITA 良好性能的一大保證。作為國內最早使用 Rust 的團隊，從 2016 年開始至今也在和 Rust 一同成長。 Rust 語言的其他特性：保證內存安全，基于 trait 的泛型，模式匹配，類型推斷，高效 C 綁定等等，也極大的提高了我們的開發效率。

未來我們還會在微服務架構改進，網絡層，Block/Transaction 廣播，狀態存儲，硬件加速，VM，并行計算等等各個方面做更多研究，將 CITA 性能提上一個更高的水平。

CITA技術白皮書：https://github.com/cryptape/c...

Ed25519： https://exonum.com/blog/09-27...

eip-658：https://github.com/ethereum/E...

batch_tx：https://docs.nervos.org/cita/...

Rust versus C gcc fastest programs： https://benchmarksgame-team.p...