作者：imToken
もしあなたが頻繁にBase、Arbitrum、Optimism間をクロスチェーンで行き来しているなら、微妙な「断絶感」を感じたことがあるでしょう。
単一のL2取引はほぼ秒で完了しますが、資産をチェーンAからチェーンBに移す際には、数分、あるいはそれ以上の待ち時間が必要になることが多いです。これはL2自体の速度が遅いからではなく、従来のプロセスにおいて、クロスレイヤー・クロスチェーンを含む取引は、長く厳格なルートを経る必要があるためです。
L2ソーターによる並び替え → L1に提出 → L1の合意と最終確定（Finality）、要するに、現在のイーサリアムのアーキテクチャでは、L1の最終確定には通常2つのEpoch（約13分）が必要です。これは安全性のために必要なことですが、相互運用性（Interop）にとっては遅すぎると感じられます。
結局のところ、イーサリアムの大きなビジョンの中では、将来的に何百何千ものL2が存在し、それらは互いに孤立した実行の孤島ではなく、全体として協調して動作すべきです。そうであれば、問題の核心は、この待ち時間をできるだけ短縮できるかどうかにかかっています。
この背景のもと、イーサリアムのInteropロードマップは加速（Acceleration）段階で、次の3つの高度に協調した改善方向を明確に示しています：高速確認ルール（Fast L1 Confirmation Rule）、L1スロット時間の短縮（Shorter L1 Slots）、二層ネットワーク決済周期の圧縮（Shorter L2 Settlement）。
これは散発的な最適化ではなく、「確認、拍子、決済」を軸としたシステム的な再構築と言えます。
現状のイーサリアムアーキテクチャでは、メインネットのブロック生成間隔は約12秒であり、バリデータは各スロットで現在のチェーン状態に対して投票します。そして最終確定（Finality）は複数のスロット後に達成されます。
要するに、取引がブロックに含まれていても、システムは長時間待たなければ、その取引が再編や巻き戻しのリスクから安全であると確信できません。現在のところ、取引の最終的な確定には約2 Epoch（13分）が必要とされており、多くのオンチェーン金融シナリオにとっては長すぎると感じられます。
では、「Finalityが到達する前に、アプリケーションやクロスチェーンシステムに『十分に速く、かつ十分に信頼できる』確認信号を提供できないか？」これがイーサリアムのInteropロードマップで明確に示されたProject #4：Fast L1 Confirmation Rule（高速確認ルール）の目的です。
その核心は非常にシンプルで、アプリケーションやクロスチェーンシステムが15〜30秒以内に、「強力かつ検証可能な」L1確認信号を得られるようにし、13分の完全なFinalityを待つ必要をなくすことです。
仕組みとしては、迅速確認ルールは新たなコンセンサスプロセスを導入するのではなく、イーサリアムのPoS体系において各スロットで行われるattester投票を再利用します。あるブロックが早期のスロットで十分な数の分散した検証者投票を蓄積していれば、たとえ最終確定段階に入っていなくても、「合理的な攻撃モデル下では、ほぼ巻き戻される可能性が極めて低い」と見なすことができるのです。
要するに、この確認レベルはFinalityを置き換えるものではなく、Finality前に、プロトコルが明確に認める強い確認を提供します。これにより、クロスチェーンシステムやIntent Solver、ウォレットは、最終性の確定を盲信せずとも、15〜30秒以内に安全に次の処理を進められるのです。
現在、Based Rollupのストーリーで推進されているプリ確認（Preconfirmation）も、この方向性の重要な工程的役割を担っています。そのロジックは非常にシンプルで、字義通りに考えると、例えば：
12306で電車のチケットを購入する際、行程を選択して署名取引を行うと、予約システムは事前確認情報を提供します。これは、「あなたの購入行為（各取引）が受理され、次の確認プロセスに入った」ことを示すものであり、その時点で私たちは行程の計画や荷物の準備を始めることができ、最終的に座席や車両が確定（取引がL1に公開）された段階で、正式に購入・予約が完了します。
要するに、Based Rollupにおいて、プリ確認は取引が正式にL1に提出されて確認される前に、その取引をブロックに含めることを約束し、ユーザーに「取引は受理され、処理中である」という初期の確認信号を与える仕組みです。
「最初に強い口頭の約束をし、最終確定は後で追補する」この階層的確認のロジックにより、イーサリアムのInteropロードマップは、「安全性」と「速度」の間で微細に信頼レベルを切り分け、できるだけスムーズな相互運用体験を構築しています。
迅速確認ルールのような「コンセンサス層の論理的再構築」に並行して、より根本的で物理的な変更が必要です。それは、スロットの長さを短縮することです。
もし迅速確認が「最終的な合意前に一時的な約束」をするものであれば、L1スロット時間の短縮は帳簿の「清算周期」を直接短縮することになります。InteropロードマップのProject #5の段階的目標は、イーサリアムメインネットのスロット時間を現在の12秒から6秒に圧縮することです。
これは一見単純な「半減」ですが、実際にはチェーン全体に連鎖的な影響をもたらします。スロットが短くなるほど、取引のブロックへの取り込み、検証、確認のリズムが速まり、全体のプロトコルレイヤーの遅延が低減します。
ユーザーの実体験にも直結し、L1のインタラクション（例：ETHの送金）の確認感覚が速くなるほか、L2の状態をL1に提交するリズムもタイトになり、さらに短いスロットと高速確認ルールの組み合わせは、「ほぼリアルタイムのオンチェーンフィードバック」を形成します。これにより、エコシステム内のDAppやウォレット、クロスチェーンプロトコルは、「秒単位の確認体験」をより良く構築できるのです。
クロスチェーンの相互運用プロトコルにとって、時間短縮は資金利用効率の飛躍的向上を意味します。現在のクロスチェーンブリッジやマーケットメーカーは、異なるチェーン間の資産調整において、数分、あるいはそれ以上の「資金の流れ待ち」リスクを負っています。このリスクをヘッジするために、より高い手数料を徴収せざるを得ません。
しかし、L1の決済周期が短縮され、資金の回転速度が倍増すれば、その「流れ待ち」の資本占用は著しく減少します。結果として、摩擦コストの低減、ユーザー手数料の削減、着金遅延の短縮が実現し、開発者やユーザーは安全なL1決済層に再び回帰しやすくなるのです。
もちろん、「心拍」の頻度を倍にするのは容易ではありません。イーサリアム基金会の複数の作業グループが、この複雑なエンジニアリングを並行して推進しています。
総じて、6秒スロットと高速確認ルールの組み合わせにより、イーサリアムは「ほぼリアルタイムのオンチェーンフィードバック」を実現し、エコシステムのdAppやウォレットは、これまでにない秒単位の確認体験を構築できる見込みです。
InteropロードマップのProject #6：Shorter L2 Settlementは、最も議論を呼ぶとともに、最も想像力を刺激する部分です。
現状のアーキテクチャでは、Optimistic Rollupは通常7日のチャレンジ期間に依存しています。ZK Rollupも証明の生成と検証のリズムに制約されており、安全性は申し分ないものの、相互運用の観点からは現実的な問題を抱えています。
資産や状態が「時間ロック」されたまま、チェーン間を移動することになり、これがコスト増やSolverの再バランス負担増を招き、最終的にはユーザーの手数料や遅延を増大させるのです。したがって、決済周期の短縮は、相互運用のスケール化において重要なレバーとなります。現在の主な技術的方向性は次の通りです。
ただし、相互運用の議論において避けて通れない核心的疑問は、もし決済チャレンジ期間を従来の7日から1時間に短縮した場合、攻撃者に悪用の余地を残すのではないか、という点です。
理論的には、この懸念は根拠のないものではありません。特に、「強い検閲」（検証ノードの集団による悪意ある行為）とは異なり、実際に警戒すべきは、ブロックビルダー主導のソフト検閲攻撃です。攻撃者はコンセンサスを制御する必要はなく、ただ防御者の取引を抑制し続けるだけで、重要な取引をオンチェーンに載せられなくなるのです。
興味深いことに、こうしたシナリオに関する唯一の体系的な経済学的分析は、Offchain Labsが2025年2月に発表した論文《Economic Censorship Games in Fraud Proofs》にあります。この論文は、最も悲観的なモデルから比較的楽観的なモデルまで、3つのモデルを構築しています。
実務では、検証者が空スロットを選ぶ可能性もあり、設計によっては最悪のG¹モデルに退化することもあります。そのため、論文は最悪ケースから分析を行っています。
この前提のもと、研究者は「少額で大きく防ぐ」遅延防御メカニズムを提案しています。これは、「一クリック遅延」権を持つ防御者が、短時間で複雑な誤り検証を完了しなくてもよい仕組みです。重要な取引をオンチェーンに載せるためのトリガーとなる特別な取引を成功させれば、その時点でチャレンジ期間は自動的に7日に延長されるのです。
例えば、防御者がL2の状態異常を発見した場合、1時間以内にすべての検証を完了しなくても、L1に特別な取引を送信するだけで、チャレンジ期間は一気に7日に戻ります。これにより、攻撃者は非対称のコストを負う必要が出てきます。攻撃者は高額の優先手数料を支払い続ける必要があり、その間に防御者は一度の成功で長期の遅延を引き起こせるのです。
論文の定量的な試算によると、資金力のある攻撃者が100億ドルの資金を投入して継続的な検閲攻撃を仕掛ける場合、
つまり、これは非常に重要な構造的優位性を持つ仕組みです。攻撃者のコストは線形に増加しますが、防御者は一度の成功だけで済むため、コスト比は非常に高くなります。
このコスト対安全性の比率（Cost to Attack vs. Cost to Defend）は、決済周期を大幅に短縮しても、イーサリアムの経済的安全性を堅持できることを示しています。
相互運用にとっても、これは極めて重要です。高速確認と短縮された決済周期は、安全性を犠牲にしなくても実現可能であり、合理的な制度設計の下では、秒単位のクロスチェーンと経済的安全性の両立も十分に可能です。これにより、秒級クロスチェーンの実現に向けた最も堅固な基盤が整います。
( 最後に一言
なぜ数秒、数分の遅延を最適化するためにこれほど努力するのか、と疑問に思う人もいるでしょう。
Web3のガジェット時代では、「待つこと」が当たり前であり、「待つこと」が分散化のために支払うべきプレミアムだと考えられてきました。しかし、Web3が一般ユーザーに広がる過程では、ユーザーは自分がどのチェーン上で操作しているかを気にすべきではなく、またL1の最終性のロジックを計算すべきでもありません。
高速確認、6秒のハートビート、そして非対称の防御メカニズムは、本質的に一つのことを実現しています——「時間」という変数をユーザーの感覚から消し去ることです。
私が最近繰り返し述べている言葉ですが、技術の最良の形態は、「複雑さを高速な確認の中で徹底的に消し去ること」です。
18.45K 人気度
43.88K 人気度
54.91K 人気度
97.34K 人気度
3.87K 人気度
イーサリアムの「秒単位」進化：高速承認から決済圧縮まで、Interopは待ち時間をどのように排除するのか？
作者：imToken
もしあなたが頻繁にBase、Arbitrum、Optimism間をクロスチェーンで行き来しているなら、微妙な「断絶感」を感じたことがあるでしょう。
単一のL2取引はほぼ秒で完了しますが、資産をチェーンAからチェーンBに移す際には、数分、あるいはそれ以上の待ち時間が必要になることが多いです。これはL2自体の速度が遅いからではなく、従来のプロセスにおいて、クロスレイヤー・クロスチェーンを含む取引は、長く厳格なルートを経る必要があるためです。
L2ソーターによる並び替え → L1に提出 → L1の合意と最終確定（Finality）、要するに、現在のイーサリアムのアーキテクチャでは、L1の最終確定には通常2つのEpoch（約13分）が必要です。これは安全性のために必要なことですが、相互運用性（Interop）にとっては遅すぎると感じられます。
結局のところ、イーサリアムの大きなビジョンの中では、将来的に何百何千ものL2が存在し、それらは互いに孤立した実行の孤島ではなく、全体として協調して動作すべきです。そうであれば、問題の核心は、この待ち時間をできるだけ短縮できるかどうかにかかっています。
この背景のもと、イーサリアムのInteropロードマップは加速（Acceleration）段階で、次の3つの高度に協調した改善方向を明確に示しています：高速確認ルール（Fast L1 Confirmation Rule）、L1スロット時間の短縮（Shorter L1 Slots）、二層ネットワーク決済周期の圧縮（Shorter L2 Settlement）。
これは散発的な最適化ではなく、「確認、拍子、決済」を軸としたシステム的な再構築と言えます。
一、迅速確認ルール：Finality前にシステムに「信頼できる答え」を与える
現状のイーサリアムアーキテクチャでは、メインネットのブロック生成間隔は約12秒であり、バリデータは各スロットで現在のチェーン状態に対して投票します。そして最終確定（Finality）は複数のスロット後に達成されます。
要するに、取引がブロックに含まれていても、システムは長時間待たなければ、その取引が再編や巻き戻しのリスクから安全であると確信できません。現在のところ、取引の最終的な確定には約2 Epoch（13分）が必要とされており、多くのオンチェーン金融シナリオにとっては長すぎると感じられます。
では、「Finalityが到達する前に、アプリケーションやクロスチェーンシステムに『十分に速く、かつ十分に信頼できる』確認信号を提供できないか？」これがイーサリアムのInteropロードマップで明確に示されたProject #4：Fast L1 Confirmation Rule（高速確認ルール）の目的です。
その核心は非常にシンプルで、アプリケーションやクロスチェーンシステムが15〜30秒以内に、「強力かつ検証可能な」L1確認信号を得られるようにし、13分の完全なFinalityを待つ必要をなくすことです。
仕組みとしては、迅速確認ルールは新たなコンセンサスプロセスを導入するのではなく、イーサリアムのPoS体系において各スロットで行われるattester投票を再利用します。あるブロックが早期のスロットで十分な数の分散した検証者投票を蓄積していれば、たとえ最終確定段階に入っていなくても、「合理的な攻撃モデル下では、ほぼ巻き戻される可能性が極めて低い」と見なすことができるのです。
要するに、この確認レベルはFinalityを置き換えるものではなく、Finality前に、プロトコルが明確に認める強い確認を提供します。これにより、クロスチェーンシステムやIntent Solver、ウォレットは、最終性の確定を盲信せずとも、15〜30秒以内に安全に次の処理を進められるのです。
現在、Based Rollupのストーリーで推進されているプリ確認（Preconfirmation）も、この方向性の重要な工程的役割を担っています。そのロジックは非常にシンプルで、字義通りに考えると、例えば：
12306で電車のチケットを購入する際、行程を選択して署名取引を行うと、予約システムは事前確認情報を提供します。これは、「あなたの購入行為（各取引）が受理され、次の確認プロセスに入った」ことを示すものであり、その時点で私たちは行程の計画や荷物の準備を始めることができ、最終的に座席や車両が確定（取引がL1に公開）された段階で、正式に購入・予約が完了します。
要するに、Based Rollupにおいて、プリ確認は取引が正式にL1に提出されて確認される前に、その取引をブロックに含めることを約束し、ユーザーに「取引は受理され、処理中である」という初期の確認信号を与える仕組みです。
「最初に強い口頭の約束をし、最終確定は後で追補する」この階層的確認のロジックにより、イーサリアムのInteropロードマップは、「安全性」と「速度」の間で微細に信頼レベルを切り分け、できるだけスムーズな相互運用体験を構築しています。
二、L1スロットの短縮：イーサリアムの「心拍」周期を加速
迅速確認ルールのような「コンセンサス層の論理的再構築」に並行して、より根本的で物理的な変更が必要です。それは、スロットの長さを短縮することです。
もし迅速確認が「最終的な合意前に一時的な約束」をするものであれば、L1スロット時間の短縮は帳簿の「清算周期」を直接短縮することになります。InteropロードマップのProject #5の段階的目標は、イーサリアムメインネットのスロット時間を現在の12秒から6秒に圧縮することです。
これは一見単純な「半減」ですが、実際にはチェーン全体に連鎖的な影響をもたらします。スロットが短くなるほど、取引のブロックへの取り込み、検証、確認のリズムが速まり、全体のプロトコルレイヤーの遅延が低減します。
ユーザーの実体験にも直結し、L1のインタラクション（例：ETHの送金）の確認感覚が速くなるほか、L2の状態をL1に提交するリズムもタイトになり、さらに短いスロットと高速確認ルールの組み合わせは、「ほぼリアルタイムのオンチェーンフィードバック」を形成します。これにより、エコシステム内のDAppやウォレット、クロスチェーンプロトコルは、「秒単位の確認体験」をより良く構築できるのです。
クロスチェーンの相互運用プロトコルにとって、時間短縮は資金利用効率の飛躍的向上を意味します。現在のクロスチェーンブリッジやマーケットメーカーは、異なるチェーン間の資産調整において、数分、あるいはそれ以上の「資金の流れ待ち」リスクを負っています。このリスクをヘッジするために、より高い手数料を徴収せざるを得ません。
しかし、L1の決済周期が短縮され、資金の回転速度が倍増すれば、その「流れ待ち」の資本占用は著しく減少します。結果として、摩擦コストの低減、ユーザー手数料の削減、着金遅延の短縮が実現し、開発者やユーザーは安全なL1決済層に再び回帰しやすくなるのです。
もちろん、「心拍」の頻度を倍にするのは容易ではありません。イーサリアム基金会の複数の作業グループが、この複雑なエンジニアリングを並行して推進しています。
総じて、6秒スロットと高速確認ルールの組み合わせにより、イーサリアムは「ほぼリアルタイムのオンチェーンフィードバック」を実現し、エコシステムのdAppやウォレットは、これまでにない秒単位の確認体験を構築できる見込みです。
三、L2決済周期の短縮：資産「即提・即走」へ
InteropロードマップのProject #6：Shorter L2 Settlementは、最も議論を呼ぶとともに、最も想像力を刺激する部分です。
現状のアーキテクチャでは、Optimistic Rollupは通常7日のチャレンジ期間に依存しています。ZK Rollupも証明の生成と検証のリズムに制約されており、安全性は申し分ないものの、相互運用の観点からは現実的な問題を抱えています。
資産や状態が「時間ロック」されたまま、チェーン間を移動することになり、これがコスト増やSolverの再バランス負担増を招き、最終的にはユーザーの手数料や遅延を増大させるのです。したがって、決済周期の短縮は、相互運用のスケール化において重要なレバーとなります。現在の主な技術的方向性は次の通りです。
ただし、相互運用の議論において避けて通れない核心的疑問は、もし決済チャレンジ期間を従来の7日から1時間に短縮した場合、攻撃者に悪用の余地を残すのではないか、という点です。
理論的には、この懸念は根拠のないものではありません。特に、「強い検閲」（検証ノードの集団による悪意ある行為）とは異なり、実際に警戒すべきは、ブロックビルダー主導のソフト検閲攻撃です。攻撃者はコンセンサスを制御する必要はなく、ただ防御者の取引を抑制し続けるだけで、重要な取引をオンチェーンに載せられなくなるのです。
興味深いことに、こうしたシナリオに関する唯一の体系的な経済学的分析は、Offchain Labsが2025年2月に発表した論文《Economic Censorship Games in Fraud Proofs》にあります。この論文は、最も悲観的なモデルから比較的楽観的なモデルまで、3つのモデルを構築しています。
実務では、検証者が空スロットを選ぶ可能性もあり、設計によっては最悪のG¹モデルに退化することもあります。そのため、論文は最悪ケースから分析を行っています。
この前提のもと、研究者は「少額で大きく防ぐ」遅延防御メカニズムを提案しています。これは、「一クリック遅延」権を持つ防御者が、短時間で複雑な誤り検証を完了しなくてもよい仕組みです。重要な取引をオンチェーンに載せるためのトリガーとなる特別な取引を成功させれば、その時点でチャレンジ期間は自動的に7日に延長されるのです。
例えば、防御者がL2の状態異常を発見した場合、1時間以内にすべての検証を完了しなくても、L1に特別な取引を送信するだけで、チャレンジ期間は一気に7日に戻ります。これにより、攻撃者は非対称のコストを負う必要が出てきます。攻撃者は高額の優先手数料を支払い続ける必要があり、その間に防御者は一度の成功で長期の遅延を引き起こせるのです。
論文の定量的な試算によると、資金力のある攻撃者が100億ドルの資金を投入して継続的な検閲攻撃を仕掛ける場合、
つまり、これは非常に重要な構造的優位性を持つ仕組みです。攻撃者のコストは線形に増加しますが、防御者は一度の成功だけで済むため、コスト比は非常に高くなります。
このコスト対安全性の比率（Cost to Attack vs. Cost to Defend）は、決済周期を大幅に短縮しても、イーサリアムの経済的安全性を堅持できることを示しています。
相互運用にとっても、これは極めて重要です。高速確認と短縮された決済周期は、安全性を犠牲にしなくても実現可能であり、合理的な制度設計の下では、秒単位のクロスチェーンと経済的安全性の両立も十分に可能です。これにより、秒級クロスチェーンの実現に向けた最も堅固な基盤が整います。
( 最後に一言
なぜ数秒、数分の遅延を最適化するためにこれほど努力するのか、と疑問に思う人もいるでしょう。
Web3のガジェット時代では、「待つこと」が当たり前であり、「待つこと」が分散化のために支払うべきプレミアムだと考えられてきました。しかし、Web3が一般ユーザーに広がる過程では、ユーザーは自分がどのチェーン上で操作しているかを気にすべきではなく、またL1の最終性のロジックを計算すべきでもありません。
高速確認、6秒のハートビート、そして非対称の防御メカニズムは、本質的に一つのことを実現しています——「時間」という変数をユーザーの感覚から消し去ることです。
私が最近繰り返し述べている言葉ですが、技術の最良の形態は、「複雑さを高速な確認の中で徹底的に消し去ること」です。