擴容未來：multi-Rollup 系統設計構想

作者：AndreasTzionis；來源：ethresear.ch；編譯：Yvonne，MarsBit

長期以來，我一直有這樣一個想法，即通過多Rollup（multi-Rollup）設計來解決當前Rollup所面臨的一些問題。在大約一年半的時間裏，我認爲有人會構建它，但從未真正深入研究或考慮過這樣一個系統的細節。

現在已經過去一段時間了，似乎沒有一個設計可以解決我在本篇文章中描述的問題，所以，我將盡可能地填充這個系統的細節，希望有人能從中獲得靈感，甚至從現有的 Rollup 中借用一些想法。

介紹

今天，Rollup面臨的問題之一是用戶體驗。在許多設計中，Rollup是具有不同特徵的獨立生態系統。有一些方法可以互操作，但將多個異構系統連接起來是一個相當大的挑战。此外，吸引用戶注冊所有這些Rollup是困難的。他們必須分別了解每個Rollup，評估相關的智能合約，將他們的錢包連接到新的RPC端點，將資產橋接到鏈上等。

如果有一種Rollup設計可以爲所有Rollup提供統一的體驗，那會怎么樣？它會是什么樣子？

我一直在問自己這個問題，並得到了以下五個觀點：

它應該提供一個統一的 RPC ，以查詢和調用不同跨Rollup的智能合約。智能合約應該有一個唯一的地址，不依賴於它們所屬的Rollup。

它應該允許根據需求擴大和縮小規模。更多的交易應該意味着更多的Rollup來處理它們，並且應該平衡Rollup之間的不均勻負載。

它應該激勵不同Rollup中的排序器保持在线。系統應該鼓勵其他排序器取代離线排序器。

它應該支持即時的跨鏈轉账。交易應該結算得足夠快，這樣跨鏈操作才有意義。

它應該在多個合並中保持輕客戶端和區塊瀏覽器的功能。區塊瀏覽器應該提供一個統一的區塊鏈視圖，輕量級客戶端應該允許低成本地驗證。

考慮到所有這些，我提出了一個設計，包括一個Rollup hub和一個可變數量的子Rollup。Rollup hub既是所有子Rollup的注冊中心又是負載均衡器，但不做任何智能合約處理。智能合約在子Rollup中處理。

在接下來的部分中，我將通過一個草稿設計來解釋我上面提到的5個考慮因素。

設計概述

系統有兩個主要組件：Rollup hub和子Rollup。Rollup hub 系統有兩個主要組件：Rollup hub和子Rollup。Rollup hub是一個Rollup，包含所有子Rollup的所有智能合約注冊表，並決定哪個Rollup負責哪個智能合約。此外，Rollup hub包含另一個子Rollup的所有排序器的注冊表。子鏈負責執行Rollup hub在智能合約注冊表中分配給它們的智能合約的交易。排序器注冊表包含每個排序器系統有兩個主要組件：Rollup hub和子Rollup。Rollup hub是一個Rollup，包含所有子Rollup的所有智能合約注冊表，並決定哪個Rollup負責哪個智能合約。此外，Rollup hub包含另一個子Rollup的所有排序器的注冊表。子鏈負責執行Rollup hub在智能合約注冊表中分配給它們的智能合約的交易。排序器注冊表包含每個排序器RPC端點和DA地址。

排序器注冊表（Sequencers registry）

排序器注冊表充當全局智能合約地址到智能合約地址的映射。這用於將 RPC 調用路由到與查詢或更新的智能合約相對應的特定排序器 RPC。

智能合約注冊表

智能合約注冊表充當了從全局智能合約地址到智能合約地址的映射。

Rollup鏈

子鏈通常有一個狀態根，此狀態路由可以通過直接調用智能合約來更新，也可以在Rollup hub將智能合約分配給另一個Rollup時更新，在這種情況下，應該刪除該智能合約，並將其添加到其他智能合約中。

統一RPC

