原文標題：《RFC: Deep dive into snap sync for rollups》

原文作者：George Spasov，LimeChain 區塊鏈架構師兼共同創辦人

原文編譯：Sharon ，BlockBeats

編按：隨著Rollup 不斷增多，問題也隨之顯現。將 Rollup 進行 Snap Sync（快照同步），可以使節點能夠從系統的其他參與者獲取預處理資訊來進行同步，同時自身也可以適當地驗證它。這也是一種「減輕基礎設施提供者的中心化向量」的方式。

概述

以下的各種想法和概念的探索，與對改善Rollup 節點時間來最初將其狀態同步到匯總的最新Rollup 的時間有關。在下文中，這個改進的過程可以被稱為 Rollup 的“Snap Sync”，這是從類似命名 L1 的過程中汲取的靈感。本文檔概述了 Snap Sync 如何用於 Rollup 的整體思路，並深入探討了各種 Rollup 參與者的角色和需求。

Rollup 節點的 Snap Sync 是一個重要的概念，因為 rollup 有望實現比 L1 高出幾個數量級的吞吐量。

雖然Rollup 承諾任何觀察資料可用性層的人，都將擁有所有資料來重新執行和同步Rollup，但實際上這將很快變得十分緩慢。這種緩慢的情況可能會導致透過將資料整合到少數專門持續同步 L1 的實體中來實現集中化。

Snap Sync 的目的是使節點能夠透過從系統的其他參與者獲取預處理資訊來進行同步，但自己適當地驗證它。

概念化的觀點

以下是一個概念性的想法，包含4 個步驟，可用於Rollup 的Snap Sync。它概述了新的 Rollup 節點如何同步到 Rollup 的尖端。

1. 同步節點記錄來自Rollup 的L1 智能合約的最近（理想情況下不是最後一個）最終確定的區塊及其區塊哈希/狀態根。

2. 此節點連接到一個或多個對等點並下載指定的最終區塊的狀態。

3. 節點根據步驟 1 中 L1 記錄的區塊雜湊/狀態根驗證區塊雜湊/狀態根。

4. 節點繼續從 L1 同步後續的最終確定（如果適用）和虛擬狀態。

深度闡述

上面的概念看似簡單，但和往常一樣，細節決定成敗。當您開始考慮 Rollup 系統中各個參與者的目標和動機時，Snap Sync 的 Rollup 特定特性就會開始出現。以下是 Snap Sync 設計的幾個重要考慮因素，它們提供了更多輸入，以便提出更完整的概念解決方案。

跟隨者節點的作用

rollup 中的主要參與者是排序器和證明者（Optimistic Rollup 可以將其驗證者視為證明者）。

排序器的工作是（以某種方式）取得使用者事務並將其排序到 L1 中。他們透過發布 Rollup（理想情況下有效）序列的服務來獲得報酬。證明者獲取數據並產生給定序列有效性的證明。證明者因在 L1 中提交有效證明而獲得報酬。

最終，這兩位參與者都將因其具體行為而獲得獎勵。定序器透過對 L2 狀態修改事務進行排序而獲得報酬。

為了讓排序器完成其工作，它們只需要最近的虛擬狀態和某個版本的記憶體池（私有化或公共化）。他們根本不需要關心（讀取儲存）過去已驗證或未驗證的狀態。

證明者因提供證明而獲得報酬。他們只需要來自 L1 DA 層的序列資訊。他們也不需要關心（閱讀儲存）過去的狀態。

這給最終用戶留下了相當大的真空——沒有參與者的工作是為讀取當前或歷史狀態的 RPC 請求提供服務。雖然 Rollup 設計者通常將跟隨者節點視為排序器的「簡化」版本，但實際上，現在人們可以爭辯說，它們是一個完全獨立的參與者，具有單獨的目標——為網路使用者提供服務。

從 L1 節點推理，您應該請求狀態讀取的是您自己的「完整節點」。人們可以推斷，「你自己的完整節點」相當於「你自己的跟隨者節點」。跟隨者節點需要保存 Rollup 的部分或全部歷史狀態，以便能夠為（您的）歷史資料的 RPC 請求提供服務。

一些非常非常常見的歷史操作是－－「給我從合約X 發出的事件」，「給我我的交易哈希的交易收據」 。目前沒有其他演員需要服務其中任何一個。

跟隨者節點的型別與sync 型別

Sync 跟隨者節點的簡單方法是從L1 DA 層下載L2 序列並重新執行它們，直到趕上提示。如前所述，作為唯一的 Sync 模式，這很快就會變得不切實際地慢。

因此，這是一個可能但不充分的跟隨者節點版本。在下文中，我們將完全從 L1 DA 同步並儲存完整狀態的節點稱為歸檔跟隨節點。

