僅供教育參考，不構成財務、投資、交易最終性或安全建議。排序器行為、備援路徑和結算保障因網路而異，並可能在升級後改變。
直接答案
在許多 Rollup 中，排序器是接收交易、選擇交易順序並產生區塊或批次的元件或參與者。它可以在已排序的交易資料發布到底層網路之前，先向使用者提供快速確認。具體分工並不一致：區塊建構、執行和批次發布可能由同一營運方完成，也可能由不同服務分別完成。
錢包顯示成功，並不代表排序器就是最終結算來源。交易確認的保障強度取決於排序器是否只是公布了區塊、協議資料是否已經到達 L1，以及相關 L1 區塊與 Rollup 狀態聲明或證明是否達到所需的最終性狀態。
運作機制
- 接收。 使用者或應用程式向排序器端點提交已簽署交易，不過網路也可能定義透過 L1 提交的路徑。
- 排序。 排序器在協議有效性規則約束下選擇交易並決定順序。這項選擇會影響延遲、費用、審查和 MEV。
- 建構。 它把已排序交易組裝成 Rollup 區塊，並可能執行交易以計算結果狀態。
- 預確認。 排序器快速傳播區塊或收據。這是暫定的排序訊號，並不自動等同於 L1 最終確定的結果。
- 發布。 批次提交器或同等服務把協議規定的交易資料發布到資料可用性層，通常是 L1。獨立節點利用這些資料和協議規則派生出規範 Rollup 鏈。
- 結算。 狀態承諾、錯誤證明或有效性證明把執行結果連結到結算。這些機制檢查或確立狀態轉換的正確性，但本身不會讓交易排序去中心化。
範例
錢包最初把一筆交易顯示為「排序器已確認」。在此階段，營運方仍可能無法發布相應批次，或按該網路規則替換尚未發布的區塊。批次資料被納入 L1 後，獨立節點可以派生該交易在 Rollup 鏈中的位置，但 L1 重組仍可能影響它。只有滿足適用的 L1 與 Rollup 最終性條件後，應用程式才應為結果加上相應標籤。
這一過程描述的是狀態模型，而不是通用的時間承諾。待處理、不安全、安全和已最終確定等術語依協議而定；橋接提領在可執行前還可能有額外的證明或挑戰延遲。
風險
- 停機。 活躍排序器停止工作時，即使資金沒有遺失，直接提交和快速出塊也可能暫停。
- 審查。 營運方可能延遲或拒絕特定交易。強制納入或逃生路徑只有在已經部署、無需許可、可以使用且相關資料可用時才有效。
- 重排與 MEV。 在協議約束內，排序控制權可能被用於搶跑、尾隨交易或差別待遇。
- 暫定狀態回滾。 把排序器收據當成最終結果的應用程式，可能根據之後被替換或從未發布的區塊採取行動。
- 發布與底層故障。 壅塞、批次提交器故障、資料不可用或 L1 重組，都可能延遲或改變驗證者派生出的鏈。
- 營運集中。 即使證明能夠驗證執行，單一營運方、簽署金鑰、RPC 端點或升級權限仍會形成共同故障點和控制點。
常見誤解
- 排序器決定最終結算。 最終結算遵循 Rollup 合約、證明或挑戰規則、資料可用性和底層共識。
- 快速收據不可逆。 預確認可以有實用價值，但不具備與已發布且已最終確定的資料相同的保障。
- 強制納入保證立即執行。 備援路徑可能需要一筆 L1 交易、等待期、特定呼叫資料和正常運作的合約路徑。
- 有效性證明消除了排序器風險。 它可以證明執行正確，但排序仍可能中心化、可被審查或不可用。
- 去中心化排序消除了所有信任。 它可以分散排序權力，但也會引入自身的共識、活性、金鑰管理和互通性假設。
相關主題
來源
- 擴展以太坊 - Ethereum.org（查閱日期：2026-08-21）
- 派生規範 - OP Stack Specification（查閱日期：2026-08-21）
- 交易最終性 - Optimism Documentation（查閱日期：2026-08-21）
- Arbitrum Nitro：第二代樂觀 Rollup - Arbitrum Documentation（查閱日期：2026-08-21）