新しい歴史

ロールアップ相互運用性ソリューションの現状

に 2077 Research29m2024/12/20

長すぎる; 読むには

相互運用性は、Ethereum のロールアップ中心のロードマップの成功に不可欠です。このレポートでは、ロールアップの相互運用性の状態について解説し、相互運用性の問題に対する既存および提案されたソリューション、その制限、およびロールアップの相互運用性インフラストラクチャの将来の改善に関する洞察を提供します。

ロールアップ中心のエコシステムの愛好家として、私は常にロールアップの相互運用性を向上させるソリューションに興味を持っていました。さらに、この調査レポートを作成した唯一の理由は、この分野における相互運用性の重要性を訴えるためでした。その後、記事を書くことは、特定のトピックに関する自分の理解を固め、人々に理解してもらうための優れた方法であることに気付き、今ここにいます。

暗号通貨の世界では毎日新しいことが学ばれているので、今日では「ロールアップの相互運用性はイーサリアムの将来にとって重要」という時代の私のビジョンがかなり時代遅れになっているのは明らかです。哲学の観点からは、私は今でも同じビジョン**に従っています。ロールアップの相互運用性はイーサリアムの将来にとって絶対に重要であり、エコシステム全体がそれを改善するソリューションに取り組むべきです。しかし、テクノロジーの観点からは、このトピックについて多くの新しいアイデアを学び、いくつかのことについて考えが変わりました。

以下の内容を理解するには、ロールアップとその相互運用性の問題について基本的な知識を持っていることが役に立ちます。そうでない場合は、私の記事「Dr. Dankshard、または私が心配するのをやめてロールアップを愛するようになった方法」が優れた入門書となります。

メルハバ！

11月13日の夕方、 Devconnect Istanbulの初日。ZkSyncの大ファンである私は、このサミットの初めてのイベントとして、人生初の zkSync Connect に参加することにしました。そこで、ある男性と出会い、zkCafe の Luma ページに書かれていた「Mosyo Coffee」に一緒に向かいました。そのエリアには 2 軒のカフェがあり、夕方になってようやく目的の場所を見つけました。

上の写真よりもずっと暗く、土砂降りの雨が降っていました。フードコートがある屋上の端に座り、 Claveの無料トークンで買ったコーヒーを飲みながら、新しい友人にハッカソンプロジェクトのアイデアについて話しました。

「ミニアカウント」があります。ERC -4337アカウントの検証ロジックは署名チェックではなく、L2 の単一の受信ボックスブリッジ内の操作のハッシュの存在です。ハッシュは、特定のソースチェーンの親アドレスから送信する必要があります。親アドレスは、任意の L2 または Ethereum L1 のメインのスマートウォレットです。別の L2 とやり取りするには、次の操作を行います。

そこにミニアカウントを展開し、メインウォレットを親アドレスとして設定します。展開は誰でも実行できるため、プロトコルまたはウォレットプロバイダーから資金を調達できます。
送信するユーザー操作のハッシュを L2 の受信トレイブリッジに送信し、宛先チェーン ID を設定します。
このハッシュは他のハッシュとバンドルされて L1 に送信されます。L1 のスマートコントラクトはこのバンドルを宛先 L2 に転送し、受信トレイブリッジはハッシュをバンドル解除してミニアカウントが読み取れるようにします。
送信者は、プロトコルのスマートコントラクトでのトランザクションの開始者にインセンティブを与えるために、ハッシュに少額の手数料を追加します。
ハッシュが宛先 L2 に到達すると、ユーザー操作をこの L2 の AA メモリプールに送信します。ERC-4337 標準を利用することで、独自のミニアカウントメモリプールを再実装する必要がなくなり、既存のコードベースを持つウォレットにプロトコルを簡単に統合できます。

簡単に言うと、L2 のスマートウォレットからやり取りしたい任意の L2 にトランザクションを送信する L1 ベースのブリッジを作成するつもりでした。ハッカソンで実装するところまで行きましたが、経験が浅く、一人で作業していたため完成できませんでした。友人に説明した後、彼は私にこう尋ねました。

なぜウォレットのネットワークを変更し、トークンブリッジを使用して必要な資金を必要なネットワークに移動しないのでしょうか?

私はこう答えました: EOA ウォレットを使用する場合、これは間違いなく選択肢になります。EOA ウォレットはすべての EVM ネットワークで同じように動作し、同じアドレスを共有するため、ウォレット設定でネットワークを変更するだけで、すべての EVM ネットワークでトランザクションを送信できます。

ただし、この領域はアカウント抽象化ベースのスマートアカウントに移行しています。これらのアカウントを使用すると、プログラムによってウォレットに必要な機能を追加できます。

P256 署名により、携帯電話内の安全なチップを使用してトランザクションに署名することが可能になります。
ソーシャルリカバリを通じて、ウォレットを回復する権限を持つ保護者として親戚を追加し、安全でないシードフレーズを排除することができます。
Paymaster テクノロジーにより、ガス料金を任意のトークンで支払ったり、誰かに代わって料金を支払ってもらったりすることが可能になります。
量子コンピュータが従来の署名方式を破り始めたら、新しいウォレットを作成せずに、AA ウォレットの方式を量子耐性のある方式に変更するだけで済みます。

このリストは際限なく続きます。アカウントの抽象化により、実行可能プログラムを本格的なウォレットとして使用できるようになるからです。しかし、これにはすべてコストがかかります。ブリッジを介して資金を移動するだけでなく、すべてのキー、ガーディアン、設定を含むアカウント全体を再展開する必要があるため、ウォレットを別のチェーンに簡単に移行することはできません。場合によっては、これは複雑すぎるか、不可能な場合があります。たとえば、 P256 プリコンパイルをサポートしていないロールアップの場合 (この署名スキームは使用するにはコストがかかりすぎる可能性があります)。

これが私がこのプロトコルを作った理由です。基本的に、多くの L2 に AA アカウントがあります。そこからトランザクションを送信するには、特定の L2 のメインアカウントからハッシュを L1 ブリッジメッセージングを介してそれらの「ミニアカウント」に送信して、意図を確認する必要があります。実際、この方法では複数のウォレットを削除するのではなく、すべての検証ロジックを単一の「親」アカウントに移動するだけです。

