自以太坊選擇了以彙總為核心的路線圖以來，整個社區都認為彙總將成為以太坊擴展性問題的解決方案。然而，直到今天，彙總在計算能力方面仍然不及某些高性能的一層網絡。

這可能是因為彙總團隊不僅要處理執行問題，還需要應對各種證明系統、橋接等事務，以推動以太坊的擴展。

但現在，一種新的彙總類型正在崛起，旨在釋放彙總的真正潛力：Gigagas 彙總。在我們之前的系列中，我們探討了基於以太坊的彙總、加速彙總和原生彙總。在本文中，我們將研究 Gigagas 彙總，瞭解其試圖解決的問題以及其運作方式。

彙總的性能挑戰是什麼？

L2 的主要性能問題集中在 DA（數據可用性）問題上。然而，隨著 @eigen_da 等外部 DA 解決方案的進展以及 blobs 的引入，DA 不再是瓶頸。相反，我們現在面臨多個新的限制。

其中一個最大的問題在於 EVM 的實現通常是單線程的，這意味著它一次只能使用一個 CPU 核心，即使現代 CPU 具有多個核心，可以同時處理不同任務。因此，性能上限受單個核心的時鐘頻率限制。

過渡到並行執行是一個複雜的過程，需要對 EVM、狀態管理和交易結構進行必要的修改。同時，@VangelisAndr 最近的研究表明，以太坊 64.85% 的交易可以並行化，想象一下在 L2 上可以並行化多少交易，從而進一步提升性能。

另一個挑戰是提高 L2 的區塊 gas 限制以實現更高的吞吐量，這可能會影響證明機制。如果欺詐證明需要提交整個區塊，它們可能會與以太坊自身的區塊大小限制衝突。L2 的區塊生產方式不同於 L1，在排序器和執行客戶端中提供了優化和並行化的機會，使其擺脫傳統 L1 的概念。

一個重大挑戰是實現共享排序，以增強 L2 之間的互操作性，同時保持去中心化。然而，這種方法仍然較新，主要的彙總可能會抵制將排序控制權交給第三方，因為增加可組合性的好處尚不明確，並且可能影響性能。

以太坊使用修改版的 Merkle-Patricia Trie（MPT）來管理和驗證其鍵值數據。EVM 並未規定狀態應如何存儲，因此節點客戶端可以嘗試不同的解決方案。目前，LevelDB、PebbleDB 和 MDBX 等實現正在使用中，但它們缺乏經過認證的鍵值存儲的固有屬性，例如加密完整性證明。這增加了信任假設，複雜化了欺詐證明，並增加了驗證狀態變化的開銷，影響效率和安全性。

對於大多數彙總，性能通常以交易數量而非 gas 計算。然而，在深入探討 gigagas 彙總如何解決可擴展性問題之前，我們需要先了解為什麼 gas 比 TPS 更具意義，以及為什麼我們應該關注它。

為什麼我們要衡量 gas？

在彙總和以太坊本身的性能測量中，通常使用每秒交易數（TPS），但更精確的度量方式可能是“每秒 gas”。這一指標表示網絡每秒的計算能力，其中“gas”代表執行交易或智能合約等操作的計算成本。

然而，TPS 忽略了不同交易和操作的複雜性及資源需求差異，使其成為一個不完整甚至具有誤導性的網絡性能指標。一個網絡可能處理更多交易，但計算成本較低，而 TPS 無法真實反映系統的實際容量。

採用每秒 gas 作為標準性能指標可以更清晰、更準確地衡量區塊鏈的吞吐量和效率。@paramonoww 撰寫了一篇文章，探討了為什麼 TPS 是一個不合理的指標。

關注 gas 很重要，因為它反映了網絡能處理多少工作量，從而更清晰地展現可擴展性和效率。gas 價格影響網絡經濟，包括交易費用和獎勵，這反過來會影響用戶行為和網絡安全。因此，每秒交易數提供了一個大致的概覽，而每秒 gas 則能深入展現區塊鏈的真實性能。

既然我們理解了 gas，那麼什麼是 gigagas 以及 gigagas 彙總呢？

什麼是 gigagas 彙總？

Gigagas 以每秒十億 gas 單位來衡量帶寬，相比 TPS 提供了更優越的容量測量方式。Gigagas 彙總本質上是旨在管理每秒 1 gigagas（即 10 億 gas 單位）的彙總。雖然這一概念直觀易懂，但其實現卻極具挑戰。目前，即使採用中心化排序，也沒有任何以太坊彙總能接近這一基準，整個生態系統的處理能力僅約為每秒 6000 萬 gas（60 Mgas）。

來源： rollup.wtf

Gigagas 彙總將通過以 gigagas 計量交易處理能力來擴展吞吐量，使得龐大的交易量或複雜操作能夠更快速地執行。它們將通過數據壓縮、證明生成和主鏈數據提交方面的創新來提高效率，旨在實現最小開銷和最大吞吐量。

