Rollup排序器完全指南：概念、現狀與共享排序

原文編譯：0x11 ，Foresight News

原文編譯：0x11 ，Foresight News

原文編譯：0x11 ，Foresight News

原文編譯：0x11 ，Foresight News

共享排序器正在飛速發展，是時候對它是什麼及其存在的原因進行深入分析了。這篇文章分析的對象僅限於Optimistic Rollup，歡迎ZK 關注者前來指教。

排序器是什麼？

排序器是Optimistic Rollup 中的半信任化角色。雖然交易可以由主鏈本身進行排序，但這並不經濟，用戶必須單獨提交其Rollup 交易對應的主鏈交易，並支付主鏈上費用。排序器通過允許Rollup 交易共享單個主鏈交易來為用戶解決這些問題。

排序器聚合鏈下的多筆用戶交易來補充主鏈的排序，並將它們作為單個交易集合提交到主鏈，交易成本在用戶間分攤。排序器還可以壓縮交易集合，進一步節省主鏈數據可用性成本。與依賴排序器的用戶相比，自主排序的用戶將為包含在Rollup 中的交易支付更多費用。但是，排序器可以對交易集合中的交易排序進行控制。它可以選擇不包含用戶交易，從而迫使用戶自行排序，支付更高的主鏈成本。它還可以通過重新排序和插入提取的方法在交易集合中提取MEV。它們實際上擁有對Rollup 的優先寫入權限。值得注意的是，因為排序器可以與合約交互，所以只有絕對可靠的交易才能通過鏈上機制可靠地強制執行，不可靠的交易在強制排序時很可能會失敗。。

這使得排序器成為Rollup 用戶的半信任方。雖然排序器無法阻止用戶訪問Rollup，但他們可以延遲用戶的訪問，導致用戶承擔額外的費用，並從用戶的交易中提取價值。通過去中心化進一步約束排序器的行為是一個活躍的

研究課題

排序和執行有什麼區別？Fred排序器是主鏈排序的補充，它不計算Rollup 的狀態，實際上它可能會選擇對無效交易進行排序。 Rollup 節點必須解析和清理排序數據，導出Rollup 的有效歷史記錄，並執行歷史記錄以生成最新狀態。排序器則完全不參與此過程。

不過，正如我的朋友

不斷提醒我的那樣，一旦交易被排序，結果就是確定的。這意味著所有Rollup 節點將根據排序器生成的順序達成一致結果。給定已知歷史，Rollup 有一個正確的狀態。一旦節點找到這個狀態，一個或多個提議者會將其提交給主鏈的Rollup 合約。

理論上，任何節點都可以是提議者，不需要任何權限。提議者將狀態連同保證金一起提交給主鏈。如果欺詐證明結果是狀態無效，保證金就會被沒收。該合約在計時器結束後接受證明，然後其中包含的用戶交易在主鏈上執行。執行節點通過欺詐遊戲確保提議者誠實，我們傾向於將執行節點稱為「Rollup 全節點」或「驗證者」。

換句話說，一旦排序被提交到主鏈，狀態就變成最終的和不可變的。提議者計算並報告最終狀態給Rollup 合約，以維護Rollup 到主鏈的資產橋的利益。提議者不會創造狀態，他們只是計算並證明它。 Rollup 合約不會創建或最終確定Rollup，它只是從提議者那裡獲得Rollup 狀態。Barry為什麼要將排序和提議分離？

這是一個複雜的問題。從根本上說，將它們分開是因為它們本身是分開的。這聽起來像是同義反复，但似乎每個人都花了很長時間才意識到這一點。我們驀然回首，才發現Rollup 的思想歷史多年來一直在Plasma 和狀態通道中曲折發展。在基於比特幣的proto-Rollup 早期，並沒有排序器，用戶只需將他們的交易發佈到主鏈。之後，這種設計消失多年，最終因為

的工作重新出現。在Barry 和Celestia 之間，Rollup 的研究主要集中在Rollup 橋與主鏈的交互上。在Sovereign Rollup 出現之前，甚至沒有人意識到我們其實在構建更好的Mastercoin。

