摘要：本文將會(huì)簡(jiǎn)要討論秘猿科技是如何對(duì)進(jìn)行性能優(yōu)化的。在區(qū)塊鏈中，的共識(shí)是一個(gè)連續(xù)的共識(shí)。預(yù)處理在傳統(tǒng)的類共識(shí)的區(qū)塊鏈中，共識(shí)和交易的處理都是串行的。在共識(shí)的過程中，是閑置的。減少不必要的消息。例如，在服務(wù)收到時(shí)，需要對(duì)其合法性進(jìn)行驗(yàn)證。

在前兩期中，秘猿小課堂給大家分享了構(gòu)建高性能區(qū)塊鏈內(nèi)核 CITA 背后的思考。這一期，我們深入研究 CITA 是如何進(jìn)行性能優(yōu)化，并且將交易處理的性能達(dá)到 15000 TPS量級(jí)

秘猿科技區(qū)塊鏈小課堂第 6 期
點(diǎn)擊關(guān)注秘猿科技在思否的技術(shù)社區(qū)吧～

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

CITA 作為支持智能合約的區(qū)塊鏈框架，有非常良好的性能表現(xiàn)，交易處理的性能可以達(dá)到 15000 TPS[1]，非常適合作為 Layer2 的高性能區(qū)塊鏈解決方案。本文將會(huì)簡(jiǎn)要討論秘猿科技是如何對(duì) CITA 進(jìn)行性能優(yōu)化的。

傳統(tǒng)的公有區(qū)塊鏈往往采用整體式架構(gòu)。因?yàn)樾枰紤]去中心化，就需要考慮節(jié)點(diǎn)可以在普通硬件上可以執(zhí)行，而在架構(gòu)設(shè)計(jì)上無法兼顧性能。CITA 作為專門面向企業(yè)用戶設(shè)計(jì)的高性能許可鏈（許可鏈可以是聯(lián)盟鏈，也可以是公有許可鏈），采用微服務(wù)架構(gòu)，可以更好的利用服務(wù)器集群，而不是使用單一機(jī)器運(yùn)行節(jié)點(diǎn)。這樣可以充分利用硬件的優(yōu)勢(shì)，節(jié)點(diǎn)不再是一個(gè)物理概念，而是一個(gè)邏輯概念。

傳統(tǒng)的 PBFT 類算法中，一般使用三階段協(xié)議 prevote、precommit、commit ，以 Tendermint 為例。

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

在 CITA-BFT 中，我們優(yōu)化了 Commit 階段。在區(qū)塊鏈中，Block 的共識(shí)是一個(gè)連續(xù)的共識(shí)。所以，我們可以將當(dāng)前 Block 的 Proof 放到下一個(gè)塊的 Proposal 中，這樣可以在下一個(gè)塊的 Prevote 階段對(duì)上一個(gè) Block 的 Proof 進(jìn)行統(tǒng)一，不再廣播共識(shí)后的 Block。

這樣做的優(yōu)點(diǎn)有兩個(gè)：

減少了一輪消息的廣播，縮短了共識(shí)時(shí)間，并且減少了網(wǎng)絡(luò)的負(fù)擔(dān)。
傳統(tǒng)的 PBFT 類共識(shí)算法在 Commit 階段，如果 Proposer 發(fā)送掉線等情況，會(huì)需要額外的一輪進(jìn)行共識(shí)，而在 CITA-BFT 則不會(huì)發(fā)生這種情況。

在傳統(tǒng)的 PBFT 類共識(shí)的區(qū)塊鏈中，共識(shí)和交易的處理都是串行的。在共識(shí) Block 的過程中，Executor 是閑置的。共識(shí)完成之后，將新的 Block 發(fā)送給 Executor 處理，Consensus 等待 Executor 處理完之后才能進(jìn)行新的高度的共識(shí)，此時(shí) Consensus 模塊是閑置的。待 Executor 處理完 Block 之后，發(fā)送最新的 Status 之后，Consensus 才進(jìn)行新高度的共識(shí)。