目前，多個團隊正在積極研發 gigagas 彙總。例如，@Abundance_xyz 正在構建完整的 gigagas 彙總技術棧，而 @rise_chain 正專注於構建 gigagas 彙總，並對 EVM 及其生態進行大規模修改和優化。接下來，我們將深入探討 gigagas 彙總的運作方式，重點關注 RISE。

Gigagas 彙總是如何運作的？

RISE 是一個 L2 平臺，旨在解決以太坊彙總的性能問題。儘管已有諸多進展，但當前的 L2 方案仍無法達到 Solana 的速度。RISE 通過並行 EVM、連續執行以及基於 RethSDK 的全新狀態架構來提高吞吐量，目標是實現每秒超過 1 Gigagas 的帶寬。

RISE 的架構包含一個完全開源的並行 EVM 執行引擎 pevm，該引擎通過區塊流水線支持連續執行。在狀態訪問方面，RISE 採用版本化默克爾樹（Versioned Merkle Trees）來優化性能，並使用專為 EVM 鏈狀態設計的自定義數據庫 RiseDB。

RISE 技術棧構建於 Reth 之上。在數據可用性方面，該架構需要高帶寬，並採用模塊化設計以適應不同的數據可用性解決方案。此外，RISE 採用 based sequencing 來去中心化區塊生產。如果你不瞭解 based 彙總，可以查看本系列的第一篇文章，其中探討了其優缺點。

在典型的 L2 方案中，由於共識、執行和默克爾化的順序處理方式，區塊時間僅有約 8% 用於實際執行。這種方式效率低下，共識可能佔用 40-80% 的時間，而默克爾化最多佔用剩餘時間的 60%。RISE 的連續區塊流水線（Continuous Block Pipeline, CBP）通過並行執行、連續交易處理和併發狀態根計算來改進這一流程，使得幾乎 100% 的區塊時間都用於交易執行，相較於傳統方法大幅提升效率。

以太坊使用兩層狀態系統，並採用默克爾帕特里夏樹（MPT）來確保數據完整性。然而，由於 MPT 結構和底層數據庫的 LSM（Log-Structured-Merge）樹特性，會導致高讀寫放大效應，使狀態查詢涉及大量 I/O 操作。MPT 通過擴展節點減少冗餘，但仍然面臨 SSD 低效利用、較高的壓縮開銷以及 CPU 在 I/O 等待期間的低利用率等問題。

RISE 通過採用版本化默克爾樹（Versioned Merkle Tree）來解決這些問題，該方案使用版本化密鑰提高存儲效率。此外，RISE 還採用 LETUS 方法，結合增量編碼（delta encoding）和日誌結構文件（log-structured files）來減少放大效應，從而實現更高效的存儲管理和數據檢索。

每個彙總都會變成gigagas 彙總嗎？

並非所有彙總都會轉變為 gigagas 彙總，其中有多個原因。並非所有應用都需要如此高的性能，而 gigagas 技術的複雜性和成本可能對於交易需求較低或用例較簡單的項目而言並不值得。

一些彙總更關注易用性、隱私性或特定行業應用，而不是純粹的吞吐量。此外，在可擴展性與去中心化之間需要權衡，一些項目可能更傾向於保持去中心化結構，而不是追求 gigagas 級別的性能。漸進式擴展可能更為現實，避免了對系統進行大規模變更的需求。

向 gigagas 級別過渡可能會影響現有集成，或在沒有必要的情況下增加用戶交互的複雜性。是否選擇成為 gigagas 彙總，很大程度上取決於項目的資源、戰略目標及其在鏈上生態中的定位。

結論

Gigagas 彙總在以太坊擴展性方面邁出了重要一步，通過對彙總技術棧的多項改進，解決了傳統 L2 彙總面臨的核心瓶頸，如單線程執行、默克爾化管理以及狀態存儲效率低下等問題。

然而，要實現 gigagas 級別的性能，需要相對複雜且具有變革性的架構調整。同時，這也涉及取捨，例如在可擴展性與去中心化之間的權衡。因此，並非生態系統中的每個彙總都必須成為 gigagas 彙總。

除此之外，gigagas 彙總的出現將為以太坊社區提供重要機遇，展示以太坊真正的強大潛力。

在本系列文章中，我們深入探討了以太坊擴展的不同類型：第一部分介紹了 based 彙總，第二部分探討了 booster 彙總，第三部分分析了 native 彙總，最後在本篇文章中介紹了 gigagas 彙總。雖然本系列到此結束，但關於 rollup 的探索遠未停止，敬請期待後續關於以太坊最新創新的系列文章和深度分析！

免責聲明：

1. 本文轉載自【2077 研究】，所有版權歸原作者所有【2077 研究】。若對本次轉載有異議，請聯繫 Gate Learn 團隊，他們會及時處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止複製、分發或抄襲翻譯文章。