L2が止まったら資産は戻せるか｜ロールアップのデータ可用性と強制退出の確かめ方

ある会社が、自社のサービスをL2（ロールアップ）の上で動かそうとしています。利用者の資産も、そのL2に預かることになります。採用を決める責任者には、手数料や速さより先に確かめたいことがありました。L2が止まったとき、預けた資産をL1へ戻せるのか。

答えは、3つの手順が運営者抜きでつながるかどうかで決まります。

1. 保存されたデータから、最新の残高を作り直す
2. 運営者を通さず、L1から取引を送る
3. L1で資産を受け取る

1の「作り直す」には、過去のデータが要ります。そのため、必要な履歴や証明を、運営者とは別の手段で手に入れられるかも確かめます。

以下では、この責任者が採用を判断する順に、障害の見分け方、データの置き場所（データ可用性の方式）による違い、実際の退出手順の例、訓練の項目を見ていきます。L2の基礎はL2/独自チェーン学習ロードマップが入口になります。

「L2が止まった」は3種類に分けて考える

「L2が止まった」と分かっただけでは、どう動くべきか決められません。利用者が待つべきか、L1から強制的に取引を送るべきか、最後に確定した状態まで退避すべきか。そこで少なくとも次の3種類を、別々のアラートと手順書にします。

blobはL2がL1へデータを載せるための入れ物、commitmentはデータの中身を指し示す要約値です。障害ごとに失われるものは違います。

• シーケンサーの停止・検閲：取引をすぐに受け付けてもらうこと
• バッチ投稿の停止：L1から安全に状態を導けることと、取引の確定性（finality）
• オフチェーンDAの停止：第三者が自分で状態を作り直し、証明を作れること

OP Stackの公式ドキュメントも、シーケンサー自体が取引を処理できない障害と、処理済みの取引をL1へ投稿できない障害を分けています。前者は、L1のOptimismPortalへ取引を送る手段で迂回できます。後者で大事なのは、L2の仮の確認（soft confirmation）を、L1から導ける状態と取り違えないことです（Optimism Docs: Sequencer outages）。

退出できるとは、運営者以外が3つの手順をやり切れること

退出できる、とは非常ボタンがあることではありません。障害が起きても、運営者以外の誰かが次の3つを最後までやり切れることです。

1. 状態を作り直せる：最後にL1で確定した状態までのバッチのデータ、状態の差分、実行の規則、ノードのソフトウェアを手に入れられる。
2. シーケンサーを迂回できる：L1の受付口（inboxやportal）へ取引を出し、決められた期限の後に正式なL2チェーンへ取り込ませられる。
3. L1の資産を引き出せる：出金の状態遷移、不正証明／有効性証明（fraud/validity proof）、異議申立の期間を経て、L1の預け先（escrow）から正しい持ち主へ移せる。

この3つは、保存されたデータ → 状態の作り直し → L1への強制取引 → L1の資産の引き出し、の順につながります。どこか1か所でも第三者が実行できなければ、退出の道は途切れます。

なぜデータがそれほど大事なのか。Ethereum.orgは、データがなければ状態の遷移を独立に確かめられないと説明しています。ZK Rollupでも、利用者は自分の残高を知ることも、状態の更新に要る情報を作ることもできません（ethereum.org: Data availability）。

有効性証明は「遷移は正しい」と保証します。しかし「利用者が最新の状態のMerkle pathを手に入れられる」ことまでは、自動では保証しません。

データの置き場所で、最悪のとき誰が作り直せるかが変わる

L1に全データを置く方式なら、第三者がL1の履歴から状態を作り直せます。一方、委員会（DAC）に任せる方式では、委員がデータを出さなければ作り直せません。ですからDA方式は、コストではなく「最悪のとき誰が作り直すか」で比べます。

calldataは取引に直接載せるデータ、genesisはチェーンの最初の状態です。確定のときに誰がデータを確かめるかは、後半の補足にまとめました。

外部DAレイヤーそのものの仕組みと比較はCelestia徹底解説とEigenDA徹底解説で扱っています。ここでは、障害のときに退出できるかという観点だけで比べます。

