Vitalik: どのようなレイヤー 3 が理にかなっていますか?

レイヤー 2 のスケーリングに関する議論で頻繁に再浮上するトピックは、「レイヤー 3」の概念です。セキュリティとスケーラビリティの向上を主な目的としてレイヤー 1 に固定されたレイヤー 2 プロトコルを構築できるのであれば、セキュリティのためにレイヤー 2 に固定され、その上にさらにスケーラビリティを追加したレイヤー 3 プロトコルを構築することで、それを拡張できるのではないでしょうか。

このアイデアの簡単なバージョンは次のとおりです。2 次成長を実現できるスキームがある場合、そのスキームを積み重ねて指数関数的な成長を実現できますか?同様のアイデアとしては、私の 2015 年のスケーラビリティに関する論文や、Plasma 論文で言及されているマルチレイヤー スケーリングなどがあります。残念ながら、レイヤー 3 のこのような単純な概念を実行可能なソリューションに変えるのはそれほど簡単ではありません。データの可用性の制約、緊急フェッチのためのレイヤー 1 帯域幅への依存、またはその他の多くの問題により、設計には常にスタックできず、スケーラビリティが 1 回しか向上しないものがあります。

Starkware が提案したフレームワークのようなレイヤー 3 に関する新しいアイデアは、より複雑です。同じものを単に積み重ねるのではなく、レイヤー 2 とレイヤー 3 に異なる目的を割り当てます。この潜在的なアプローチ形式は、正しい方法で実行されれば機能する可能性があります。この投稿では、3 層アーキテクチャで何が意味を持ち、何が意味を持たないかについて詳しく説明します。

ロールアップをロールアップの上に積み重ねることでスケーリングを維持できないのはなぜですか?

Rollups (私の長い投稿はこちらをご覧ください) は、ブロックチェーンを実行する際の 2 つの主なスケーリングのボトルネックであるコンピューティングとデータに対処するために、さまざまな手法を組み合わせたスケーリング テクノロジーです。この計算は、「詐欺証明」や SNARK などの方法によって解決されてきました。これらの方法では、各ブロックの処理と検証を非常に少数の参加者に依存しており、他の人は証明プロセスが正しく完了したことを確認するためにわずかな量の計算を実行するだけで済みます。これらのスキーム、特に SNARK は、ほぼ無限にスケーラブルです。さらに多くの計算を単一の証明にまとめるために、「SNARK の SNARK」を作り続けることができます。

データが異なります。 Rollups は一連の圧縮技術を使用して、トランザクションがオンチェーンに保存する必要があるデータの量を削減します。単純な通貨転送は約 100 バイトから約 16 バイトに削減され、EVM 互換チェーンでの ERC20 転送は約 180 バイトから約 23 バイトに削減され、プライバシーを保護する ZK-SNARK トランザクションは約 600 バイトから約 80 バイトに圧縮できます。いずれの場合も、約 8 倍の圧縮が行われます。ただし、ロールアップでは、ユーザーがアクセスして検証できる媒体でチェーン上でデータを利用できるようにする必要があります。これにより、ユーザーはロールアップの状態を独自に計算し、既存の認証者がオフラインのときに認証者として参加できるようになります。データは一度圧縮できますが、再度圧縮することはできません。再度圧縮できる場合は、通常、2 番目のコンプレッサーのロジックを最初のコンプレッサーに組み込んで、一度圧縮した場合と同じ利点を得る方法があります。したがって、「ロールアップの上にロールアップ」を重ねても、スケーラビリティは大きく向上しませんが、以下で説明するように、このパターンは他の目的にも使用できます。

では、レイヤー3の「健全な」バージョンとは何でしょうか?

さて、Starkware がレイヤー 3 に関する投稿で何を主張しているかを見てみましょう。 Starkware は非常に優秀な暗号学者で構成されており、彼らは正気なので、彼らがレイヤー 3 を主張している場合、彼らのバージョンは「ロールアップがデータを 8 倍圧縮する場合、ロールアップの上にロールアップを重ねると、明らかにデータが 64 倍圧縮される」よりもはるかに複雑になります。 。

以下はStarkwareの投稿からの画像です。

いくつかの引用:

上の図は、そのようなエコシステムの例を示しています。 L3 には以下が含まれます:

1. Validium のデータ可用性を備えた StarkNet は、価格設定に非常に敏感なアプリケーションでよく使用されます。

2. 指定されたストレージ構造やデータ可用性の圧縮を採用するなどして、アプリケーションのパフォーマンスを向上させるようにカスタマイズされた、アプリケーション固有の StarkNet システム。

