公鏈Gravity發表Litepaper，基於高效能EVM帶來全新使用者體驗

原文來源：Gravity

引言

自2024 年8 月Gravity Alpha 主網路上線以來，該網路已處理超過2.75 億筆交易，每日平均交易量高達260 萬筆，並成功實現3,000 萬G 的交易費用。而隨著 Litepaper 的發布，我們對這條高效能 EVM 鏈的未來藍圖充滿期待。本文將深入解析 Litepaper，揭示 Gravity 如何為現實世界應用建立一個卓越的高效能 Layer-1 區塊鏈架構。

Gravity 是 Galxe 打造的高效能、EVM 相容的 Layer-1 區塊鏈。 Gravity 的開發源自於 Galxe 的發展需求。 Galxe 平台作為全球最大的鏈上分送平台，連結了一個龐大的多鏈生態，吸引了超過 2,500 萬用戶。在其不斷發展的進程中，Galxe 已發展為去中心化超級應用，整合了Quest、Passport、Score、Compass 和Alva 等創新工具，同時提供忠誠積分、活動NFT、代幣獎勵、zk-身份驗證和跨鏈智能儲蓄等豐富的服務。在持續發展的過程中，Galxe 的高交易量成為推動 Gravity 構建的重要因素——其忠誠度積分系統支援每秒 51.2 筆交易，代幣獎勵活動支持每秒 32.1 筆交易。這促使我們在去中心化 Galxe 後端時，需要轉向 EVM 區塊鏈，同時保持最佳的使用者體驗。

隨著 Galxe 全面鏈上化的發展，交易量的進一步成長是可預期的。預計吞吐量需求將達到每秒 5,000 萬 gas，而滿足更廣泛生態需求（如跨鏈結算、忠誠度積分交易和 NFT 市場）可能需要每秒 5 億 gas 的處理能力。為此，Gravity 的目標是支援每秒 1 gigagas 的吞吐量，以滿足資源密集應用的擴展需求。

現有解決方案中，許多平台透過以太坊實現可擴展性，但L2 Rollup 的挑戰期不可避免地導致交易延遲，這對Galxe 等需要即時交易確認的應用並不友善。儘管部分 DApp 嘗試透過信任模式或外部監控來彌補延遲，但這些方法引入了額外的複雜性和風險，對於核心應用場景顯然並不理想。

在這種背景下，Gravity 應運而生。 Gravity 以平行EVM 為核心，透過開發Grevm，這款目前最快的開源並行EVM 執行系統，縮小了L2 和L1 的效能差距，此外，Gravity 模組化Aptos 的架構，整合瞭如Quorum Store 和AptosBFT 共識引擎等經過驗證的組件。利用 AptosBFT 的成熟架構，Gravity 規避了從零開發的複雜性和潛在風險。最終，Gravity 不僅建立了一條提供全鏈體驗的高效能 L1 區塊鏈，還推出了首個管線區塊鏈 SDK，大大簡化了開發者和用戶的互動流程。

Gravity 提供了前所未有的可擴展性、去中心化能力和近乎即時的交易速度。其技術結合了 L1 和 L2 的優勢，實現了每秒 10,000 筆交易和亞秒的終結性。同時，透過整合 EigenLayer 和 Babylon 等再質押協議，Gravity 不僅在啟動階段確保了強大的安全性，還降低了長期依賴單一資產的系統性風險。

未來，Gravity 將依照以下路線圖推進：

· 推出Devnet 階段1，測試即時效能；

· 啟動Longevity Testnet，驗證網路長期穩定性；

·從Gravity Alpha 主網過渡到完全運營的Gravity 主網，為去中心化技術大規模應用奠定基礎。

以下是 Gravity Litepaper 的全文編譯。

摘要