このようなプロトコルのもう 1 つの興味深い点は、L2 だけでなく、Ethereum とのブリッジを組み込んだすべての L1 (サイドチェーン) との相互運用性を可能にすることです。私が思いつくのは、Polygon PoS、Ronin、Gnosis、Avalanche などです。ただし、これはロールアップ中心の相互運用性プロトコルとして設計されているため、これは単なる楽しい技術的事実です。

このプロジェクトのアイデアは非常に巧妙でしたが、実際の実装には重大な欠点がありました。それは、速度です。全体の設計は、Ethereum L1 に接続された標準的なロールアップブリッジに依存しています。ロールアップブリッジは、セキュリティを継承するために、Ethereum 上のスマートコントラクトに状態を証明するという点で独特です。すでにご存知かもしれませんが、楽観的検証と ZK 検証は、これを行うための 2 つの最も一般的な方法です。

楽観的検証は、通常約 7 日間の「チャレンジウィンドウ」を開くことで機能します。この間に、チャレンジャーはトランザクションバッチの無効な部分を示す不正証明を送信できます。この証明が有効である場合、ロールアップはブロックチェーンを再編成してこのバッチを削除します。不正証明がないまま 7 日が経過すると、バッチは自動的に有効とみなされ、すべてのメッセージと引き出しが Ethereum 上で確定されます。

おそらくすでにお分かりでしょう。L1 へのメッセージ送信が 7 日間遅れるため、楽観的なロールアップからクロスチェーントランザクションを送信するのは、あまり良い考えではありません。なぜでしょうか。DEX スワップを 1 週間待つつもりですか。このときまでに価格はどうなるでしょうか。

クロスチェーントランザクションを楽観的ロールアップに送信する方がはるかに優れています。OP スタックシーケンサーは、再編成の可能性を最小限に抑えるためにメッセージを処理する前に数ブロック待機しますが、トランザクションを数分間待機することは、一部のタスクではすでにある程度許容できます。

さらに、イーサリアムコミュニティは現在、シングルスロットファイナリティに取り組んでいます。これにより、すべてのブロックが個別にファイナライズされ、次のブロックでは元に戻せなくなります。これが実装されると、L1 から L2 へのメッセージングには約 12 秒かかります。

このようなアカウントを ZK ロールアップでホストする方がよいですが、それでもあまり使いやすくはありません。以下の統計からわかるように、ZKsync Era は 21 時間で完了し、Linea は 5 時間、 Starknet は9 時間で完了します。

しかし、なぜそうなるのでしょうか? 強力なクラスターでは ZK 証明の生成は高速ではないのでしょうか? 簡単に言えば、2 つの問題があります。

ZKsync Era などの一部の ZK ロールアップでは、証明システムにバグがあった場合にセキュリティカウンシルが一部のバッチを元に戻す時間を確保するために実行遅延を設定しています。zkEVM は非常に複雑なテクノロジであり、この複雑さのため、複数の証明システムを同時に使用してバグを確率的に防止することはまだ実現可能ではありません。
ZK 証明の検証は、証明する計算に比べると非常に軽量ですが、オンチェーンでの検証は依然としてかなりコストがかかります。証明システムによっては、検証ごとに最大 100 万ガスかかる場合があります。平均ガス価格 9 gwei と現在の ETH 価格を考慮すると、L1 での検証のみで 1 回の証明に約 30 ドルかかります。
- 最新の ZK ロールアップでは、一定時間ごとに多数のバッチに対して 1 つの証明を生成することでこれらの費用を最小限に抑えていますが、これによりブリッジのファイナリティ速度が低下します。バッチを生成してブロックごとに証明すると、ブロックあたり 30 ドル、つまり1 日あたり 216,000 ドルの費用がかかります。100 TPS の場合、検証コストだけでトランザクションあたり約 0.025 ドルになります。また、証明を生成してバッチをオンチェーンで公開する必要もあります。

取引に 1 ～ 2 時間待つのは、まだ長すぎます。どうすればよいでしょうか?

まず、8 か月前に始めたハッカソンプロジェクトを忘れて、すべてのトランザクションをメインのスマートウォレットから開始する必要があるというメンタルモデルを排除してみましょう。ロールアップごとにスマートウォレットのロジックを共有する必要はなぜあるのでしょうか。一時的な EOA を生成し、メインのスマートウォレットから資金をそこにブリッジし、やりたい作業をいくつか実行して、残った分をブリッジしてしまえばよいのではないでしょうか。

私のClave (または、使用しているスマートウォレット) には、Secure Enclave 署名とソーシャルリカバリー機能が搭載されているため、携帯電話を紛失した場合でも、常に資金を安全に保管できます。また、これらの一時アカウントがどうなるかなんて誰も気にしません。すでにそれらのアカウントで用事を済ませています。すべての資金は、現在 Clave にあります。

しかし、このアプローチには根本的な問題があります。同じウォレットを他のチェーンで定期的に使用できないという前提により、チェーンで実行できるタスクの数が大幅に制限されます。たとえば、次のことはできません。

メインネットワーク（この場合はZKsync Era）に移行できないため、ローカルの貸付プラットフォームに預金を作成します。
メインネットワークに代替可能な同等物がないトークンを取得します（たとえば、そのネットワークでネイティブに鋳造されている場合）
あなたの投票は一時的なアカウントに残される必要があるため、ローカル DAO に参加してください。

基本的に、ユーザーとしてできることは、毎回ブリッジすることなく複数の受取人に資金を分散し、メインチェーンにブリッジバックできるトークンへのスワップの流動性を高めることだけです。

したがって、これらのウォレットを有用にするには、メインのスマートウォレットで使用するのと同じルール（セキュアエンクレーブ、ソーシャルリカバリなど）を使用してアクセスする必要があります。つまり、上記のアイデアとその実現不可能性に戻ります。ただし、これらのミニアカウントにメインウォレットのリカバリプロパティのみを与えることができる実行可能な緩和策があります。

