"EVM 互換"という4文字は、ETHのL2拡張の語りでは使い古されているけれど、OP Stackの退出手順を実際に開いてみると、クロスチェーンをしているのではなく、4段階のステートマシンと帳尻合わせをしていることが分かる：L2が開始 → output proposalがその取引の状態をカバーするまで待つ → L1でprove_withdrawalを行いMerkle証明を通す → 7日間のdispute gameのウィンドウを完了させてからfinalize。Base/OP Mainnet上では、ユーザーはこの件の不満をとっくに言っていた：最初の3ステップの間、資金はL1 bridgeコントラクトにロックされていて、失われたわけではないが、あなたのものでもない。さらに、途中のいずれかでL1のgasが足りない、output rootがチャレンジされる、proposerが停止する、などが起きると、出金は「Ready to prove」または「Waiting for finalization」で詰まる。

Arbitrum側は表向き2件だけ（L1でのretryable ticket作成＋L2実行）だが、ticketの自動redeemが失敗するとメモリ上のバッファに落ち、7日以内なら誰でも手動redeemできる。期限を過ぎると初めてescrowが返る。さらに厄介なのがTrail of Bitsが指摘した「順序の乱れ」による実行——AがBに先に走ってしまい、プロトコルがそのような時系列を扱えていないなら、再入型の脆弱性を埋め込んだのと同じだ。つまり「手順が少ない」ことは「状態が分かりやすい」ことと同義ではなく、複雑さをprecompileの中に隠しているだけだ。

だから#dusk のEVMテストネットからの退出を、initiate / submit proof / finalizeの3ステップに分けるのは、@Dusk がユーザーをわざと意地悪しているのではなく、OPの「7日間のチャレンジ期間＋証明の成熟度」をこっそり簡略化していない、というだけだ。だがテストネットではテスト用コインで回して通るので、ウォレットがWaiting for output proposal / Ready to prove / Waiting to finalizeといった状態の列挙を認識できることは証明できても、メインネットの高負荷下でproposerが安定してrootを出せること、dispute gameが継続的にチャレンジされてユーザーを窒息させないこと、そしてユーザーのEVM側ガスとL1側の2回の操作コストが同時に十分であることは証明できない。

私はETH L2のブリッジが「どのツールチェーンに互換だ」とは数えたことがないのを見てきた。見るのは3つの確定シグナルだけだ：退出のミドル時間が7日という理論値から下方向に収束しているか、proveに失敗した場合に次のoutput rootに差し替えて全手順をやり直さずに延命できるか、資産が詰まったときにユーザーがEtherscanのコントラクトで自分のwithdrawalの保存証明を読めるか。ボタン数が少ないのはUXの砂糖でしかない。状態が説明可能であることこそが安全の土台だ。この3点がメインネットのデータで再検証されるまでは、「EVM互換」は開発者側の便利さに過ぎず、ユーザー側の準備完了とは言えない——$DUSK これがBaseなら、同じようにArbitrumも同じ。