OP MainnetとUnichainのInterop計画とは？初期機能・開始条件・運用準備を整理

OP Stack Interopは、OP Stackで動く複数のチェーンを、共通の検証ルールのもとで連携させる仕組みです。2026年10月22日に示された初の本番計画では、OP MainnetとUnichainの2チェーンを組み合わせ、まずネイティブETHの移動を可能にする方針が示されました。

ただし、2026年12月15日は確定した開始日ではありません。技術準備に加えて、別途のガバナンス承認や協調ハードフォークが必要です。また、初期段階からあらゆるトークンやアプリが自由に連携できるわけでもありません。

この記事の主対象は、導入判断を担うアプリ開発者とノード運用者です。一般利用者にも必要な範囲を分け、確定事項と未確定事項、ETH移動の流れ、低遅延化に伴う再編リスクを整理します。

読み分け：一般利用者は「初期セット」「ETHはどう移動するか」と末尾のチェック表、アプリ開発者は「処理が成立する仕組み」と「再編リスク」、ノード運用者は開始条件以降の構成・移行・監視を中心に読むと、必要な情報を追いやすくなります。

用語の関係：OP StackはL2を構築するソフトウェア基盤、Superchainはその共通仕様やガバナンスを共有するチェーン群、Interopはそのうち依存セットに登録されたL2間でメッセージを検証する機能です。Sequencerが取引を並べ、op-nodeがL1データからL2チェーンを導出し、Verifierが結果を独立検証します。本稿は公式発表・仕様を2026年10月27日に確認して作成し、承認結果、正式な有効化時刻、指定版、対象チェーンが変わった場合に更新します。

OP MainnetとUnichainが初の本番Interopセットへ

Optimism Foundationが公開した計画は、OP MainnetとUnichainを初の本番Interopセットにするものです。発表時点の提案種別はinformational / discussionであり、計画の共有と議論を目的としています。すでに本番有効化が承認されたという意味ではない点が重要です。

初期セットを構成する2つのチェーン

「セット」とは、クロスチェーンメッセージを互いに受信できるチェーンのまとまりです。初期計画ではOP MainnetとUnichainだけが対象になります。Unichainの本番chain IDは130で、公式のSuperchain Registryに設定が記録されています。チェーン名が似ているかどうかではなく、正式な設定と依存セットへの登録によって対象を判断します。

2チェーンから始めるのは、連携範囲を限定した状態で本番の運用や障害対応を確かめるためと理解できます。これは公式資料に明記された理由ではなく、仕様からの推論であり、将来の参加チェーン数や追加時期は確定していません。依存セットへのチェーン追加はネットワークアップグレードに当たり、現行仕様ではセットから簡単に削除できないため、参加範囲は慎重に決める必要があります。

初期リリースはネイティブETH移動に限定

最初に提供される用途は、OP MainnetとUnichainの間におけるネイティブETHの移動です。ネイティブETHとは、各チェーンでガス代の支払いなどに使われるETHを指します。初期リリースを「すべての資産とアプリが即座につながる機能」と捉えるのは正確ではありません。

ERC-20や追加チェーンは段階的に対応

ERC-20トークン、アプリケーション統合、追加チェーンへの対応は、その後の段階に位置づけられています。ERC-20の相互運用にはERC-7802への適合、チェーン間で同じコントラクトアドレスを使うこと、適切なmint・burn権限などが関係します。ネイティブETHが動けば既存の全トークンも自動的に動く、という関係ではありません。

関連する基礎知識を整理したい場合は、クロスチェーンの仕組みとレイヤー2の解説も参考になります。

12月15日は確定日ではない　有効化に必要な条件

2026年12月15日は承認前の目標日

運用準備文書では、テストネットを2026年12月3日、本番を同年12月15日に有効化する目標が示されています。しかし、本番の正確な時刻は設定されておらず、ガバナンス承認前です。したがって、12月15日を変更不能な締め切りやサービス開始日として扱うべきではありません。

Upgrade 20・21が準備する基盤

Upgrade 20はSuper Rootを扱う紛争ゲームを、Upgrade 21はETHLockboxなど共有L1基盤を準備します。これらはInteropに必要な土台ですが、導入されたというだけでクロスチェーンメッセージ検証が始まるわけではありません。

Super Rootを争う仕組みは、Interopが未有効の単一チェーンにも先行して導入できます。つまり「Super Rootが存在する」と「Interopが有効である」は別の状態です。準備段階のアップグレード完了を、利用開始の合図と取り違えないようにしましょう。

別途必要なガバナンス提案と協調ハードフォーク