Ethereumのプロトコルが、ある時点でblobのデータを使える状態にしたとします。その事実だけでは、数か月後に新しいノードがgenesisから同期できるとは限りません。ある時点でデータが利用可能であること（availability）と、長く取り出せること（retrievability）は別なのです。

そこでL2の運営側は、次のことを目標値（SLO）に含めます。複数の事業者への保存、中身のhash、復元にかかる時間、ノードのバージョンとの対応です（ethereum.org: Data availability vs. retrievability）。

StarkExの公式ドキュメントでは、2つのモードの違いが説明されています。ZK-Rollupモードは、退出に要る残高の差分をチェーン上に公開します。一方、ValidiumモードはDACがチェーンの外で残高のデータを持ちます。DACの署名は「委員がデータを知っている」という信頼の上に立つもので、データそのものをL1へ置く方式ではありません（StarkEx Docs: Data availability）。

データがなければ、強制取引を送っても引き出せない

OP StackとArbitrum Nitroには、シーケンサーを迂回して取引を取り込ませる手段があります。OP StackではL1のOptimismPortalへのdeposit transaction、Arbitrum NitroではL1のDelayed Inboxです。

ただし、どちらも送った直後にL2で確定するわけではありません。取り込みまでの待ち時間（sequencing windowや強制取り込みまでの遅延）があります。そのうえ、出金の証明と異議申立の期間が別に続きます。待つ条件と運用上の扱いはシーケンサー停止時のサービス継続設計にまとめています。

ここでは、データ可用性が退出そのものを左右する例として、StarkExを見ます。

StarkEx：凍結の後の退出には、最新の状態のMerkle証明が要る

StarkEx Spotでの退出は、次の流れで進みます。

1. 利用者が、チェーン上で全額の出金（full withdrawal）を要求する
2. アプリケーションが猶予期間（既定7日）のうちに処理しなければ、システムを凍結（freeze）へ移せる
3. 凍結した時点の残高の要約値（vault treeのroot）に対するMerkle pathを手に入れ、退出（escape）の手続きをして、保留中の出金から引き出す

大事なのは、公式手順が次の前提に立っている点です。「凍結後は、アプリのデータ可用性の方式に応じて、そのデータが公開されるか、アプリのAPIから取得できるはず」（StarkEx Docs: Withdrawing and escaping）。

前に見たとおり、ZK-Rollupモードは残高の差分をチェーン上に公開します。しかしValidiumモードでは、DACがデータを出さなければどうなるか。状態の遷移が正しく証明されていても、利用者は退出に要るMerkle pathを用意できないおそれがあります。つまり、証明が正しくても、データを持っていなければ引き出せないことがあるのです。

アプリの中の資産は、同じように戻るとは限らない

LPトークン、貸付の持分、無期限先物のポジション、クロスチェーンのラップ資産。こうしたアプリの中の資産は、L2上の複数のコントラクト、Oracle、定期実行のボット（keeper）、外部のブリッジに頼っています。

そのため、ロールアップ本体からETHや標準的なトークンを引き出せても、アプリの中のポジションが同じように戻るとは限りません。障害の間に解消できなければ、L1へ出せるのはポジションを表すトークンだけかもしれません。何も出せない場合もあります。

• 資産ごとに、L1の預け先、L2での表し方、発行・焼却の権限、正式なブリッジを対応付ける。
• 通常の出金、シーケンサーの迂回、システムの凍結、アップグレード／guardian（緊急停止の権限を持つ者）による停止を、別々の状態遷移として図にする。
• Oracleが止まったときの清算、利息の積み上がり、期限の到来をどう扱うかを、プロトコルの仕様に書く。
• 緊急用の画面がなくても使えるよう、コントラクトアドレス、ABI、calldata、証明の作り方を、別に保管する。

ですから採用の判定は、「L2がStage 2か」「非常口（escape hatch）があるか」というラベルだけで終えません。Stage 2は、運営者への依存の少なさを示す成熟度の段階です。自社が持つ・預かる資産の一つひとつについて、L1への最後の送金までたどって確かめます。