先ほど説明したのと同じミニアカウントを作成しますが、1 つのキーで直接トランザクションを送信できるようにします。親ウォレットは、L1 ベースのブリッジを介してこのキーを変更したり、ミニアカウントに親 L2 の状態からキーを読み取らせたりできるようになりました。このように、一時キーが失われた場合、親ウォレットは、低速だがアトミックな L1 ベースのブリッジを介してキーの変更を開始できます。

アトミック性 — 実行中に失敗しないアクションの特性。開始されなかったか、完了したかのどちらかです。L1ベースのブリッジは、送信されたメッセージが失われることがないため、アトミックです。順序、可用性、信頼性は、Ethereum L1 によって保証されます。

これはずっと良いですね！これで、通常のトランザクションはトークンブリッジングにのみ時間がかかります。トークンが送信先に到着した後は、トランザクションの送信はメインチェーンと同じくらい高速になります。キーを紛失した場合は、親ウォレットのチェーンに応じて数時間から7日間待つ必要がありますが、頻繁に使用することはないため、ほとんどのユースケースでこのトレードオフは許容できます。また、今日でもウォレットに実装することは可能です。私も独自の実装を作成しましたが、それは決して安全でも実稼働対応でもなく、視覚化のみを目的としています。

同様の手法が Web3 先物取引プラットフォームでも使用されています。トークンをペアで (通常は USDC) スマートコントラクトに承認し、プラットフォームのフロントエンドに保存されている一時的なキーを支出用に割り当てます。これにより、ユーザーはメインウォレットで各アクションに署名することなく、迅速にアクションを実行できます。デバイスを変更したり、ブラウザーのデータを消去したりした場合は、メインウォレットを使用してキーを再割り当てするだけです。

しかし、暗号通貨のあらゆるものと同様に、このアプローチも完璧ではありません。2 つの欠点があります。

ミニアカウントは ERC-4337 に準拠しているため、バッチ処理、支払人、支出限度額などのすべての機能をサポートできますが、これらの機能は親アカウントから継承されなくなりました。実際、親アカウントはミニアカウントの単一のソーシャルリカバリガーディアンとして機能しますが、ガーディアンとはユーザー自身です。
トークンブリッジングは、外部ブリッジを使用して実行する必要があります。クロスチェーントランザクションの開始により、トークンをメッセージとともに運び、実質的に 1:1 でアトミックに受信できます。ただし、このソリューションでは、これはもはやオプションではないため、外部ブリッジングが唯一の高速オプションとして残されています。

最新のブリッジは数秒で資金を送金できますが、a)大規模な送金では手数料が非常に高くなる可能性があり、b) アトミックではなく、Ethereum のセキュリティ特性を継承していません。ブロックチェーンブリッジのセキュリティ特性に注意することが特に重要です。

外部ブリッジを使用してトークンを転送することは、ミニアカウントを操作するためにメッセージを渡すのとは異なり、ある程度許容されます。その理由は、外部ブリッジが最悪のケースになる可能性があり、おそらく外部ブリッジへの攻撃が原因であるためです。

トークンブリッジングでは、最悪の場合、送信したトークンを受信できないことがあります。このような場合、ブリッジしたい X 個のトークンが失われ、別のブリッジに切り替わります。
クロスアカウントメッセージングで起こり得る最悪の事態は、ブリッジを介してなりすましメッセージを渡すことで、すべてのミニアカウントが盗まれることです。このような場合、メインチェーンを除くすべてのチェーンのウォレットとそのすべての価値が失われます。

そのため、L1 を使用してアトミックにブリッジする効率的な方法がない限り、トークンブリッジングに外部ブリッジを利用することはほぼ選択肢の 1 つです。これは実際に、現在ロールアップチェーンを操作する多くのユーザーが使用しているオプションです。

たとえば、トークンをアカウント間でネイティブに転送したり、一意のプリコンパイルで署名を検証したりするために、すべてのトランザクションを 1 か所で検証したいとします。その場合、現在の ZK ロールアップの最終処理が遅いという問題に直面します。少し戻って、以前の手法で何を改善できるか考えてみましょう。

ロールアップのブリッジのファイナリティが遅いのはなぜでしょうか? 楽観的なロールアップでは理由がすでに明らかになっているため、ZK ロールアップをターゲットとします。

本格的な VM 環境の ZK 証明システムは複雑で、特に環境が ZK フレンドリー (EVM) でない場合は複雑です。そのため、バグが含まれる可能性が高くなります。複数の証明システムを使用すればこれを防ぐことができますが、実装が非常に複雑で、1 つのバッチに対して複数の証明を生成すると、時間がかかり、コストがかかりすぎる可能性があります。回避策として、ロールアップチームは実行遅延を有効にして、緊急時にチェーンをロールバックできるようにします。これが、一部のロールアップ (例: ZKsync Era) でブリッジのファイナリティを遅くする原因です。
新しい状態を提案し、それを ZK が L1 に証明するのは非常にコストのかかるタスクであるため、コストを最小限に抑えるために、ロールアップシーケンサーはブロックごとではなく数時間ごとにそれを実行します。

ただし、例外があります。Scrollは約 1 分ごとに状態を提案しますが、a) 証明の検証は依然として数時間ごとに行われるため、検証されないままになり、b) Scroll は現在使用するロールアップの中で最もコストのかかるものの 1 つになります。

もっと簡単に言い換えると、問題はコストの証明とコストの検証です。それぞれの問題とその解決方法を見てみましょう。

本質的に、私たちの仕事は、外部ブリッジによってもたらされる追加の信頼の仮定なしに、ロールアップ上のスマートウォレットを他のロールアップと迅速に相互運用できるようにすることです。スマートウォレットは通常、ペイマスター、ソーシャルリカバリー、セキュアエンクレーブ、支出限度額などのいくつかの通常の AA 機能と、そこからオンチェーントランザクションを送信できるようにするメイン操作で構成されます。