可以推斷，多個用例需要節點的同步速度比歸檔跟隨者節點所能提供的速度快得多。這些都是實際需求，可以從 Rollup 的正常運作、其加密經濟學中觸發，或者純粹是為了快速抓住（MEV？）機會。此類節點可以連接到檔案跟隨者節點，並使用上面概述的「概念化觀點」來同步到 Rollup 的提示。

更深入地說，如果跟隨者節點僅從存檔跟隨者下載最新的驗證狀態並同步到前向（透過重新執行虛擬狀態），那麼它在很大程度上無法滿足我們要求跟隨者節點滿足的要求。他們將無法回答有關最後一個最終確定檢查點之前任何區塊的歷史狀態（最近或不是）的查詢。這概述了跟隨者節點需要從最後確定狀態之前的狀態進行同步。

從跟隨者節點運營商的角度來看，可以做出兩個單獨的決策。這些決策有點類似 L1 節點用於鏈同步的模式。

首先，跟隨者節點可能會選擇一個固定的歷史驗證序列（檢查點）作為起點並從那裡向前同步。就像快照同步模式下的 Geth 僅儲存最後 128 個區塊一樣，Snap 跟隨者節點可以從最後 X（例如 32）個驗證序列開始同步。

此外，它可以選擇在任何時候僅保留已驗證提示的最後一個 X（例如 32）的狀態。 Snap 跟隨者節點將能夠為匯總的最新狀態和區塊提供查詢服務。 X 參數需要仔細選擇，以確保大多數使用者的歷史資料需求和 Snap 跟隨者節點的儲存需求之間的適當平衡。

其次，跟隨者節點可能會選擇以與捕捉跟隨者節點類似的方式進行捕捉同步，但也保留多個/所有其他已驗證序列的狀態——檢查點。我們可以將該節點稱為完整跟隨者節點。需要注意的是，完整跟隨者節點不需要重新執行舊歷史檢查點之間的交易，而只為它們保存狀態。

這種機制允許完整的跟隨者節點為較舊的 Rollup 狀態的請求提供服務。全 跟隨者節點可以看到請求的區塊信息，計算之前同步和驗證的檢查點，並且只重新執行下一個序列的交易，直到所需的區塊。

這種方法不像歸檔節點那樣佔用儲存空間，但由於需要下載和重新執行數據，因此對查詢的回應也不那麼有效率且快速。

所有三種類型的跟隨者節點都有自己特定的權衡集，並且對於使用者的各種用例都是最佳的。

排序器和證明器也需要跟隨者節點

如上所述，定序器和證明器有自己的狀態資料需求。與使用者類似，他們需要以某種方式同步到 Rollup 中所需的點。從本質上講，這意味著排序器和證明器需要一種機制來快速同步到最新的最終狀態並從那裡繼續。諷刺的是，這實際上意味著他們需要某種形式的跟隨者節點才能快速同步。 （現在是誰被簡化了排序器？）

想要進行Snap Sync 並開始排序的定序器和證明器都可以連接到跟隨者節點，下載最新的最終狀態，對其進行驗證並繼續同步虛擬狀態。

進一步的研究途徑

深入研究 Snap Sync 機制，會出現一些實際問題。這些都需要考慮並需要進一步的研究和構思。

序列化狀態機制

在上面的文字中，我們將檢查點資料傳輸的複雜性隱藏在「連線和下載狀態」後面。然而，在幕後，這意味著需要有一個定義的協議，用於在任何給定檢查點對 Rollup 狀態進行序列化、分區和傳輸。

下載狀態的機制

雖然任何尋求Snap Sync 的節點都可以連接到“一個”跟隨者，但這會帶來活性和可用性問題。以類似「torrent」的方式從多個追蹤者並行同步可以透過並行化加速 Snap Sync 流程，並能夠進一步驗證和驗證下載的資料。

結論

Snap Sync 對於減輕基礎設施供應商的中心化向量至關重要。雖然從表面上看，snap sync 的過程有些簡單，但當考慮到網路中不同參與者的各種激勵、角色和需求時，就會出現一些有趣的細微差別。

同步過程展示了跟隨者節點（通常被誤解的）角色對於 Rollup 生態系統來說是特殊且重要的，並且需要仔細設計。深入研究跟隨者節點，根據操作者的需求，出現了各種跟隨者節點的同步模式。

最後但並非最不重要的一點是，上面的分析展示了跟隨者節點對於rollup 的其他參與者（排序者和證明者）的重要性。這使得跟隨者節點對於整個系統的穩健性非常重要。

歡迎對上述分析提出任何意見。歡迎對「進一步研究途徑」提出任何想法、建議和/或貢獻。

原文連結

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia