首頁

Partnered With:

對Layer2而言，強制提款與逃生艙功能到底有多重要？

极客 Web3

閱讀本文需 20 分鐘

可以讓使用者把資產安全撤回至Layer1的「強制提款」功能，已然成為不可或缺的必備設施。

原文標題：《對 Layer2 而言，強制提款與逃生艙功能到底有多重要？》

原文來源：Faust，極客Web3

在現實世界中，幾乎每一棟高樓大廈都有一個不可或缺的要素：安全出口。當火災地震等突發事件降臨時，安全出口就是保障民眾生命安全的救命稻草。而在以太坊 Layer2 這個承載了百億美元資產的託管平台體系中，可以讓用戶把資產安全撤回至 Layer1 的「強制提款」功能，已然成為不可或缺的必備設施。

Vitalik 在最近的文章「Different types of layer 2s」中也強調，使用者能否順利的把資產從Layer2 撤回至Layer1，是一個非常重要的安全指標。

但「順利提款」問題在過去似乎沒有得到大多數人的重視，甚至許多Layer2 專案方都沒有上線「強制提款」或「逃生艙」功能。在 L2 生態體系未成火候的時代，漠視「無需許可的提款」似乎不成問題。但如今 Layer2 已經承載了 120 多億美元的資產，已然變成了一棟「太大而不能倒」的大廈。如果這樣的摩天大樓沒有安全出口，後果簡直是不可想像的。

抱著讓廣大讀者重視Layer2 安全風險的目的，《極客web3》將在下文以路印協議V3 和Arbitrum 為例，為大家闡明為何forced withdraw 與escape hatch 等“無需許可的提款功能」是Layer2 不可缺少的一環。

（根據L2BEAT dYdX 瀏覽器顯示，迄今為止dYdX 強制交易/提款功能，總計被使用過152 次，超過100 萬美元的大額提款多達7 筆）

抗審查性是大問題：如果Sequencer 故意拒絕你的請求，怎麼辦？

過去關於Layer2 的科普文章往往有一個問題，就是大多數時候都著重強調「安全性」與表面上的「可用性」，卻忽略了「抗審查性」。即便是在談論去中心化排序器方案時，許多人注意到的也是 MEV 是否去中心化，而不是抗審查性的改善。

換句話說，大多數人往往注重Layer2 的狀態轉換是否有效，排序器能不能盜幣，欺詐證明/有效性證明系統有沒有投入使用，卻忽略了一個不該被忽視的風險：如果Sequencer 一直拒絕你的交易請求，或者乾脆長時間故障，甚至停機，這個時候怎麼辦？

要知道，在 Solana 宕機期間，曾有人因為資產面臨清算而無法及時補倉，使得幾百萬美元的資產面臨風險。此類拒絕用戶請求的場景一旦發生，造成的經濟損失並不可小視。

即便只有個別人可能遭遇此類情況，但如果落到了一些手握大量資金的鯨魚身上，整個市場都可能連帶遭殃（假設某人在以太坊上的Defi 借貸協議有幾億美元資產可能在一周內被清算，但他因為用了Tornado 而被OFAC 列入製裁名單。獨立於以太坊的公鏈上去分析。如果 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 向前推進一步。