Gravity 是Galxe 打造的高效能、EVM 相容的Layer-1 區塊鏈，專為大規模應用和多鏈生態設計。其特色包 括 每秒 1 gigagas 的吞吐量、亞秒交易最終確認 和依托再質押協議的 PoS 共識機制。 Gravity 的設計依賴兩大核心開源元件：(1) Gravity SDK，它是一種基於再質押的流水線式AptosBFT PoS 共識引擎；(2) Gravity reth，一個採用並行EVM Grevm (Gravity EVM) 驅動的執行層。這些工具為 Web3 應用 程式提供了建構替代 Layer-1 和高效 Layer-2 的能力，尤其在 EVM 鏈上表現突出。本文深入探討Gravity 的工程設計和技術創新，展示如何透過管線架構、先進的共識演算法、平行執行技術以及優化的儲存機制（透過增強reth 和改良Aptos 共識引擎）來滿足高性能需求。

引言

Gravity 的開發起源於 Galxe 在營運中遇到的挑戰。 Galxe 是一款領先的 Web3 應用，為用戶提供忠誠度積分、 活動 NFTs、代幣獎勵、零知識身份驗證以及多鏈智慧儲蓄等服務。隨著 Galxe 快速發展，其忠誠度積分系統每秒 平均處理 51.2 筆交易，而代幣獎勵活動平均每秒處理 32.1 筆交易。在逐步去中心化 Galxe 的過程中，將這些 用例遷移到 EVM 區塊鏈，同時確保流暢的使用者體驗成為了一項難題。因此，開發一條高效能 EVM 區塊鏈，能夠滿 足 (1) 高交易吞吐量和 (2) 幾乎即時的交易確認，變得至關重要。

在這一背景下，選擇現有 Layer-2 解決方案或開發新的 Layer-1 是關鍵決策點。 Layer-1 借助共識演算法實現最終 性，而 Layer-2 則借助 Rollup 協定解決這個問題。二者存在取捨：Layer-1 通常因共識演算法限製而犧牲部分吞吐 量，但能實現更快的交易最終確認。例如，基於 AptosBFT 的共識演算法可在亞秒級確認交易，而樂觀 Rollup 可能 因挑戰期長達七天。儘管零知識證明可加快此流程，最終確認仍需數小時。考慮到 Gravity 對亞秒級最終確認 的需求（尤其是其全鏈意圖協議），我們選擇建立 Layer-1。

儘管Layer-2 在與以太坊通訊上有原生優勢，但像Gravity 這樣的Layer-1 可透過Gravity 意圖協定和跨鏈橋，實現與以太坊及其他區塊鏈的深度互通性。這種設計不僅與以太坊無縫協作，也增強了整個 Web3 生態的連結性。

此外，再質押協議 (restaking) 顯著降低了建構 PoS Layer-1 區塊鏈的難度。 Gravity 借助 EigenLayer 和 Babylon 等協議，整合了以太坊和比特幣的質押資產及其廣泛的驗證者網路。這為 PoS 共識提供了經濟保障，使 Gravity 的去中心化與安全性達到與以太坊相當的水準。

綜上所述，Gravity 被建構為一個高效能、EVM 相容的Layer-1 區塊鏈，以滿足現代Web3 應用的可擴展性與性能需求。雖然其開發初衷是服務 Galxe，但 Gravity SDK 和 Grevm (Gravity EVM) 提供的靈活框架，適合用來構 建造任何 Layer-1 和高效 Layer-2，功能類似 Tendermint/Cosmos SDK。

我們需要1 gigagas/s 的吞吐量

對於區塊鏈來說，吞吐量是最關鍵的效能指標，通常以每秒交易數（TPS）或每秒gas 使用量（gas/s）來衡量。以 Galxe 的忠誠點系統為例，它要求至少達到 400 萬 gas/s 才能穩定運作。此資料源自於每筆忠誠點交易平 均消耗 80,000 gas，同時每秒能處理約 51.2 筆交易，由此計算得出。