3. StarkEx システム (dYdX、Sorare、Immutable、DeversiFi にサービスを提供しているシステムなど) には Validium または Rollup データの可用性があり、実証済みのスケーラビリティの利点が StarkNet にすぐにもたらされます。

4. プライベート StarkNet インスタンス (この例では L4 とも呼ばれます) では、パブリック StarkNet に含めずにプライバシー保護タイプのトランザクションを存在させることができます。

この記事を「L3 の 3 つのビジョン」に要約すると次のようになります。

• L2 はスケーリングに使用され、L3 はプライバシーなどのカスタマイズされた機能に使用されます。このビジョンでは、「二次スケーラビリティ」を提供しようとする試みはありません。代わりに、スタックにはアプリケーションの拡張を支援するレイヤーがあり、さまざまなユースケースのカスタマイズされた機能要件を満たす独立したレイヤーがあります。

• L2 は一般的な容量拡張に使用され、L3 はカスタマイズ可能な容量拡張に使用されます。カスタマイズ可能なスケーリングには、さまざまな形式があります。たとえば、計算に EVM 以外のものを使用する特殊なアプリケーション、アプリケーション固有のデータ形式に最適化されたデータ圧縮を使用したロールアップ (各ブロックで「データ」と「証明」を分離し、証明を単一の SNARK に置き換えることを含む) などです。

• L2 は信頼できない拡張 (ロールアップ) に使用され、L3 は信頼が弱い拡張 (バリディウム) に使用されます。 Validium は、SNARK を使用して計算を検証するシステムですが、データの可用性は信頼できる第三者または委員会に委ねられています。私の意見では、Validium はひどく過小評価されています。特に、多くの「エンタープライズ ブロックチェーン」アプリケーションは、実際には、Validium を実行し、ハッシュをチェーンの集中サーバーに定期的に送信する証明者によって最もよく機能する可能性があります。 Validium はロールアップよりもセキュリティ レベルは低くなりますが、はるかに安価です。

私の意見では、これら 3 つのビジョンはすべて基本的に妥当です。特殊なデータ圧縮には独自のプラットフォームが必要であるという考えは、おそらく最も弱い提案です。ユーザーがアプリケーション固有のサブコンプレッサーを使用して自動的に拡張できる汎用ベースレイヤー圧縮スキームを使用して L2 を設計するのは簡単ですが、それ以外の使用例は妥当です。しかし、それでも大きな疑問が残ります。3 層構造はこれらの目標を達成するための正しい方法なのでしょうか?認証、プライバシー システム、カスタマイズされた環境を L1 だけでなく L2 に固定する意味は何でしょうか?結局のところ、この質問に対する答えは非常に複雑です。

L2 のサブセットツリーでは、入金と出金がより安価かつ容易になりますか?

3 層モデルが 2 層モデルより優れている理由の 1 つは、3 層モデルではサブエコシステム全体を単一のロールアップ内に存在させることができるため、そのエコシステム内でのクロスドメイン操作を、高価な L1 を経由せずに非常に安価に実行できることです。

しかし、2 つの L2 間、または L3 間でも、入出金は非常に安価になる可能性があることがわかりました。ここで重要なのは、トークンやその他の資産をルートチェーン上で発行する必要がないことです。つまり、Arbitrum で ERC20 トークンを持ち、Optimism でそのラッパーを作成し、L1 トランザクションなしで 2 つの間を行き来することができます。

このようなシステムがどのように機能するかを見てみましょう。スマート コントラクトには、Arbitrum の基本コントラクトと Optimism のラップされたトークン コントラクトの 2 種類があります。 Arbitrum から Optimism に転送するには、基礎となる契約にトークンを送信して、領収書を生成する必要があります。 Arbitrum が完了すると、L1 状態にルート化されたその受領書の Merkle 証明を取得し、それを Optimism のラップされたトークン コントラクトに送信できます。Optimism はそれを検証し、ラップされたトークンを発行します。トークンを元に戻すには、同じ操作を逆順に実行します。

Arbitrum での入金を証明するために必要な Merkle パスは L1 状態を経由しますが、Optimism は入金を処理するために L1 状態ルートを読み取るだけで済み、L1 トランザクションは必要ありません。ロールアップ データは最も希少なリソースであるため、このスキームの実際の実装では、スペースを節約するために、Merkle 証明を直接使用するのではなく、SNARK 証明または KZG 証明を使用することに注意してください。

L1 ベースのトークンと比較すると、このアプローチにはアキレス腱があります (少なくとも楽観的なまとめでは)。つまり、預金も詐欺防止期間を待つ必要があるのです。トークンが L1 にルートされている場合、Arbitrum または Optimism から L1 に引き出すには 1 週間の遅延が必要ですが、入金は即時です。ただし、この制度では、入金と出金の両方に 1 週​​間の遅延が発生します。とはいえ、理想的なロールアップよりも 3 層アーキテクチャの方が優れているかどうかは明らかではありません。チート防止ゲームで実行されるシステム内で行われるチート防止ゲームの安全性を確保するには、多くの技術的複雑さが伴います。

幸いなことに、これらの問題はいずれも ZK ロールアップでは発生しません。 ZK ロールアップでは、セキュリティ上の理由から 1 週間の待機時間は必要ありませんが、他の 2 つの理由から、より短い待機時間 (第 1 世代のテクノロジでは 12 時間かかる場合があります) が必要になります。まず、特により複雑な一般化された ZK-EVM ロールアップでは、ブロックの並列化不可能な計算時間をカバーするのに時間がかかります。第二に、経済的な理由から、証明取引に関連する固定費を最小限に抑えるために、証明は頻繁に提出する必要はありません。専用ハードウェアを含む次世代の ZK-EVM テクノロジーは最初の問題に対処し、より優れた設計のバッチ検証は 2 番目の問題に対処できます。次に議論するのは、最適化と証明の一括送信の問題についてです。

ロールアップとバリディウムには、確認時間と固定コストのトレードオフがあります。 L3 はこれに役立ちますが、他に同じことができるものは何でしょうか?

トランザクションごとのロールアップのコストは安価です。アプリケーションに応じて、わずか 16 ～ 60 バイトのデータです。しかし、ロールアップでは、トランザクションのバッチをチェーンに送信するたびに、高い固定コストを支払う必要があります。楽観的なロールアップでは、バッチごとに 21,000 L1 ガスが必要であり、ZK ロールアップでは 400,000 を超えるガスが必要です (STARKS だけで量子耐性のあるものを提供したい場合は、数百万のガスが必要です)。

もちろん、ロールアップは、1,000 万ガス相当の L2 トランザクションが発生してバッチ全体が送信されるまで待つという単純な選択も可能ですが、そうするとバッチ間隔が非常に長くなり、ユーザーはセキュリティの高い確認をより長く待たなければなりません。したがって、トレードオフが必要になります。つまり、バッチ間隔を長くしてコストを最適化するか、バッチ間隔を短くしてコストを大幅に増加させるかです。

具体的な数字を示すために、バッチあたり 600,000 ガスのコストで ZK ロールアップを実行し、トランザクションあたり 368 ガスのコストで完全に最適化された ERC20 転送 (23 バイト) を処理することを考えてみましょう。このロールアップが導入の初期段階から中期段階にあり、TPS が 5 であると仮定します。各トランザクションのガス コストとバッチ間隔を計算できます。

多くのカスタム検証とアプリケーション固有の環境が存在する世界に移行すると、その多くは 5 TPS を大きく下回るパフォーマンスになります。したがって、時間とコストのトレードオフを特定することが非常に重要になります。実際、「L3」パラダイムはこの問題を解決します。 ZK ロールアップ内の ZK ロールアップは、単純な実装であっても、固定コストが約 8,000 レイヤー 1 ガス (証明用に 500 バイト) のみです。上記の表は次のように変更されます。

問題は基本的に解決されているので、L3s は良いのでしょうか?多分。しかし、ERC 4337 集約検証にヒントを得た、この問題を解決する別の方法があることに注意する必要があります。

戦略は次のとおりです。現在、各 ZK ロールアップまたはバリディウムが証明を受け取ると、 S _new = STF(S _old ,D)であることが証明されます。つまり、新しい状態ルートは、古い状態ルート上でトランザクション データまたは状態増分を正しく処理した結果である必要があります。この新しいスキームでは、ZK ロールアップは、バッチ バリデータ コントラクトから、各ステートメントがS _new = STF(S _old ,D) の形式である一連のステートメントの証明を検証したというメッセージを受け入れます。このようなバッチ証明は、再帰的な SNARK スキームまたは Halo 集約によって構築できます。