拋開出處不談，排序器解決了一個特定的問題：用戶交易成本最小化。然而，這個過程中又引入了一個新問題：排序器可以同時對同一交易產生多個排序結果。如果排序完全由主鏈完成，將會有一個單一的規範排序，但用戶交易費用會更昂貴。我們選擇使用排序器來改善Rollup 中的用戶體驗。

假設存在很多個排序器，因為有多個提議者。排序器們可以提交相互衝突的排序，我們現在需要一種機制來「規範」主鏈上的特定排序批次。當前的Rollup 通過一個單一的、特定的、已知的、半可信的排序器來實現這一點。選擇單個排序器使我們能夠解決這個問題，直到去中心化排序器到來。因為我們想要多個提議者，但只需要一個排序器，所以必須將這兩個角色分開。

數據依賴性是另一個重要的原因：提議者需要排序，但是排序器不需要狀態。提議者依賴於排序器工作的輸出，但是排序器不依賴於提議者。因為數據依賴是單向的，所以需要在角色之間劃定界限，並允許參與者專注於單一角色。

為了回答最初的問題，我們將提議者和排序器分開，因為它們本身是分開的。提議者在排序器的下游工作。 Rollup 將信任和權威授予了排序器，而提議者只是一個普通工作人員。

Arbitrum

排序器、提議者和驗證者現狀

Arbitrum 和Optimism 是兩種常見的ORU 方案。我想簡要介紹一下他們中的主要角色，不會涉及到代碼，只是規範和文檔。 Optimism 的討論將僅限於（尚未部署的）Bedrock 設計。

除了批處理和壓縮用戶交易外，Arbitrum 排序器還運行一個完整的節點。交易被直接發送到排序器，它在交易排序時創建一個可信的WebSocket 提要。 Arbitrum 將此提要作為「軟」確認來源。排序器對排序結果作出承諾，用戶通常可以依賴該排序。節點、MEV 搜索者或其他參與者可以使用此提要來預先計算Rollup 狀態。delayed inbox排序器會定期將經過排序的壓縮交易發佈到主鏈。主鏈最終確定代表Rollup 的「硬」確認。一旦主鏈確定了排序，它就成為Arbitrum 鏈上不可更改的部分，其中排序的所有交易都成為最終狀態，結果狀態也成為最終狀態。

自然地，因為排序器設置交易順序，所以它具有優先寫入權限。排序器可以控制排序的內容，從而控制Rollup 歷史中交易的排序。當然，用戶可以通過主鏈上的RBlock強制包含交易。搜索者已經竭盡全力將WebSocket 交易提要的延遲降到最低，因此他們很可能會形成一個強大的MEV 市場來對Arbitrum 交易進行排序。

有13 個經過許可的Arbitrum 提議者，他們中每一個都在名為「

Optimism

」的特定承諾中託管了ETH。用戶可以選擇依賴一定比例的質押來做出關於Rollup 的最終決定，而無需運行Rollup 完整節點。雖然Arbtirum 驗證者可以識別欺詐，但只有提議者可以通過欺詐證明質疑承諾的有效性。實際上，只有提議者可以成為完整的驗證者。

正義，就像一個排序器，是盲目的，它必須帶著劍

與Arbitrum 一樣，除了批處理和壓縮用戶交易外，Optimism 排序器也運行一個完整的節點。交易直接發送到排序器，排序器在排序時創建可信的預確認。 Optimism 用戶可以使用這些確認作為最終軟確認的來源。排序器對排序作出承諾，用戶通常可以依賴該排序。節點、MEV 搜索者或其他參與者可以使用這些確認來預先計算Rollup 狀態。

排序器會定期將經過排序的壓縮交易發佈到主鏈。主鏈最終確定代表Rollup 的「硬」確認。一旦主鏈確定了序列，它就成為Optimism 鏈歷史中不可更改的一部分。其中排序的所有交易都成為最終狀態，結果狀態也成為最終狀態。小結小結

小結

共享排序器

共享排序器

共享排序器

在對排序器有了新的理解後，讓我們繼續討論我真正想談的內容：共享排序器。當Rollup 共享同一個排序器時會發生什麼？

借用不同的Rollup 是什麼意思？借用

Ben 的定義