目標：不必爲每個Rollup連接到一個新的鏈，並對用戶透明地進行跨Rollup交易。

統一的 RPC 在多Rollup網絡中恢復了單個鏈的用戶體驗，用戶不必連接到不同的網絡來使用不同的Rollup。

系統使用來自Rollup hub的Rollup排序器的注冊表來查找與特定智能合約對應的排序器的RPC端點。然後將請求直接提交給該排序器。通過向不同的Rollup提交請求，可以完成多個交易。查看以下部分以獲取更多細節。

如何工作

Rollup hub爲所有子鏈保存一個排序器的注冊表。

當用戶想要提交一個新的交易時，用戶錢包會查詢智能合約注冊中心來獲取該智能合約的RollupID，並查詢排序器注冊中心來獲取同一Rollup中的排序器的RPC端點。

然後將交易提交到排序器的 RPC 端點。

負載均衡

目標：平衡所有Rollup的費用

負載均衡允許在Rollup中平衡負載。當系統堵塞時，可以生成新的Rollup來處理負載。當沒有太多使用時，可以刪除Rollup來節省資源。此外，系統可以通過將交易中需求高的智能合約移動到具有更多可用容量的Rollup來避免費用飆升。

如何工作

每個epoch，Rollup hub都會評估系統中所有Rollup的負載。epoch應該持續幾個小時(可能爲6到24小時)，以避免大規模的智能合約重新分配。

Rollup hub可以決定重新分配哪些智能合約，以及何時生成或刪除Rollup，可以使用治理或使用不同智能合約的Gas消耗歷史來自主決定。

Rollup hub檢查是否有任何Rollup的交易負載高於平均值(即費用很高)或低於平均值(即費用很低)。

如果一個Rollup的負載高於平均值，Rollup hub會評估哪些智能合約消耗了最多的gas，並將其重新分配到一個能夠承擔額外負載的不同的Rollup。然後，智能合約將從其初始主機Rollup狀態中刪除。

如果所有Rollup的平均負載高於平均值，Rollup hub將創建一個新的Rollup，並向新Rollup分配一些智能合約。 類似地，如果所有Rollup的平均負載低於平均值，Rollup hub將刪除一個Rollup，並將其智能合約重新分配給其他Rollup。

Rollup鏈應該在每個時期查看Rollup hub，下載任何分配給它們的新智能合約的存儲，並刪除任何不再由它們負責的智能合約。

注意：下載一些智能合約的存儲可能不是一件小事。首先，狀態在DA層不可用，並且大小相當大。這限制了最小的epoch時間，需要一個寬限期來准備智能合約存儲。

排序激勵

目標：使用原生代幣中的部分獎勵激勵備用排序器。

今天大多數Rollup都是建立在單鏈上，只有一個或很少幾個排序器來管理，目標是最大化Rollup的正常運行時間。相比之下，在多Rollup系統中，有多個獨立的子Rollup，每個都必須在线才能在整個系統中保持活性。

排序器自然會受到激勵加入Rollup以收集MEV，但最好爲這些排序器提供適當的獎勵，因爲它們更一致，不會像MEV那樣錯位激勵。這些獎勵應該來自Rollup hub貨幣政策。

此外，最好有幾個排序器處於待命狀態，並准備進入，這些排序器可以在交易需求增加時加入系統，並在沒有計算資源時離开系統。

備用排序器將留在排序器隊列中，並獲得少量的可用性承諾獎勵。當它們在Rollup中被交換時，它們將獲得全部獎勵。獎勵將來自Rollup hub的費用燃燒機制。

如何使用

排序器可以通過提交一個財務債券(類似於當前的Rollup系統)加入Rollup hub的排序器隊列。

隊列中的排序器需要提供 DA 證明，表明它們具有Rollup集线器狀態，並且可以隨時讀取以加入Rollup。

當他們提交證據時，他們將獲得部分獎勵，即系統本地代幣。該代幣是Rollup樞紐上的句柄。