這項預測得到了 Gravity Alpha Mainnet 的實踐數據支持。作為我們測試中的 Layer 2 網絡，Gravity Alpha Mainnet 的忠誠點交易顯示其吞吐量可以穩定達到 400 萬 gas/s，驗證了前述估算的準確性。

雖然鏈上操作的高成本可能會導致需求小幅下降，但Galxe 的擴張趨勢顯示，在高峰時段需求可能會提升至當前水準的兩到三倍。此外，隨著其他應用場景的加入，如 NFT、代幣獎勵，以及未來的零知識證明支援的全鏈任務，如果 Galxe 完全鏈上化，預計吞吐量需求將達到 5000 萬 gas/s。而假設Gravity 鏈上的應用gas 使用遵循帕累托分佈（類似於Uniswap 一直消耗以太坊10% 的gas），為滿足更廣泛的生態需求，如跨鏈結算、忠誠點交易和NFT 市場，理想情況下應支援5 億gas/s 的吞吐量。因此，為滿足這些潛在需求，區塊鏈必須具備每秒 1 gigagas 的處理能力，確保它能適應資源密集應用的擴展。

為了達到如此高的吞吐量，關鍵在於引進並行 EVM。我們開發了 Grevm，這是目前最快的開源並行 EVM 執行系統，具體效能可以參考後續章節。

亞秒級的確認時間

吞吐量之外，交易的確認速度對於使用者體驗也至關重要。現代用戶習慣了類似 Web2 的幾乎即時回應，而這對區塊 鏈來說仍然是一個挑戰。以 Galxe 為例，它與完全鏈上遊戲類似，對低延遲有一定要求。目前，大多數 EVM 區塊 鏈的交易確認時間從數秒到數天不等，遠遠無法滿足這項要求。我們選擇 AptosBFT 共識演算法來實現亞秒的確認 時間。

儘管 L2 Rollup 在理論上能提升吞吐量，但它們的挑戰期會導致交易延遲，這對需要即時交易確認的應用（如 Galxe）非常不利。雖然一些 DApp 嘗試透過信任模式或外部監控來優化這一點，但引入了額外的複雜性與風險，對於關鍵應用程式並不理想。 Gravity SDK 透過設計五階段管線，將共識和執行流程並行化，縮短了 L2 和 L1 的性 能差距（具體設計詳見後文）。

基於再質押(Restaking) 的PoS 安全

Gravity SDK 提供了一種安全擴展以太坊的方法，不限於L2 Rollup，而是選擇透過再質押保護的L1 架構，平衡效能、互通性和安全性。核心模組整合 EigenLayer 和 Babylon 等再質押協議，提供了經濟信任支持，為構 建穩健的權益證明共識提供保障。

借助以太坊的450 億美元質押資產和85 萬驗證者，以及透過Babylon 接入比特幣的6000 億美元資產，Gravity 能從一開始就建立堅實的安全基礎，避免新區塊鏈常見的啟動問題及安全隱患，同時長期降低單一資產帶來的系統性風險。

Gravity Chain 架構

Gravity Chain 包含兩個主要元件：Gravity SDK 和Gravity reth。 Gravity SDK 是一種改進自 Aptos 鏈的區塊 鏈框架，Aptos 是目前最先進的基於 HotStuff 共識演算法家族的 PoS 區塊鏈，其管線架構極大提升了吞吐量和資源 效率。 Gravity reth 是一個基於 reth 的執行層，以區塊流反應器（BSR）的形式運行，用於接收來自共識層的提議區塊。透過優化 reth，Gravity reth 實現了並行執行、批次非同步狀態提交計算以及儲存效率提升。這兩個元件透過 Gravity 共識引擎介面（GCEI）和 reth 轉接器緊密結合，由管線控制器動態管理每個階段的進度。

設計將區塊執行從區塊共識中分離，使執行層作為區塊提議的消費者。我們對 reth 的優化，使其完美適應由區塊 流反應器（BSR）管理的管線區塊提議流程。

Gravity Chain 的交易流程如下：

1. 交易透過Gravity reth JSON RPC 介面提交，該接口完全兼容以太坊。

2. 隨後，交易進入 Gravity SDK 的記憶體池並在網路中傳播，驗證者對交易進行批次處理並產生 Quorum Store（QS）憑證。

3. 每輪次的領導者提出一個區塊提案，包含區塊元資料和從記憶體池及 QS 中選取的有序交易。

4. 提案被標記為有序後，將進入執行層。

5. 執行層的 Grevm 並行處理交易，產生執行結果，並將新狀態傳遞至狀態管理模組。

6. 狀態模組計算狀態根並傳遞給共識引擎以達成狀態根共識。

7. 狀態根最終確認後，儲存模組持久化狀態根和區塊資料。

接下來的章節將詳細介紹每個元件。

Gravity SDK：開源管線區塊鏈的創新實踐

Gravity SDK 是一種模組化開源區塊鏈框架，基於生產就緒的Aptos 區塊鏈開發。其目標是模組化 Aptos 的架構，借鏡已驗證的組件如 Quorum Store 和 AptosBFT 共識引擎，打造首個管線區塊鏈 SDK。

Gravity SDK 選擇Aptos 作為基礎的原因包括：

· 頂級技術架構：Aptos是基於HotStuff 家族共識的先進PoS 區塊鏈。

· 極致效能表現：Aptos 提供每秒 16 萬筆交易的吞吐量，並且最終確認時間低於 1 秒。

· 實戰可靠性：Aptos 已通過生產環境的驗證，表現出卓越的穩定性和高效性。

· 避免重複造輪子：利用Aptos 的成熟架構可以規避從零開發的複雜性和潛在風險，而其他試圖超越Aptos 的嘗試大多理論和實踐不足。

· 協同增益：隨著Aptos 的不斷發展，Gravity SDK 能夠無縫整合其新特性，如隨機數API，同時也透過模組化架構和創新安全機制反哺Aptos。

基於 Gravity SDK 的區塊鏈透過 Gravity 共識引擎介面（GCEI）與管線共識引擎對接。儘管 GCEI 相容於多種執 行層，但 Gravity SDK 目前主要支援 Gravity reth。關於 GCEI 的詳細內容將在後續章節中展開討論。

Gravity Consensus Engine Interface (GCEI)

GCEI（Gravity Consensus Execution Interface）協定是共識層與執行層之間的通訊橋樑。它規範了兩層之間的 交互，確保透過管線控制器使共識與執行流程保持同步。

傳統區塊鏈SDK與Gravity SDK 的主要區別在於其流水線化的共識引擎。執行層必須實作為一個區塊流反應器（Block Stream Reactor），這意味著它需要能夠連續地消費提議的區塊流，且狀態承諾必須與交易執行非同步計算。此外，執行層需要能夠向共識層提供回壓訊號，以便動態調整區塊提議的節奏。

此外，由於Gravity SDK 的管線特性，執行層必須能夠處理提議區塊中不可執行的交易，因為記憶體池由於無法存取最新的世界狀態而無法嚴格檢查任何交易的有效性：執行可能尚未完成。同時，執行結果不應阻塞後續區塊的生成，因為在Gravity SDK 將區塊共識與狀態共識並行化後，執行層變成了對提議區塊流的一個反應器，可以自由地在後續階段返回執行結果。

GCEI 協定規格定義了兩組API：

· 共識層API：這些API由Gravity SDK 實現，用於執行層響應共識引擎提議的區塊並提交狀態承諾。

· 執行層 API：這些 API 必須由執行層實作。共識引擎將使用這些 API 在將交易提議到區塊之前進行盡力驗證、流化提議的區塊，並通知執行層最終的狀態承諾。

從交易生命週期的角度來看，GCEI 協議定義了以下：

1. check_txn（執行層 API）

· 輸入：接收一個交易（GTxn）作為輸入。

