在 Layer 2 上設置「逃生艙」功能，可以保障用戶能夠順利將資產撤回 Layer1。
（前情提要：一山高過一山的比特幣Layer2：攻克不可能三角 ）
（背景補充：投資機構眼中的 Layer2》IOSG創辦人Jocy：我對 L2 現況的思考 ）
在現實世界中，幾乎每一棟高樓大廈都有一個不可或缺的要素：安全出口。當火災地震等突發事件降臨時，安全出口就是保障人們生命安全的救命稻草。而在以太坊 Layer2 這個承載了百億美元資產的託管平臺體系中， 可以讓使用者把資產安全撤回至 Layer1 的 「強制提款」 功能 ，已然成為不可或缺的必備設施。
Vitalik 在最近的文章 「Different types of layer 2s」 中也強調， 使用者能否順利的把資產從 Layer2 撤回至 Layer1， 是一個非常重要的安全指標。
但 「順利提款」 問題在過去似乎沒有得到大多數人的重視，甚至許多 Layer2 專案方都沒有上線 「強制提款」 或 「逃生艙」 功能。在 L2 生態體系未成火候的時代，漠視 「無需許可的提款」 似乎不成問題。但 如今 Layer2 已經承載了 120 多億美元的資產， 已然變成了一棟 「太大而不能倒」 的大廈。如果這樣的一棟摩天大樓沒有安全出口，後果簡直是不可想像的。
抱著讓廣大讀者重視 Layer2 安全風險的目的，《極客 web3》將在下文以路印協議 V3 和 Arbitrum 為例，為大家闡明為何 forced withdraw 與 escape hatch 等 「無需許可的提款功能」 是 Layer2 不可缺少的一環 。
抗審查性是大問題：如果 Sequencer 故意拒絕你的請求，怎麼辦
過去關於 Layer2 的科普文章往往有一個問題，就是大多數時候都著重強調 「安全性」 與表面上的 「可用性」，卻忽略了 「抗審查性」。即便是在談論去中心化排序器方案時，很多人注意到的也是 MEV 是否去中心化，而不是抗審查性的改善。
換句話說，大多數人往往注重 Layer2 的狀態轉換是否有效，排序器能不能盜幣，欺詐證明 / 有效性證明系統有沒有投入使用，卻忽略了一個不該被忽視的風險： 如果 Sequencer 一直拒絕你的交易請求，或者乾脆長時間故障，甚至停機，這個時候怎麼辦？
延伸閱讀：幣安研報：Rollups過於中心化，深度解讀L2去中心化排序器
要知道， 在 Solana 當機期間，曾有人因為資產面臨清算而無法及時補倉，使得幾百萬美元的資產面臨風險。 此類拒絕使用者請求的場景一旦發生，造成的經濟損失並不可小視。
即便只有個別人可能遭遇此類情況，但 如果落到了一些手握大量資金的鯨魚身上，整個市場都可能連帶遭殃 （假設某人在以太坊上的 Defi 借貸協議有幾億美元資產可能在一週內被清算，但他因為用了 Tornado 而被 OFAC 列入制裁名單。此人大部分資金都在 OP 上，而 OP 排序器配合 OFAC 拒絕它的請求）
我們不妨把這個問題投射到 avalanche 或 polygon 等獨立於以太坊的公鏈上去分析。如果 Avalanche 上超過 2/3 的 Validator 共識節點決定對你展開交易審查，那麼它們可以拒絕把你發起的 Txn 打包進區塊裡，或者不承認包含你的 Txn 的區塊。 這個時候，你的錢基本就被埋在了這條鏈裡出不來：
除非你能拉攏一些 Validator，使得參與審查攻擊的 Validator 不足 2/3，或者你能號召一些人通過社會共識的方法，把 Avalanche 分叉。顯然在這個時候，你還是有辦法把資金快速撤出 Avalanche 的，並且我們要考慮到，超過 2/3 的 Validator 聯合起來對某個地址發起交易審查，本身就需要一段時間去達成，這會給被審查的使用者留下充沛時間 「逃出生天」。
但在 Layer2 上，這種情況可能大不相同。 Layer2 的 Sequencer 一般都是由官方自己在執行，如果 Sequencer 想要對你展開審查攻擊，它可以把你的錢 「凍結在 Layer2」， 也就是徹底拒絕你發起的，把資產從 L2 跨到 L1 的交易請求。顯然按照 L2 的運作機理，如果你不能繞開排序器執行提款操作，是完全可能被 Sequencer 把資產凍結在 L2 不能轉移走的。
那麼該怎麼解決這種問題呢？其實說白了就是， 怎麼實現 「無需許可」 的提款功能， 讓使用者在被 Sequencer 或 Layer2 專案方審查的情況下，安然無恙的把資產撤回到 Layer1 上？有一些專案方提出了去中心化 Sequencer 的方案，但這治標不治本，如果這些數量極為有限的排序器聯合起來審查你，還是可以把你的資產 「凍結」，況且 POS 節點的反女巫也是個棘手的問題（參考 Multichain 事件）。
真正最有效的辦法，是直接在 L1 鏈上設定一個 「出口」，讓使用者在長時間得不到 Sequencer 響應時， 通過 L1 上的專用出口把資金從 L2 撤出。
路印協議 V3 版本的強制提款與破產清算模式
這裡我們以路印協議的 V3 版本為例，它針對使用者發起的強制提款分列了兩種不同情況，第一種情況是：
使用者直接在 Layer1 上通過 ExchangeV3 合約中的 forcedWithdraw 函式發起強制提款， 宣告自己在路印協議的 L2 帳戶是哪個，以及要提走哪種 Token。之後，ExchangeV3 合約會丟擲一個鏈上事件，提示有人發起了強制提款請求。由於路印協議的所有節點（包括 Sequencer）都執行著 Geth 客戶端，所以會從以太坊區塊中獲知，有人發起強制提款並觸發了對應的鏈上事件。
要注意的是， 強制提款不會被立刻處理，而是置入 pendingForcedWithdrawals 佇列，處於待處理狀態。 Sequencer 注意到有人在 Layer1 發起強制提款後，一般會在 15 天內觸發 ExchangeV3 合約中的 Process 函式，在以太坊鏈上把 Token 轉給提款發起者（從 L2 專案方在以太坊鏈上的存款地址，給提款者轉錢）。
如果 Sequencer 在 15 天內沒有響應使用者的強制提款請求， 使用者可以呼叫 notifyForcedRequestTooOld 函式，讓 ExchangeV3 合約丟擲名為 WithdrawalModeActivated 的事件，通知路印協議的全節點， 破產清算模式被激活了。
如果破產清算模式被啟用，此時路印協議 V3 會停止接收 Sequencer 提交的新 L2 區塊，也就是說這個時候路印協議整個就停止了運轉。 這個過程會持續至少 30 天。
但在破產清算模式下，使用者依然可以在 Layer1 上把自己的資產提走，只不過需要提交 merkle proof 證明自己的資產狀況 / 狀態，在 L2 的狀態樹上是可查的。（ 證明自己在 Layer2 的資產餘額，和自己發起提款時宣告的金額是一致的 ）
路印協議的這種破產清算模式， 在 L2BEAT 上也被稱作 Escape Hatch 逃生艙機制。 這種模式的觸發有個先決條件，就是 排序器在規定的時間內沒有響應使用者的強制提款請求， 或者 Sequencer 長期故障或停機。此時使用者可以通過手動觸發的方式，讓 Rollup 合約進入凍結模式 / 停止運轉。然後 使用者可以構造 merkle Proof 證明自己在 Layer2 上的資產情況，從 L2 專案方在 L1 的存款地址中，把屬於自己的那部分資產提走。
在 StarkEx 的文件中，還為這一過程畫了專門的示意圖。如果 L2 使用者在 L1 提交的 Forced Withdrawal 請求在 7 天視窗期結束時，未得到定序器響應，則該使用者可以呼叫 freeze Request 功能讓 L2 進入凍結期。此時，L2 定序器將無法在 L1 上更新 L2 的狀態，L2 狀態凍結後要過 1 年才能解凍。之後使用者可以提交 merkle proof 並提款。
但要構造 Merkle Proof，需要先獲知完整的 L2 狀態樹，也就是需要找一個 L2 全節點索要資料，同時需要一段程式碼來生成 merkle Proof，顯然這需要一定的技術門檻。為了方便廣大使用者， L2BEAT 此前曾宣告，Layer2 應該設定一批許可權開放且程式碼開源的全節點，幫使用者獲知 L2 上全體帳戶的狀態（包含餘額、交易次數等）。 這一舉動其實也說明了強制提款與逃生艙機制的重要性。
Arbitrum 的 「強制包含交易」 功能
但強制提款 / 逃生艙似乎不是唯一的抗審查解決方案。比如， Arbitrum 採用了 「強制包含交易」 的方式， 使用者可以先在 L1 上的 delayed Inbox 合約提交需要被 Sequencer 處理的 Txn/withdraw， 如果 Sequencer 超過 24 小時沒有處理，使用者可以呼叫 L1 上 Sequencer Inbox 合約的 force Inclusion 函式，讓 Txn 直接被包含進 Arbitrum 的交易序列中 （丟擲一個鏈上 event 告知 Arbitrum 全節點，幾筆 delayed Inbox 上有記錄的 Txn 需要被包含進 L2 的帳本中）。
相比之下， Arbitrum 的方法要更簡單些，但這種方法還是略帶不足 ：因為它只丟擲一個鏈上事件告訴 Arbitrum 節點，有幾筆被排序器忽略了的交易需要被包含進 L2 最長鏈中，而不是像路印協議和 StarkEx 的 破產模式 / 逃生艙 那樣允許使用者直接在 L1 上把錢提走。 如果 Arbitrum 的挑戰者節點聯合起來發動審查攻擊，似乎還是可以讓使用者的錢被凍結在 L2。
所以說 Arbitrum 的 force Inclusion 還不夠 permissionless，雖然只要有一個誠實節點願意釋出欺詐證明，就可以指出排序器忽略了某個使用者的 forceInclusion 請求，但這還是引入了一定程度的信任假設，只不過程度很輕微。
更確切的說，「需要被強制包含的交易」 是要被至少 1 個 ARB 的挑戰者節點認可的， 這些節點目前有 9 個，它們有權決定給哪些 L2-L1 之間的跨鏈訊息放行，現在也只有它們能釋出欺詐證明。 只要這 9 個節點聯合串謀，理論上還是可以讓使用者的 「強制交易」 無效。
所以，目前 Arbitrum 的強制包含交易 / 提款，不像路印和 StarkEx 的破產清算模式那樣無需 L2 節點許可。但 L2BEAT 還是對 Arbitrum 的這個方案給予了很高的評價。因為在未來， Arbitrum 會上線名為 BOLD 的 Permissionless 的欺詐證明發布機制，挑戰者節點屆時將難以或無法串謀 （現在其實就很難串謀）。
按照 L2BEAT 的資料，目前 TVL 超過 5000 萬美元，且沒有針對 Sequencer Failure 或 Proposer Failure 中的某項提供應對舉措的，包括： OP Mainnet、Base、zkSync Era、Mantle、Starknet、Linea、Polygon zkEVM、Metis。 這些 L2 都可以在極端情況下導致使用者資產被凍結在 L2 提不出來。
所以顯而易見，強制提款或破產清算模式有其存在的必要性，雖然目前它只是依靠使用者 – 排序器這個對手方之間的博弈來發揮作用， 還稱不上真正意義的 「隨時可提款」（Arbitrum 有 24 小時延時且可能失敗，路印最長 15 天延時，StarkEx 有 7 天最大延時），但顯然 「有總比沒有好」。而且強制提款的延時問題，相信可以在未來靠著更精巧的機制設計被妥善解決 （目前主要顧及到某些 MEV 科學家可能利用 forceInclusion 發起搶跑交易，所以要引入延時。具體詳情可以閱讀各大 L2 專案方的官方資料）
隨著去中心化 Sequencer 被越來越多 L2 納入路線圖，以及 Vitalik 為首的以太坊基金會不斷向人們加強對 Layer2 安全性的教育，類似強制提款的抗審查交易功能勢必會被越來越多人所重視，這將使得以太坊 Layer2 體系更接近一個抗審查、去信任化的金融基礎設施體系。 如果 Layer2 實現了去信任化的資金進入進出方式，相信將會有更多做市商與流動性提供者進入 L2 基礎設施， 為整個 web3 的 mass adoption 向前推進一步。