ウォレットから他のロールアップを使用する場合、メイン操作が必要なのはなぜでしょうか? おそらく、多目的ロールアップ (Arbitrum、Base、ZKsync Era) でホストされており、このロールアップでもユーザーやスマートコントラクトと対話する必要があるためです。

この特定のケースでは、外部トークンブリッジを使用するだけで十分です。たとえば、タスクを同じロールアップ内の dApp と別のロールアップ内の dApp とのやり取りに置き換えるだけです。

この多目的性が、ロールアップの証明システムに複雑さをもたらします。毎秒多数のスマートコントラクトとトランザクションが発生している仮想マシン全体の状態を検証するのは、かなり困難な作業です。ロールアップではまったく異なる機能セットを必要とする 2 種類のタスクを実行したいと考えています。オンチェーントランザクションの場合は、高速な L2 包含、低い L2 料金、VM の幅広い機能であり、マルチロールアップトランザクションの場合は、高速なブリッジのファイナリティです。

しかし、仮想マシンを廃止して、スマートアカウントと他の L2 へのメッセージングのみを処理できるロールアップを構築したらどうなるでしょうか。Vitalik Buterin は、Devconnect Istanbul の頃に「キーストアロールアップ」と呼ばれる同様の手法を提案しました。これについては次に説明します。

キーストアのロールアップ

アイデアは、アカウントキーのみを保存し、別のキーを使用して変更できる ZK ロールアップを作成することです。このロールアップは、これらすべてのキーを含む Merkle ツリーのルートを L1 にプッシュします。次に、L2 のスマートアカウントの 1 つからトランザクションを送信するときに、現在のキーの Merkle 証明を生成し、アカウントはそれを L1 で使用可能なキーストアルートに対して検証します。これで、アカウントはキーを認識し、それを使用して署名を検証できます。

このようなロールアップは非常にシンプルで、複数の証明システムを簡単に実装できるため、そこに保存されるキーは実際には L1 と同じくらい安全です。

Vitalik のオリジナル設計の他に、キーストアロールアップには 3 つの主要な設計があります。

Scroll のアプローチは、キーストアデータを L1 に保存しながらも、zkEVM ロールアップから更新できるようにすることです。このために、L1 ストレージの読み取りコストを抑える L1SLOAD プリコンパイルを導入しています。その後、他の L2 の AA アカウントがこのデータを読み取って、キーやガーディアンなどの構成を同期できます。
ベースチームは、状態ルートのみが L1 に保存され、トランザクションは calldata を使用して順序付けられるため、ツリーをいつでも再構築できるという手法を研究しています。L2 のアカウントは、Merkle 証明を使用して現在のキーを取得することが期待されています。
Stackr の設計は Base や Vitalik と非常に似ていますが、特殊な最小限の VM を使用した独自の「マイクロロールアップ」フレームワークを利用しています。

一般的に言えば、オフチェーン処理に委任されるタスクの数（つまり、L2 上にあるものの数）と実装の詳細が異なります。

このアイデアをさらに拡張して、キーだけでなくスマートアカウントロジック全体を処理することもできます。これも計算上それほど難しくはありません。基本的に、次のタスクを処理するだけで済みます。

L1 へのデータの送信:キーストアロールアップ上のアカウントは、トランザクションの意図を L1 に通知できる必要があります。トランザクション全体を L1 に保存する必要はありません。ユーザー操作のすべてのハッシュを含む Merkle ツリーのルートのようなもので十分です。その後、ミニアカウントからトランザクションを送信するために必要なのは、送信先 L2 からルートを読み取り、特定の AA 操作が実際に親アカウントから要求されたことを証明することだけです。
署名チェック:ユーザーは、特定のロールアップで実行するユーザー操作のハッシュに署名します。キーストアロールアップは、署名を検証して意図を証明し、ハッシュをツリーに追加して L1 にプッシュします。ECDSA、 P256 、耐量子暗号などのいくつかの署名スキームで十分です。
ソーシャルリカバリ: 「ガーディアン」と呼ばれる、意図的に選ばれた他のアカウントに、ユーザーのアカウントのキー変更に投票してもらいます。ユーザーはガーディアンとしきい値を設定し、キー紛失時に回復を依頼できます。また、拒否ベースの回復や、 ZK-Email 、ZK-OTP、 Web Proofsなどの代替ガーディアンスキームを実装して、ロールアップのユーザー以外にもソーシャルリカバリを拡張することもできます。
支出ルール:ウォレットが盗まれた場合、保護者が管理する支出ルールにより、ユーザーがウォレットを取り戻すまでの潜在的な損失を大幅に減らすことができます。この機能は、資金を貯めたり、たとえば子供用のウォレットを作ったりするのにも役立ちます。親が小遣いを渡し、その使い道を制限することで、子供が貯金の仕方を学べるようにすることができます。
トークン残高:不必要と思われるかもしれませんが、キーストアロールアップ内に暗号資産を保存できると、複数のミニアカウントに分割されることがなくなり、ユーザーの資産のセキュリティが大幅に向上します。また、ユーザーエクスペリエンスを向上させる多くの機能も利用できます。
ペイマスター:ロールアップは、新規ユーザーを引き付けるために無料トランザクションを提供したり、ETH だけでなく任意のトークンで料金を支払えるようにしたりすることができます。より複雑なペイマスターロジックも実装できます。たとえば、シーケンサーは、別のチェーンのスワップがキーストアロールアップにブリッジバックされるときに、そのチェーンから料金を受け取ることができます。
内部トークン転送:ロールアップユーザー間で資金を即座に送信するだけでなく、直接転送は、ミニアカウントからキーストアロールアップの親アカウントへのブリッジに L1 を使用するにはファイナリティが遅すぎる他のロールアップとのインテントベースのブリッジを実装するのにも役立ちます。このように、キーストアロールアップは基本的にハブとして機能し、数十のさまざまな L2 上のミニアカウント間でトークンを安価に転送できます。

このようなシステムは、ロールアップ内の完全な VM よりも技術的にはるかに単純であるため、複数の証明システムの証明を同時に生成することが可能であり、証明生成の複雑さは依然として大幅に軽減されます。