· 輸出：傳回交易的發送方位址、nonce 和 gas 限制。

用途：此方法用於共識引擎在將交易提議到區塊之前運行盡力驗證。此方法可以對同一交易多次調用，例如當交易進入內存池時、在被提議到區塊之前以及狀態承諾最終確定時。

2. submit_txn（共識層API）

輸入：從執行層接收一個交易（GTxn）。

輸出：傳回 Result<()>，表示交易是否成功加入記憶體池。

用途：執行層可以使用此方法將交易提交至記憶體池。共識引擎隨後會透過網路傳播該交易，並在接收到 一批交易後形成 Quorum Store。

3. recv_ordered_block（執行層API）

輸入：接收一個ordered_block（類型為BlockBatch），其中包含排序後的交易和區塊元資料。

輸出：傳回 Result<()>，表示執行層是否成功接收並接受了該區塊。

用途：一旦共識引擎提議了一個區塊，它就會被送到執行層進行交易執行。此方法允許執行層接收和 處理提議的區塊。

4. update_state_commitment（共識層API）

輸入：某區塊編號的狀態承諾（StateCommitment）。

輸出：返回 Result<()>，表示狀態承諾是否被本地共識引擎成功接受。

用途：執行層計算出狀態承諾後，將其發送到共識層以便最終確定，即與其他驗證者達成2f+1 的輕量級共識。如果狀態承諾共識與提議區塊的進度差距過大，管線控制器將調整區塊提議的節奏。

5. commit_block_hash（執行層 API）

輸入：接收一組 block_ids 向量，表示需要提交的區塊。

輸出：回傳 Result<()>，指示操作成功與否。

用途：當狀態承諾最終確定時，共識層將通知執行層將區塊雜湊提交到區塊鏈儲存中。

區塊鏈管線

Gravity SDK 利用五階段管線架構最大化硬體資源利用速率，從而實現更高吞吐量和更低延遲。管線在不同區塊 之間交錯執行任務，管線管理器使用回饋機制確保區塊鏈穩定前進。前三個階段屬於共識層，而後兩個階段屬於 執行層。

各階段解釋如下：

· 階段1：交易傳播：此階段有效率地在驗證者之間傳播交易，確保在區塊構建期間及時且可靠地包含交易。設計中解耦了交易傳播與共識機制，遵循Narwhal & Tusk 和Aptos 的思想，即驗證者連續共享交易批次，利用所有網路資源並發運作。當一批交易獲得 2f+1 權重簽名時（形成 PoAv，即可用性證明），確保 該批交易由至少 f+1 誠實驗證者存儲，使得所有誠實驗證者均可檢索到這些交易用於執行。

· 階段 2：區塊元資料排序：此階段在網路內建立一致且公認的交易和區塊元資料順序。共識機制（AptosBFT）遵循雙鏈規則（2-chain rule）以提供拜占庭容錯區塊。區塊隨後將流入執行階段，準備進行並行 處理。

· 階段 3（BSR）：平行交易執行：此階段屬於執行層的一部分，在此階段中並行執行交易。執行結果將被傳 遞到狀態承諾階段。

· 階段 4：狀態承諾：此階段完成交易執行所引起的狀態變更並準備區塊最終確定。狀態承諾與交易執行非同步計 算，確保下一區塊的執行不受當前區塊狀態承諾的阻礙。

· 階段 5：狀態持久化：此階段將已承諾的狀態變化持久化到區塊鏈儲存中。最終狀態根及相關資料儲存在 Gravity Store 中，該儲存採用高度最佳化的儲存引擎，設計為快速存取且可靠。同時通知記憶體池和 Quorum Store 清除未來無法再包含的交易。

Staking 和Restaking 模組