，我們應該將Rollup 視為狀態、狀態轉換函數和證明系統。 Rollup 有合約和賬戶，它有一個虛擬機來處理交易以更新這些合約和賬戶，而非主權Rollup 有一個證明系統來運行與主鏈的橋接。每個組件有多種設計，它們可以在一定程度上混合搭配。

但是，有些組件比其他組件更平等。總的來說，我們大概應該把狀態看作是鏈的本質。鏈不傾向於改變它們的狀態。畢竟，以太坊開發者多次更改虛擬機，多次更改共識機制，但只更改過一次狀態。狀態即是Rollup，虛擬機和證明系統的存在是為了支持它。因此，不同的Rollup 具有不同的狀態。它們可能共享一個證明系統或一個STF，但兩個Rollup 永遠不可能共享相同的狀態。

Rollup 使排序器能夠選擇提取函數下一次運行的輸出。排序器選擇Rollup 節點下一步將看到和處理的數據，因此對STF 的操作和下一個狀態有一定的控制。

共享排序器

共享排序器

共享排序器

共享排序器

共享排序器為兩個或多個Rollup 的提取函數提供輸入。因此，它為兩者設置新的歷史記錄，控制STF 的輸入。它可以單獨為每個Rollup 執行此操作，也可以同時為兩者執行此操作。單獨設置歷史記錄時，它的工作方式與未共享的排序器完全相同。

然而，當同時為兩個Rollup 創建新的歷史記錄時，共享排序器可以通過原子「鏈接」兩個Rollup 的歷史記錄來行使一些額外的權力。排序器同時為每個Rollup 生成序列，並確保兩者都確認或都不確認。這允許排序器對兩條鏈的歷史進行控制，因此對Rollup 的下一個狀態有一定程度的控制。

原子包含（不是原子執行）

在這一點上，我必須重申，排序器可以對其產生的排序行使很大的自由裁量權。這意味著雖然用戶可以使用共享排序器在多個Rollup 上進行交易，而無需與主鏈進行交互，但他們不一定依賴排序器在這些交易之間產生任何特定的關係。共享排序器的支持者設想了一種新結構，用戶可以在其中指定包含的原子性，即可以強制排序器通過共享強制排序機制同時對多個Rollup 中的一組交易進行排序。這將允許用戶確保所有這些原子交易都包含在Rollup 歷史中，或者全部不包含。

這並不像看起來那麼好。因為只有絕對可靠的交易才能強制排序，只有絕對可靠的交易集才能保證在原子包含時原子執行。正如我們之前所說，包含和執行是分開的。 Rollup 在包含之後和執行之前通過過濾器功能過濾掉無效交易。假設排序器獲取用戶的原子集，並導致一個交易失敗或失效。該交易將在排序後被過濾，並且不會執行。這意味著原子包含不足以保證原子執行，除非涉及的所有交易都是絕對可靠的。

具體而言，可以原子執行簡單的發送和取款，但任何容易出錯的東西，如交換或DeFi 交互，都不能。不幸的是，大多數高價值交互都包含1 個或多個容易出錯的交易，因此似乎很難使原子包含發揮作用。這有效地排除了通過共享排序器進行交叉Rollup 的DeFi 可組合性。共享排序器不是靈丹妙藥，用戶的資產可能被鎖定在異步跨鏈模型中，直到流程結束。

Rollup 組合的原子執行

還記得之前談到的排序器如何在將排序發佈到主鏈之前提供可信的執行保證嗎？您可以設想一個共享排序器針對多Rollup 系統做同樣的事情。共享排序器可以運行每個Rollup 的完整節點，並使用它們來確定交易是否成功。然後它可以承諾它不會產生原子交易集不全部成功的排序。

我在別處寫過這個，另一個可靠的選擇是在交易和Rollup 狀態之間集成顯式的偶然關係。這會將評估突發事件的負擔轉移到提議者身上，因為他們必鬚根據他們對遠程Rollup 的信任來計算和提議狀態根。但是，我認為我們可以通過重複應用過濾器功能來簡化它。假設偶然性在某個交易和區塊中是明確的，我們可以運行兩次過濾器，一次假設預測的狀態有效，一次假設預測的狀態無效。這可以擴展到n 個預測狀態，代價是對過濾器函數進行2 ^n 次評估.

結論

結論

結論