しかし、証明の検証はまだ問題です。以前計算したように、ガスコストはガス価格に応じて最大 100 万ガスまたは約 25 ～ 50 ドルになります。このコストは固定されており、バッチ内のトランザクションの数に依存しません。つまり、トランザクションが少なすぎると、各トランザクションの手数料が非常に高くなる可能性があります。このコストを削減するには、主に 2 つの方法があります。

整列レイヤー

Aligned は、再ステーキング演算子を利用して ZK 証明を安価に検証する EigenLayer AVS です。EigenLayer に詳しくない方のために、Aligned で証明が検証される方法を簡単にまとめると次のようになります。

ユーザーは証明検証リクエストをネットワークに送信し、その料金を支払います。
提携オペレーターは、それぞれがデポジットを結合した Ethereum バリデーターであり、ノード上で証明を検証し、その有効性に署名します。
2/3 のオペレーターが証明に署名すると、集約された署名が Ethereum L1 に送信され、検証されます。
無効な証明が確定した場合、その証明に署名したバリデータは、オンチェーンで検証することで削除される可能性があります。この方法では、証明は Aligned オペレーターの総ステークの 2/3 に相当する経済的セキュリティを獲得します。

このアプローチには明らかな欠点があります。Ethereum はもはや証明の有効性を保証しません。ロールアップのブリッジの TVL が Aligned ステークの合計の 2/3 よりも高い場合、それを攻撃すると利益になります。また、1 ～ 2 ブロックのファイナリティレイテンシについて話しているため、楽観的に攻撃を防ぐことはできません。

ただし、ロールアップが大きくなりすぎない限り、これは比較的安全なオプションである可能性があります。ロールアップが大きくなると、トランザクションの需要によって L1 証明の検証が価値あるものになる可能性があります。ドキュメントによると、Aligned を使用して ZK 証明を検証するには約 3000 GAS かかりますが、これは Ethereum L1 でもほぼ無料です。

証明集約レイヤー

システムに追加の信頼の前提を導入することに不安がある場合、またはプロトコルがすでに大きくなりすぎているがトランザクションの需要は大きくなっていない場合は、代替手段があります。

ZK およびロールアップチームは最近、証明集約プロトコルに積極的に取り組み始めました。ZK にあまり詳しくない方のために説明すると、証明集約とは、ZK 証明が別の ZK 証明の有効性を証明することです (その証明は、今度は別の証明を証明できます)。つまり、証明を 1 つの証明に「集約」し、すべての検証コストを証明コストに移行します。残っているのは、チェーン上で 1 つの ZK 証明を検証し、それが証明する他のすべての ZK 証明の有効性を確認することです。やれやれ!

ZK 証明オンチェーン検証。

証明の集約は、証明の集約よりも検証コストが高い場合に意味を持ちます。つまり、10 個の証明を生成して検証するコストが、これらの 10 個の証明を個別に検証するコストよりも低い場合、集約は利益をもたらします。これは、計算能力によって大きく制限されている Ethereum L1 ではさらに役立ちます。証明システムによっては、他のすべてのオンチェーンアクティビティを除いて、ブロック全体に約 100 件の証明検証しか含めることができません。

一般的に、証明集約プロトコルには 2 つの種類があります。

汎用（ユニバーサル）集約：このようなプロジェクトは通常、最も人気のあるZKプロトコル（Groth16、Halo2、Plonky）のいくつかをサポートしており、ほとんどのZK回路はそれらの上に構築され、処理に対して料金を徴収します。証明を必要とするdAppは、プロトコルからデータを公開し、独自に処理します。現在開発中のNebraのユニバーサル証明集約システムは、まさにこれを行います。Alignedは、いわゆる「スローモード」検証にも取り組んでいますが、これは実際には証明集約システムでもあります。
共有ロールアップブリッジの集約:楽観的ロールアップの共有シーケンスと同様に、スタックを持つ ZK ロールアップは、ブリッジ内のすべての ZK ロールアップの集約された状態証明を使用して共有ブリッジで動作します。これにより、共有シーケンスのようにスタック内で同期構成が可能になるだけでなく、証明検証のコストも最小限に抑えられます。Polygon のAggLayerや ZKsync のHyperbridgeについて聞いたことがあるかもしれません。これらは、ブリッジ内で証明の集約で動作する共有ロールアップブリッジです。

ユニバーサル集約システムの利点は、プロジェクトに依存せず、集約プロセス自体に特化しているため、証明の検証が非常に速く、コストが低いことです。また、ブリッジコンポーネントがないため、補助輪がない可能性があります。

集約ロールアップブリッジは、キーストアロールアップが既存のロールアップスタックと同期して構成できるようにするのにも役立ちます。たとえば、 L2BEAT によると、現在 13 のプロジェクトが Polygon CDK を使用して構築されており、11 のプロジェクトが ZK スタックを使用しています。これらすべてが共有証明集約ブリッジに接続すると、キーストアロールアップをそのうちの 1 つに接続すると、L1 に触れることなく、多くの L2 とのシームレスな対話が可能になります。これが機能するには、ブリッジが L2 に対して異なる状態遷移ロジックをサポートしている必要があります。キーストアロールアップのロジックは、ブリッジ内の他の L2 とは異なるためです。

ただし、これらのブリッジは通常、アップグレード可能であり、DAO またはセキュリティカウンシルによって制御されます。キーストアロールアッププロジェクトは、接続先のブリッジのオペレーターに主権を譲ることに抵抗を感じる場合があります。また、ブリッジは、ZKsync Era の現在の動作と同様に、補助輪の予防措置として実行遅延を導入する可能性があり、これにより、このキーストアロールアップ設計の効率が実質的に完全に失われます。

このように、キーストアのロールアップは、他の ZK ロールアップと同様に、証明検証コストを最小限に抑えることができ、さらに、既存のロールアップスタックとの同期構成と組み合わせることもできます。

「Keystore+」ロールアップによる効率的なインテントベースのブリッジ