建構一個安全的權益證明（PoS）Layer 1 區塊鍊是一項複雜任務，尤其是在僅依賴鏈上特定Token 進行質押的情況下。這種方法在早期階段可能面臨經濟安全性不足的問題，例如 Token 價值波動或驗證者參與度有限等。為了 解決這個問題，Gravity SDK 提供了一個靈活的 Staking 和 Restaking 模組，旨在透過本地和外部的質押機制提 升網路的安全性。

Gravity SDK 的關鍵策略之一是引入了EigenLayer 和Babylon 等Restaking 協議。這些協議允許驗證者將其他成熟網路（如以太坊和比 特幣）的資產重新質押，從而利用其現有的安全保障。透過允許驗證者抵押這些鏈的資產，Gravity SDK 能夠提升 網路的經濟安全性，而無需完全依賴本地 Token。這種方法不僅增強了鏈的穩健性，也推動了驗證者生態系的多 樣性。 Staking 模組的設計以模組化為核心，其 Restaking 組件具有高度的靈活性，能夠隨著區塊鏈生態系統的 演變輕鬆適配新的 Restaking 協議。

模組不僅支援 Restaking 資產，還支援在支援鏈上質押自訂 ERC20 Token，例如以太坊上的 G Token。驗證 者可以透過質押這些允許的 Token 參與共識，為網路的安全性做出貢獻。驗證者的投票權根據其總質押價值計算，包括自訂 Token 和 Restaking 協議中的資產。此計算依據鏈的具體配置進行，確保每條鏈可依自身需 求靈活設定質押和再質押規則。

共識引擎中的 Epoch 管理器與 Staking 模組直接協作，用於計算下一輪驗證者集合的權重。它透過從執行層取得 質押值，確保共識過程能夠準確反映最新的質押動態。在此架構中，跨鏈資產（例如來自以太坊的質押資產）必須 首先橋接到執行層，然後才能用於計算驗證者的總質押值。橋接機制的實現由執行層負責，這樣可以更靈活地處理 跨鏈通訊。可能的解決方案包括 PoS 橋、鏈狀態的零知識證明，以及嵌入式自啟動跨鏈訊息傳遞。

更多技術細節、API 設計及 Staking 和 Restaking 機制的完整說明將會在後續文件中詳細介紹。

Gravity Reth：區塊流反應器EVM 執行層

在Gravity SDK 架構中整合以太坊虛擬機（EVM）執行層帶來了獨特的挑戰，特別是在充分利用其管線共識引擎的能力時。為了實現無縫整合並充分發揮此架構的潛力，我們需要對開源以太坊用戶端 reth 進行多項關鍵最佳化。這些優化從根本上將 reth 轉變為 Gravity reth，一種為管線共識引擎量身定制的管線優化 EVM 執行層。

傳統區塊鏈架構依序處理區塊，確保每個區塊在提議下一個區塊之前完全驗證和執行。然而，Gravity SDK 採用 了一種管線共識機制，將區塊處理的各個階段分開以提高效能。這個範式的轉變引入了複雜性：

意外交易：在管線鏈中，由於先前區塊的執行可能尚未完成，記憶體池無法存取最新的世界狀態。因此，提議區塊中包含的交易在提議時可能無法執行，因為在沒有最新狀態的情況下，其有效性無法被嚴格驗證。

非阻塞執行結果：為了防止管線停滯，執行結果不應阻止後續區塊產生。執行層必須能夠非同步處理提議 區塊，並在稍後階段返回執行結果而不阻礙共識過程。對於 EVM，這意味著需要重新定義 blockhash，消除 對區塊頭中 stateRoot 欄位的依賴。

為了解決這些問題，我們引入了四個關鍵最佳化：

· 區塊流反應器（Block Stream Reactor, BSR）：BSR 旨在將reth 調整為Gravity SDK 的管線區塊提議流程。它使執行層能夠持續消費提議區塊流，作為一個非同步處理區塊的反應器。 BSR 與共識引擎建立了一個動態 回饋循環，結合適當的回壓訊號。這些訊號根據執行層的吞吐量和延遲即時調整區塊提議和狀態提交的速度。如 果實因複雜交易或資源限制導致執行層滯後，回壓機制會降低區塊提議速率，以確保系統穩定。