本番有効化には、別のガバナンス提案、2チェーンで足並みをそろえるL2ハードフォーク、共有L1基盤への移行が必要です。監査、テスト、実装状況によって計画が変わる可能性もあります。運用者はカレンダーの日付だけで判断せず、承認結果、正式な時刻、指定ソフトウェア版を一組の情報として確認する必要があります。

OP Stack Interopでクロスチェーン処理が成立する仕組み

開始メッセージと実行メッセージの2段階

OP Stack Interopのクロスチェーン処理は、送信元チェーンの開始トランザクションと、宛先チェーンの実行トランザクションから成ります。開始側ではログとしてメッセージの根拠が残り、実行側はその識別情報を参照します。宛先の処理だけを見ても成立せず、送信元に対応する開始メッセージが存在し、時刻やチェーンなどの条件を満たす必要があります。

この検証を外部の独立したバリデータ集合へ丸ごと委ねる設計ではありません。OP Stackのフォーク選択と証明の仕組みを用い、Verifierがチェーンを再実行しながら整合性を確認します。ブリッジ運営者の署名数だけを見る方式とは、信頼の置き方が異なります。

依存セットが定める相互受信の範囲

依存セットは、受信側がどのチェーンの開始メッセージを認めるかを定めます。セット内のチェーンは相互にメッセージを受け取るメッシュとして扱われます。一方、セット外のチェーンを参照しても、有効な実行メッセージにはできません。

利用者やアプリは、画面に表示されたチェーン名だけでなくchain IDも照合する必要があります。名前やアイコンが似たネットワーク、テストネット、本番ネットを取り違えると、意図した実行が成立しないおそれがあります。

Super RootとVerifierが担うチェーン横断検証

Super Rootは、同じ依存セットに属する全チェーンの検証済み状態を、同じ時刻で束ねるコミットメントです。あるチェーンだけを切り離して見るのではなく、参照先をたどった先まで含む推移的な依存関係を検証します。全チェーンの必要データが確認できるまで、検証済みとしての回答は返せません。

Verifierは安全性を一段で決めるのではなく、unsafe、cross-unsafe、safe、finalizedなどの段階で追跡します。宛先ブロックが送信元の開始メッセージに依存する場合、その開始メッセージがsafeになるまで宛先側もsafeへ昇格できません。この連動が、速さと確実性の違いを生みます。

メッセージの有効期限は7日

メッセージには時刻とChain IDの不変条件があり、開始から604800秒、つまり7日を超えた実行メッセージは無効です。未来のブロックを開始元として参照することも認められません。期限は「送信操作をすれば永遠に実行できる」という誤解を防ぐ重要な条件です。

ネイティブETHは2チェーン間でどう移動するのか

送信元でLiquidityへETHを預ける

ネイティブETHの移動にはSuperchainETHBridge、L2間Messenger、ETHLiquidityが関わります。利用者が送信元のBridgeを呼び出すと、ETHは送信元チェーンのLiquidityへ預けられ、宛先での受け取りに必要なクロスチェーンメッセージが開始されます。

ここでいうLiquidityは取引所の注文板ではなく、チェーン間でネイティブETHを供給するためのシステム契約です。EVMそのものを変更せずに、各チェーンでネイティブ資産として扱えるよう設計されています。一般的な暗号資産の流動性とは文脈が異なるため注意してください。

クロスチェーンメッセージを中継する

送信元で預け入れが完了しただけでは、宛先の受取人へETHは渡りません。送信元の開始メッセージを参照し、宛先で実行する段階が必要です。このため、ユーザーから見える一連の移動であっても、ブロックチェーン上では単一取引ではなく、2つのチェーンにまたがる処理です。

宛先のLiquidityから受取人へ送る

宛先ではメッセージが検証・中継された後、宛先側のLiquidityから同額のETHが受取人へ送られます。したがって「同じETHの個体がチェーン間を瞬間移動する」というより、送信元と宛先の供給量をシステム全体で調整する仕組みとして捉えると理解しやすくなります。

実際に利用する際は、送信元と宛先、受取人アドレス、対応アプリ、手数料表示、最終確認状態を確認すべきです。送金の一般的な注意点は仮想通貨を安全に送る方法も参照できます。

Bridgeだけに許可されるmint・burn権限

ETHLiquidityのmintとburnはSuperchainETHBridgeだけが呼び出せる前提です。この権限管理が崩れると、不正な供給増加につながり得ます。利用者から見えにくい部分ですが、Bridgeのアドレスと権限が仕様どおりかは、ネイティブ資産の整合性に直結します。

ノード運用者に求められるop-supernode構成と更新準備

両チェーンの実行クライアントを用意

運用者はOP MainnetとUnichainの両方について実行クライアントを用意します。片方のチェーンだけでは、クロスチェーン依存関係をローカルに追跡できません。ディスク容量、同期時間、RPC接続数、バックアップ方針も2チェーン分を前提に見直す必要があります。

