紹介

2020年末、Ethereumはロールアップ中心のアプローチ高速かつ安価な取引を実現します。ただし、これには増加した断片化というコストがかかります。ユーザーと流動性が複数のロールアップに分散するため、この断片化は統一されたEthereum体験を阻害するエコシステム全体の課題です。

この記事では、この断片化の根源を調べ、ロールアップ相互運用、曖昧化の主要な課題の 1 つを調べ、この問題に対処するために存在するソリューションを分類します。ロールアップの相互運用性に関して提案されているさまざまなソリューションについて説明し、関連するトレードオフを強調することで、ロールアップの相互運用性の未来と、より接続されたロールアップの未来を構築する方法を垣間見ることができることを願っています。

断片化の問題

異なるロールアップ間での状態の断片化は、ユーザーエクスペリエンスの低下、資本効率の低下、ネイティブな合成性の欠如につながります：

ユーザーエクスペリエンス:フラグメンテーションはユーザーに、頻繁にネットワークを切り替えさせ、同じトークンの複数のコピーを管理し、さまざまなウォレットを使い分けさせます。これにより、ユーザーがシームレスで「うまくいく」イーサリアム体験を楽しむのが難しくなります。たとえば、AliceがロールアップAに資金を持っていて、ロールアップBでのみ利用可能なトークンを購入したいとします。ただ「購入」をクリックする代わりに、まずネットワークを切り替え、AからBに資金を移し、L1の確認を待ってから取引を実行する必要があります。

流動性：多くのロールアップに分散された流動性により、取引ペアには深さと効率が欠如しています。これにより、悪い価格、レンディングプロトコルの収益率の低下、および最適でない取引実行が生じます。

Composability: 単一のチェーン上で、貸出プロトコルは同じトランザクション内でDEX契約を呼び出すことで、ポジションを即座に清算できます。すべてが1つのアトミックで実行されます。同期段階。断片化された、マルチロールアップの世界では、そのプロセスは非同期になります。プロトコルは1つのロールアップで清算をトリガーするかもしれませんが、別のロールアップのDEXでメッセージの最終処理を待つかもしれません。何か問題が発生した場合、プロセスを元に戻すことは簡単ではありません。イーサリアムには、クロスロールアップの契約呼び出しを行うためのツールやこれらの呼び出しの迅速な実行を保証するためのツールもありません。この即時性の喪失、原子的な相互作用の欠如は、イーサリアムのエコシステムを強力にする相互運用性を損ないます。

相互運用性

その中心には、相互運用性ということがあり、あるロールアップで始まる取引を別のロールアップで更新することを可能にすることを意味します。たとえば、ロールアップAからロールアップBにトークンを送信するような状況です。理想的には、このアクションは、Aの残高が減少し、Bの残高が増加するように一度に行われます。実際には、異なるロールアップ間でそのようなシームレスな「全てまたは何もしない」動作を実現することは困難です。

理想的には、ロールアップ間の相互作用は、イーサリアムL1上で行われるのと同様に、同期的に機能します。同期的な環境では、異なるロールアップ内の異なる契約への複数のコールを1つのトランザクションにまとめることができ、それが完全に成功するか完全に失敗するかを即座に提供し、アトミックな結果を提供します。

それに対して、非同期の相互運用性は、さまざまなロールアップ間で時間をかけて複数のステップが分散されることを含みます。単一のアトミックトランザクションではなく、あるアクションが1つのロールアップでイベントをトリガーし、その後、別のロールアップ上で相互作用を完了する前に確認を待つかもしれません。非同期の相互運用性は、中断に対処する必要があります：ロールアップのうちの1つだけが行動を適時に行う必要があり、その後、この部分的な状態遷移を元に戻す必要が出てくるかもしれません（相手のロールアップがその役割を果たさなかったため）。同期的および非同期的な相互運用性は、ここで議論する多くの共通の課題を共有しています。

この記事は、プロトコルレベルの統合が必要なネイティブロールアップの相互運用性ソリューションに焦点を当てています。流動性プロバイダーに依存し、交換可能トークンの転送のみをサポートする外部ブリッジソリューションは除外します。

相互運用性の課題

ロールアップ間の真の相互運用性を実現することは、単にメッセージをやり取りすることだけではありません。 トランザクションが安全かつ迅速に確定されることも含まれます。 Ethereum L1に完全に依存すると、長い遅延と高いコストを意味する可能性があります。 AliceはロールアップAに資金を持っていますが、ロールアップBでのみ利用可能なトークンを購入したいと考えています。 2つのオプションが可能です。

• Rollup Bは、イーサリアムを介してブリッジされた場合にのみ、アリスの資金を受け入れます。 この場合、アリスは資金をL1に引き出し、それをrollup Bに入金し、最後にrollup Bでトークンを購入する必要があり、高い遅延とコストが発生します。
• Rollup Bは、イーサリアムレイヤー1で最初に決済するのではなく、トランスファーを直接処理することで、より高速で安価な経路を提供します。しかし、以下で説明するように、これにより、Rollup BがRollup Aが二重になる、決済しない、または無効な状態遷移を提出する場合に再編リスクにさらされる可能性があります。

2つのL2がEthereumよりも速いレイテンシーで相互作用する場合(つまり、L1への状態遷移をコミットまたは解決する前)、ロールアップが対処する必要がある3つの基本的な問題、すなわち曖昧さ、無効性、非決済があります。

• Equivocation: ロールアップは、異なるチェーンに対して矛盾する状態をブロードキャストし、実質的に同じ資産を複数回約束します。
• 無効：L1上で状態遷移が証明可能に正しくない可能性があります。
• 決済されない場合: 証明生成または決済プロセスが無期限に停滞する可能性があります。

ここで繰り返しになりますが、これらすべての問題は、すべての状態遷移が完全にイーサリアム上で解決されるL1確定を待つことで簡単に解決できます。ただし、私たちは、イーサリアムよりも高速なレイテンシで安全なクロスロールアップ相互作用を可能にすることに興味があります。このサブファイナリティウィンドウで動作する際にセキュリティを維持する解決策を探ります。

これらの課題を例を挙げて説明しましょう：例えば、AliceがScrollメインネット上で10 ETHを所有し、それらをArbitrumにあるBobに送金したいとします。理想的には、Aliceはこれら2つのチェーン間でリクイディティをより速いEthereumよりも速いレイテンシでネイティブに移動できるはずです。もしもそのような解決策が存在し、ArbitrumがL1に何も提出する前にArbitrumがAliceにArbitrum内で10 ETHを付与するということがあった場合、Arbitrumにとってどのような問題が発生する可能性がありますか？

• Equivocation: Scrollは、異なる状態遷移でAliceの取引が含まれていないL1にコミットすることで、Arbitrumから10 ETHを奪い取ることに成功しました（解決するために再構築する必要があります）。
• 無効：スクロールは曖昧ではなく、取引を含む状態遷移が無効であるため、スクロールはL1でそれを決済することができず、資金をアービトラムに提供することができない（つまり、それを証明することができない）。再び、アービトラムは決済するために再編する必要があります。
• 決済なし：スクロールは曖昧にならず、状態遷移が有効ですが、スクロールの指定された証明者がオフラインになり、そのため決済が行われません。 Arbitrumは再度再編成する必要があります。

Arbitrumは、ScrollがL1にコミットする前(曖昧な場合)とScrollが決済する前(無効および未決済の場合)にAlice in Scrollから送信された10 ETHを統合することにより、ArbitrumはScrollのセキュリティに関する考慮事項に応じてチェーンでリスクを負います。

ロールアップの相互運用性の重要な側面は、システムがどのように等価性を処理するかです。異なるアーキテクチャは異なるアプローチを取ります。OPスーパーチェーンのような一部のシステムでは、ロールアップは一緒に再編成されるように設計されています。つまり、1つのロールアップが等価性を持つと、すべての関連するロールアップはシステム全体での一貫性を維持するために状態を再編成しなければなりません。これはクロスチェーンコンティンジェントブロックと呼ばれる特性です。他のアーキテクチャは、以下で探っていくさまざまなメカニズムを通じて等価性を完全に防ぐことに焦点を当てています。

