Unstoppable Sequencing 是與 Spire 合作開發的，充分利用了他們在 Blob 共享方面的專業知識。感謝@norswap 、 @donnoh 、 ETH 、 Ilia Shirobokov 、 Julie以及 Spire 團隊的反饋。
介紹
Rollup排序器擁有巨大的權力。它們決定哪些交易被打包、以什麼順序打包以及何時打包。它們是 Layer-2 的守門人。當這些守門人出現故障或審查用戶時會發生什麼？
通常，用戶依賴於“強制包含”，這是一種通過創建 L1 交易來創建 L2 交易的機制。然而，雖然強制包含保留了逃生艙口，但由於 L1 交易需要單獨提交而不是批量提交，因此不足以支持Rollup的持續運行。
解決方案：讓批量操作無需許可，且經濟實惠，任何人都可以接受。只要 Layer1 正常運行，即使出現故障或惡意排序器， Rollup也能保持接近正常的吞吐量。這就是“永不停歇的排序”。
為什麼強制包容如今會失敗
強制納入如何運作？
以OP Stack為例，流程如下：
用戶調用
OptimismPortal2合約上的depositTransaction函數並指定他們想要進行的 L2 交易的詳細信息。門戶合約發出一個事件，誠實的OP Stack 節點知道讀取該事件，將其轉換為實際的 EVM 交易，並在序列器關閉時插入到 L2 塊中。
關鍵在於，每個 L2 交易都需要一個對應的 L1 交易。即使在最簡單的情況下，這些 L1 交易也至少需要 10 萬個 Gas 單位。
現在考慮由Rollup排序器發佈的批量交易。批量處理功能使排序器能夠將數百或數千個 L2 交易合併到單個 L1 交易中。例如，在這筆 L1 交易中， Base 發佈了價值 384kb 的Rollup交易。一筆簡單的轉賬交易大約 100 字節，一筆 DEX 交換交易接近 1kb，這意味著批量處理帶來的容量增益至少是 100 比 1。
Base 為這 100 倍的容量提升支付了多少 L1 Gas？價格和單筆強制打包交易一樣，因為現在由於擁堵情況良好，blob 基本上可以免費發佈！
隨著Rollup需求的增長，blobspace 的價格無疑會上漲，但它總是比 calldata 或合約交互便宜得多，因為它是Rollup數據可用性的預期載體。
如果序列器發生故障怎麼辦？
當排序器離線時，強制打包成為唯一的選擇。沒有了批量打包帶來的效率提升，交易打包成本將成倍增加。用戶別無選擇，只能退出。
強制加入可能會導致大規模退出，但代價高昂。每位用戶必須：
- 為在 L2 上發起提現的強制交易支付 10 萬 L1 gas
- 再支付 200k+ L1 gas 來完成 L1。
成本會隨著用戶需要退出的資產數量以及發起提現所需的交易數量（例如，在提現之前先結清貸款）的增加而上升。最終，當所有人都試圖同時提現時，L1 Gas 成本將飆升。
假設每個用戶提取 L1 gas 需要 25 萬，用戶數量為 1000 萬，gas 激增定價為 100 gwei， ETH價格為 4000 美元，那麼我們退出的總成本為：
250k gas per user * 10M users * 100 gwei gas price / 1e18 * $4k ETH price = $1B USD
雖然成本巨大，但該模型仍然過於樂觀，因為它假設所有有價值的資產都可以退出到 L1。對於已在 L1 上表示的橋接資產來說，這或許是正確的，但對於在Rollup上原生髮行的資產，目前尚不清楚是否會圍繞“等價”的 L1 資產形成社會共識。
最後，一旦所有費用都支付完畢，所有用戶資產都安全地轉移到 Layer-1 上，接下來該怎麼辦？用戶無法繼續留在 Layer-1 上，成本太高了！這就是他們最初使用Rollup的原因。但是，在經歷了大規模退出造成的巨大價值損失之後，我們能指望他們重新存入另一個具有相同漏洞的Rollup嗎？
要點很明確：為了使以太坊Rollup生態系統能夠生存，rollup 必須通過使鏈能夠在沒有中心化測序儀的情況下運行來消除因測序儀故障而導致大規模退出的需要。
解決方案：實現Rollup經濟學民主化
為了使Rollup能夠在沒有集中式排序器的情況下運行，我們必須讓普通用戶能夠使用相同的經濟工具，從而使集中式排序本身變得可行。
排序器擁有三個關鍵優勢，可以實現Rollup經濟學：
批處理：將多個 L2 交易合併為單個 L1 提交。這是 rollups 的根本效率提升。
Blob 訪問：使用 Blob 存儲代替合約事件發送。Blob 專為Rollup數據可用性而設計，並將始終是以太坊最高效的 DA 載體。然而，如果 calldata 更便宜，用戶應該可以選擇使用它，就像現在的Rollup序列器一樣。
規模經濟：根據以太坊協議規則，blob 的購買是“全有或全無”的——你不能只購買 10KB 的 blob 空間。中心化排序器需要積累足夠的交易才能高效地使用 blob。而個人用戶則無法做到這一點，因此我們需要一種排序方法，讓用戶能夠共享 blob，從而避免為未使用的空間付費。
推出 Unstoppable Sequencing
不可阻擋的排序是一種分散式批處理的框架，當主排序器出現故障時，需要保留Rollup容量和審查阻力。
術語
- Sequencer ：構建批量有序 L2 交易的實體。
- 批處理器 (Batcher) ：將已構建的 L2 交易批次發佈到 L1 的實體。排序器 (sequencer) 和批處理器可以是同一個實體，但預期的安排是讓批處理器成為處理 blob 共享的專門角色。
- Rollup節點：使用 L1 歷史記錄確定性地得出Rollup狀態的軟件。“確定性”是指所有誠實的Rollup節點在給定相同的 L1 歷史記錄的情況下，都將得出相同的狀態。
- Rollup共識客戶端：從 Layer-1 數據中提取批次，並將交易和元數據列表發送到執行客戶端以構建和執行區塊的軟件。示例：
op-node - Rollup執行客戶端：執行區塊並存儲Rollup狀態的軟件。例如：
op-geth
這裡我們假設Rollup將執行和共識分離，就像在OP Stack 和 L1 本身中一樣，但這對於解釋來說並不是必需的。
角色和權限
不可阻擋的排序並不需要消除需要許可/中心化的排序器。中心化的排序器可以提供高級服務（高可用性、預先確認，以及最終與其他 Rollup 的同步可組合性），這些服務需要保證區塊空間和費用。
在 Unstoppable Sequencing 模型中，有兩個排序器角色：
優先級排序器：每個 L1 區塊最多隻有一個優先級排序器。該排序器的批次始終位於 L2 區塊的起始位置，並且保證該排序器佔用 L2 區塊空間的百分比，該百分比可通過 rollup 配置。
無需許可的排序器：其他所有人。它們的批次在二級區塊中排在優先級排序器的批次之後，並且它們的區塊空間無法保證——它們會使用優先級排序器未消耗的所有 Gas。
不可阻擋排序方法與如何選擇優先級排序器以及保證多少百分比的 L2 區塊氣體無關。
一個“純粹”的Rollup可能不需要優先級排序器。另一個 Rollup 可能有一個優先級排序器，但只保證 50% 的區塊空間，使其與普通用戶處於平等地位，等等。
設置這些參數沒有“一刀切”的方法。Unstoppable Sequencing 確保在參數選擇方面具有最大的彈性，而且至關重要的是，無論選擇哪種參數，Unstoppable Sequencing 在優先級排序器缺失的情況下都能提供相同級別的保護。
在呼叫情況下，Batcher 的角色完全無需許可；任何人都可以發佈由優先級排序器或無需許可的排序器創建的批次。
批處理格式（可在 L1 數據中的任何位置掃描）
在不可阻擋的排序中，批次是可以嵌入以太坊調用數據或 blob 有效負載中任何位置的字節字符串，並且可以通過單獨掃描每個以太坊 L1 交易來發現，而無需通過（例如）特權發佈地址進行過濾。
為什麼如此自由？對符合條件的 DA 交易的限制限制了 blob 的可共享性。例如，如果兩個 rollup 要求將消息發佈給不同的接收者，則它們無法共享 blob。Unstoppable Sequencing 旨在最大限度地兼容所有批處理協議，並承擔到處查找批處理的開銷，以提高用戶的效率。
不可停止的批次由 36 字節的標頭和後跟 RLP 編碼的交易（以及優先批次的 65 字節簽名）組成：
[PROTOCOL_ID] [CHAIN_ID] [VERSION] [ROLE] [LENGTH] [RLP_TX_LIST] [SIG if ROLE=1]協議 ID （22 字節： 0x756e73746f707061626c652073657175656e63696e67 ）：十六進制編碼的字符串“unstoppable sequence”。此標識符使Rollup節點能夠通過掃描這個“神奇”的字節字符串來檢測位於 blob 或 calldata 中任何位置的批次。
鏈 ID （8 個字節）：標識批次目標鏈。
版本（1 個字節）：今天的版本 1。
角色（1 個字節）：區分批次類型。0 表示無0 ， 1表示優先級。
長度（4 個字節）：指定後面跟著多少個字節的 RLP 交易數據。
RLP_TX_LIST ：實際交易，編碼為標準以太坊 RLP 列表。
簽名（65 字節，僅用於優先級）：ECDSA 簽名，涵蓋[CHAIN_ID][VERSION][ROLE][RLP_TX_LIST] 。這證明該批次來自優先級排序器。
部分區塊（“區塊碎片”）
Unstoppable Sequencing 將每個批次視為一個 L2 塊的部分。同一 L1 塊中的多個批次將合併為一個 L2 塊，因此：
- 小參與者不需要獨自填滿整個街區，並且
- 我們避免了“完全無政府狀態”的浪費工作，即只有一個完整區塊提議者“獲勝”。
費用如何計算？
直觀地說，每個排序器都應該從其發佈的批次交易中獲得費用。對於優先級排序器來說，這是可能的，但對於無需許可的排序器則不行，因為 L1 區塊提議者總是可以用自己批次的副本搶先執行排序器。
這種安排激勵了 L1 區塊提議者投入精力對Rollup進行排序，以便在優先級排序器發生災難性故障時提供所需的吞吐量。但是，如果你不是L1 提議者，發佈無需許可的批次的動機又是什麼呢？
即使沒有協議費用，無需許可的排序器仍然可能受到以下因素的激勵：
- 與用戶達成的私下交易/預付款安排
- 操作需要包含自己的交易的大型Rollup應用程序
- MEV 或交易排序帶來的其他間接收益
該協議的最後一個選項和“未來功能”是讓用戶指定他們喜歡的排序器，該排序器將是唯一一個（除了他們自己之外）能夠對他們的交易進行排序並收取費用的人。
從批次中確定性地獲取 L2 狀態
現在讓我們端到端地看一下這個過程，從無需許可的測序器的角度開始，以確定性 L2 塊的生成結束。
步驟 1：批量創建、提交和 Blob 共享
無權限排序器通過標準 RPC 調用（ eth_sendRawTransaction ）收集用戶交易。當排序器收集到足夠多的交易併發布後，它會：
- 將它們包裝在 Unstoppable Sequencing 批處理格式中
- 使用viem 的 toBlobs方法對批次進行編碼以實現 blob 兼容性（處理 BLS 字段模數約束）
此時，排序器已準備好將包含交易批次的 Blob 交易提交到 Layer-1。然而，如果這樣做，它們將與大型中心化排序 Rollup 競爭相同的六個 Blob 插槽。這在經濟上是不可行的，因此 Unstoppable Sequencing 在設計時就考慮到了 Blob 共享。
由於 blob 共享需要多個序列器之間的協調，因此將其作為單獨的服務自然是有意義的。
我們與Spire合作，使用其DA Builder 產品開發了該協議的 blob 共享功能。我們相信他們的產品最為成熟，並將在 Facet Chain 上的 Unstoppable Sequencing 實現中使用它。然而，整體方案與提供商無關；任何兼容的聚合器都可以使用。
要使用像 Spire 這樣的共享服務，用戶需要將原本提交給 L1 的 Blob 交易發送到 Spire 的 RPC 端點。Spire 隨後會解碼該 Blob，將其數據與其他排序器的數據合併成一個新的 Blob，並將其提交給 L1。
Spire 甚至支持 Flashbots 的 RPC 方法，例如eth_sendBundle這樣排序器就可以在收到單個用戶交易後立即向 Spire 提交批次，並針對每個收到的新用戶交易重新提交一個指向同一 L1 區塊的新批次。這消除了各個排序器在最佳時機方面的負擔。
注意：如果即使使用Blob 聚合服務，Blob 經濟仍然不可行，則排序器始終可以將批次作為調用數據發佈到 L1。
步驟 2：發現和驗證（節點掃描所有內容）
對於每個 L1 區塊，節點按順序迭代每個 L1 交易並檢查：
- 然後是交易的調用數據
- 每個 blob 都附加到該 tx（按 blob 索引升序排列）。
它掃描每個字節流以查找 Unstoppable PROTOCOL_ID ，並在匹配時解析固定長度的標頭並驗證：
-
CHAIN_ID與Rollup匹配， -
VERSION受支持， -
RLP_TXS解碼正確 - 對於優先批次（
ROLE=1），SIG會根據特定於彙總的授權集進行驗證 - 確保所有優先級批次中所有交易的 gas 限額總和不超過特定於彙總的保證 gas 分配。
格式錯誤或不匹配的批次將被忽略。有效批次將進入下一步。
步驟 3：聚合和排序
節點從 L1 塊收集所有有效批次並使用以下排序鍵對其進行排序：
- 優先級？0：1
- L1 交易索引
- 呼叫數據中的字節偏移量
- 斑點索引
- blob 中的字節偏移量
也就是說，優先批次優先，並且如果事務在 calldata 和 blob 中都有批次，則所有 calldata 批次都會在 blob 批次之前。
每個批次都會被“解包”成其組成交易，保留其在批次中的順序，並附加傳統的單筆交易強制包含交易。總而言之：
- 所有優先批量交易
- 所有無需許可的批量交易
- 存款/傳統強制交易
結果是 L2 交易的確定性有序列表，但Rollup執行客戶端可能無法從該列表構建 L2 塊，因為某些交易可能無效。
在以太坊中，交易“失敗”分為兩類：
失敗的交易（區塊有效） ：當合約功能恢復或交易耗盡 gas 時，交易仍然可以包含在有效區塊中。
無效交易（區塊無效） ：某些交易錯誤會導致整個區塊無效，從而導致執行客戶端拒絕該區塊。例如：
- 賬戶資金不足以支付燃氣費用
- 無效的隨機數值
- 合約部署超出規模限制
在傳統的單方區塊創建中，The Block生產者可以在提交之前刪除所有無效交易。然而，在“不可阻擋排序”系統中，當合並來自多方的批次時，這種方法並不可行。
步驟 4：執行和過濾
解決方案是從上一步中節點創建的 L2 交易的有序列表中“過濾掉”使區塊無效的交易。
然而，識別無效交易並不是可以在Rollup共識客戶端中“靜態”完成的事情，因為交易的有效性可能取決於執行The Block中先前交易的結果。
因此，Unstoppable Sequencing 需要修改執行客戶端才能啟用此過濾功能。具體流程如下：
共識客戶端在正常的
engine_forkchoiceUpdated調用中將交易發送到執行客戶端。執行客戶端開始使用這些交易構建 L2 塊，按順序一次執行一個。
當執行客戶端遇到無效交易時，它不會因錯誤而停止進程，而是跳過該交易並轉到列表中的下一個交易。
侷限性和權衡
無需許可的測序器面臨不確定性
優先級排序器具有可預測的排序順序和有保證的 Gas 分配。無需許可的排序器不知道其最終的執行順序。如果在無需許可的批次交易嘗試購買 Gas 時，L2 區塊已滿，則這些交易將被過濾掉。
攻擊者可以利用此機制，在某個無需許可的排序器之前提交多個批次，試圖將其排除在The Block之外。然而，持續的垃圾郵件攻擊將給攻擊者帶來巨大的成本，因為 Layer-2 的區塊基礎費用會隨之增加。
如果一批交易的部分或全部未進入 L2 區塊，那麼從協議的角度來看，這些交易將會丟失。也就是說，如果排序器想要將這些交易打包到不同的 L2 區塊中，他們必須通過新的交易將該批交易再次提交到 L1 區塊。
一個更具成本效益但更復雜的“未來功能”是讓Rollup節點維護一個已過濾交易的“內存池”，並自動將其包含在內，而無需在未來的 L2 區塊上重新提交。
預先確認和同步可組合性
某些高級功能需要能夠可靠地模擬交易結果：
- 預先確認：用戶希望在 Layer 1 納入之前獲得交易執行的保證
- 同步可組合性：跨鏈調用需要確定性模擬
這些服務只能由發佈第一批服務的人可靠地提供——當優先級排序器處於活動狀態時，或者當優先級排序器不存在時，由 L1 提議者提供。
這就形成了一種自然的分工：優先級排序器提供優質服務和保障，而無需許可的批處理則確保鏈在任何條件下都具有抗審查性和可操作性。
垃圾郵件怎麼辦？
無權限系統容易滋生垃圾郵件。攻擊者可以在多個區塊中發佈數千筆無效交易，迫使節點處理垃圾數據。Unstoppable Sequencing 能解決這個問題嗎？
目前每個區塊 6 個 blob 的限制意味著每 12 秒區塊最多有 ~7,500 個垃圾交易，這對於當今的硬件來說是可以處理的。
隨著 blobspace 的增長，這可能成為一個挑戰，但解決這一挑戰需要付出無需許可和彈性的代價。
結論
L2 建立在批處理的基礎上。傳統的強制包含機制會將交易還原為單個交易，從而破壞了這一模型，導致在排序器發生故障時無法維持正常運行。
Unstoppable Sequencing 通過使批處理無需權限即可解決這個問題——任何人都可以創建和發佈批處理，並將其嵌入到 L1 數據的任何位置，並通過 Blob 共享分擔成本。這種方法會帶來額外的複雜性，但它確保了 L2 能夠抵禦審查、故障和攻擊。只要有人可以在 L1 的某個位置發佈批處理，鏈就能持續運行。
