執筆者: Vitalik Buterin、イーサリアム共同創設者
編集者: Dong Yiming、チェーン キャッチャー
フィードバックとレビューを提供してくれた Georgios Konstantopoulos、Karl Floersch、Starkware チームに心より感謝いたします。
レイヤ 2 のスケーリングに関する議論でよく浮上するトピックは、「レイヤ 3」の概念です。セキュリティの実現とスケーラビリティの向上を主な目的として、レイヤ 1 にアンカーされたレイヤ 2 プロトコルを構築できれば、「レイヤ 2 にアンカーされた」プロトコルを構築し、レイヤ 3 の上にさらにスケーラビリティを追加することで、確実にセキュリティを実現できます。プロトコルの規模を拡大するには？
このアイデアを簡単に説明すると、2 次的な成長を達成できるソリューションがある場合、そのソリューションをそのソリューションの上に積み重ねて、指数関数的な成長を実現できるかということです。同様のアイデアには、私の 2015 年のスケーラビリティに関する論文や、プラズマの論文で言及されている多層拡張機能が含まれます。残念ながら、このような単純なレイヤー 3 の概念は、実現可能なソリューションを形成するのがそれほど簡単ではありません。設計には、データ可用性の制約、緊急に抽出されたレイヤー 1 帯域幅への依存、またはその他の多くの問題により、スタッカブルではなく、スケーラビリティを向上させるだけのものが常に存在します。
Starkware が提案したフレームワークなど、レイヤー 3 に関する新しいアイデアはより複雑です。同じものを単にその上に積み重ねるのではなく、レイヤー 2 とレイヤー 3 に異なる用途を割り当てます。このアプローチの潜在的な形式は、正しい方法で実行されれば機能する可能性があります。この記事では、3 層アーキテクチャで何が意味をなすのか、何が意味をなさないのかについて詳しく説明します。
ロールアップの上にロールアップを積み重ねることによってスケーリングを続けることができないのはなぜですか?
ロールアップは、ブロックチェーンを実行する際の 2 つの主なスケーリング ボトルネック (コンピューティングとデータ) を解決するために、さまざまなテクノロジを組み合わせたスケーリング テクノロジです。この計算は、「不正証明」または SNARK などのアプローチによって解決されています。このアプローチでは、各ブロックの処理と検証を非常に少数の参加者に依存し、証明プロセスが完了したかどうかを確認するために他の参加者が少量の計算を実行するだけで済みます。正しく。これらのスキーム、特に SNARK はほぼ無限に拡張可能であり、「多数の SNARK の SNARK」を作成し続けることで、より多くの計算を 1 つの証明に減らすことができます。
データが違います。ロールアップは一連の圧縮技術を使用して、トランザクションがチェーン上に保存する必要があるデータ量を削減します。単純な通貨転送は約 100 バイトから約 16 バイトに削減され、EVM 互換チェーンでの ERC20 転送は約 16 バイトに削減されます。約 180 バイトから約 180 バイト、23 バイト、プライバシーを保護する ZK-SNARK トランザクションは、約 600 バイトから約 80 バイトに圧縮できます。すべてのケースで約 8 倍の圧縮が行われます。ただし、Rollup では、ユーザーが独自に Rollup の状態を計算し、既存の認証者がオフラインになったときに認証者として参加できるように、ユーザーのアクセスと検証を保証する媒体でデータをオンチェーンで利用できるようにする必要があります。データは一度圧縮できますが、再度圧縮することはできません。可能であれば、通常、2 番目のコンプレッサーのロジックを最初のコンプレッサーに組み込んで、1 回圧縮することで同じ利点を得る方法があります。したがって、「ロールアップの上にロールアップを重ねる」ことによって、実際にはスケーラビリティが大幅に向上するわけではありませんが、以下で説明するように、このパターンは他の目的にも使用できます。
では、レイヤー 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 はプライバシーなどのカスタマイズ機能に使用されます。このビジョンでは、「スケーラビリティの二次的な成長」を提供する試みはありません。代わりに、アプリケーションのスケーリングを支援するスタック内に 1 つの層があり、その後、さまざまなユースケースのカスタム機能のニーズを満たす独立した層があります。
L2 は一般的な拡張に使用され、L3 はカスタマイズ可能な拡張に使用されます。カスタマイズ可能なスケーリングは、計算に EVM 以外のものを使用する特殊なアプリケーション、アプリケーション固有のデータ形式に最適化されたデータ圧縮ロールアップ (「データ」と「プルーフ」を個別に結合し、プルーフを単一の SNARK で置き換えるなど) など、さまざまな形式で提供されます。 ）など。
L2 はトラストレス拡張機能 (ロールアップ) に使用され、L3 は弱い信頼拡張機能 (Validium) に使用されます。Validium は、SNARK を使用して計算を検証するシステムですが、データの可用性は信頼できる第三者または委員会に委ねられます。私の意見では、Validium は非常に過小評価されており、特に多くの「エンタープライズ ブロックチェーン」アプリケーションは、実際には、Validium を実行し、チェーンの集中サーバーにハッシュを定期的に送信する証明者によって、最高のサービスを提供する方が適切である可能性があります。Validium はロールアップよりもセキュリティ レベルが低くなりますが、コストははるかに安くなります。
私の見解では、3 つのビジョンはすべて基本的に健全です。特殊なデータ圧縮には独自のプラットフォームが必要であるという考えは、おそらく最も弱い主張です。ユーザーがアプリケーション固有のサブコンプレッサーを使用して自動スケールできる共通のベースレイヤー圧縮スキームを使用して L2 を設計するのは非常に簡単ですが、それを超えて、これらのユースケースはすべて正当です。しかし、それでも大きな疑問が残ります。3 層構造はこれらの目標を達成するための正しい方法なのでしょうか? 認証、プライバシー システム、カスタム環境を L1 だけではなく L2 に固定することにどのような意味があるのでしょうか? この質問に対する答えは非常に複雑であることがわかりました。
L2 のサブセット ツリーでは入金と出金がより安く簡単になりますか?
2 層モデルに対する 3 層モデルの優位性について考えられる議論の 1 つは、3 層モデルではサブエコシステム全体が 1 つのロールアップ内に存在できるため、そのエコシステム内でクロスドメイン操作が非常に容易に実行できるということです。高価なL1フィニッシュを経ずに安く。
しかし、2 つの L2 間、さらには L3 間でも、入出金が非常に安くなることが判明しました。これの鍵となるのは、トークンやその他の資産をルート チェーンで発行する必要がないということです。つまり、Arbitrum で ERC20 トークンを所有し、Optimism でそのラッパーを作成し、L1 トランザクションなしで 2 つの間を行き来することができます。
このようなシステムがどのように機能するかを見てみましょう。スマート コントラクトには、Arbitrum の基本コントラクトと Optimism のカプセル化されたトークン コントラクトの 2 種類があります。Arbitrum から Optimism に転送するには、基礎となるコントラクトにトークンを送信する必要があり、これにより領収書が生成されます。Arbitrum が完了したら、そのレシートのマークル証明を取得して L1 状態にルートし、それを Optimism のラップされたトークン コントラクトに送信すると、それが検証され、ラップされたトークンが発行されます。トークンを元に戻すには、同じことを逆に実行できます。
Arbitrum でのデポジットを証明するために必要なマークル パスは L1 状態を通過しますが、Optimism はデポジットを処理するために L1 状態のルートを読み取るだけで済み、L1 トランザクションは必要ありません。ロールアップ データは最も希少なリソースであるため、このスキームの実際の実装では、スペースを節約するためにマークル証明ではなく SNARK または KZG 証明が直接使用されることに注意してください。
L1 ベースのトークンと比較すると、このスキームには致命的な弱点があります (少なくとも楽観的なまとめに関しては)。入金も不正防止ウィンドウを待つ必要があります。トークンが L1 にルートされている場合、Arbitrum または Optimism から L1 に出金するには 1 週間の遅延が必要ですが、入金は即座に行われます。ただし、この制度では入金・出金ともに1週間の遅れが生じます。とはいえ、理想的なロールアップをベースにした 3 層アーキテクチャの方が優れているかどうかは明らかではありません。不正対策ゲーム上で実行されるシステム内で行われる不正対策ゲームの安全性を確保するには、多くの技術的な複雑さが必要です。
幸いなことに、これらの問題はいずれも ZK ロールアップでは問題になりません。安全上の理由から、ZK ロールアップでは 1 週間の待機期間は必要ありませんが、他の 2 つの理由によりさらに短い期間が必要です (第一世代のテクノロジーでは 12 時間かかる可能性があります)。まず、特により複雑な汎用 ZK-EVM ロールアップでは、並列化できないブロックの計算時間をカバーするのに時間がかかります。第 2 に、経済的な考慮事項により、認証取引に関連する固定費を最小限に抑えるために、認証の提出頻度を低くする必要があります。特殊なハードウェアを含む次世代の ZK-EVM テクノロジーは最初の問題を解決し、より適切に設計されたバッチ検証により 2 番目の問題を解決できます。次に議論したいのは、最適化とバッチ提出証明の問題です。
ロールアップと Validium には、確認時間と固定コストのトレードオフがあります。L3 はこの問題の解決に役立ちますが、他に何ができるでしょうか?
トランザクションごとのロールアップのコストは安く、アプリケーションに応じて、データ量はわずか 16 ～ 60 バイトです。しかし、ロールアップはトランザクションのバッチをチェーンに送信するたびに高い固定コストも支払わなければなりません。オプティミスティック ロールアップはバッチあたり 21,000 L1 ガスを必要とし、ZK ロールアップは 400,000 ガス以上を必要とします (STARKS のみで量子セキュリティを提供したい場合) 、何百万ものガスが必要です）。
もちろん、Rollup は単に 1,000 万 Gas 相当の L2 トランザクションが存在するまで待機してバッチ (トランザクション) 全体を送信することを選択することもできますが、これによりバッチ間隔が非常に長くなり、ユーザーは高セキュリティの確認をより長く待たなければなりません。したがって、バッチ間隔を長くしてコストを最適化するか、バッチ間隔を短くしてコストを大幅に増加させるかのトレードオフが必要です。
具体的な数値を示すために、バッチあたり 600,000 Gas のコストがかかる ZK ロールアップを考えて、トランザクションあたり 368 Gas のコストがかかる完全に最適化された ERC20 転送 (23 バイト) を処理してみましょう。このロールアップは導入の初期から中期にあり、TPS が 5 であると仮定します。トランザクションおよびバッチ間隔ごとのガスを計算できます。
多くのカスタム検証とアプリケーション固有の環境が存在する世界に移行すると、その多くは 5TPS を大幅に下回るでしょう。したがって、時間とコストの間のトレードオフを特定することが非常に重要になり始めます。実際、「L3」パラダイムはこの問題を解決します。ZK Rollup の ZK Rollup は、単純な実装であっても、固定コストは約 8,000 Layer-1 ガス (証明用に 500 バイト) のみです。これにより、上の表は次のように変更されます。
基本的に問題は解決したのでL3で良いでしょうか？多分。ただし、ERC 4337 集計検証にヒントを得て、この問題を解決する別の方法があることに注意してください。
戦略は次のとおりです。現在、すべての ZK Rollup または Validium がプルーフを受け取った場合、それは Snew = STF(Sold,D)であることの証明となります。新しいステート ルートは、トランザクション データの正しい処理の結果であるか、古いステート ルート上のステート インクリメントである必要があります。この新しいスキームでは、ZK Rollup はバッチ検証コントラクトから、ステートメントのバッチの証明を検証したというメッセージを受け入れます。ステートメントのそれぞれの形式は Snew = STF(Sold,D) です 。このようなバッチプルーフは、再帰的 SNARK スキームまたは Halo アグリゲーションを通じて構築できます。
これはオープンなプロトコルになります。どの ZK-Rollup にも参加でき、どのバッチ証明者も互換性のある ZK-Rollup からプルーフを集約し、アグリゲータからトランザクション手数料の補償を受け取ることができます。バッチャー コントラクトは証明を 1 回検証し、そのソルアップの (Sold、Snew、D) トリプルを 含むメッセージを各ロールアップに配信します。トリプルがバッチャー コントラクトから取得されたという事実は、変換が有効であるという証拠として使用されます。 。
適切に最適化されている場合、このシナリオのロールアップあたりのコストは 8000 に近くなる可能性があります。新しく更新された状態書き込みの追加に 5000、新旧のルートに 1280、その他のデータ処理にさらに 1720 がかかります。したがって、同じ節約効果が得られます。Starkware には、実際には SHARP と呼ばれる同様のものがすでにありますが、これは (まだ) パーミッションレスなオープン プロトコルではありません。
このアプローチに対する 1 つの応答は次のようになります。「しかし、これは実際には単なるレイヤ 3 アプローチではないでしょうか?」ベースレイヤー <- ロールアップ <- 検証の代わりに、ベースレイヤー <- バッチメカニズム <- ロールアップまたは検証を使用します。ある哲学的枠組みから見れば、これは真実かもしれません。ただし、重要な違いがあります: 中間層は複雑な完全な EVM システムではなく、簡素化された高度に特殊化されたオブジェクトであるため、安全である可能性が高く、別の特殊なトークンなしで機能する可能性が高くなります。最小限に管理され、時間が経っても変更されない可能性が高くなります。
結論: 「レイヤー」とは一体何ですか?
同一のスケーリング スキームを積み重ねた 3 層スケーリング アーキテクチャは、通常、うまく機能しません。ロールアップの上にロールアップを重ねた形式 (ロールアップの 2 つの層が同じテクノロジーを使用している) も満足のいくものではありません。ただし、L2 と L3 が異なる目的を果たす 3 層アーキテクチャは機能する可能性があります。たとえそれが長期的に物事を行うための最善の方法ではないとしても、ロールアップの上に Validium を追加することは意味があります。
しかし、どのアーキテクチャが意味をなすのかを詳細に検討し始めると、「レイヤー」とは何で、何がそうでないのかという哲学的な疑問が生じます。ベース レイヤー <- バッチ メカニズム <- ロールアップまたは検証と、ベース レイヤー <- ロールアップ <- ロールアップまたは検証は同じ仕事をしますが、その仕組みの点では、証明集約レイヤーはロールアップよりも ERC-4337 に似ています。通常、ERC-4337 を「レイヤー 2」とは呼びません。同様に、Tornado Cash を「レイヤー 2」とは呼びません。したがって、一貫性を保ちたい場合は、L2 の上に位置するプライバシー重視のサブシステムを L3 とは呼びません。 「レイヤー」については、未解決の意味論的な議論があります。
この点に関しては、多くの考えられる学派があります。私の個人的な好みは、「レイヤー 2」という用語を次の特性を持つものに限定することです。
1. その目的はスケーラビリティを向上させることです
2. 「ブロックチェーン内のブロックチェーン」モデルに従っています。独自のトランザクション処理メカニズムと独自の内部状態を持っています。
3. イーサリアムチェーンのセキュリティをすべて継承します
したがって、理想的なロールアップと ZK ロールアップは L2 ですが、検証、証明集約スキーム、ERC 4337、オンチェーン プライバシー システム、および Solidity は別の問題です。それらの一部を L3 と呼ぶのは理にかなっているかもしれませんが、おそらくすべてではありません。いずれにせよ、定義を確定するには時期尚早のようであり、マルチアグリゲーション エコシステムのアーキテクチャは固まったわけではなく、ほとんどの議論が時間がかかっています。理論上のみの場所です。
つまり、言語的な議論は、どの構造が実際に最も意味があるのかという技術的な問題ほど重要ではありません。明らかに、プライバシーなどの非スケーリング ニーズに対応する特定の「レイヤー」には重要な役割があり、証明集約の重要な機能は何らかの方法で、できればオープン プロトコルを通じて満たされる必要があります。しかし同時に、ユーザー向け環境と L1 をリンクする中間層をできるだけシンプルにする技術的な理由も十分にあり、多くの場合、EVM ロールアップの「接着層」であることは正しいアプローチではない可能性があります。L2 拡張エコシステムが成熟するにつれて、この記事で説明されているより複雑な (そしてより単純な) 構造がより大きな役割を果たし始めるのではないかと思います。
元のリンク:
https://vitalik.ca/general/2022/09/17/layer_3.html
**この記事は原著者の見解のみを表すものであり、投資に関する意見や推奨を構成するものではありません。
-終わり-
[記事掲載の目的は、より価値のある情報を広めることであり、記事の著作権は原著者に帰属し、その内容や意見はユニタイムズの立場を代表するものではありません。この WeChat プラットフォームに表示される画像はすべてインターネットから収集されたものであり、著作権は著作権所有者に属します。著作権所有者が、自分の作品が誰でも閲覧するのに適していないか、無料で使用すべきではないと考える場合は、WeChat の制服 2018 を追加してくださいご連絡いただければ、このプラットフォームはすぐに修正します。】
お越しの際は「いいね！」をクリックしてください。