在實(shí)際的共識(shí)過程中，節(jié)點(diǎn)在 Prevote 階段收到 Proposal 并驗(yàn)證之后，Proposal 就有很大可能變成最終 Commit 的 Block。在網(wǎng)絡(luò)情況正常的情況下，通常一輪共識(shí)即可完成當(dāng)前高度的 Block，此時(shí)如果提前對(duì) Proposal 中的交易進(jìn)行處理，則在共識(shí)流程中的后半部分則和交易的執(zhí)行是同時(shí)進(jìn)行的。當(dāng) Executor 處理完之后，等待 Consensus 發(fā)送已經(jīng)確認(rèn)的 Block，此時(shí) Executor 只需要判斷此 Proposal 是否是共識(shí)的 Block。如果是，則直接將處理結(jié)果進(jìn)行 Finalize，并通知 Consensus 進(jìn)行新高度的共識(shí)；如果否，則重新處理，這種情況和沒有預(yù)執(zhí)行的流程是一致的。

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

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

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

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

除此之外，我們還對(duì)微服務(wù)之間的消息進(jìn)行優(yōu)化，來提高微服務(wù)間通信的效率。

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

在 Bitcoin 中，為了解決輕節(jié)點(diǎn)的交易驗(yàn)證問題，引入了 MerkleTree。但是 Merkle Tree 的每個(gè)節(jié)點(diǎn)的產(chǎn)生都要計(jì)算一次 Hash，而 Hash 計(jì)算非常耗時(shí)。

大家注意到最后的葉子節(jié)點(diǎn) Hc 是直接復(fù)制了 Hc。這樣是因?yàn)?Bitcoin 和 Ethereum 中交易是依次加入到 Merkle Tree 中，可以遞增地去構(gòu)造 Merkle Root。比如節(jié)點(diǎn)當(dāng)前的 PendingBlock 中有交易 TxA、TxB、TxC、TxD，當(dāng)前的 Merkle Root 是 H(ABCD)。新交易來 TxE 來了之后，計(jì)算 H(EE)，再向上計(jì)算，這樣原有的 H(ABCD) 部分不用再計(jì)算。

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

在 CITA 中，交易會(huì)先經(jīng)過 Auth 驗(yàn)證進(jìn)入交易池，然后由 Consensus 一次性選取交易打包后共識(shí)，最后再由 Executor 處理，同時(shí)將處理后的結(jié)果 Receipt Root 存入 header 中 。由于是先共識(shí)交易內(nèi)容然后再計(jì)算交易的結(jié)果，所以 Block 中的交易的處理結(jié)果 Receipt Root 順序已經(jīng)完全確定，不會(huì)再發(fā)生修改了。由此我們可以將所有 Receipts 一次性算出其 Receipt Root，而不用考慮其動(dòng)態(tài)計(jì)算的過程。由此我們可以優(yōu)化 Receipt Root 的計(jì)算。

對(duì)比 Bitcoin 和 Ethereum 中的 Merkle Tree，會(huì)發(fā)現(xiàn)由于沒有奇數(shù)節(jié)點(diǎn)的復(fù)制，節(jié)點(diǎn) E 這里的 Hash 計(jì)算會(huì)減少。我們稱這棵樹為 Static Merkle Tree。

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

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

除此之外，CITA還實(shí)現(xiàn)了 Ed25519 簽名，相比 secp256k1 性能更好，并且在安全性方面也更有優(yōu)勢(shì)，用戶可以根據(jù)個(gè)人需求選擇自己想要的簽名算法。我們性能測(cè)試的 15000 TPS 的數(shù)據(jù)指的是 secp256k1。

在軟件設(shè)計(jì)中，異步處理通常也是比較好的性能優(yōu)化手段。除了前文提到的交易預(yù)處理，在 CITA 中的其他模塊中也存在一些這樣的設(shè)計(jì)。比如在 Executor 中，Block 執(zhí)行完成之后，需要將最新的 State 保存到 DB，而一旦 State 狀態(tài)變更比較多時(shí)，此操作將比較耗時(shí)。由此，Executor 提前將 Status 發(fā)送給其他模塊，然后再到 DB 進(jìn)行存儲(chǔ)。當(dāng)然可能會(huì)在存儲(chǔ)失敗時(shí)導(dǎo)致異常情況，因此在 Conseneus 會(huì)保存最新的幾個(gè) Block，來防止其他微服務(wù)內(nèi)存儲(chǔ)失敗的特殊情況發(fā)生。

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

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

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

未來我們還會(huì)在微服務(wù)架構(gòu)改進(jìn)，網(wǎng)絡(luò)層，Block/Transaction 廣播，狀態(tài)存儲(chǔ)，硬件加速，VM，并行計(jì)算等等各個(gè)方面做更多研究，將 CITA 性能提上一個(gè)更高的水平。

CITA技術(shù)白皮書：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...