昨天結尾叫你去 L2BEAT 查 Sequencer failure 跟 Proposer failure 那兩欄,今天要把那兩欄真正講完。那兩欄問的不是「排序權歸誰」,而是一個更狠的問題:排序器不理你的時候,你能不能自己把交易塞進去、把錢拿出來。這是兩個獨立的能力,分別對應強制收錄(forced inclusion)與逃生艙(escape hatch),而且大多數 L2 只做到其中一半,少數連一半都沒做到。L2BEAT 在 Linea 的頁面上直接寫「Sequencer failure: No mechanism」,並註明要等到「6 個月沒有 finalized block」之後 Operator 角色才會轉為公開——這句話翻成人話是:如果 Linea 的排序器今天決定不理你,你的合法退出路徑是等半年。這篇要拆的就是這些計時器各自量的是什麼,以及 L2BEAT 的 Stage 框架到底把門檻設在哪裡。
📖 學
強制收錄的機制:交易先進 L1 的信箱,計時器交給 L1 管
強制收錄的共同骨架只有一句:使用者把交易送到 L1 上的一個 inbox 合約,合約記下它跟時間戳,超過延遲窗之後排序器若還沒把它排進 L2 的序列,狀態轉換就會被判定無效。關鍵在於「無效」這兩個字——這不是排序器的道德義務,而是協定層的硬約束。L1 合約在驗證下一批 batch 時會檢查 inbox 裡逾期的訊息有沒有被收進去,沒有就拒收整批。排序器不能繞過,只能拖到期限為止。
Arbitrum 的版本最好懂。使用者把訊息丟進 delayed inbox,等固定 24 小時之後,任何人(不只本人)都可以去 SequencerInbox 合約呼叫 forceInclude,把訊息從 delayed inbox 推進主序列。Arbitrum 文件裡有個容易被忽略的細節:delayed inbox 是 FIFO,排序器必須照訊息在 L1 上出現的順序收錄,所以它沒辦法「只針對你一個人拖」。要拖你,就得連你後面所有人一起拖,這讓審查的成本從個人層級升到全網層級。這個設計選擇比 24 小時這個數字本身更重要。
OP Stack 的做法不叫 forced inclusion,叫 sequencing window。使用者直接送交易到 L1 的 OptimismPortal 合約,產生一筆 deposit transaction;OP Stack 規格規定 deposit 最遲會在 SEQUENCING_WINDOW_SIZE 個 L1 區塊之內被收進 L2,預設是 12 小時(各條鏈可自訂)。超過窗口而排序器還沒交出 batch,節點會自己往下推導區塊——推導出來的區塊裡只有被強制收錄的 deposit 交易,一般 L2 交易全部消失。這是 OP Stack 最反直覺的一點:sequencing window 到期不是「排序器被罰」,而是鏈自己在沒有排序器的情況下繼續走,只走 L1 那條軌。
zkSync Era 走 priority queue。使用者可以把交易排進 L1 的 priority queue,排序器不能挑著跳過,但——這是重點——L2BEAT 的評估寫得很白:使用者可以把交易「送進」佇列,卻不能「強制」它被執行,排序器可以整個停止處理佇列。更麻煩的是 zkSync 的合約裡有 TransactionFilterer,中心化 operator 可以無延遲地啟用它來過濾交易。所以 zkSync Era 的 priority queue 是「防選擇性審查」的,不是「防全面停擺」的,兩者差很多。
Starknet 目前只有 L2BEAT 稱為「Log via L1」的機制:使用者可以在 L1 上登記一筆交易,但無法強制它被收錄;實際的補救路徑是 Security Council 的少數成員可以繞過排序器、直接提交包含該交易的 state root。這等於把抗審查外包給一組人,而不是外包給合約。Starknet 社群自己也承認這件事,他們的 escape hatch 研究串就是在討論怎麼補上這個洞。順帶一提,Starknet 在 2026-01-05 發生過一次主網停擺兩小時以上的事故,起因是某筆交易的 proving error,團隊為了鏈的一致性主動暫停排序器——這正是「排序器不理你」的真實樣態,而且不需要惡意。
Linea 是最值得看的案例,因為它讓你看到強制收錄從無到有的中間狀態。L2BEAT 追蹤到 LineaRollup 合約已經升級到帶有 forced transaction 功能的版本(LineaRollup_ForcedTrx_v8_0),新增了 storeForcedTransaction、nextForcedTransactionNumber、forcedTransactionL2BlockNumbers 等狀態,_finalizeBlocks 也加上了「有沒有 forced trx 過期」的檢查,強制收錄費用寫死在 forcedTransactionFeeInWei,值是 1000000000000000 wei(0.001 ETH)。功能寫好了、部署了、費用參數都設了——但 storeForcedTransaction 只有 FORCED_TRANSACTION_SENDER_ROLE 能呼叫,而這個角色目前沒有分配給任何人。合約裡還有一份 filter list,名單上的地址不能從 L1 發強制交易。所以 Linea 在 L2BEAT 上的 Sequencer failure 至今仍是 No mechanism,Exit window 是 None(合約可即時升級,程式碼升級延遲 0 秒)。
| L2 | 強制收錄路徑 | 延遲窗 / 期限 | L2BEAT Sequencer failure |
|---|---|---|---|
| Arbitrum One | delayed inbox + forceInclude | 固定 24 小時(BoLD 附帶的 Censorship Timeout 可縮短,預設關閉) | Transact using L1(約 1 天延遲) |
| OP Stack(OP Mainnet / Base) | OptimismPortal deposit | sequencing window 預設 12 小時 | Transact using L1 |
| zkSync Era | L1 priority queue | 可入列但無法強制執行;operator 可用 TransactionFilterer 過濾 | 受限 |
| Starknet | Log via L1 | 無強制期限,靠 Security Council 少數繞過 | 受限 |
| Linea | 合約已具備但角色未分配 | 未啟用;另有可被過濾的地址名單 | No mechanism(6 個月無 finalized block 後 Operator 轉公開) |
Arbitrum 那個「可縮短」的機制值得單獨講:BoLD 首次釋出時帶了一個叫 Censorship Timeout(原名 Delay Buffer)的功能,參數是 isDelayBufferable,設計目的是當母鏈或排序器出現持續審查、或排序器直接離線時,自動縮短強制收錄的時間窗,讓爭議解決不必每一步都等 24 小時。但它預設是關閉的,因為正確設定值取決於該鏈的 batch 發布頻率與結算的母鏈。所以「Arbitrum 有辦法把 24 小時縮短」跟「Arbitrum 現在是 24 小時」兩句話同時成立,差別在於開關有沒有打開。
更正一:強制收錄買的是抗審查,不是低延遲
常見說法是「有強制收錄就不怕排序器掛掉」。這句話把活性(liveness)跟安全性(safety)混在一起了。強制收錄保護的是安全性面向的抗審查:不管排序器多壞,你的交易終究會進鏈,你的資產終究拿得回來。它完全不保護活性:排序器掛掉的那 12 到 24 小時裡,鏈對一般使用者而言就是停的。你的清算部位不會因為「我等一下可以強制收錄」而免於被清算,你的套利機會不會因為延遲窗存在而還留在那裡。
把這件事講清楚有實際後果。強制收錄的延遲窗越長,協定的抗審查保證越穩健(給了排序器團隊修 bug 的緩衝,也讓 L1 重組風險不會污染 L2 序列),但使用者在故障期間的體驗越差。Arbitrum 官方對 24 小時的解釋正是「給營運排序器的團隊一段舒服的時間修 bug」。這是一個明擺著的取捨,不是疏漏。反過來說,如果哪條鏈把延遲窗設成 5 分鐘,那不是它比較去中心化,而是它把 L1 重組與排序器暫時性故障的風險轉嫁給了狀態一致性。
第二層更正:強制收錄不等於「你能提款」。強制收錄只保證你的交易上鏈。要把錢從 L2 提到 L1,你的提款交易上鏈之後,還需要有人提出包含這筆提款的 state root,而且這個 state root 要能在 L1 上被驗證。如果 proposer 是白名單制而白名單裡的人全都不動,你的提款交易上鏈了也沒用——這就是 L2BEAT 為什麼把 Proposer failure 獨立成一欄。Linea 頁面上寫得很直接:只有白名單 proposer 能在 L1 發布 state root,一旦失效,提款就是凍結的。
逃生艙的三個前提:資料、算力、獨立路徑
逃生艙(escape hatch / forced withdrawal)要成立,需要三件事同時具備,少一件就是空的。第一是狀態資料必須可取得。你要證明「這些錢是我的」,得先重建出 L2 的狀態、算出你那筆餘額的 Merkle proof。第二是要有人能算出證明。ZK rollup 的情況下,如果 prover 是白名單且全體罷工,或者 proving 需要的硬體規格高到一般人跑不動,那「理論上任何人都能提出證明」就只是理論。第三是 L1 上要有一條不依賴 operator 的獨立驗證路徑:一個 L1 合約入口,接受你的 Merkle proof 直接放款,或者一個能把系統推進「凍結狀態」的開關,凍結之後所有人都可以憑證明直接從 L1 合約提款。
第一個前提就是 validium 逃生艙失效的原因。validium 把資料放在鏈下(DAC 或外部 DA 層),如果資料保管方拒絕交出資料,使用者算不出 Merkle proof,逃生艙的門把就在那裡但你打不開。這是整個 rollup 與 validium 之爭裡最實際的分野:validium 的資產安全在正常狀況下由 ZK 證明保證(沒人能偷你的錢),但在退出狀況下由資料保管方保證(有人能鎖住你的錢)。L2BEAT 把這種風險標成「Funds can be frozen if data availability managers withhold offchain state data」,不是誇張。
比較成熟的逃生艙設計會加一個「強制凍結」步驟:使用者送出 forced exit 請求,超過期限仍被忽略時,可以把整個系統推進 frozen state,禁止進一步的狀態更新,然後所有人憑 Merkle proof 從 L1 提款。這個設計的精髓在於它把「拒絕服務」變成「自我了斷」——排序器繼續忽略你的代價是整條鏈停止運作,所以它的理性選擇是處理你的請求。StarkEx 系的產品用的就是這一套。至於通用 EVM rollup 要怎麼做出可用的逃生艙,學術上還在推進,2025 年有一篇 arXiv 論文 A Practical Rollup Escape Hatch Design(2503.23986)專門處理這個問題。
L2BEAT Stage 的實際條文:三條要求,而且門檻寫得很硬
L2BEAT 的 Stages 頁面(頁面標註 Last updated on 23 Jul 2025,精確規格在 forum 的 The Stages Framework 貼文)把三個級距寫得比多數人以為的更明確。Stage 0 有六條:專案自稱 rollup、state root 發到 L1、DA 在 L1、有可重建狀態的開源節點軟體、有正經的證明系統、至少 5 個外部行為者可以提交詐欺證明。Stage 1 現在不是條列而是一條原則:除了 bug 之外,要無限期擋住一則 L2→L1 訊息(例如提款)或塞進一則無效的 L2→L1 訊息,唯一辦法是攻陷 Security Council 的 75% 以上;由 Security Council 以外的實體發起的升級,必須提供至少 7 天的退出窗。這條原則底下附了一個假設:如果 proposer 集合對任何有足夠資源的人開放,就假設任何時刻至少有一個活著的 proposer(1-of-N,N 無上限)——但明確不假設它不審查。
Stage 2 是三條:一、詐欺證明系統必須是無需許可的,任何人都能提交,不是白名單。二、面對不想要的升級,使用者至少有 30 天可以退出,而且這條涵蓋 DAO 發起的升級。唯一的例外是存在鏈上 bug 偵測機制時(例如同一批次能生出兩個互相矛盾的有效 ZK 證明),對已偵測到的 bug 允許即時升級——L2BEAT 舉的例子是 Polygon zkEVM 合約的「Emergency Mode」。三、Security Council 若存在,權限必須被限制到只能因鏈上可裁決的錯誤而介入。
L2BEAT 自己在同一頁強調了一件常被漏掉的事:Stages 框架衡量的是去中心化成熟度,不是安全性。一個團隊要部署一條「很不安全但是 Stage 2」的鏈非常容易——證明系統可以極度實驗性,合約可以根本沒審計過。去中心化只有在「permissioned 行為者帶來的風險大於 bug 帶來的風險」這個時點之後,才是安全性的良好代理。頁面上還放了 Vitalik 2025 年那篇 The math of when stage 1 and stage 2 make sense 的圖。這是對「Stage 越高越安全」這種直覺的官方否認。
2026 年的實際分佈,誠實地說是尷尬的。Aztec 在 2026-06-22 前後透過鏈上治理投票撤銷了 rollup 合約的所有權,達成 Stage 2,這是少數大聲宣布的案例。在此之前,長期以來 L2BEAT 上真正拿到 Stage 2 的主要是 DeGate v1 與 Fuel v1 這類體量不大的專案。至於前幾大的 L2,Arbitrum One 在 2026 年是 Stage 1,Base 與 OP Mainnet 在 2026-01 前後拿到 Stage 1(呼應昨天講的),zkSync Era 與 Linea 仍是 Stage 0,Starknet 的級距在不同二手來源之間說法不一(有的說 Stage 1、有的說 Stage 0)——已標存疑,以 L2BEAT 專案頁當下顯示為準。這裡我刻意不給一張「2026 年 Stage 分佈完整表」,因為這些數字每個月都在動,二手部落格抄來的版本錯誤率很高,你該做的是自己去查。
治理升級這條後門:退出窗是你唯一的逃生時間
可升級合約是 L2 最大的單一風險來源,而且它繞過上面所有討論。強制收錄再完美、逃生艙再健全,只要有人能把橋合約的實作換掉,你的資產就是那個人的。L2BEAT 在 Linea 的風險摘要裡把它排在第一條:「Funds can be stolen if a contract receives a malicious code upgrade. There is a 0s delay on code upgrades.」零秒。這代表使用者的逃生時間是零。
升級延遲期(exit window)就是把這個零變成正數的機制。合約升級提案送出之後鎖在 timelock 裡 N 天,這 N 天就是使用者看到提案、判斷不接受、把資產撤出 L2 的全部時間。Stage 1 要求非 Security Council 發起的升級至少 7 天,Stage 2 要求全部升級(包含 DAO 發起的)至少 30 天。這兩個數字不是隨便訂的:它必須大於「提款挑戰期 + 使用者反應時間」,否則你發現不對勁時已經來不及走完提款流程。
Security Council 的 M-of-N 是另一半。它存在的理由是真的有緊急狀況——鏈上 bug 需要即刻修補,等 30 天可能整條鏈都空了。但緊急權力天生會膨脹,所以 Stage 2 的條文才把它鎖死成「只能因鏈上可裁決的錯誤介入」。實務上這條線很難守。2026 年 5 月的 L2BEAT 月報就記了兩件相關的事:Arbitrum Security Council 執行了一次緊急治理修補,處理 L1 Timelock 合約可能被跨鏈訊息觸發、導致 bridge proposer 角色被放棄的漏洞(團隊聲明使用者資金未曾有風險,只影響治理);同月 Arbitrum 治理還通過了一項修訂版憲法提案,授權轉移先前由 Security Council 凍結的 30,765 枚以上 ETH,依據是美國法院命令。第二件事值得盯著看:它示範了 security council 的權力如何跟傳統法律系統交會,而這是任何 Stage 條文都沒有涵蓋的維度。
zkSync Era 的參數也值得對照:非緊急升級走約 4 天 3 小時的延遲,緊急升級路徑需要 6/8 Security Council + 5/8 Guardians + 3/6 ZKsync Foundation 且可即時執行。4 天比 7 天短,這是它卡在 Stage 0 的原因之一。
更正二:七天挑戰期跟強制收錄延遲窗是兩個時鐘
「Optimistic rollup 提款要等七天」跟「強制收錄要等 24 小時」被混為一談的頻率高得驚人,但它們量的是完全不同的東西,而且在同一次提款裡是串聯的。
強制收錄的延遲窗(Arbitrum 24 小時、OP Stack 12 小時)量的是:從你把交易丟進 L1 inbox,到協定強制排序器必須把它納入 L2 序列為止。這是進場的時鐘,它保護的是「我的交易能不能上 L2」。
詐欺證明的挑戰期(七天)量的是:從有人在 L1 提出一個 state root(裡面包含你的提款),到這個 state root 被視為最終、L1 橋合約願意放款為止。這是出場的時鐘,它保護的是「這個 state root 是不是真的」。
正常情況下你只會遇到第二個時鐘,因為排序器好好地把你的提款交易收了。排序器審查你的時候,兩個時鐘串起來跑:先等 12 到 24 小時把交易強制塞進去,再等七天挑戰期過。所以「排序器審查我時我要多久拿到錢」的答案是八天左右,不是七天,也不是一天。第三個時鐘還在旁邊:治理升級的退出窗(7 天或 30 天)。你要在退出窗內走完前面那八天,退出窗才是有效的——這就是為什麼 Stage 2 把門檻設在 30 天而不是 10 天,因為 10 天扣掉八天之後,你的思考時間只剩兩天。
🧠 記
強制收錄是把交易送到 L1 的 inbox 合約,超過延遲窗後排序器不收錄則狀態轉換無效;Arbitrum 是固定 24 小時、FIFO 順序、任何人可呼叫 forceInclude,BoLD 的 Censorship Timeout 可縮短但預設關閉;OP Stack 是 12 小時的 sequencing window,窗口到期後節點只推導出 deposit 交易;zkSync Era 的 priority queue 能入列不能強制執行,operator 還有 TransactionFilterer 可即時過濾;Starknet 只有 Log via L1、靠 Security Council 少數繞過;Linea 的 forced transaction 合約已部署(費用 0.001 ETH、有地址過濾名單)但 FORCED_TRANSACTION_SENDER_ROLE 無人持有,L2BEAT 上仍是 No mechanism,而且合約升級延遲 0 秒。強制收錄買的是抗審查不是低延遲;能上鏈不等於能提款,提款還要 proposer 肯發 state root。逃生艙要三個前提:資料可得、有人算得出證明、L1 上有獨立驗證路徑;validium 資料在鏈下,第一個前提就可能不成立。L2BEAT Stage 2 三條:無需許可的詐欺證明、所有升級(含 DAO)至少 30 天退出窗(鏈上可偵測 bug 除外)、Security Council 只能因鏈上可裁決錯誤介入;Stage 1 的原則是無限期擋住 L2→L1 訊息需攻陷 ≥75% Security Council、非 SC 升級至少 7 天退出窗,且明確不假設 proposer 不審查。L2BEAT 自己說 Stage 衡量的是去中心化不是安全,Stage 2 的鏈也可能很不安全。三個時鐘:強制收錄延遲窗(進場)、挑戰期七天(出場)、升級退出窗(逃命),被審查時前兩個串聯約八天。
✍️ 實踐
今天 20 分鐘,做一次「我這條鏈的三個時鐘各是多少」的實查。
第一步(6 分鐘):打開 l2beat.com,挑一條你真的有資產在上面的鏈,進它的專案頁,把 Risk analysis 那六格全部看完,特別記下 Sequencer failure、Proposer failure、Exit window 三格的文字說明而不只是標籤。標籤會寫「Transact using L1」,說明才會告訴你延遲是幾小時、有沒有前提條件。
第二步(6 分鐘):在同一頁往下捲到 Stage 區塊,看它現在是 Stage 幾、以及「N issues need fixing」那幾條具體是什麼。Linea 的頁面會顯示 Stage 1 還差 5 項、Stage 2 還差 2 項,點開看差在哪。然後回頭對照 l2beat.com/stages 的條文,確認你理解那幾項為什麼是門檻。
第三步(5 分鐘):算出你自己的最壞情況總時間。公式是「強制收錄延遲窗 + 挑戰期(ZK rollup 則是 finalization 時間)」,再確認這個總和有沒有小於該鏈的升級退出窗。如果退出窗是 None 或 0 秒,那答案就是:遇到惡意升級時你沒有逃生時間,這件事你要知道並自己決定接不接受。
第四步(3 分鐘):去該鏈的官方文件搜尋 forced / force inclusion / escape hatch 三個關鍵字,確認 L2BEAT 的描述跟官方文件對得上。對不上的話,通常是 L2BEAT 比較新。
自我檢查:如果我問你「你那條鏈的排序器現在開始審查你,你多久能把錢拿到 L1」,你能不能講出一個具體數字、並說出這個數字是哪兩個時鐘加起來的?如果不能,回第一步。第二個檢查:你能不能說出你那條鏈的合約升級延遲是幾天、由誰批准?如果答案是「不知道」或「0 秒」,那你對這條鏈的信任模型其實是「信任那個團隊」,而不是「信任以太坊」。
🔗 延伸學習
- L2BEAT — Stages Framework:Stage 0/1/2 三級距的官方條文與說明,含 L2BEAT 自己對「Stage 不等於安全」的澄清。精確規格見 forum 上的 The Stages Framework。
- Arbitrum Docs — The Sequencer and Censorship Resistance:delayed inbox、24 小時 force inclusion、FIFO 收錄順序的第一手說明。
- Optimism Docs — Forced Transaction:OptimismPortal 送 deposit、sequencing window 到期後節點如何自行推導區塊。
- A Practical Rollup Escape Hatch Design(arXiv 2503.23986):通用 rollup 逃生艙設計的學術處理。另可參考 Starknet 社群的 escape hatch 研究串。
💬 問 AI
我想搞懂我常用的 L2 在「排序器拒絕服務」時的真實逃生路徑。請針對我指定的鏈(我會告訴你是哪一條),用以下結構回答,並且每一項都標註你的資訊來源與時間點,查不到就直接說查不到,不要推測:
1. 強制收錄:有沒有?入口合約是什麼?延遲窗多少?誰可以觸發?有沒有任何前置條件(角色權限、費用、地址過濾名單)?
2. 提款路徑:交易上鏈之後,誰負責提出 state root?是白名單還是無需許可?如果提出者全部罷工會怎樣?
3. 逃生艙:有沒有不依賴 operator 的 L1 提款路徑?資料在鏈上還是鏈下?如果資料保管方拒絕提供資料,我還能不能算出提款證明?
4. 三個時鐘:強制收錄延遲窗、最終性/挑戰期、合約升級退出窗,分別是多少?被審查時的最壞情況總時間是多少?
5. 升級權限:誰能升級橋合約?Security Council 是幾之幾?權限有沒有被限制成只能處理鏈上可裁決的 bug?
6. L2BEAT 現在給它 Stage 幾?差哪幾項才到下一級?
最後請直接告訴我:這條鏈的信任模型底線是「信任以太坊」還是「信任某個團隊或某組人」,並說明你這樣判斷的具體依據。