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

ロールアップ中心のエコシステムの愛好家として、私は常にロールアップの相互運用性を向上させるソリューションに興味を持っていました。さらに、この調査レポートを作成した唯一の理由は、この分野における を訴えるためでした。その後、記事を書くことは、特定のトピックに関する自分の理解を固め、人々に理解してもらうための優れた方法であることに気付き、今ここにいます。 相互運用性の重要性 暗号通貨の世界では毎日新しいことが学ばれているので、今日では の相互運用性はイーサリアムの将来にとって絶対に重要であり、エコシステム全体がそれを改善するソリューションに取り組むべきです。しかし、テクノロジーの観点からは、このトピックについて多くの新しいアイデアを学び、いくつかのことについて考えが変わりました。 「ロールアップの相互運用性はイーサリアムの将来にとって重要」という時代の私のビジョンがかなり時代遅れになっているのは明らかです。哲学の観点からは、私は今でも同じビジョン**に従っています。ロールアップ 以下の内容を理解するには、ロールアップとその相互運用性の問題について基本的な知識を持っていることが役に立ちます。そうでない場合は、私の記事 が優れた入門書となります。 「Dr. Dankshard、または私が心配するのをやめてロールアップを愛するようになった方法」 メルハバ！ 11月13日の夕方、 の初日。ZkSync 大ファンである私は、このサミットの初めてのイベントとして、人生初の zkSync Connect に参加することにしました。そこで、ある男性と出会い、zkCafe の Luma ページに書かれていた「Mosyo Coffee」に一緒に向かいました。そのエリアには 2 軒のカフェがあり、夕方になってようやく目的の場所を見つけました。 Devconnect Istanbul の 上の写真よりもずっと暗く、土砂降りの雨が降っていました。フードコートがある屋上の端に座り、 の無料トークンで買ったコーヒーを飲みながら、新しい友人にハッカソン プロジェクトのアイデアについて話しました。 Clave 「ミニアカウント」があります。ERC アカウントの検証ロジックは署名チェックではなく、L2 の単一の受信ボックス ブリッジ内の操作のハッシュの存在です。ハッシュは、特定のソース チェーンの親アドレスから送信する必要があります。親アドレスは、任意の L2 または Ethereum L1 のメインのスマート ウォレットです。別の L2 とやり取りするには、次の操作を行います。 -4337 そこにミニアカウントを展開し、メインウォレットを親アドレスとして設定します。展開は誰でも実行できるため、プロトコルまたはウォレットプロバイダーから資金を調達できます。 送信するユーザー操作のハッシュを 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 時間、 9 時間で完了します。 Starknet は しかし、なぜそうなるのでしょうか? 強力なクラスターでは ZK 証明の生成は高速ではないのでしょうか? 簡単に言えば、2 つの問題があります。 ZKsync Era などの一部の ZK ロールアップでは、証明システムにバグがあった場合にセキュリティ カウンシルが一部のバッチを元に戻す時間を確保するために実行遅延を設定しています。zkEVM は非常に複雑なテクノロジであり、この複雑さのため、複数の証明システムを同時に使用してバグを確率的に防止することはまだ実現可能ではありません。 ZK 証明の検証は、証明する計算に比べると非常に軽量ですが、オンチェーンでの検証は依然としてかなりコストがかかります。証明システムによっては、検証ごとに最大 100 万ガスかかる場合があります。平均ガス価格 9 gwei と現在の ETH 価格を考慮すると、L1 での検証のみで 1 回の証明に約 30 ドルかかります。 最新の ZK ロールアップでは、一定時間ごとに多数のバッチに対して 1 つの証明を生成することでこれらの費用を最小限に抑えていますが、これによりブリッジのファイナリティ速度が低下します。バッチを生成してブロックごとに証明すると、ブロックあたり 30 ドル、つまり 費用がかかります。100 TPS の場合、検証コストだけでトランザクションあたり約 0.025 ドルになります。また、証明を生成してバッチをオンチェーンで公開する必要もあります。 1 日あたり 216,000 ドルの 取引に 1 ～ 2 時間待つのは、まだ長すぎます。どうすればよいでしょうか? まず、8 か月前に始めたハッカソン プロジェクトを忘れて、すべてのトランザクションをメインのスマート ウォレットから開始する必要があるというメンタル モデルを排除してみましょう。ロールアップごとにスマート ウォレットのロジックを共有する必要はなぜあるのでしょうか。一時的な EOA を生成し、メインのスマート ウォレットから資金をそこにブリッジし、やりたい作業をいくつか実行して、残った分をブリッジしてしまえばよいのではないでしょうか。 私の (または、使用しているスマート ウォレット) には、Secure Enclave 署名とソーシャル リカバリー機能が搭載されているため、携帯電話を紛失した場合でも、常に資金を安全に保管できます。また、これらの一時アカウントがどうなるかなんて誰も気にしません。すでにそれらのアカウントで用事を済ませています。すべての資金は、現在 Clave にあります。 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 が、a) 証明の検証は依然として数時間ごとに行われるため、検証されないままになり、b) Scroll は現在使用する ものの 1 つになります。 は約 1 分ごとに状態を提案します ロールアップの中で最もコストのかかる もっと簡単に言い換えると、問題はコストの証明とコストの検証です。それぞれの問題とその解決方法を見てみましょう。 本質的に、私たちの仕事は、外部ブリッジによってもたらされる追加の信頼の仮定なしに、ロールアップ上のスマートウォレットを他のロールアップと迅速に相互運用できるようにすることです。スマートウォレットは通常、ペイマスター、ソーシャルリカバリー、セキュアエンクレーブ、支出限度額などのいくつかの通常の AA 機能と、そこからオンチェーントランザクションを送信できるようにするメイン操作で構成されます。 ウォレットから他のロールアップを使用する場合、メイン操作が必要なのはなぜでしょうか? おそらく、多目的ロールアップ (Arbitrum、Base、ZKsync Era) でホストされており、このロールアップでもユーザーやスマート コントラクトと対話する必要があるためです。 この特定のケースでは、外部トークン ブリッジを使用するだけで十分です。たとえば、タスクを同じロールアップ内の dApp と別のロールアップ内の dApp とのやり取りに置き換えるだけです。 この多目的性が、ロールアップの証明システムに複雑さをもたらします。毎秒多数のスマート コントラクトとトランザクションが発生している仮想マシン全体の状態を検証するのは、かなり困難な作業です。ロールアップではまったく異なる機能セットを必要とする 2 種類のタスクを実行したいと考えています。オンチェーン トランザクションの場合は、高速な L2 包含、低い L2 料金、VM の幅広い機能であり、マルチロールアップ トランザクションの場合は、高速なブリッジのファイナリティです。 。Vitalik Buterin は、Devconnect Istanbul の頃に「キーストア ロールアップ」と呼ばれる同様の手法を提案しました。これについては次に説明します。 しかし、仮想マシンを廃止して、スマート アカウントと他の L2 へのメッセージングのみを処理できるロールアップを構築したらどうなるでしょうか キーストアのロールアップ アイデアは、アカウント キーのみを保存し、別のキーを使用して変更できる ZK ロールアップを作成することです。このロールアップは、これらすべてのキーを含む Merkle ツリーのルートを L1 にプッシュします。次に、L2 のスマート アカウントの 1 つからトランザクションを送信するときに、現在のキーの Merkle 証明を生成し、アカウントはそれを L1 で使用可能なキーストア ルートに対して検証します。これで、アカウントはキーを認識し、それを使用して署名を検証できます。 このようなロールアップは非常にシンプルで、複数の証明システムを簡単に実装できるため、そこに保存されるキーは実際には L1 と同じくらい安全です。 Vitalik のオリジナル設計の他に、キーストア ロールアップには 3 つの主要な設計があります。 アプローチは、キーストア データを L1 に保存しながらも、zkEVM ロールアップから更新できるようにすることです。このために、L1 ストレージの読み取りコストを抑える L1SLOAD プリコンパイルを導入しています。その後、他の L2 の AA アカウントがこのデータを読み取って、キーやガーディアンなどの構成を同期できます。 Scroll の 、状態ルートのみが L1 に保存され、トランザクションは calldata を使用して順序付けられるため、ツリーをいつでも再構築できるという手法を研究しています。L2 のアカウントは、Merkle 証明を使用して現在のキーを取得することが期待されています。 ベース チームは 設計は Base や Vitalik と非常に似ていますが、特殊な最小限の VM を使用した独自の「マイクロロールアップ」フレームワークを利用しています。 Stackr の 一般的に言えば、オフチェーン処理に委任されるタスクの数（つまり、L2 上にあるものの数）と実装の詳細が異なります。 このアイデアをさらに拡張して、 なく を処理することもできます。これも計算上それほど難しくはありません。基本的に、次のタスクを処理するだけで済みます。 キーだけで スマート アカウント ロジック全体 キーストア ロールアップ上のアカウントは、トランザクションの意図を L1 に通知できる必要があります。トランザクション全体を L1 に保存する必要はありません。ユーザー操作のすべてのハッシュを含む Merkle ツリーのルートのようなもので十分です。その後、ミニ アカウントからトランザクションを送信するために必要なのは、送信先 L2 からルートを読み取り、特定の AA 操作が実際に親アカウントから要求されたことを証明することだけです。 L1 へのデータの送信: ユーザーは、特定のロールアップで実行するユーザー操作のハッシュに署名します。キーストア ロールアップは、署名を検証して を証明し、ハッシュをツリーに追加して L1 にプッシュします。ECDSA、 、 などのいくつかの署名スキームで十分です。 署名チェック: 意図 P256 耐量子暗号 「ガーディアン」と呼ばれる、意図的に選ばれた他のアカウントに、ユーザーのアカウントのキー変更に投票してもらいます。ユーザーはガーディアンとしきい値を設定し、キー紛失時に回復を依頼できます。また、 や、 、ZK-OTP、 などの代替ガーディアン スキームを実装して、ロールアップのユーザー以外にもソーシャルリカバリを拡張することもできます。 ソーシャルリカバリ: 拒否ベースの回復 ZK-Email Web Proofs ウォレットが盗まれた場合、保護者が管理する支出ルールにより、ユーザーがウォレットを取り戻すまでの潜在的な損失を大幅に減らすことができます。この機能は、資金を貯めたり、たとえば子供用のウォレットを作ったりするのにも役立ちます。親が小遣いを渡し、その使い道を制限することで、子供が貯金の仕方を学べるようにすることができます。 支出ルール: 不必要と思われるかもしれませんが、キーストア ロールアップ 暗号資産を保存できると、複数のミニ アカウントに分割されることがなくなり、ユーザーの資産のセキュリティが大幅に向上します。また、ユーザー エクスペリエンスを向上させる多くの機能も利用できます。 トークン残高: 内に ロールアップは、新規ユーザーを引き付けるために無料トランザクションを提供したり、ETH だけでなく任意のトークンで料金を支払えるようにしたりすることができます。より複雑なペイマスター ロジックも実装できます。たとえば、シーケンサーは、別のチェーンのスワップがキーストア ロールアップにブリッジバックされるときに、そのチェーンから料金を受け取ることができます。 ペイマスター: ロールアップ ユーザー間で資金を即座に送信するだけでなく、直接転送は、ミニ アカウントからキーストア ロールアップの親アカウントへのブリッジに L1 を使用するにはファイナリティが遅すぎる他のロールアップとのインテント ベースのブリッジを実装するのにも役立ちます。このように、キーストア ロールアップは基本的にハブとして機能し、数十のさまざまな L2 上のミニ アカウント間でトークンを安価に転送できます。 内部トークン転送: このようなシステムは、ロールアップ内の完全な VM よりも技術的にはるかに単純であるため、複数の証明システムの証明を同時に生成することが可能であり、証明生成の複雑さは依然として大幅に軽減されます。 しかし、証明の検証はまだ問題です。以前計算したように、ガス コストはガス価格に応じて最大 100 万ガスまたは約 25 ～ 50 ドルになります。このコストは固定されており、バッチ内のトランザクションの数に依存しません。つまり、トランザクションが少なすぎると、各トランザクションの手数料が非常に高くなる可能性があります。このコストを削減するには、主に 2 つの方法があります。 整列レイヤー 再ステーキング演算子を利用して ZK 証明を安価に検証する EigenLayer AVS です。EigenLayer に詳しくない方のために、Aligned で証明が検証される方法を簡単にまとめると次のようになります。 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は、プロトコルからデータを公開し、独自に処理します。現在開発中の 、まさにこれを行います。Alignedは、いわゆる にも取り組んでいますが、これは実際には証明集約システムでもあります。 汎用（ユニバーサル）集約： Nebraのユニバーサル証明集約システムは 「スローモード」検証 楽観的ロールアップの共有シーケンスと同様に、スタックを持つ ZK ロールアップは、ブリッジ内のすべての ZK ロールアップの集約された状態証明を使用して共有ブリッジで動作します。これにより、共有シーケンスのようにスタック内で同期構成が可能になるだけでなく、証明検証のコストも最小限に抑えられます。Polygon の や ZKsync の について聞いたことがあるかもしれません。これらは、ブリッジ内で証明の集約で動作する共有ロールアップ ブリッジです。 共有ロールアップ ブリッジの集約: AggLayer Hyperbridge ユニバーサル集約システムの利点は、プロジェクトに依存せず、集約プロセス自体に特化しているため、証明の検証が非常に速く、コストが低いことです。また、ブリッジコンポーネントがないため、補助輪がない可能性があります。 集約ロールアップ ブリッジは、キーストア ロールアップが既存のロールアップ スタックと同期して構成できるようにするのにも役立ちます。たとえば、 、現在 13 のプロジェクトが Polygon CDK を使用して構築されており、11 のプロジェクトが ZK スタックを使用しています。これらすべてが共有証明集約ブリッジに接続すると、キーストア ロールアップをそのうちの 1 つに接続すると、L1 に触れることなく、多くの L2 とのシームレスな対話が可能になります。これが機能するには、ブリッジが L2 に対して異なる状態遷移ロジックをサポートしている必要があります。キーストア ロールアップのロジックは、ブリッジ内の他の L2 とは異なるためです。 L2BEAT によると ただし、これらのブリッジは通常、アップグレード可能であり、DAO またはセキュリティ カウンシルによって制御されます。キーストア ロールアップ プロジェクトは、接続先のブリッジのオペレーターに主権を譲ることに抵抗を感じる場合があります。また、ブリッジは、ZKsync Era の現在の動作と同様に、補助輪の予防措置として実行遅延を導入する可能性があり、これにより、このキーストア ロールアップ設計の効率が実質的に完全に失われます。 このように、キーストアのロールアップは、他の ZK ロールアップと同様に、証明検証コストを最小限に抑えることができ、さらに、既存のロールアップ スタックとの同期構成と組み合わせることもできます。 「Keystore+」ロールアップによる効率的なインテントベースのブリッジ 前述のように、L2 から L1 へのブリッジングだけが問題ではありません。ほとんどのロールアップ シーケンサーは、L1 から L2 へのメッセージの受け渡しにも遅延を適用します。これは、Ethereum ブロックが作成されたときにはまだ最終版ではなく、次の約 64 ブロック (2 エポック、約 13 分) 内で元に戻すことができるためです。これらの再編成はネットワークの遅延によって発生し、一部のノードがすでに見逃したと見なしているときに、一部の提案がネットワークに表示されるのが遅すぎます。 んが 、ロールアップ チームは依然としてメッセージの欠落に関連するリスクを冒したくないため、L1 からのブリッジに遅延を適用します。これらの遅延は、一部のロールアップ ( 、 ) では約 1 分ですが、 のように最大 6 分になる場合があり、 のように L1 ファイナリティを要求する場合もあります。 ほとんどの再編成は 2 ブロックより深くはありませ (2 年前には 7 ブロックの再編成がニュースに登場しました) OP スタック ZK スタック Arbitrum Linea Ethereum コミュニティは、各ブロックがエポックに 1 回ではなく独立してファイナライズされる ます。ただし、2025 年第 1 四半期に予定されている ことは確かであるため、SSF が実装されるまでには少なくとも 1 年かかるでしょう。 シングル スロット ファイナリティに積極的に取り組んでい 次の Pectra アップグレードでは計画されていない この拡張キーストア ロールアップ設計を実装するチームがこのようなトランザクション遅延に不安がある場合は、前述の緩和策を実装できます。すべてのミニ アカウントには、トランザクションを送信することが承認されたキーがあるか、キーストアの静的キーを使用します (Vitalik の元の設計どおり)。ただし、アカウント管理はメイン キーストア アカウントで行われます。SSF が L1 に実装された後、ロールアップは承認された支出キーを削除でき、ユーザーは大幅な速度低下なしに AA カスタマイズ機能全体を利用できるようになります。 ここで私はアレックスに同意します。15 秒の遅延は絶対に許容範囲です。特に、キーストア ロールアップ トランザクションが L1 で確定した後は操作がアトミックであるためです。トークン転送について言えば、受信者のウォレットは UI レベルで「保留中」ステータスを実装することもできます。 ただし、ロールアップ間のトークン転送には依然として問題があります。キーストア ロールアップ内にトークン ボールトを実装すると、受信者のロールアップに応じて、そこからのトークン転送に 1 ～ 15 分かかります。実装しない場合は、ユーザーの残高を複数の L2 上のミニ アカウントに分割すると、セキュリティ上のリスクが生じ、一部の資産が流動性の低い L2 にロックされ、そこからのブリッジにコストがかかりすぎたり、時間がかかりすぎたりする可能性があります。 代替案として、インテントベースのブリッジをロールアップに統合し、他のすべてのロールアップに展開したり、 準拠のプロトコルなどの既存のインフラストラクチャを再利用したりすることもできます。次のセクションでは、インテント ブリッジについて簡単に説明します。 ERC-7683 インテントベースブリッジとは何ですか? 既存のクロスチェーン ブリッジのほとんどは、メッセージング プロトコルに基づいています。たとえば、 、 使用してデポジットに関するメッセージを宛先チェーンに渡し、これを信頼のソースとして利用しています。このようなブリッジを介してトークンを送信すると、一方の側でトークンがロックされ、もう一方の側でデポジットに関するメッセージが送信され、そこにある金庫で対応する量のトークンがロック解除されます。 Stargate は LayerZero を 一方、 、2 つのチェーン間でメッセージを送信しません。代わりに、送信される資金は「クロスチェーン注文」として金庫にロックされ、その後、要求された量のトークンを宛先チェーンに送信することで、誰でも注文を満たすことができます。注文を満たす人は誰でも、宛先チェーンの最終状態が金庫に通知され、転送を確認できると、ソースチェーンからロックされたトークンを請求できます。 インテントベースのブリッジは これは、宛先チェーンの目的 (ブリッジ) の最終性を待つか、外部のオラクル プロトコルを介して行われます。たとえば、 、まだ最終化されていない L2 の状態を取得します。 Across は UMA の楽観的オラクルを使用して このシナリオでは、Ethereum L1 が信頼のソースとして使用されます。Across などの一部のプロトコルでは、代わりに外部オラクルを使用します。実際の設計は既存のプロジェクトによって異なる場合があります。ここでは一般的なアイデアのみを示します。 これらの拡張キーストア ロールアップに同じ設計を使用して、キーストアと他のすべての L2 間の信頼性のない高速で安価な双方向ブリッジを実装できます。高速ブリッジのファイナリティにより、L2 での履行の証明にはわずか数分しかかからないため、他の L2 はほぼ無料になります。 からの 意図ベースの注文 キーストアからの注文もおそらく安価になるでしょう。L2 の流動性はキーストアを通じて比較的速く供給できるからです。このように、このようなキーストア ロールアップ設計は、意図に基づくブリッジングのハブとなり、ユーザーは数分ではなく即座にトランザクションを送信でき、ブリッジングにほとんど費用がかかりません。ロールアップ チームは、キーストアを通じて 1:1 でブリッジングの流動性を供給することもできますが、これにはそれほど費用はかかりません。 すべてのチェーンに統一されたENS名 受信者がどのチェーンに属しているかに関係なく、すべてのミニアカウントに解決される単一の があると想像してください。この設計により、これが可能になります。どのように? username.eth メインのキーストア アカウントのアドレスはすでにわかっているので、 と 使用して、Ethereum L1 も含め、すべてのバイトコード相当の EVM チェーンでミニ アカウントのアドレスを同じにすることができます。次に、ENS リゾルバで統一されたアドレスを設定すると、名前がすべての EVM L2 で機能します。 マルチチェーン ファクトリ CREATE2 を ただし、例外的なケースが 2 つあります。 これらの EVM では、CREATE2 ルールに従ってカスタム アドレスを生成し、 に従ってチェーン識別子とともに ENS に追加できます。 ZK Stack などのバイトコードと同等でない EVM。 ENSIP-11 ロジックは同じですが、代わりに、 に従ってカスタム アドレスを ENS に追加します。 キーストアなどの非 EVM L2。 ENSIP-9 このアプローチは非常に 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 のアプリケーションの名前を挙げてみると、 、 、 、 (現在は Solana 専用)、さまざまな NFT コレクション、ZKP2P がすぐに思い出されるでしょう。Mirror でさえ、当初は OP Stack ロールアップのみをミントとしてサポートしていました。ZKsync Era のアプリケーションの名前を挙げてみてください。 ユーザー向け Friend.tech Farcaster Daimo Time.fun うーん... : Ethereum と完全に同等であるため、Ethereum と EVM フォークのインフラストラクチャ全体がすぐに使用できます。さらに、ドキュメントでは、オプティミスティック ロールアップのすべての特性とツールが綿密に定義および説明されています。チュートリアル、コース、マラソン、開発者向けリレーションなど、さまざまなものがあります。 開発者向け 一方、1 年前の zkEVM もあり、そのすべてがバイトコード同等であるわけではありません。それらはすべて、その上に構築する際に と困難を抱えています。それらはほとんどが十分に文書化されておらず、ネットワークとほとんど互換性のない既存のインフラストラクチャに大きく依存しています。「互換性のある」 VM を監査するのは非常に困難で費用がかかり、質問できる ChatGPT さえありません。 多くの相違点 ZK ロールアップにはエコシステムがありません。使用できるアプリケーションも、ソーシャル メディアも、人気の NFT やトークンもなく、すべてのアクティビティはエアドロップ ファーミングに集約されます。Ethereum エコシステムのトップ 10 に含まれないペアの流動性はほとんど見つかりません。スクロールに飽きると、 ZK ロールアップを表示し始めます。 ユーザーにとって： DefiLlama は 「しかし、楽観的ロールアップは、既存のインフラストラクチャとの互換性によって実際に勝っています。ZK ロールアップは、その点でどのように勝てるのでしょうか?」 開発者やアクティビティをプラットフォームに引き付けるために、バイトコードの同等性や プリコンパイルを導入する必要はありません。ZK ロールアップは、その点で優れているわけではありません。その代わりに、高速なファイナリティと相互運用性、完全な水平スケーラビリティ、根本的に高いセキュリティ、分散化が優れています。これらこそが、ZK ロールアップのエコシステム内のプロジェクトで活用され、エコシステム内で有利になるはずです。 blake2f この記事を書いたのは、この間にこの分野で登場し、発展してきた ZK ロールアップを含むすべてのテクノロジーの全体像をまとめ、それらを使用して、今日のこの分野で最も重要な問題であるロールアップの相互運用性を解決する方法を示すためです。私たちは ZK とその無限のメリットを受け入れなければなりません。私たちは、それらを活用して、Web3 を世界中のすべての人にとっての場に近づけるものを構築する必要があります。 これはおそらく私がこれまでに作成した中で最大の比較表です。当然のことですが、昨年、Ethereum コミュニティは、既存の技術を使っても、この分野の最も差し迫った問題を解決するまったく新しいソリューションを作成するために、柔軟に組み合わせて操作できる多くの新しいアイデアとテクノロジーを考案しました。 はい、ロールアップの相互運用性こそが、世界全体を Web3 にオンボードするのを妨げる最も差し迫った問題であると、私は今でも確信しています。スケーリングはもはやそれほど緊急ではありません。4844 では、1 秒あたり最大 1,000 件のトランザクションを処理できます。これは、世界最大の国の金融活動に匹敵します。PeerDAS 間もなく登場し、これをさらに増加させます。ただし、断片化は依然として Ethereum エコシステムに深刻な脅威をもたらします。エコシステムがどれだけ大きくなっても、エコシステムは 12 の異なる帝国のように感じられるべきではなく、1 つの大きなメカニズムのように感じられるべきです。非常に異なっているのに、非常に同一です。 が 私たちはまだ早い段階ではありません。この記事は、そのことを示すためのものです。私たちは、巨大な L2 エコシステムの相互運用性を支援する実用的なシステムを開発するために、全力を尽くさなければなりません。これは今すぐに可能です。まもなく、あらゆる DAO に参加し、数千キロ離れた所有者の ENS に資産を送信できるようになります。地理的な境界をデジタルの境界に置き換えるべきではありません。 この研究が気に入ったり、その主張に同意できたり、何か新しいことを学んだり、このメッセージをさらに広めたいと思ったりした場合は、ソーシャル メディアで共有したり、コメントを残したり、ロールアップの相互運用性の重要性についてさらに話し合ったりしてください。お読みいただきありがとうございました。 著者注: この記事のバージョンは以前 公開されていました。 こちらで