Reth 如何實現每秒 1 GB Gas 量，甚至更高？
內容
我們於 2022 年開始構建 Reth，爲以太坊 L1 提供復原能力，並解決 L2 上的執行層擴展問題。
今天，我們很高興與大家分享 Reth 在 2024 年如何實現 L2 每秒 1 GB Gas，以及我們超越這一目標的長期路線圖。
我們邀請生態系統與我們合作，推動加密領域的性能和嚴格基準測試的前沿發展。
我們已經實現規模化擴展了嗎？
加密貨幣要達到全球規模並避免投機成爲主要用例，有一條非常簡單的途徑，即讓交易變得便宜且快速。
如何衡量性能？每秒Gas量是指什麼？
性能通常通過“每秒事務數”(TPS) 指標來衡量。特別是對於以太坊和其他 EVM 區塊鏈來說，更細致、或許更準確的衡量標準是“每秒的 Gas 量”。該指標反映了網路每秒可以處理的計算工作量，其中“gas”是衡量執行交易或智能合約等操作所需的計算工作量的單位。
將每秒Gas量作爲性能指標進行標準化可以讓我們更清楚地了解區塊鏈的容量和效率。它還有助於評估對系統的成本影響，防止可能利用不太細致的測量的潛在拒絕服務 (DOS) 攻擊。該指標有助於比較不同以太坊虛擬機（EVM）兼容鏈的性能。
我們建議 EVM 社區採用每秒 Gas 作爲標準指標，同時納入Gas定價的其他方面，制定綜合性能標準。
我們如今處於哪個發展階段？
每秒的 Gas 量是通過將每個區塊的目標 Gas 使用量除以區塊時間來確定的。在這裏，我們展示了各種 EVM 鏈 L1 和 L2 的當前每秒 Gas 吞吐量和延遲（並非詳盡無遺）：
我們強調每秒 Gas 來全面評估 EVM 網路性能，捕獲計算和存儲成本。 Solana、Sui 或 Aptos 等網路由於其獨特的成本模型而未包括在內。我們鼓勵努力協調所有區塊鏈網路的成本模型，以實現全面和公平的比較。
我們正在開發一個用於 Reth 復制真實工作負載的連續基準測試套件，如果您想就此進行合作，請聯系我們。我們需要一個用於節點的TPC 基準。
Reth 如何達到每秒 1 GB Gas？甚至更高？
2022年，我們構建 Reth 的部分出於迫切需要專門爲網路規模的匯總構建客戶端的原因。我們認爲我們的前進道路充滿希望。
Reth 在實時同步期間已達到 100-200mgas/s（包括發送方恢復、執行交易以及計算每個塊上的 trie）；所以，需要再擴展 10 倍才能實現我們每秒 1GB gas 的短期目標。
隨着我們推進 Reth 的開發，我們的擴展計劃必須在可擴展性與效率之間取得平衡：
- 縱向擴展： 我們的目標是最大限度地利用每個“盒子”的全部潛力。通過優化每個系統處理交易和數據的方式，我們可以大大提高整體性能，同時也使單個節點運營商更加高效。
- 橫向擴展： 盡管進行了優化，但網路規模的交易量仍然超出了任何單個服務器的處理能力。爲了解決這個問題，我們希望實現一個橫向擴展的架構，類似於區塊鏈節點的 Kubernetes 模型。這意味着將工作負載分散到多個系統上，以確保沒有單個節點成爲瓶頸。
我們在這裏探索的優化不涉及解決狀態增長，我們正在單獨研究這一點。
以下是我們打算如何實現這一目標的總體計劃：
在整個堆棧中，我們還使用參與者模型針對 IO 和 CPU 進行優化，以允許將堆棧的每個部分部署爲服務，並對其利用率進行精細控制。最後，我們正在積極評估替代數據庫，但尚未確定候選數據庫。
Reth的縱向擴展路線圖
我們的目標是最大限度地提高運行 Reth 的單個服務器或筆記本電腦的性能和效率。
即時（Just-In-Time）EVM 和提前（Ahead-of-Time）EVM
在以太坊虛擬機（EVM）等區塊鏈環境中，字節碼執行通過解釋器進行，解釋器順序處理指令。此方法會帶來開銷，因爲它不直接執行本機匯編指令，而是通過 VM 層進行操作。
即時（JIT）編譯通過在執行之前將字節碼轉換爲本機機器代碼來解決這個問題，從而繞過了虛擬機的解釋過程，提高了性能。這種技術提前將合約編譯成優化的機器代碼，在 Java 和 WebAssembly 等其他虛擬機中得到了廣泛應用。
然而，JIT 可能容易受到旨在利用 JIT 進程的惡意代碼的攻擊，或者可能在執行過程中速度太慢而無法實時運行。Reth 將提前（AOT）編譯需求最高的合約並將其存儲在磁盤上，以避免不受信任的字節碼試圖在實時執行期間濫用我們的本機代碼編譯步驟。
我們一直在爲 Revm 開發 JIT/AOT 編譯器，目前正在與 Reth 集成。完成基準測試後，我們將在未來幾周內將其開源。平均大約 50% 的執行時間花在 EVM 解釋器上，因此這應該會提供大約 2 倍的 EVM 執行優化，盡管在一些計算量較大的情況下，它可能會產生更大的影響。未來幾周，我們將在 Reth 中分享我們自己的 JIT EVM 的基準測試和集成。
並行EVM
並行以太坊虛擬機（並行 EVM）的概念可以實現同步事務處理，這與 EVM 的傳統串行執行模型不同。我們有兩條實施道路：
- 歷史同步： 在歷史同步中，我們可以通過分析過去的事務並識別所有歷史狀態衝突來計算最佳的並行化調度。請參閱我們在Github對舊分支中早期嘗試。
- 實時同步： 對於實時同步，我們可以使用類似於區塊STM推測執行的技術，無需任何附加信息（如訪問列表）。該算法在狀態競爭嚴重時性能較差，因此我們希望根據工作負載的形狀探索串行和並行執行之間的切換，以及靜態預測將訪問哪些存儲槽以提高並行性的質量。查看此處由第 3 方團隊提供的一個 PoC。
根據我們的歷史分析，約 80% 的以太坊存儲插槽是獨立訪問的，這意味着並行性可以使 EVM 執行速度提高高達5倍。
優化狀態承諾
我們最近寫了關於狀態根對性能的影響以及 Reth 數據庫模型與其他客戶端之間的差異，以及它的重要性。
在Reth模型中，計算狀態根是與執行交易不同的過程（查看我們的代碼），允許使用標準 KV 存儲，而無需了解有關 trie 的任何信息。目前，這需要>75%的端到端時間來密封一個區塊，並且是一個非常令人期待的優化領域。
我們確定了以下 2 個“易於完成的任務”，它們可以使我們的狀態根性能提高 2-3 倍，而無需更改任何協議：
- 完全並行化狀態根： 目前，我們僅並行重新計算已更改帳戶的存儲樹，但我們可以更進一步，在存儲根作業在後臺完成時並行計算帳戶樹。
- 管道狀態根： 通過通知狀態根服務有關所觸及的存儲插槽和帳戶的信息，在執行期間從磁盤預取中間 trie 節點。
除此之外，我們還看到了一些與以太坊 L1 狀態根行爲不同的前進路徑：
- 更低頻的狀態根： 不是在每個塊上計算狀態根，而是每 T 個塊計算一次。這減少了整個系統中狀態根所花費的總時間百分比，並且可能是最簡單且最有效的解決方案。
- 尾隨狀態根： 不必在同一塊計算狀態根，而是讓它落後幾個塊。這允許執行繼續進行而不會阻塞狀態根計算。
- 替換 RLP 編碼器和 Keccak256： 與使用 RLP 編碼不同，直接連接字節並使用更快的哈希函數（如 Blake3）可能會更便宜。
- 更寬的Trie： 增加樹的 N-arity 子節點，以減少由於 trie 的 logN 深度而導致的 IO 增大。
這裏有幾個問題：
- 上述變化對輕客戶端、L2、橋、協處理器和其他依賴頻繁帳戶和存儲證明的協議的次級影響是什麼？
- 我們能否同時優化 SNARK 證明和原聲執行速度的狀態承諾？
- 利用我們現有的工具，我們可以獲得的最寬的狀態承諾是什麼？見證人規模有哪些次級效應？
Reth的橫向擴展路線圖
我們將在 2024 年全年執行上述多項要點，並實現 1gigagas/秒的目標。
然而，縱向擴展最終會遇到物理和實際的限制。沒有任何一臺機器能夠滿足全世界的計算需求。我們認爲這裏有兩條路可以讓我們隨着更多負載的到來而引入更多的“盒子”來進行擴展：
多Rollup Reth
如今的 L2 堆棧需要運行多個服務來遵循該鏈：L1 CL、L1 EL、L1 -> L2 派生函數（可能與 L2 EL 捆綁在一起）和 L2 EL。雖然這非常適合模塊化，但在運行多個節點堆棧時這會變得復雜。想象一下必須運行 100 次匯總會怎樣！
我們希望允許在與 Reth 相同的流程中啓動匯總，並將運行數千個匯總的運營成本降低到幾乎爲零。
我們已經與我們執行擴展項目 ([1],[2]）一起着手進行這項工作，未來幾周將有更多內容。
雲原生Reth
高性能排序器可能對單個鏈有足夠的需求，需要擴展到單個機器之外。這在當今的整體節點實現中是不可能的。
我們希望允許運行雲原生 Reth 節點，將其部署爲服務堆棧，可以根據計算需求自動擴展，並使用看似無限的雲對象存儲來實現持久性。這是 NeonDB、CockroachDB 或 Amazon Aurora 等無服務器數據庫項目中的常見架構。
早起我們團隊分享了關於解決這些問題的想法。
展望未來
我們打算逐步向所有 Reth 用戶推出此路線圖。我們的使命是讓每個人都能享受 1 gigagas/s 及以上的訪問速度。我們將在 Reth AlphaNet 上測試我們的優化，我們希望人們使用 Reth 作爲 SDK 來構建優化後的高性能節點。
有些問題我們還沒有找到答案。
- Reth 如何幫助提高整個 L2 生態系統的性能？
- 當我們的一些優化可能適用於平均情況時，我們如何適當地衡量最壞的情況？
- 我們如何應對 L1 和 L2 之間潛在的分歧狀況？
對其中許多問題，我們都沒有答案，但我們有足夠多的有希望的線索，這能讓我們探索一段時間，並希望在未來幾個月看到這些努力能取得成果。
聲明：
- 本文轉載自[paradigm]，著作權歸屬原作者[Georgios Konstantopoulos]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。
Compartir
Artículos relacionados
什麼是穩定幣 USDT？
Reth 如何實現每秒 1 GB Gas 量，甚至更高？
內容
我們於 2022 年開始構建 Reth，爲以太坊 L1 提供復原能力，並解決 L2 上的執行層擴展問題。
今天，我們很高興與大家分享 Reth 在 2024 年如何實現 L2 每秒 1 GB Gas，以及我們超越這一目標的長期路線圖。
我們邀請生態系統與我們合作，推動加密領域的性能和嚴格基準測試的前沿發展。
我們已經實現規模化擴展了嗎？
加密貨幣要達到全球規模並避免投機成爲主要用例，有一條非常簡單的途徑，即讓交易變得便宜且快速。
如何衡量性能？每秒Gas量是指什麼？
性能通常通過“每秒事務數”(TPS) 指標來衡量。特別是對於以太坊和其他 EVM 區塊鏈來說，更細致、或許更準確的衡量標準是“每秒的 Gas 量”。該指標反映了網路每秒可以處理的計算工作量，其中“gas”是衡量執行交易或智能合約等操作所需的計算工作量的單位。
將每秒Gas量作爲性能指標進行標準化可以讓我們更清楚地了解區塊鏈的容量和效率。它還有助於評估對系統的成本影響，防止可能利用不太細致的測量的潛在拒絕服務 (DOS) 攻擊。該指標有助於比較不同以太坊虛擬機（EVM）兼容鏈的性能。
我們建議 EVM 社區採用每秒 Gas 作爲標準指標，同時納入Gas定價的其他方面，制定綜合性能標準。
我們如今處於哪個發展階段？
每秒的 Gas 量是通過將每個區塊的目標 Gas 使用量除以區塊時間來確定的。在這裏，我們展示了各種 EVM 鏈 L1 和 L2 的當前每秒 Gas 吞吐量和延遲（並非詳盡無遺）：
我們強調每秒 Gas 來全面評估 EVM 網路性能，捕獲計算和存儲成本。 Solana、Sui 或 Aptos 等網路由於其獨特的成本模型而未包括在內。我們鼓勵努力協調所有區塊鏈網路的成本模型，以實現全面和公平的比較。
我們正在開發一個用於 Reth 復制真實工作負載的連續基準測試套件，如果您想就此進行合作，請聯系我們。我們需要一個用於節點的TPC 基準。
Reth 如何達到每秒 1 GB Gas？甚至更高？
2022年，我們構建 Reth 的部分出於迫切需要專門爲網路規模的匯總構建客戶端的原因。我們認爲我們的前進道路充滿希望。
Reth 在實時同步期間已達到 100-200mgas/s（包括發送方恢復、執行交易以及計算每個塊上的 trie）；所以，需要再擴展 10 倍才能實現我們每秒 1GB gas 的短期目標。
隨着我們推進 Reth 的開發，我們的擴展計劃必須在可擴展性與效率之間取得平衡：
- 縱向擴展： 我們的目標是最大限度地利用每個“盒子”的全部潛力。通過優化每個系統處理交易和數據的方式，我們可以大大提高整體性能，同時也使單個節點運營商更加高效。
- 橫向擴展： 盡管進行了優化，但網路規模的交易量仍然超出了任何單個服務器的處理能力。爲了解決這個問題，我們希望實現一個橫向擴展的架構，類似於區塊鏈節點的 Kubernetes 模型。這意味着將工作負載分散到多個系統上，以確保沒有單個節點成爲瓶頸。
我們在這裏探索的優化不涉及解決狀態增長，我們正在單獨研究這一點。
以下是我們打算如何實現這一目標的總體計劃：
在整個堆棧中，我們還使用參與者模型針對 IO 和 CPU 進行優化，以允許將堆棧的每個部分部署爲服務，並對其利用率進行精細控制。最後，我們正在積極評估替代數據庫，但尚未確定候選數據庫。
Reth的縱向擴展路線圖
我們的目標是最大限度地提高運行 Reth 的單個服務器或筆記本電腦的性能和效率。
即時（Just-In-Time）EVM 和提前（Ahead-of-Time）EVM
在以太坊虛擬機（EVM）等區塊鏈環境中，字節碼執行通過解釋器進行，解釋器順序處理指令。此方法會帶來開銷，因爲它不直接執行本機匯編指令，而是通過 VM 層進行操作。
即時（JIT）編譯通過在執行之前將字節碼轉換爲本機機器代碼來解決這個問題，從而繞過了虛擬機的解釋過程，提高了性能。這種技術提前將合約編譯成優化的機器代碼，在 Java 和 WebAssembly 等其他虛擬機中得到了廣泛應用。
然而，JIT 可能容易受到旨在利用 JIT 進程的惡意代碼的攻擊，或者可能在執行過程中速度太慢而無法實時運行。Reth 將提前（AOT）編譯需求最高的合約並將其存儲在磁盤上，以避免不受信任的字節碼試圖在實時執行期間濫用我們的本機代碼編譯步驟。
我們一直在爲 Revm 開發 JIT/AOT 編譯器，目前正在與 Reth 集成。完成基準測試後，我們將在未來幾周內將其開源。平均大約 50% 的執行時間花在 EVM 解釋器上，因此這應該會提供大約 2 倍的 EVM 執行優化，盡管在一些計算量較大的情況下，它可能會產生更大的影響。未來幾周，我們將在 Reth 中分享我們自己的 JIT EVM 的基準測試和集成。
並行EVM
並行以太坊虛擬機（並行 EVM）的概念可以實現同步事務處理，這與 EVM 的傳統串行執行模型不同。我們有兩條實施道路：
- 歷史同步： 在歷史同步中，我們可以通過分析過去的事務並識別所有歷史狀態衝突來計算最佳的並行化調度。請參閱我們在Github對舊分支中早期嘗試。
- 實時同步： 對於實時同步，我們可以使用類似於區塊STM推測執行的技術，無需任何附加信息（如訪問列表）。該算法在狀態競爭嚴重時性能較差，因此我們希望根據工作負載的形狀探索串行和並行執行之間的切換，以及靜態預測將訪問哪些存儲槽以提高並行性的質量。查看此處由第 3 方團隊提供的一個 PoC。
根據我們的歷史分析，約 80% 的以太坊存儲插槽是獨立訪問的，這意味着並行性可以使 EVM 執行速度提高高達5倍。
優化狀態承諾
我們最近寫了關於狀態根對性能的影響以及 Reth 數據庫模型與其他客戶端之間的差異，以及它的重要性。
在Reth模型中，計算狀態根是與執行交易不同的過程（查看我們的代碼），允許使用標準 KV 存儲，而無需了解有關 trie 的任何信息。目前，這需要>75%的端到端時間來密封一個區塊，並且是一個非常令人期待的優化領域。
我們確定了以下 2 個“易於完成的任務”，它們可以使我們的狀態根性能提高 2-3 倍，而無需更改任何協議：
- 完全並行化狀態根： 目前，我們僅並行重新計算已更改帳戶的存儲樹，但我們可以更進一步，在存儲根作業在後臺完成時並行計算帳戶樹。
- 管道狀態根： 通過通知狀態根服務有關所觸及的存儲插槽和帳戶的信息，在執行期間從磁盤預取中間 trie 節點。
除此之外，我們還看到了一些與以太坊 L1 狀態根行爲不同的前進路徑：
- 更低頻的狀態根： 不是在每個塊上計算狀態根，而是每 T 個塊計算一次。這減少了整個系統中狀態根所花費的總時間百分比，並且可能是最簡單且最有效的解決方案。
- 尾隨狀態根： 不必在同一塊計算狀態根，而是讓它落後幾個塊。這允許執行繼續進行而不會阻塞狀態根計算。
- 替換 RLP 編碼器和 Keccak256： 與使用 RLP 編碼不同，直接連接字節並使用更快的哈希函數（如 Blake3）可能會更便宜。
- 更寬的Trie： 增加樹的 N-arity 子節點，以減少由於 trie 的 logN 深度而導致的 IO 增大。
這裏有幾個問題：
- 上述變化對輕客戶端、L2、橋、協處理器和其他依賴頻繁帳戶和存儲證明的協議的次級影響是什麼？
- 我們能否同時優化 SNARK 證明和原聲執行速度的狀態承諾？
- 利用我們現有的工具，我們可以獲得的最寬的狀態承諾是什麼？見證人規模有哪些次級效應？
Reth的橫向擴展路線圖
我們將在 2024 年全年執行上述多項要點，並實現 1gigagas/秒的目標。
然而，縱向擴展最終會遇到物理和實際的限制。沒有任何一臺機器能夠滿足全世界的計算需求。我們認爲這裏有兩條路可以讓我們隨着更多負載的到來而引入更多的“盒子”來進行擴展：
多Rollup Reth
如今的 L2 堆棧需要運行多個服務來遵循該鏈：L1 CL、L1 EL、L1 -> L2 派生函數（可能與 L2 EL 捆綁在一起）和 L2 EL。雖然這非常適合模塊化，但在運行多個節點堆棧時這會變得復雜。想象一下必須運行 100 次匯總會怎樣！
我們希望允許在與 Reth 相同的流程中啓動匯總，並將運行數千個匯總的運營成本降低到幾乎爲零。
我們已經與我們執行擴展項目 ([1],[2]）一起着手進行這項工作，未來幾周將有更多內容。
雲原生Reth
高性能排序器可能對單個鏈有足夠的需求，需要擴展到單個機器之外。這在當今的整體節點實現中是不可能的。
我們希望允許運行雲原生 Reth 節點，將其部署爲服務堆棧，可以根據計算需求自動擴展，並使用看似無限的雲對象存儲來實現持久性。這是 NeonDB、CockroachDB 或 Amazon Aurora 等無服務器數據庫項目中的常見架構。
早起我們團隊分享了關於解決這些問題的想法。
展望未來
我們打算逐步向所有 Reth 用戶推出此路線圖。我們的使命是讓每個人都能享受 1 gigagas/s 及以上的訪問速度。我們將在 Reth AlphaNet 上測試我們的優化，我們希望人們使用 Reth 作爲 SDK 來構建優化後的高性能節點。
有些問題我們還沒有找到答案。
- Reth 如何幫助提高整個 L2 生態系統的性能？
- 當我們的一些優化可能適用於平均情況時，我們如何適當地衡量最壞的情況？
- 我們如何應對 L1 和 L2 之間潛在的分歧狀況？
對其中許多問題，我們都沒有答案，但我們有足夠多的有希望的線索，這能讓我們探索一段時間，並希望在未來幾個月看到這些努力能取得成果。
聲明：
- 本文轉載自[paradigm]，著作權歸屬原作者[Georgios Konstantopoulos]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。
Artículos relacionados