· 狀態提交與交易執行的解耦：第二項最佳化涉及將狀態提交計算與交易執行分開。透過解耦這些過程，我們實 現了狀態提交計算的非同步化，使後續區塊的執行無需等待當前區塊的狀態提交完成。我們重新定義了 blockhash，去除了對區塊頭中 stateRoot 欄位的依賴，確保狀態根計算不會阻止後續區塊生成。

· 儲存層最佳化：在管線架構中，高效能快取和持久化多版本狀態值與狀態提交至關重要。第三項最佳化著重於增 強儲存層以滿足這些需求而不引入瓶頸。透過優化儲存機制，我們確保狀態資料能夠快速寫入並高並發檢索。這 包括建立多版本儲存引擎和支援從資料庫到儲存 API 的非同步 I/O。

· 並行 EVM：最後一項最佳化涉及並行化 EVM 內的交易執行。我們開發了 Grevm，一種並行 EVM 運行時，透過 並發執行交易顯著加速交易處理。 Grevm 利用從交易模擬中獲得的資料依賴提示優化並行執行，減少交易重新執 行並提高吞吐量。

Grevm（Gravity EVM） - 並行EVM 執行

Grevm 是一個開源項目，託管在GitHub 上（如果尚未開源，未來將會開源）。請參閱其 README 以取得更多資訊。

Grevm（Gravity EVM） 是基於revm 的開源並行EVM 運行時。 Grevm 的演算法靈感來自 BlockSTM，並透過引入從模擬結果中獲得的交易資料依賴圖加以增強。此 機制使並行執行調度更加高效，最大限度地減少交易重新執行。

在我們的基準測試中，Grevm 是目前最快的開源並行 EVM 實作。對於無衝突交易，Grevm 比順序執行快 4.13 倍，運行速度達到 26.50 gigagas/s。如果模擬真實世界 100 μs 的 I/O 延遲，其速度是順序執行的 50.84 倍，吞吐量為 6.80 gigagas/s。這種性能的飛躍歸功於並行化執行與非同步 I/O 操作的整合——並行 化使得 I/O 操作能夠有效率地重疊，從而進一步加速。

Grevm 的核心思想是利用交易間的資料依賴性，透過推測的交易讀取/寫入集合來優化並行執行。儘管所有提示並非完全 準確，但這些基於模擬的提示通常足夠實用。例如，在以太坊主網上，根據歷史Gas 使用情況，大約30% 的交易是簡單的以太幣轉賬，另有25%-30% 是ERC20 代幣轉賬，這些交易通常只涉及讀取和寫入有限數量的帳戶和儲存槽。對於這些交易，模擬結果具有一致的準確性。

基於這些見解，我們為Grevm 開發了一個三階段並行執行框架，作為Block-STM 模型的後續工作，並結合了從交易模擬中獲得的資料依賴提示：

· 階段1：提示產生與狀態預先載入－模擬交易以收集依賴提示並預熱記憶體快取。此階段可以在不同時間點 執行，具體取決於區塊鏈的設計。例如，當新交易到達記憶體池時，可以立即執行模擬以提前準備依賴提示。

· 階段 2：依賴分析－將模擬階段收集的依賴提示轉換為表示交易間依賴關係的有向無環圖（DAG）。此 DAG 用於規劃後續並行執行中的交易調度。

· 階段 3：衝突解決下的平行執行－使用基於依賴 DAG 的修改版 BlockSTM 演算法並行執行交易。調度程 序不再嚴格依照區塊中交易的序號（如 1, 2, 3, ..., n）選擇交易，而是優先根據 DAG 排序交易，以最小 化衝突並減少重新執行需求。

非同步批次狀態提交