これはオープン プロトコルになります。つまり、どの ZK ロールアップでも参加でき、どのバッチ証明者も互換性のある ZK ロールアップから証明を集約し、アグリゲータから取引手数料を受け取ることができます。バッチャ コントラクトは証明を 1 回検証し、各ロールアップに_{そのロールアップ}の ( Sold 、 Snew 、 D)トリプルを含むメッセージを渡します。トリプルがバッチ コントラクトから来たという事実は、遷移が有効であったことを証明する証拠として使用されます。

適切に最適化されていれば、このシナリオの各ロールアップのコストは 8000 近くになる可能性があります。そのうち 5000 は新しい更新を追加するための状態書き込み、1280 は古いルートと新しいルート、さらに 1720 はその他のデータ処理にかかることになります。したがって、同じ節約効果が得られます。 Starkware には、SHARP と呼ばれる類似のプロトコルがすでに存在しますが、これは (まだ) 許可のないオープン プロトコルではありません。

このアプローチに対する 1 つの反応は、「しかし、これは単なる別のレイヤー 3 アプローチではないのか?」というものです。ベース レイヤー <- バッチ メカニズム <- ロールアップまたはバリディウムを使用して、ベース レイヤー <- ロールアップ <- バリディウムを置き換えます。ある哲学的観点からすると、これは真実かもしれない。しかし、重要な違いがあります。中間層は複雑な完全な EVM システムではなく、単純化された高度に特殊化されたオブジェクトであるため、安全である可能性が高く、別の特殊なトークンなしで構築される可能性が高く、最小限の管理である可能性が高く、時間の経過とともに変更される可能性が低くなります。

結論: 「レイヤー」とは一体何でしょうか?

同じスケーリング ソリューションを積み重ねる 3 層スケーリング アーキテクチャは、通常はうまく機能しません。ロールアップの上にロールアップを重ねる形式（2 層のロールアップで同じテクノロジーが使用される）も不十分です。ただし、L2 と L3 の目的が異なる 3 層アーキテクチャは機能します。ロールアップに加えてバリディウムを使用することは、長期的には最善の方法であるかどうかは定かではありませんが、意味があります。

しかし、どのアーキテクチャが意味をなすのかという詳細に立ち入っていくと、哲学的な疑問が生じます。「レイヤー」とは何か、そして何がそうではないのか?ベース レイヤー <- バッチ メカニズム <- ロールアップまたはバリディウムとベース レイヤー <- ロールアップ <- ロールアップまたはバリディウムは同じ機能を果たしますが、動作の点では証明集約レイヤーはロールアップよりも ERC-4337 に似ています。通常、ERC-4337 を「レイヤー 2」と呼ぶことはありません。同様に、Tornado Cash を「レイヤー 2」と呼ぶことはありません。したがって、一貫性を保つために、L2 の上にあるプライバシー重視のサブシステムを L3 と呼ぶことはありません。したがって、まず何を「レイヤー」と呼ぶべきかについて、未解決の意味論的議論が存在します。

この点に関しては、さまざまな考え方が考えられます。私の個人的な好みとしては、「レイヤー 2」という用語を、次の特性を持つものに限定します。

1. スケーラビリティの向上が目的

2. 「ブロックチェーン内のブロックチェーン」モデルを採用しており、独自のトランザクション処理メカニズムと独自の内部状態を持っている。

3. イーサリアムチェーンの完全なセキュリティを継承

したがって、理想的なロールアップと ZK ロールアップは L2 ですが、検証、証明集約スキーム、ERC 4337、オンチェーン プライバシー システム、および Solidity は別の問題です。いくつかを L3 と呼ぶのは理にかなっているかもしれませんが、すべてを L3 と呼ぶのはおそらく無理でしょう。いずれにせよ、定義を確定するのは時期尚早と思われます。また、マルチアグリゲーションエコシステムのアーキテクチャは未だ確定しておらず、ほとんどの議論は理論上のみ行われています。

つまり、言語的な議論よりも、どの構造が実際に最も意味をなすかという技術的な問題の方が重要です。明らかに、プライバシーなどの非スケーリングのニーズに応える特定の「レイヤー」には重要な役割があり、証明集約の重要な機能は、できればオープン プロトコルを通じて、何らかの方法で満たされる必要があります。しかし同時に、ユーザー向けの環境と L1 をリンクする中間層を可能な限りシンプルに保つことには、十分な技術的理由があります。多くの場合、EVM ロールアップの「接着層」として機能することは適切なアプローチではない可能性があります。 L2 拡張エコシステムが成熟するにつれて、この記事で説明したより複雑な (そしてより単純な) 構造がより大きな役割を果たし始めるのではないかと思います。