前述のように、L2 から L1 へのブリッジングだけが問題ではありません。ほとんどのロールアップシーケンサーは、L1 から L2 へのメッセージの受け渡しにも遅延を適用します。これは、Ethereum ブロックが作成されたときにはまだ最終版ではなく、次の約 64 ブロック (2 エポック、約 13 分) 内で元に戻すことができるためです。これらの再編成はネットワークの遅延によって発生し、一部のノードがすでに見逃したと見なしているときに、一部の提案がネットワークに表示されるのが遅すぎます。

ほとんどの再編成は 2 ブロックより深くはありませんが(2 年前には 7 ブロックの再編成がニュースに登場しました) 、ロールアップチームは依然としてメッセージの欠落に関連するリスクを冒したくないため、L1 からのブリッジに遅延を適用します。これらの遅延は、一部のロールアップ ( OP スタック、 ZK スタック) では約 1 分ですが、 Arbitrumのように最大 6 分になる場合があり、 Lineaのように L1 ファイナリティを要求する場合もあります。

Ethereum コミュニティは、各ブロックがエポックに 1 回ではなく独立してファイナライズされるシングルスロットファイナリティに積極的に取り組んでいます。ただし、2025 年第 1 四半期に予定されている次の Pectra アップグレードでは計画されていないことは確かであるため、SSF が実装されるまでには少なくとも 1 年かかるでしょう。

この拡張キーストアロールアップ設計を実装するチームがこのようなトランザクション遅延に不安がある場合は、前述の緩和策を実装できます。すべてのミニアカウントには、トランザクションを送信することが承認されたキーがあるか、キーストアの静的キーを使用します (Vitalik の元の設計どおり)。ただし、アカウント管理はメインキーストアアカウントで行われます。SSF が L1 に実装された後、ロールアップは承認された支出キーを削除でき、ユーザーは大幅な速度低下なしに AA カスタマイズ機能全体を利用できるようになります。

ここで私はアレックスに同意します。15 秒の遅延は絶対に許容範囲です。特に、キーストアロールアップトランザクションが L1 で確定した後は操作がアトミックであるためです。トークン転送について言えば、受信者のウォレットは UI レベルで「保留中」ステータスを実装することもできます。

ただし、ロールアップ間のトークン転送には依然として問題があります。キーストアロールアップ内にトークンボールトを実装すると、受信者のロールアップに応じて、そこからのトークン転送に 1 ～ 15 分かかります。実装しない場合は、ユーザーの残高を複数の L2 上のミニアカウントに分割すると、セキュリティ上のリスクが生じ、一部の資産が流動性の低い L2 にロックされ、そこからのブリッジにコストがかかりすぎたり、時間がかかりすぎたりする可能性があります。

代替案として、インテントベースのブリッジをロールアップに統合し、他のすべてのロールアップに展開したり、 ERC-7683準拠のプロトコルなどの既存のインフラストラクチャを再利用したりすることもできます。次のセクションでは、インテントブリッジについて簡単に説明します。

インテントベースブリッジとは何ですか?

既存のクロスチェーンブリッジのほとんどは、メッセージングプロトコルに基づいています。たとえば、 Stargate は、 LayerZero を使用してデポジットに関するメッセージを宛先チェーンに渡し、これを信頼のソースとして利用しています。このようなブリッジを介してトークンを送信すると、一方の側でトークンがロックされ、もう一方の側でデポジットに関するメッセージが送信され、そこにある金庫で対応する量のトークンがロック解除されます。

一方、インテントベースのブリッジは、2 つのチェーン間でメッセージを送信しません。代わりに、送信される資金は「クロスチェーン注文」として金庫にロックされ、その後、要求された量のトークンを宛先チェーンに送信することで、誰でも注文を満たすことができます。注文を満たす人は誰でも、宛先チェーンの最終状態が金庫に通知され、転送を確認できると、ソースチェーンからロックされたトークンを請求できます。

これは、宛先チェーンの目的 (ブリッジ) の最終性を待つか、外部のオラクルプロトコルを介して行われます。たとえば、 Across は UMA の楽観的オラクルを使用して、まだ最終化されていない L2 の状態を取得します。

このシナリオでは、Ethereum L1 が信頼のソースとして使用されます。Across などの一部のプロトコルでは、代わりに外部オラクルを使用します。実際の設計は既存のプロジェクトによって異なる場合があります。ここでは一般的なアイデアのみを示します。

これらの拡張キーストアロールアップに同じ設計を使用して、キーストアと他のすべての L2 間の信頼性のない高速で安価な双方向ブリッジを実装できます。高速ブリッジのファイナリティにより、L2 での履行の証明にはわずか数分しかかからないため、他の L2からの意図ベースの注文はほぼ無料になります。

キーストアからの注文もおそらく安価になるでしょう。L2 の流動性はキーストアを通じて比較的速く供給できるからです。このように、このようなキーストアロールアップ設計は、意図に基づくブリッジングのハブとなり、ユーザーは数分ではなく即座にトランザクションを送信でき、ブリッジングにほとんど費用がかかりません。ロールアップチームは、キーストアを通じて 1:1 でブリッジングの流動性を供給することもできますが、これにはそれほど費用はかかりません。

すべてのチェーンに統一されたENS名

受信者がどのチェーンに属しているかに関係なく、すべてのミニアカウントに解決される単一のusername.ethがあると想像してください。この設計により、これが可能になります。どのように?

メインのキーストアアカウントのアドレスはすでにわかっているので、マルチチェーンファクトリとCREATE2 を使用して、Ethereum L1 も含め、すべてのバイトコード相当の EVM チェーンでミニアカウントのアドレスを同じにすることができます。次に、ENS リゾルバで統一されたアドレスを設定すると、名前がすべての EVM L2 で機能します。

ただし、例外的なケースが 2 つあります。

ZK Stack などのバイトコードと同等でない EVM。これらの EVM では、CREATE2 ルールに従ってカスタムアドレスを生成し、 ENSIP-11に従ってチェーン識別子とともに ENS に追加できます。
キーストアなどの非 EVM L2。ロジックは同じですが、代わりに、 ENSIP-9に従ってカスタムアドレスを ENS に追加します。

