如何建構高性能區塊鏈

原文來源：Aptos Labs

自計算技術誕生以來，工程師與研究人員不斷探索如何將運算資源推向效能極限，力求在最大化效率的同時最小化運算任務的延遲。高效能與低延遲這兩大支柱始終塑造著電腦科學的發展，影響從 CPU、FPGA 到資料庫系統，以及近期的人工智慧基礎設施和區塊鏈系統等廣泛領域。在追求高性能時，流水線技術成為不可或缺的手段。自 1964 年 IBM System/360 引進管線技術以來 [1]，它一直是高效能係統設計的核心，推動了該領域的關鍵討論與創新。

管線技術不僅應用於硬件，在資料庫領域也有廣泛應用。例如，Jim Gray 在其著作《高效能資料庫系統》中引入了管線並行方法 [2]。此方法將複雜的資料庫查詢分解為多個階段並同時運行，從而提高效率和效能。管線技術在人工智慧領域同樣至關重要，特別是在廣泛使用的深度學習框架 TensorFlow 中。它利用資料管線並行處理資料預處理和加載，確保訓練與推理的資料流暢通，使 AI 工作流程更快、更有效率 [3]。

區塊鏈也不例外。其核心功能類似於資料庫，處理交易並更新狀態，但增加了拜占庭容錯共識的挑戰。提升區塊鏈吞吐量（每秒交易數）和降低延遲（至最終確認的時間）的關鍵在於優化不同階段——排序、執行、提交和同步交易——在高負載下的互動。這項挑戰在高吞吐量場景下尤其關鍵，因為傳統設計難以維持低延遲。

為了探討這些理念，我們不妨回顧一個熟悉的類比：汽車工廠。理解裝配線如何革新製造業，有助於我們領會區塊鏈流水線的演進——以及為何像 Zaptos[8] 這樣的下一代設計將區塊鏈性能推向新高度。

從汽車工廠到區塊鏈

想像你是一家汽車工廠的老闆，有兩個主要目標：

· 最大化吞吐量：每天組裝盡可能多的汽車。

· 最小化延遲：縮短每輛車的建造時間。

現在，設想三種類型的工廠：

簡單工廠

在簡單工廠中，一組多能工人按部就班地組裝一輛汽車。一名工人組裝引擎，下一名工人安裝車輪，以此類推——一次只生產一輛車。

問題在於？部分工人常常處於等待狀態，整體生產效率低下，因為沒有人同時在同一輛車的不同部分上工作。

福特工廠

引進福特裝配線 [4]！在這裡，每名工人專注於單一任務。汽車沿著傳送帶移動，每輛車經過時，一名專職工人會添加自己的部件。

結果如何？多輛汽車同時處於不同組裝階段，所有工人都在忙碌。吞吐量大幅提升——但每輛車仍需依序經過每名工人，意味著每輛車的延遲時間不變。

魔法工廠

想像一個魔法工廠，所有的工人可以同時在一輛車上工作！不再需要將汽車從一個工位移到下一個工位，汽車的每個部分都同時建造。

結果呢？汽車以創紀錄的速度組裝完成，每一步都在同步進行。這是解決吞吐量和延遲問題的理想場景。

好了，汽車工廠的討論到此為止－區塊鏈呢？事實證明，設計高性能區塊鏈與優化組裝線並無太大不同。

區塊鏈如汽車工廠

在區塊鏈中，處理一個區塊類似於組裝一輛汽車。類別例如下：

· 工人 = 驗證者資源

· 汽車 = 一個區塊

· 組裝任務 = 共識、執行和提交等階段

· 組裝任務 = 共識、執行和提交等階段

·

區塊鏈管線的演進

傳統架構：順序區塊鏈

想像一個依序處理區塊的區塊鏈。驗證者需要：

1. 接收區塊提案。

2. 執行區塊以更新區塊鏈狀態。

3. 繼續對此狀態進行共識。

4. 將狀態持久化到資料庫。

5. 開始下一個區塊的共識。

問題在哪裡？

· 執行和提交處於共識過程的關鍵路徑中。

· 每個共識實例需等待前一個完成才能開始。

這個設定就像前福特時代的工廠：工人（資源）在一次只專注於一個區塊（汽車）時常常處於空閒狀態。不幸的是，許多現有區塊鏈仍屬於此類別，導致吞吐量低、延遲高。

Aptos：並行化性能

Diem 引入了一種管線架構，將執行和提交從共識階段解耦，同時共識階段本身也採用了管線設計。

· 非同步執行與提交 [5]：驗證者首先對一個區塊達成一致，然後根據父區塊的狀態執行該區塊。在由驗證者法定人數簽署認證後，狀態持久化到儲存中。

· 管線共識（Jolteon[6]）：新的共識實例可以在前一個完成之前開始，類似於移動的裝配線。

這透過允許不同區塊同時處於不同階段來提升吞吐量，並將區塊時間顯著縮短至僅需 2 次訊息延遲。然而，Jolteon 基於領導者的設計可能會造成瓶頸，因為領導者在交易分發時會超載。

Aptos 透過 Quorum Store[7] 進一步優化了管線，這是一種將資料分發與共識解耦的機制。 Quorum Store 不再依賴單一領導者在共識協議中廣播大數據區塊，而是將資料分發與元資料排序分離，允許驗證者非同步並行分發資料。這種設計利用了所有驗證者的總頻寬，有效消除了共識中的領導者瓶頸。

圖示：Quorum Store 如何平衡基於領導者共識協議的資源利用率。

至此，Aptos 區塊鏈打造了區塊鏈的「福特工廠」。正如福特的裝配線革新了汽車生產——不同汽車的不同階段同時進行——Aptos 同時處理不同區塊的不同階段。每個驗證者的資源都被充分利用，確保流程中沒有部分處於等待狀態。這種巧妙的編排帶來了高吞吐量系統，使 Aptos 成為高效且可擴展地處理區塊鏈交易的強力平台。

圖示：Aptos 區塊鏈中連續區塊的管線處理。驗證者可以對連續區塊的不同階段進行管線處理，以最大化資源利用率並提高吞吐量。

雖然吞吐量至關重要，但端對端延遲——從交易提交到最終確認的時間——同樣重要。對於支付、去中心化金融（DeFi）和遊戲等應用，每毫秒都很關鍵。許多用戶在高流量事件中體驗過延遲，因為每筆交易必須依序通過一系列階段：客戶端-全節點-驗證者通訊、共識、執行、狀態認證、提交和全節點同步。在高負載下，執行和全節點同步等階段會帶來更多延遲。

圖示：Aptos 區塊鏈的管線架構。圖中顯示客戶端 Ci、全節點 Fi 和驗證者 Vi。每個框表示區塊鏈中交易區塊從左到右需要經歷的一個階段。管線包括五個階段：共識（包括分發和排序）、執行、認證、提交和全節點同步。

這就像福特工廠：儘管裝配線最大化了整體吞吐量，但每輛車仍需依次通過每個工人，因此完成時間較長。為了真正將區塊鏈效能推向極限，我們需要打造一個「魔法工廠」——讓這些階段並行運作。

Zaptos：邁向最優區塊鏈延遲

Zaptos[8] 透過三種關鍵優化進一步降低延遲，同時不犧牲吞吐量。

· 樂觀執行：透過在收到區塊提議後立即開始執行來減少管線延遲。驗證者立即將區塊添加到管線，並在父區塊完成後推測性地執行。全節點從驗證者接收提議後，也執行樂觀執行以驗證狀態證明。

· 樂觀提交：在區塊執行後立即將狀態寫入儲存空間－甚至在狀態認證之前。當驗證者最終認證狀態時，僅需最小的更新即可完成提交。如果一個區塊最終未被排序，其樂觀提交的狀態會被回滾以保持一致性。

· 快速認證：驗證者透過在最終共識輪次並行發送認證訊息，提前開始認證已執行區塊的狀態，而無需等待共識完成。這項優化在常見情況下有效減少了一個輪次的流水線延遲。

圖示：Zaptos 的平行管線架構。除共識外的其他階段實際上被隱藏在共識階段內，從而降低端對端延遲。

透過這些優化，Zaptos 有效地將其他管線階段的延遲隱藏在共識階段內。因此，如果區塊鏈採用最優延遲的共識協議，整體區塊鏈延遲也能達到最優！

空談無益，資料說話

我們透過地理分散式實驗評估了 Zaptos 的端到端效能，以 Aptos 作為高效能基準。更多細節請見論文 [8]。

在 Google Cloud 上，我們模擬了一個由 100 個驗證者和 30 個全節點組成的全球去中心化網絡，分佈在 10 個地區，使用與 Aptos 部署類似的商用級機器。

吞吐量-延遲

圖示：Zaptos 與 Aptos 區塊鏈的常見效能表現。

上圖比較了兩種系統的端對端延遲與吞吐量關係。兩者在負載增加時延遲逐漸上升，並在最大容量時出現急劇 spikes，但 Zaptos 在達到峰值吞吐量之前始終表現出更穩定的延遲，低負載下延遲減少 160 毫秒，高負載下減少超過 500 毫秒。

令人印象深刻的是，Zaptos 在生產級主網環境中以 20k TPS 實現亞秒延遲——這一突破使得需要速度和可擴展性的現實世界應用成為可能。

延遲分解

圖示：Aptos 區塊鏈的延遲分解。

圖示：Zaptos 的延遲分解。

延遲分解圖詳細展示了驗證者和全節點在每個管線階段的持續時間。關鍵見解包括：

· 至 10k TPS：Zaptos 的整體延遲幾乎等同於其共識延遲，因為樂觀執行、認證和樂觀提交階段實際上被「隱藏」在共識階段內。

· 超過 10k TPS：由於樂觀執行和全節點同步時間的增加，非共識階段變得更顯著。儘管如此，Zaptos 通過重疊大多數階段顯著減少了整體延遲。例如，在 20k TPS 時，基線總延遲為 1.32 秒（共識 0.68 秒，其他階段 0.64 秒），而 Zaptos 為 0.78 秒（共識 0.67 秒，其他階段 0.11 秒）。

結論

區塊鏈架構的演進類似於製造業的轉型－從簡單的順序工作流程到高度並行化的管線。 Aptos 的管線方法顯著提升了吞吐量，而 Zaptos 更進一步，將延遲降低至亞秒級，同時維持高 TPS。正如現代運算架構利用並行性最大化效率，區塊鏈必須不斷優化設計以消除不必要的延遲。透過全面優化區塊鏈管線以實現最低延遲，Zaptos 為需要速度和規模的現實世界區塊鏈應用鋪平了道路。

參考文獻

[1] Gene M. Amdahl, Gerrit A. 布萊斯. target=""> https://doi.org/10.1147/rd.82.0087

[2] David DeWitt, and Jim Gray. 1992. "Parallel Database Systems: The Future of High Performance Database Systems." Communications of the ACM. https://doi.org/10.1145/129888.129894

[3] Marti Abadi, Pauln, Nminen, Devin et al. 2016. "TensorFlow: a System for Large-Scale Machine Learning." In 12th USENIX symposium on operating systems design and implementation (OSDI).

[4] The Moving Assembly Line and the Five-Dollar Workday. https://corporate.ford.com/articles/history/moving-assembly-line.html

[5] Zekun Li, and Yu Xia. 2021. DIP-213 - Decoupled Execution. https://github.com/diem/dip/blob/7dc44ee57bb7efe76559f05dcc6851d97e2d3149/dips/dip-213.md

[6] Ratiis Kliak, Lefter, 東and Zhuolun Xiang. 2022. "Jolteon and Ditto: Network-Adaptive Efficient Consensus with Asynchronous Fallback." In International conference on financial cryptography and data security (FC).

[7] Quorum Store: How Consensus Horizontally Scales on the Aptos Blockchain. https://medium.com/aptoslabs/quorum-store-how-consensus-horizontally-scales-on-the-aptos-blockchain-988866f6d5b0

[8] Zhuolun Xiang, Zekun Li, Balaji Arun, Teng Zhang, and Alexander Spiegelman. 202 2025. "Zaptos: Towards Optimal Blockchain Latency." arXiv preprint arXaptos:2501.10612.10612.106 href="https://arxiv.org/abs/2501.10612" target=""> https://arxiv.org/abs/2501.10612

本文來自投稿，不代表 BlockBeats 觀點。