非決済と無効化は、リアルタイムのzkプルーフの生成が実用化されると、瑣末な問題になります（別名、リアルタイム証明）。しかし、二重言明の問題は根本的に異なります。zkプルーフは、アリスがアービトラム上でボブに10 ETHを送ったことを証明できますが、それによってスクロールがL1でこの遷移をコミットすることを保証するわけではありません。zkプルーフだけでは二重言明を解決することはできず、決して解決することはありません。逆に、L1の決済を待つことで二重言明を解決できますが、ロールアップのスピード優位性の代価としてです。したがって、私たちは決済前の二重言明、つまり、イーサリアムへの決済前の二重言明防止の保証に焦点を当てています。次に、私たちは、各アプローチが異なるトレードオフを伴うことを見ていきます。特に、以下で議論する信頼の前提に関して。

相互運用性アーキテクチャ

私たちは、イーサリアムよりも高速な相互運用性を持つ2つの異なるアプローチを提示し、それをメッシュとハブと呼んでいます。

要するに、メッシュモデルとは、ロールアップが互いに直接相互接続され、和解前のファイナリティを達成するために互いに曖昧にならないように信頼し合うモデルです。

ハブモデルは、相互運用性のためにロールアップが依存する共有レイヤーを導入し、クロスチェーンインタラクションのための擬似防止をより速いイーサリアムの待ち時間で処理します。実践でこの違いが意味するものを探ってみましょう。

メッシュ

メッシュモデルは、ロールアップ同士が直接通信しながら、引き続きイーサリアムL1への決済を担当するという点で、期待通りに機能します。

ますます多くのロールアップがこの大きなメッシュで相互接続されるようになると、信頼性と依存関係の推移がスケーラビリティの問題になります。 ArbitrumがScrollを信頼しているがzkSyncを信頼していない場合、ScrollはArbitrumの信頼を維持しながらzkSyncを信頼することはできません。ロールアップのクリークである「信頼グループ」のみがメッシュ内で互いに相互作用できます。この依存性の問題は、より多くのロールアップが複雑なインターオペレーションケースに関与するにつれて増大し、全体のセキュリティが最も脆弱なロールアップのセキュリティに制限される場合があります。

メッシュシステムは、事前決済の安全性に信頼を置いていますが、決済時に等価性を検出し、すべての接続されたロールアップで再編成を引き起こすことができます。

したがって、この相互運用モデルにはいくつかの欠点がありますが、望ましいクロスチェーン操作が安全かつ信頼性が証明されている主要なロールアップに限定され、これらのシステムに信頼依存関係を構築することを望む場合には完全に適しています。しかし、このモデルは、さらに多くのロールアップ、他のL2、さらにはメッシュ内のアプリチェーンL3を追加したい場合にはスケーリングがうまくいかないことがすぐに明らかになります。

ハブ

ハブモデルでは、メッシュモデルの欠点に共有レイヤーを導入することで対処されます。 各ロールアップはこのレイヤーを信頼する必要があり、相互作用の真実のソースとして機能するため、1つのロールアップをレイヤーにリンクすることははるかに簡単です。 当然、このレイヤーをできるだけ安全にする必要があります。これにより、より速いイーサリアムのレイテンシーよりも速く、最高の非等価性保証が提供されます。

このソリューションの利点は、ミックスに追加のロールアップを追加しても、相互運用レイヤーが各ロールアップの間に「シールド」として機能するため、依存性の問題が増えないことです。これには任意のL2チェーン、L3およびアプリロールアップが含まれる可能性があります - 彼らが行う必要があるのは、ハブに統合されて利点を享受することです。

このアプローチの主なトレードオフは、すべてのロールアップがハブで共有される共通の依存関係を持つことです。これにより、ハブは大きな権力を得ます。

具体的には、決済前の曖昧さを防ぐために、ハブが曖昧なロールアップと共謀しないようにする必要があります。したがって、ハブシステムは、メッシュ設計のロールアップ間の相互信頼を、他のロールアップと共謀して曖昧にしない単一の共有レイヤーへの信頼に置き換えます。