如果Rollup hub決定需要一個新的Rollup，他們將被分配並獲得全部獎勵。該獎勵由系統中消耗的總費用數量決定。

跨Rollup交易

目標：對用戶來說，Rollup交易應該是即時和透明的。

在Rollup A和Rollup B之間的跨 Rollup交易需要有2個部分：1)Rollup A上的交易2)Rollup B上的交易，只有當Rollup A上的交易成功且是final時才會發生。

爲快速確認，用戶錢包可以檢查交易是否提交到底層的DA層，並使用ZK證明是有效的。如果交易被包含並且有效，那么排序器必須對該特定交易得出相同的結論。

這一想法歸功於Mustafa Al-Bassam和Sovereign Labs。

如何使用

一個用戶提交了一個包含三個Rollup的交易，比如RollupA、B和C。

讓我們思考一個具體的例子，Rollup A有一個穩定幣智能合約，Rollup B有一個DEX，Rollup C有一個借貸協議，在這個例子中，用戶想將其穩定幣兌換爲不同的代幣，並其存入借貸協議。

用戶必須首先提交Rollup A交易，將穩定幣轉移到Rollup B上的DEX。

隨後，他們可以提交Rollup B DEX交易，該交易將穩定幣兌換爲Rollup B上所需的代幣。

繼而，該代幣應該被轉移到RollupC，因此用戶提交了第三個交易，正是這樣做的。

最後，用戶提交第4個也是最後一個交易，將代幣存入借貸協議。

輕節點和區塊瀏覽器

目標：輕節點應該能夠跨Rollup驗證智能合約，區塊瀏覽器應該提供鏈的統一視圖。

區塊鏈系統應該允許任何人運行節點並驗證鏈本身。在這種多Rollup設計中，智能合約不斷被重新分配到不同的子Rollup，應該有一種方法來跟蹤這些特定的智能合約。這是從驗證一個或多個鏈到驗證一個或多個智能合約的思維轉變。輕節點可以利用ZK證明來低成本地驗證所有子Rollup。

如何工作(輕客戶端）

Rollup節點應該支持一個驗證模式，沿着排序器模式。

驗證模式驗證單個智能合約的狀態，不像排序器模式那樣向DA層提交交易批次。

如果智能合約更改了子集群，驗證節點只需更新他們監聽的子集群，因爲他們已經擁有了智能合約存儲，直到重新分配之前。

智能合約應該一次在一個Rollup中處理。由於它們被限制在一個Rollup中，具有相同規格的驗證節點應該能夠跟蹤和驗證它們。

輕節點可以用ZK證明低成本地驗證鏈的狀態。

區塊瀏覽器是區塊鏈系統不可或缺的一部分。它們促進原生資產的余額查詢、智能合約查詢，並維護從第一個區塊到當前區塊的交易歷史。在這個多Rollup系統中，區塊瀏覽器應該提供所有子Rollup的統一視圖。

如何工作（區塊瀏覽器）

區塊瀏覽器應該支持查詢Rollup hub的余額(針對原生資產)和所有子Rollup的交易歷史。

與單一Rollup系統類似，區塊瀏覽器使用索引來實現這一點。多Rollup系統必須對所有Rollup進行索引，以便爲系統中的任何智能合約提供查詢服務。

如果Rollup hub決定擴大子Rollup的數量，區塊探索器應該准備好處理它。它們應該提供更多的子Rollup容量，或者有一個容器編排系統(例如Kubernetes)來自動擴大子Rollup。

它們應該使用來自 DA 層的區塊號，以便在所有Rollup之間保持一致性。

結論

目前上述設計只是一個想法，我可能永遠不會進一步實現它，但是我希望該設想使你感興趣。如果設計通過，我期待它可以用於Rollup項目，並接近EIP-4844、Celestia或Avail的擴容能力。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

標題：擴容未來：multi-Rollup 系統設計構想

地址：https://www.torrentbusiness.com/article/63200.html

標籤：