如何構建高性能區塊鏈
原文來源：Aptos Labs
自計算技術誕生以來，工程師與研究人員不斷探索如何將計算資源推向性能極限，力求在最大化效率的同時最小化計算任務的延遲。高性能與低延遲這兩大支柱始終塑造着計算機科學的發展，影響着從 CPU、FPGA 到數據庫系統，以及近期的人工智能基礎設施和區塊鏈系統等廣泛領域。在追求高性能時，流水線技術成爲不可或缺的手段。自 1964 年 IBM System/360 引入流水線技術以來 [1]，它一直是高性能系統設計的核心，推動了該領域的關鍵討論與創新。
流水線技術不僅應用於硬件，在數據庫領域也有廣泛應用。例如，Jim Gray 在其著作《高性能數據庫系統》中引入了流水線並行方法 [2]。該方法將復雜的數據庫查詢分解爲多個階段並同時運行，從而提高效率和性能。流水線技術在人工智能領域同樣至關重要，特別是在廣泛使用的深度學習框架 TensorFlow 中。它利用數據流水線並行處理數據預處理和加載，確保訓練與推理的數據流暢通，使 AI 工作流程更快、更高效 [3]。
區塊鏈也不例外。其核心功能類似於數據庫，處理交易並更新狀態，但增加了拜佔庭容錯共識的挑戰。提升區塊鏈吞吐量（每秒交易數）和降低延遲（至最終確認的時間）的關鍵在於優化不同階段——排序、執行、提交和同步交易——在高負載下的交互。這一挑戰在高吞吐量場景下尤爲關鍵，因爲傳統設計難以維持低延遲。
爲了探討這些理念，我們不妨回顧一個熟悉的類比：汽車工廠。理解裝配線如何革新制造業，有助於我們領會區塊鏈流水線的演進——以及爲何像 Zaptos[8] 這樣的下一代設計將區塊鏈性能推向新高度。
從汽車工廠到區塊鏈
想象你是一家汽車工廠的老板，有兩個主要目標：
· 最大化吞吐量：每天組裝盡可能多的汽車。
· 最小化延遲：縮短每輛汽車的建造時間。
現在，設想三種類型的工廠：
簡單工廠
在簡單工廠中，一組多能工人按部就班地組裝一輛汽車。一名工人組裝引擎，下一名工人安裝車輪，以此類推——一次只生產一輛車。
問題在於？部分工人常常處於等待狀態，整體生產效率低下，因爲沒有人同時在同一輛車的不同部分上工作。
福特工廠
引入福特裝配線 [4]！在這裏，每名工人專注於單一任務。汽車沿着傳送帶移動，每輛車經過時，一名專職工人添加自己的部件。
結果如何？多輛汽車同時處於不同組裝階段，所有工人都在忙碌。吞吐量大幅提升——但每輛車仍需依次經過每名工人，意味着每輛車的延遲時間不變。
魔法工廠
想象一個魔法工廠，所有的工人可以同時在一輛車上工作！不再需要將汽車從一個工位移到下一個工位，汽車的每個部分都同時被建造。
結果呢？汽車以創紀錄的速度組裝完成，每一步驟都在同步進行。這是解決吞吐量和延遲問題的理想場景。
好了，汽車工廠的討論到此爲止——區塊鏈呢？事實證明，設計高性能區塊鏈與優化裝配線並無太大不同。
區塊鏈如汽車工廠
在區塊鏈中，處理一個區塊類似於組裝一輛汽車。類比如下：
· 工人 = 驗證者資源
· 汽車 = 一個區塊
· 組裝任務 = 共識、執行和提交等階段
就像簡單工廠一次只處理一輛車，區塊鏈如果一次只處理一個區塊，會導致資源利用不足。相反，現代區塊鏈設計力求像福特裝配線一樣——同時處理多個區塊的不同階段。這就是流水線技術的用武之地。
區塊鏈流水線的演進
傳統架構：順序區塊鏈
想象一個按順序處理區塊的區塊鏈。驗證者需要：
- 接收區塊提議。
- 執行區塊以更新區塊鏈狀態。
- 繼續對該狀態進行共識。
- 將狀態持久化到數據庫。
- 開始下一個區塊的共識。
問題在哪裏？
· 執行和提交處於共識過程的關鍵路徑中。
· 每個共識實例需等待前一個完成才能開始。
這種設置就像前福特時代的工廠：工人（資源）在一次只專注於一個區塊（汽車）時常常處於空閒狀態。不幸的是，許多現有區塊鏈仍屬於這一類別，導致吞吐量低、延遲高。
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 爲需要速度和規模的現實世界區塊鏈應用鋪平了道路。
聲明：
- 本文轉載自 [BlockBeats]，著作權歸屬原作者 [Aptos Labs]，如對轉載有異議，請聯系 Gate Learn 團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由 Gate Learn 團隊翻譯， 在未提及 Gate.io 的情況下不得復制、傳播或抄襲經翻譯文章。
相關文章
什麼是穩定幣 USDT？
如何構建高性能區塊鏈
原文來源：Aptos Labs
自計算技術誕生以來，工程師與研究人員不斷探索如何將計算資源推向性能極限，力求在最大化效率的同時最小化計算任務的延遲。高性能與低延遲這兩大支柱始終塑造着計算機科學的發展，影響着從 CPU、FPGA 到數據庫系統，以及近期的人工智能基礎設施和區塊鏈系統等廣泛領域。在追求高性能時，流水線技術成爲不可或缺的手段。自 1964 年 IBM System/360 引入流水線技術以來 [1]，它一直是高性能系統設計的核心，推動了該領域的關鍵討論與創新。
流水線技術不僅應用於硬件，在數據庫領域也有廣泛應用。例如，Jim Gray 在其著作《高性能數據庫系統》中引入了流水線並行方法 [2]。該方法將復雜的數據庫查詢分解爲多個階段並同時運行，從而提高效率和性能。流水線技術在人工智能領域同樣至關重要，特別是在廣泛使用的深度學習框架 TensorFlow 中。它利用數據流水線並行處理數據預處理和加載，確保訓練與推理的數據流暢通，使 AI 工作流程更快、更高效 [3]。
區塊鏈也不例外。其核心功能類似於數據庫，處理交易並更新狀態，但增加了拜佔庭容錯共識的挑戰。提升區塊鏈吞吐量（每秒交易數）和降低延遲（至最終確認的時間）的關鍵在於優化不同階段——排序、執行、提交和同步交易——在高負載下的交互。這一挑戰在高吞吐量場景下尤爲關鍵，因爲傳統設計難以維持低延遲。
爲了探討這些理念，我們不妨回顧一個熟悉的類比：汽車工廠。理解裝配線如何革新制造業，有助於我們領會區塊鏈流水線的演進——以及爲何像 Zaptos[8] 這樣的下一代設計將區塊鏈性能推向新高度。
從汽車工廠到區塊鏈
想象你是一家汽車工廠的老板，有兩個主要目標：
· 最大化吞吐量：每天組裝盡可能多的汽車。
· 最小化延遲：縮短每輛汽車的建造時間。
現在，設想三種類型的工廠：
簡單工廠
在簡單工廠中，一組多能工人按部就班地組裝一輛汽車。一名工人組裝引擎，下一名工人安裝車輪，以此類推——一次只生產一輛車。
問題在於？部分工人常常處於等待狀態，整體生產效率低下，因爲沒有人同時在同一輛車的不同部分上工作。
福特工廠
引入福特裝配線 [4]！在這裏，每名工人專注於單一任務。汽車沿着傳送帶移動，每輛車經過時，一名專職工人添加自己的部件。
結果如何？多輛汽車同時處於不同組裝階段，所有工人都在忙碌。吞吐量大幅提升——但每輛車仍需依次經過每名工人，意味着每輛車的延遲時間不變。
魔法工廠
想象一個魔法工廠，所有的工人可以同時在一輛車上工作！不再需要將汽車從一個工位移到下一個工位，汽車的每個部分都同時被建造。
結果呢？汽車以創紀錄的速度組裝完成，每一步驟都在同步進行。這是解決吞吐量和延遲問題的理想場景。
好了，汽車工廠的討論到此爲止——區塊鏈呢？事實證明，設計高性能區塊鏈與優化裝配線並無太大不同。
區塊鏈如汽車工廠
在區塊鏈中，處理一個區塊類似於組裝一輛汽車。類比如下：
· 工人 = 驗證者資源
· 汽車 = 一個區塊
· 組裝任務 = 共識、執行和提交等階段
就像簡單工廠一次只處理一輛車，區塊鏈如果一次只處理一個區塊，會導致資源利用不足。相反，現代區塊鏈設計力求像福特裝配線一樣——同時處理多個區塊的不同階段。這就是流水線技術的用武之地。
區塊鏈流水線的演進
傳統架構：順序區塊鏈
想象一個按順序處理區塊的區塊鏈。驗證者需要：
- 接收區塊提議。
- 執行區塊以更新區塊鏈狀態。
- 繼續對該狀態進行共識。
- 將狀態持久化到數據庫。
- 開始下一個區塊的共識。
問題在哪裏？
· 執行和提交處於共識過程的關鍵路徑中。
· 每個共識實例需等待前一個完成才能開始。
這種設置就像前福特時代的工廠：工人（資源）在一次只專注於一個區塊（汽車）時常常處於空閒狀態。不幸的是，許多現有區塊鏈仍屬於這一類別，導致吞吐量低、延遲高。
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 爲需要速度和規模的現實世界區塊鏈應用鋪平了道路。
聲明：
- 本文轉載自 [BlockBeats]，著作權歸屬原作者 [Aptos Labs]，如對轉載有異議，請聯系 Gate Learn 團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由 Gate Learn 團隊翻譯， 在未提及 Gate.io 的情況下不得復制、傳播或抄襲經翻譯文章。
相關文章