全op-nodeをLight CLとして接続

各op-nodeはLight CLとして動かし、両チェーンを導出するop-supernodeへ接続します。op-supernodeは、複数チェーンの安全性とメッセージ依存関係をまとめて追跡するSupervisorの役割を担います。ここでの「Light」は検証を省くという意味ではなく、クロスチェーン調整をsupernode側へ集約する構成を表します。

接続先やJWTなどの認証設定を誤ると、必要な状態を取り込めません。設定変更は本番当日に初めて試すのではなく、公式手順とテストネットで確認し、ロールバック条件や担当者も決めておくのが実務的です。

最低準備版と今後指定される有効化版

準備文書に示された最低版は、op-supernode v1.0.6、op-node v1.19.11、op-reth v2.6.1です。ただし、これは準備を始めるための下限であり、本番有効化に使う最終指定版ではありません。有効化版は今後案内されるため、「最低版へ上げたので作業完了」と判断しないことが大切です。

同期状態とエラーを監視するポイント

Supervisor仕様には、同期状態、RPC、データベース、エラー体系が定められています。履歴が剪定されて必要データを参照できない場合はSKIPPED_DATA、依存セット外のチェーンを参照した場合はUNKNOWN_CHAINといった状態が問題の手掛かりになります。

監視では、各実行クライアントとop-nodeの高さだけでなく、supernodeが両チェーンを認識しているか、cross-safeへの昇格が停滞していないか、DBエラーやRPC遅延がないかを見る必要があります。アラートを受けたとき、単一ノードの不調か、相手チェーン由来か、依存セット全体の問題かを切り分けられるログ保存も重要です。

低遅延化と引き換えに生じる再編・運用リスク

unsafeメッセージで再編が伝播する理由

unsafe段階の開始メッセージを受け入れると、確定を待つ時間を短くできる一方、送信元のブロックが後で再編された場合に、依存する宛先ブロックも影響を受けます。送信元のSequencerが不正な状態を提示したり、フォーク選択が変わったりすれば、そのメッセージを使った宛先の処理を維持できないためです。

これは不具合というより、低遅延を選ぶ際に引き受ける安全性上の性質です。決済完了の表示やアプリ内部の残高反映では、unsafe、safe、finalizedのどこを受け入れるかを用途別に決めなければなりません。高額処理と少額の操作で同じ基準を使う必要はありませんが、選択した基準を利用者に明示することが望まれます。

無効メッセージを含むブロックの置換

無効な実行メッセージを含むブロックは、同じ高さのdeposit-onlyブロックへ置き換えられ得ます。deposit-onlyブロックはユーザー取引を除き、L1由来のdepositを中心に再構成するものです。問題のメッセージだけを無視して他のユーザー取引をそのまま残すのではなく、ブロック単位でフォーク選択に反映されます。

アプリ側では、一度表示した結果がunsafe段階では巻き戻る可能性を考慮し、冪等な処理、再試行、二重計上の防止、状態変化の通知を設計する必要があります。特に、外部サービスへの出荷や別資産の払い出しなど、ブロックチェーン外で取り消しにくい処理を早い段階で実行する場合は慎重な判断が必要です。

遠隔RPC参照が広げるDoS面

Interop取引をトランザクションプールへ受け入れるには、依存メッセージの確認にEVM実行や遠隔状態参照が必要になる場合があります。攻撃者が検証コストの高い依存関係を多数送り込めば、RPCやCPUへ負荷をかける余地が増えます。仕様も遠隔RPC参照がDoS面を広げる点を扱っています。

対策では、RPCのレート制限、タイムアウト、接続先の分離、キャッシュ、メトリクス監視を組み合わせます。ただし、制限を厳しくしすぎると正当なメッセージ検証まで遅れるため、負荷試験に基づく調整が必要です。

CPU・ストレージ・障害対応の負荷

複数チェーンのログ、実行結果、依存関係を追うため、単一チェーン運用よりCPU、ストレージ、ネットワーク、RPCの負荷が増えます。必要な履歴を早く剪定すると検証できず、保持期間を伸ばせば容量が増えます。公式仕様では一律のハードウェア要件が示されていないため、自環境のトラフィックと同期速度を計測して余裕を見積もるべきです。

障害対応の範囲も広がります。OP Mainnet側が正常でもUnichain側のデータ取得が止まれば、クロスチェーンの安全性更新が停滞する可能性があります。担当チームをチェーン別に完全分離する場合でも、連絡経路と共通の判断基準は用意しておく必要があります。

共有L1基盤への移行で注意すべき影響範囲

ETHLockboxと紛争基盤をセット内で共有