四半期ごとの復旧訓練で、本当に退出できるかを確かめる

訓練では、次のことをすべて通せるかを確かめます。

• L1で最後に確定したバッチ／rootと、L2の未確定・安全・確定したブロックを区別して表示できる
• 主系のRPCやシーケンサーのAPIなしで、保存したデータから同じstate rootを作り直せる
• 一般の利用者の権限のウォレットから、L1のinbox/portalへ強制取引を出せる
• 待つ期限の後に取引が正式なチェーンへ入り、再編成（reorg、直近のブロックの組み替え）のときの扱いも確かめられる
• 代表的な資産と複合ポジションについて、証明の作成からL1での受け取りまで、テストネット／フォーク環境で最後まで通せる
• ノードの実行ファイル、genesis、コントラクトアドレス、ABI、鍵、アーカイブを、別の管理者から復元できる
• 新規入金の停止、利用者への通知、復旧の判定、権限を使う責任者と二重承認が決まっている

訓練の結果には、データの欠損率、状態の作り直しにかかった時間、L1のガス、強制取り込みまでの時間、出金の完了時間、手作業、失敗した箇所を残します。

目標時間を超えたら、「手順書を更新」だけで閉じません。アーカイブを複数持つ、証明ツールを自動でビルドする、監視役（watcher）を置く、画面を直す、といった改善をします。

どんなときは採用を見送るか

次のどれかが、業務上の最大損失を超える場合は、そのDA方式またはRollupの採用を保留します。

• 最新の確定状態を、第三者が作り直せない
• 強制取引が、管理者による停止の影響を受ける
• アップグレードのときの退出猶予期間（exit window）内に、全利用者が退避できない
• 主要な資産が、正式な退出の手順に対応していない
• 復旧用のソフトウェアとデータを、運営者以外が手に入れられない

安い取引手数料は、この退出できないリスクの代わりにはなりません。

ロールアップ、RaaS、DAを基礎から確認する場合はL2/独自チェーン学習ロードマップ、障害時の出金を利用者にどう見せるかはL2出金の待ち時間とUX設計を参照してください。

技術担当者向けの補足

確定のときに、誰がデータを確かめるか

• L1 calldata：L1のフルノードがブロックのデータとして持つ
• Ethereum blob：Ethereumの合意の仕組みが、公開期間中の可用性を保証する
• 外部のDAレイヤー：採用したDAネットワークのバリデーター・サンプリングノード
• DACを使うValidium：委員会の定足数（quorum）がデータの保有を署名する

StarkExの退出で使う名前

猶予期間はFREEZE_GRACE_PERIOD、凍結の要求はfreezeRequestです。退出では、凍結したvault treeのrootに対するMerkle pathを取得し、verifyEscapeとescapeを呼んでから、保留中の出金から引き出します。

L2のブロックの段階

訓練の1項目めの「未確定・安全・確定したブロック」は、OP Stackなどでいうunsafe/safe/finalized headにあたります。

XTELAができること

XTELAは、L2・独自チェーンの要件整理から、DA・ブリッジ・権限の信頼の境界の設計、障害シナリオ、監視、復旧訓練、PoCと実装までを行います。貴社のシステムが障害時に本当に退出できるかを、保存データからL1での受け取りまで実際に通して確かめます。退出経路の検証について相談する

主要参考資料

• ethereum.org: Data availability
• Optimism Docs: Sequencer outages
• Optimism Docs: Forced transaction
• OP Stack Specification: Derivation
• Arbitrum Nitro whitepaper
• StarkEx Docs: Data availability
• StarkEx Docs: Withdrawing and escaping without application approval（2026年9月24日確認）

資料の確認日と注意

最終確認日は2026年8月12日（StarkExの退出手順は2026年9月24日）です。ロールアップごとのコントラクト、待機時間、アップグレード権限、DAの構成は変わるため、本番採用時は対象チェーンの設定値とデプロイ済みのコントラクトを確かめてください。