このアプローチは非常に UX フレンドリーですが、名前とアドレスが L1 リゾルバに保存されるため、L1 で多くの高価な計算とストレージを使用します。この問題はCCIP Read を使用して解決できますが、私は別の、より効率的なオンチェーン解決ロジックを思いつきました。

キーストア上のすべてのアカウントは、ENS 名の名前ハッシュによって登録され、インデックス付けされます (カスタムリゾルバを使用して単一の ENS 名で登録されます)。サブドメインが解決されると、リゾルバコントラクトは、そのような名前ハッシュを持つアカウントがロールアップ内に存在するかどうかを確認し、名前ハッシュを使用してCREATE2ベースのミニアカウントアドレスを生成します。

これらがデプロイされると、デプロイされたネームハッシュに属するキーストアデータを L1 に要求します。キーストアの実装に応じて、トランザクションインテント自体または現在の署名キーのみになります。このようにして、ロールアップごとにそれ自体とそのミニアカウントに解決される ENS 名を持つキーストアアカウントが取得されます。これらのミニアカウントは、キーストアロールアップを使用してトランザクションを検証するときにも、この ENS 名に依存します。

「Keystore+」ロールアップのシーケンスメカニズム

拡張キーストアロールアップのブリッジのファイナリティはいくつかの L1 ブロックになるはずなので、集中型シーケンサーを完全に取り除き、ベースロールアップに変えたほうがよいでしょう。以前に説明したように、平均的なユーザーにとっては 12 秒程度のトランザクション速度は許容範囲ですが、ベースシーケンシングにより、ロールアップは検閲や単一障害点に対する耐性がはるかに高まります。

ベースシーケンスでは、内部トランザクションに外部トランザクションと同じ時間がかかる (L2 に到達する時間を除く) ことを考慮する価値があります。集中型シーケンスではすべての内部操作が瞬時に行われるため、一部のチームにとってはこれが受け入れられない場合があります。

代替ロールアップ相互運用性ソリューションまたは共有シーケンスについて言及しなかった理由

私はこの記事全体を ZK ロールアップと ZK テクノロジーを中心に書きました。これは、楽観的ロールアップは基本的に高速な客観的な最終性を持つことができず、そのような特性は ZK を使用することでのみ実現できるためです。今日の楽観的ロールアップは、その封印された立場を理解しており、スタックに有効性中心の設計を統合する可能性を積極的に研究しています。そのため、たとえば、最近の Optimism と RISC Zero のパートナーシップが生まれました。

楽観的設計は、他のロールアップとの相互運用性を処理することができないという点で、基本的に制限があります。ただし、楽観的エコシステム内の相互運用性は急速に発展しています。楽観的ロールアップを相互に相互運用可能にするための主要なテクノロジは、共有シーケンスです。簡単に言えば、これはシーケンサーが複数のロールアップのバッチを同時に構築できるメカニズムです。シーケンスされたロールアップのいずれかのトランザクションが無効である場合、バッチ全体を異議申し立てして元に戻すことができます。

これにより、この「メガバッチ」内のすべてのバッチにアトミックプロパティが与えられます。つまり、すべてのバッチが有効であるか、まったく有効でないかのいずれかになります。これにより、バッチ内でアトミックな同期構成が可能になります。アトミック (有効なバッチには無効なものがない)、同期 (すべてのメッセージングがバッチ内にあり、すべてのロールアップノードによって同時に処理される) です。

このテクノロジーは、基本的に、特定の楽観的スタック内のすべてのロールアップを 1 つの大きなシャードロールアップに変換します。なぜ 1 つのスタックだけであり、すべてのスタックではないのでしょうか。これは、これが機能するためには、ロールアップを 1 つのブリッジに接続する必要があるためです。各スタックには独自のブリッジがあり、複数のブリッジで同時にバッチを構築する信頼性の高い方法はありません。つまり、共有シーケンスにより、OP Mainnet は Base および Zora とはシームレスに相互運用できますが、Arbitrum または Metis とは相互運用できません。その逆も同様です。

このような統合は、ロールアップエコシステムに危険な状況を生み出します。新しいロールアップには、既存のスタックに参加してそれと統合されるが他のスタックとは統合されないか、ZK の上に構築して上位のスタック以外のスタックと統合されるかを選択できます。共有シーケンスはまだ利用できないため、現時点ではそのような選択肢はありません。また、各 OP Stack または Arbitrum Orbit ロールアップは独立しており、独自のブリッジを備えています。ただし、統合されると、エコシステム内に 2 つの強固な有機体が形成され、それぞれがL2s TVL 全体の約 40%を占めることになります。

「わかりました。彼らが総TVLの大部分を保有するのであれば、ZKを排除して代わりに彼らの上に構築するのはどうでしょうか？」

まず第一に、共有シーケンサーは集中化の大きな推進力となります。OP メインネットシーケンサーを実行すると、バッチにはスタック内の他のロールアップからのトランザクションが含まれなくなります。そのため、手数料が減り、最終的にはバッチでスタック全体を処理できる大規模な商用シーケンサーに追い抜かれてしまいます。

しかし、最も重大な問題は、そのような場合、ロールアップエコシステムが、自らの利益を追求し、資本に対するさらなる支配を確立しようとし、エコシステムにおける技術の進歩を怠る寡占帝国に閉じ込められてしまうことです。そうなると、実際に世界を変える技術ではなく、PR と種内闘争が重要となる孤立した領域に Ethereum が押しつぶされてしまうことに対処しなければなりません。

「帝国ではなくツールを構築しましょう。帝国はユーザーを囲い込み、壁で囲まれた庭の中に閉じ込めようとします。ツールはタスクを実行しますが、それ以外はより広いオープンエコシステムと相互運用します。」—ヴィタリック・ブテリン

「ZK での共有ブリッジの集約は、楽観的共有シーケンスよりも優れている点は何ですか?」