そのため、ハブはセキュリティと分散化を考慮して構築する必要があることは驚くことではありません。そのようなハブを構築するためのいくつかの異なるオプションがあります。

• 既存のロールアップを使用する：このオプションは、既存のロールアップを使用するという利点があります。ロールアップはすでに存在しており、おそらく厳密にテストされており、それを展開するだけの問題であるはずです。
• 専用コンポーネントの作成：ロールアップにすべてのセキュリティプロパティに依存するように求める代わりに、ハブとして機能する新しい専用コンポーネントを作成します。ここでの利点は、この新しいコンポーネントがクロスチェーンのニーズに特化しているため、バグ/エクスプロイトの表面ベクトルが最小限に抑えられることです（形式的に検証される可能性さえあります！）。
• Ethereum L1そのものを使用する：このオプションでは、使用することが含まれます事前確認に基づく直接レイヤー1上で両方の世界を最大限に活用し、ピークの生存性とセキュリティを持ちながら、ほぼ即時の確認、最小限の引き出し時間などを実現します。

zkプルーフが使用されていると仮定すると、これらの3つのオプションは、証明の集約の概念を活用して、L1がサポートされているすべてのロールアップから個々のプルーフをまとめてバッチ処理する単一のプルーフを検証することにより、関連するコストをさらに削減できます。

既存のシステム

複数のプロジェクトがさまざまな相互運用ソリューションを提案しており、以下のカテゴリに分類されます。

メッシュシステム。OPスーパーチェーンおよびアービトラムのチェーンクラスターメッシュシステムは、チェーンが互いにクロス・セトルメントを行う必要があるシステムです。1つのチェーンが曖昧な動きをすれば、すべての接続されたチェーンが再編成しなければなりません。チェーンは、前決済の確認において互いに信頼する必要があります。

これらのソリューションは、信頼のクリークが事前決済の確定性を達成するために数個の大規模なロールアップを超えてスケーリングできないため、ある種のハブを使用する方向に移行する可能性があります。

ハブシステム。エスプレッソzkSyncのエラスティックチェーンハブシステムです。Scrollでは、よりスケーラブルでトラストレスな相互運用ソリューションを可能にするハブ設計を模索してきました。我がプレゼンテーション2024年のコロンビア暗号経済ワークショップでは、設計の概要が提供され、近日中に詳細が続きます。

他のシステム。ベースのロールアップには、お互い同期コンポーザビリティを実現する可能性があり、イーサリアムL1とだけでなく、イーサリアムL1を等価性防止のために利用することもできます。

PolygonのAggLayerは、ロールアップがすべて通信する共有レイヤーを提供する別のタイプのハブシステムです。ただし、共有レイヤーでの追加の信頼前提を避けることで異なります。代わりに、決済を待ち、使用します。悲観的な証拠セキュリティを提供するために。したがって、誤魔化しは決済時にのみ防止されます。事前確認は、より迅速な最終性保証を提供するためにオプションで使用できます。AggLayerは最近、パートナーシップwith Espresso Systems, that provides a shared sequencing mechanism.

結論

イーサリアムよりも高速な相互運用のための曖昧化防止メカニズムの開発には、セキュリティ、分散化、信頼性のある中立性のために慎重に検討する必要があるあらゆる種類のトレードオフが伴います。この記事では曖昧さの防止に焦点を当てましたが、データの可用性、決済レイヤーの設計(異なるロールアップ間での共有ブリッジやロールアップコントラクトの実装など)、メッセージパッシングプロトコル、システムを機能させるために必要な経済的インセンティブなど、ここでは深く説明していない他の重要な相互運用の課題がいくつかあります。しかし、ヴィタリックが言ったように最近のツイート私たちは、多くの人々が考えるよりも、これらのクロスチェーンの問題を解決することに近づいています。この相互運用性の最終段階では、ユーザーは今日の個々のロールアップとは対照的に、「1つのイーサリアム」を実際に使用しているように感じると信じています。

免責事項:

1. この記事は[から転載されていますスクロールリサーチ].すべての著作権は原著作者に帰属します[Alejandro Ranchal-Pedrosa]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人によるものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームは記事の翻訳を他言語に行います。許可されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。