Interopセットでは、参加チェーンのPortalがETH残高を共有ETHLockboxへ移し、DisputeGameFactoryやAnchorStateRegistryなど共有の紛争解決基盤へ接続します。チェーン横断の整合性を共通の基盤で扱える一方、一部の問題がセット全体の検証や出金へ影響する可能性があります。

「共有」は、すべてのチェーン状態が同一になるという意味ではありません。各L2はそれぞれの状態を持ちながら、L1上の資産保管や紛争解決の接点を共有します。運用者はL2ノードだけでなく、共有L1契約の移行状態も監視対象に含めます。

Interopセットへの移行は一方向

独立したチェーンからInteropセットへの移行は一方向です。元の構成へ戻すには契約アップグレードが必要で、単純な設定の巻き戻しでは済みません。そのため、本番移行前にはテスト結果、契約アドレス、権限、手順、緊急時の意思決定を確認する必要があります。

移行前の出金証明は再証明が必要

移行前の紛争ゲームに対して作成された出金証明は無効化され、利用者は新しい基盤に対して再証明する必要があります。証明済みという表示だけを見て放置すると、移行後にそのまま完了できない可能性があります。サービス運営者は対象ユーザーへの案内、再証明の画面導線、問い合わせ対応を準備すべきです。

Super Root導入だけではInteropは始まらない

Super Rootを使う紛争ゲームは、クロスチェーンメッセージ検証より先に導入できます。共有L1基盤への移行やSuper Rootの観測だけを根拠に、Bridge操作を解禁してはいけません。公式ガバナンスで承認された有効化条件と、実際のチェーン設定を照合することが必要です。

移行作業では、ノード運用者とアプリ運営者、利用者で確認する対象が異なります。ノード運用者はL1契約と各クライアントの状態、アプリ運営者は対応するメッセージ経路と安全水準、利用者は公式画面と宛先を主に確認します。役割を分けずに「誰かが確認しているはず」とすると、契約移行は完了しているのに画面が旧アドレスを参照する、といった境界部分の見落としが起こり得ます。

とくに出金証明の再証明は、ノードの正常性だけでは利用者へ伝わりません。移行前に証明した利用者を識別できるか、どの画面で再操作を案内するか、旧証明が使えない理由をどう説明するかまで準備しておくと、移行後の混乱を抑えやすくなります。公式仕様は個別サービスの画面設計まで定めていないため、各サービスが自らの導線に合わせて設計する領域です。

対象者別・有効化前後の実務チェックリスト

ここまでの説明を、担当者がそのまま確認に使える形へまとめます。未達項目がある場合は、日付を理由に処理を開始せず、表の対応を優先してください。

利用者向け画面では「送信元で開始済み」「宛先で実行可能」「宛先で実行済み」「安全性が昇格済み」を分けると、障害地点を判断しやすくなります。操作前後のトランザクション識別子も保存しておけば、問い合わせ時にどちらのチェーンまで進んだかを追跡できます。

開発者は正常系だけでなく、7日の期限切れ、未来時刻、依存セット外のchain ID、送信元再編を試験します。無効なメッセージが拒否されること、再実行で二重計上されないこと、unsafeの表示が確定と誤認されないことが合格条件です。監視では件数だけでなく、cross-safeへの昇格時間、遠隔RPCの失敗率、再試行、DB容量、チェーン間の同期差を追います。公式仕様に一律の警戒値はないため、テストネットと自社環境の平常値から閾値を定めます。

表の使い方：一般利用者は公式対応の有無と送付条件、開発者は状態遷移と異常系、運用者は承認・構成・監視をそれぞれ自分の合格条件として確認します。担当外の行も、引き継ぎ点だけは確認してください。たとえばノードが正常でもアプリが旧契約を参照していれば利用を開始できず、画面が対応済みでも依存セットの検証が進まなければ安全性は昇格しません。技術状態と利用者表示の両方が一致して初めて運用判断が成立します。

unsafe、safe、finalizedは単なる待ち時間の名称ではありません。送信元の状態が変わったときに宛先処理を巻き戻せるか、商品発送や外部決済のようなチェーン外処理を取り消せるかまで含めて選びます。少額なら必ずunsafeでよい、一定時間待てば必ずsafeになる、と固定せず、実際の安全状態を参照する設計が必要です。

結論として、初期計画はOP MainnetとUnichain間のネイティブETH移動に限定され、2026年12月15日は承認前の目標日です。一般利用者は公式対応経路と宛先を確認し、開発者は2段階処理と安全状態を設計し、運用者は両チェーンとop-supernodeを含む構成を検証してください。次の判断材料は、正式なガバナンス承認、有効化時刻、本番指定版の公表です。