ZK ロールアップの共有ブリッジでは、ブリッジ内の他のロールアップとは独立してシーケンス処理を実行できます。各ロールアップは独自のシーケンサーを持つことも、共有シーケンス処理を実装することもできます。すべてのシーケンス処理されたバッチの後に結果の状態ルートをアサートし、ZK を使用してそれを証明する提案者は、集約を行う者です。

さらに、ZK ロールアップの比較的高速な客観的な最終性という特性は、それがどれだけ大きくなっても、どれだけ集中化されても、ZK ロールアップがそのエコシステム内に閉じ込められることにはなりません。複数の証明システム用の大規模な zkVM 証明を迅速に生成できるレベルまで ZK が開発されると、すべての ZK ベースのロールアップスタックは、前述の理論上のキーストアロールアップが他のすべてのロールアップのトランザクションを L1 ブロックで送信するのと同じように、ほぼシームレスに相互運用できるようになります。

「しかし、オプティミスティックロールアップがそれほど悪質であるのに、ZK ロールアップという代替手段があるのに、なぜまだ存在しているのでしょうか?」

研究者や高度な技術を持つ人々で構成されるコミュニティでは、ZK が最適なスケーリングソリューションであるという点でコンセンサスが得られています。また、一般ユーザーやビルダーにとっては、オプティミスティックロールアップの方が ZK よりもはるかに優れていることに驚かれることでしょう。なぜでしょうか?

ユーザー向け: 確立されたエコシステムがあります。すべてのプラットフォームが Arbitrum と Base を知っており、dApp は常に高い流動性があり、UX は香り高いです。Base のアプリケーションの名前を挙げてみると、 Friend.tech 、 Farcaster 、 Daimo 、 Time.fun (現在は Solana 専用)、さまざまな NFT コレクション、ZKP2P がすぐに思い出されるでしょう。Mirror でさえ、当初は OP Stack ロールアップのみをミントとしてサポートしていました。ZKsync Era のアプリケーションの名前を挙げてみてください。うーん...

開発者向け: Ethereum と完全に同等であるため、Ethereum と EVM フォークのインフラストラクチャ全体がすぐに使用できます。さらに、ドキュメントでは、オプティミスティックロールアップのすべての特性とツールが綿密に定義および説明されています。チュートリアル、コース、マラソン、開発者向けリレーションなど、さまざまなものがあります。

一方、1 年前の zkEVM もあり、そのすべてがバイトコード同等であるわけではありません。それらはすべて、その上に構築する際に多くの相違点と困難を抱えています。それらはほとんどが十分に文書化されておらず、ネットワークとほとんど互換性のない既存のインフラストラクチャに大きく依存しています。「互換性のある」 VM を監査するのは非常に困難で費用がかかり、質問できる ChatGPT さえありません。

ユーザーにとって： ZK ロールアップにはエコシステムがありません。使用できるアプリケーションも、ソーシャルメディアも、人気の NFT やトークンもなく、すべてのアクティビティはエアドロップファーミングに集約されます。Ethereum エコシステムのトップ 10 に含まれないペアの流動性はほとんど見つかりません。スクロールに飽きると、 DefiLlama はZK ロールアップを表示し始めます。

「しかし、楽観的ロールアップは、既存のインフラストラクチャとの互換性によって実際に勝っています。ZK ロールアップは、その点でどのように勝てるのでしょうか?」

開発者やアクティビティをプラットフォームに引き付けるために、バイトコードの同等性やblake2fプリコンパイルを導入する必要はありません。ZK ロールアップは、その点で優れているわけではありません。その代わりに、高速なファイナリティと相互運用性、完全な水平スケーラビリティ、根本的に高いセキュリティ、分散化が優れています。これらこそが、ZK ロールアップのエコシステム内のプロジェクトで活用され、エコシステム内で有利になるはずです。

この記事を書いたのは、この間にこの分野で登場し、発展してきた ZK ロールアップを含むすべてのテクノロジーの全体像をまとめ、それらを使用して、今日のこの分野で最も重要な問題であるロールアップの相互運用性を解決する方法を示すためです。私たちは ZK とその無限のメリットを受け入れなければなりません。私たちは、それらを活用して、Web3 を世界中のすべての人にとっての場に近づけるものを構築する必要があります。

これはおそらく私がこれまでに作成した中で最大の比較表です。当然のことですが、昨年、Ethereum コミュニティは、既存の技術を使っても、この分野の最も差し迫った問題を解決するまったく新しいソリューションを作成するために、柔軟に組み合わせて操作できる多くの新しいアイデアとテクノロジーを考案しました。

はい、ロールアップの相互運用性こそが、世界全体を Web3 にオンボードするのを妨げる最も差し迫った問題であると、私は今でも確信しています。スケーリングはもはやそれほど緊急ではありません。4844 では、1 秒あたり最大 1,000 件のトランザクションを処理できます。これは、世界最大の国の金融活動に匹敵します。PeerDAS が間もなく登場し、これをさらに増加させます。ただし、断片化は依然として Ethereum エコシステムに深刻な脅威をもたらします。エコシステムがどれだけ大きくなっても、エコシステムは 12 の異なる帝国のように感じられるべきではなく、1 つの大きなメカニズムのように感じられるべきです。非常に異なっているのに、非常に同一です。

私たちはまだ早い段階ではありません。この記事は、そのことを示すためのものです。私たちは、巨大な L2 エコシステムの相互運用性を支援する実用的なシステムを開発するために、全力を尽くさなければなりません。これは今すぐに可能です。まもなく、あらゆる DAO に参加し、数千キロ離れた所有者の ENS に資産を送信できるようになります。地理的な境界をデジタルの境界に置き換えるべきではありません。

この研究が気に入ったり、その主張に同意できたり、何か新しいことを学んだり、このメッセージをさらに広めたいと思ったりした場合は、ソーシャルメディアで共有したり、コメントを残したり、ロールアップの相互運用性の重要性についてさらに話し合ったりしてください。お読みいただきありがとうございました。

著者注: この記事のバージョンは以前こちらで公開されていました。