狀態提交的產生仍然是區塊鏈管線中的關鍵瓶頸，源自於默克爾化本質上的順序性。每個子樹計算必須完成後 才能產生最終狀態提交，這會導致顯著延遲。儘管現有解決方案（如reth的帳戶級並行化）引入了一定程度的並行性，但仍有大量優化空間。在 Gravity reth 的區塊流反應器（BSR）執行層背景下，狀態 提交共識與交易執行解耦，可以異步進行推遲和批量的狀態提交計算而不阻塞執行。

為了解決這些問題，提出的框架引入了以下關鍵創新：

非同步批量雜湊計算：利用狀態提交共識與交易執行的解耦，該框架實現了狀態提交的非同步計算。狀態根更新按 批次（如每 10 個區塊計算一次）進行，以減少狀態根計算的頻率。這種批次處理方法透過聚合共享的髒節點實現 高效哈希計算，從而最大限度地減少頻繁更新的開銷並降低總體計算成本。對於小區塊，批量處理可以顯著提高並 行性；對於大區塊，則可減少總體計算成本。

完全並行化：該框架將並行化擴展至整個狀態樹，而不僅僅是單一帳戶樹。對於標記為「髒」的節點，框架採用 平行狀態計算演算法，將樹劃分為獨立的子樹並並行處理這些子樹。結果在頂層聚合以高效計算最終根。這種方法確 保擁有大量交易和狀態變化的大區塊能夠充分利用多線程，從而最大化吞吐量。

替代快速狀態根：為適應以太坊的區塊頭和BLOCKHASH 操作碼（需要訪問最近256 個區塊的狀態根），我們重新定義了狀態根。與依賴最終狀態提交（在交易執行期間不可用）不同，我們將狀態根計算為區塊變更集與先前狀態根的雜湊值組合。這種方法使得狀態根計算更快，無需等待完整的狀 態提交完成。

Gravity Store

為了滿足高效能區塊鏈對大規模資料管理的需求，Gravity Store 作為一個優化的多版本儲存層應運而生。它基於 reth 的設計，reth 已經透過將狀態提交儲存和狀態資料儲存分離來減少狀態膨脹問題，同時降低了資料讀寫的開 銷。然而，Gravity reth 的執行層需要進一步支援平行處理和非同步狀態提交，提出了更多的技術需求。

為了解決這些挑戰，Gravity Store 提出了高效率的多版本樹結構，專為我們的BSR（Block Stream Reactor）架構量身訂做。這種樹狀結構支援管理多版本的狀態更新。有別於修改後立即更新雜湊值的傳統做法，Gravity Store 會將修改過的節點標記為“髒節點”，從而實現哈希計算的延遲處理與批量執行。這種設計允許快速創建新版本、高 效查詢指定版本數據，並清理低於指定高度的舊版本，大幅提升區塊鏈狀態管理的效能。

我們也正在研究獨立開發儲存引擎 Gravity DB，其設計目標是為區塊鏈應用提供最佳化的儲存層，並支援完全非同步的 I/O 操作。引擎的設計靈感來自LETUS，一種面向區塊鏈的高效能日誌結構化通用資料庫引擎。我們的首席開發人員 Richard 作為 LETUS 的主要作者之一，將在即 將發布的部落格文章中詳細介紹其設計。

結論

Gravity Chain 是一個高效能的EVM 相容第一層區塊鏈，專為滿足現代web3 應用的可擴展性和性能需求而設計。結合Gravity SDK、管道化的AptosBFT PoS 共識引擎，以及由Grevm 驅動的Block Stream Reactor 執行層Gravity reth，Gravity 實現了每秒1 gigagas 的交易吞吐量、亞秒級的交易確認時間，以及基於再質押機制的PoS 安全性。這些技術組件的設計，為 web3 應用創建自訂的替代 L1 區塊鏈或更有效率的 L2 解決方案提供了堅實的基礎，特別適合優化 EVM 鏈的使用情境。

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