Vitalik：どのようなLayer3が意味を持つのか？
もし私たちがL1に安全性を確保するためにL2プロトコルを構築し、その上にスケーラビリティを追加できるなら、L2に安全性を確保するためにL3プロトコルを構築し、その上にさらにスケーラビリティを追加することができるでしょうか？執筆：Vitalik，《どのようなレイヤー3が意味を持つのか？》
編纂：董一鸣、チェーンキャッチャー
Georgios Konstantopoulos、Karl Floersch、Starkwareチームのフィードバックとレビューに特別な感謝を。
レイヤー2のスケーリングに関する議論でしばしば浮上するトピックの一つは「レイヤー3」の概念です。もし私たちがレイヤー1に安全性を確保し、スケーラビリティを向上させることを主な目的としたレイヤー2プロトコルを構築できるなら、もちろん「レイヤー2に安全性を確保し、その上にさらにスケーラビリティを追加する」レイヤー3プロトコルを構築することで、その規模を拡大することもできるでしょうか？
このアイデアの簡単なバージョンは次のとおりです：もしあなたが二次的な成長を実現できるスキームを持っているなら、そのスキームを自分自身の上に積み重ねて指数的な成長を得ることができるでしょうか？似たようなアイデアには、私の2015年のスケーラビリティ論文や、Plasma論文で言及されているマルチレイヤーの拡張などがあります。不幸なことに、これほど単純なレイヤー3の概念は、実行可能なスキームを形成するのがそれほど簡単ではありません。データの可用性の制限、緊急抽出に対するレイヤー1の帯域幅への依存、その他多くの問題により、設計には常に積み重ねられないものがあり、スケーラビリティの向上は一度きりのものとなることが多いのです。
レイヤー3に関する最近のアイデア、例えばStarkwareが提案したフレームワークは、より複雑です：それらは単に同じものを自分自身の上に積み重ねるだけでなく、レイヤー2とレイヤー3に異なる用途を割り当てています。正しい方法で実行されれば、このアプローチの潜在的な形は機能する可能性があります。この記事では、三層アーキテクチャの中で何が意味を持ち、何が意味を持たないかを詳しく説明します。
なぜロールアップを積み重ねることで拡張性を維持できないのか？
ロールアップ（私のこちらの長い記事を参照してください）は、ブロックチェーンを運営するための二つの主要なスケーリングボトルネック、計算とデータを解決するために異なる技術を組み合わせたスケーリング技術です。計算は「詐欺証明」やSNARKなどの方法で解決されており、これらはごく少数の参加者に各ブロックを処理し検証させ、他の人には証明プロセスが正しく完了したかを確認するために少量の計算を実行させることを要求します。これらのスキーム、特にSNARKは、ほぼ無制限にスケール可能です；私たちは「多くのSNARKのSNARK」を作り続けて、より多くの計算を単一の証明に縮小することができます。
データは異なります。ロールアップは一連の圧縮技術を使用して、取引がチェーン上に保存する必要があるデータ量を減少させます：単純な通貨の送金は約100バイトから約16バイトに、EVM互換チェーンのERC20送金は約180バイトから約23バイトに、プライバシーを保護するZK-SNARK取引は約600バイトから約80バイトに圧縮されます。すべてのケースで約8倍の圧縮があります。しかし、ロールアップはユーザーがロールアップの状態を独立して計算し、既存の証明者がオフラインのときに証明者として参加できるように、データをチェーン上で可用にする必要があります。データは一度圧縮できますが、再度圧縮することはできません - - - もしできるなら、通常は第二の圧縮器のロジックを第一の圧縮器に組み込む方法があり、一度の圧縮で同じ利点を得ることができます。したがって、「ロールアップの上にロールアップ」というのは、実際にはスケーラビリティの面で大きな利益を提供することはできませんが、以下で見るように、このパターンは他の目的に使用できます。
では、レイヤー3の「健全な」バージョンとは何でしょうか？
さて、Starkwareが彼らのレイヤー3に関する投稿で提唱していることを見てみましょう。Starkwareは非常に賢い暗号学者たちによって設立されており、理にかなった考えを持っていますので、彼らが提唱するレイヤー3は、「ロールアップがデータを8倍圧縮するなら、明らかにロールアップの上のロールアップはデータを64倍圧縮するだろう」というものよりもはるかに複雑です。
これはStarkwareの投稿にある図です：
いくつかの引用：
上の図はこのエコシステムの一例を描いています。そのL3には以下が含まれます：
Validiumデータ可用性を持つStarkNet、例えば、価格に非常に敏感なアプリケーションでよく使用されます。
より良いアプリケーションパフォーマンスを得るためにカスタマイズされたアプリケーション特有のStarkNetシステム、例えば、指定されたストレージ構造やデータ可用性圧縮を採用することによって実現されます。
StarkExシステム（例えばdYdX、Sorare、Immutable、DeversiFiにサービスを提供するシステム）は、ValidiumまたはRollupデータ可用性を持ち、StarkNetに長年の実績のあるスケーラビリティの利点をもたらします。
プライバシー保護型のStarkNetインスタンス（この例ではL4としても機能）により、プライバシー保護型の取引が存在でき、公共のStarkNetに含まれません。
私たちはこの記事を「L3の三つのビジョン」に圧縮できます：
L2はスケーリングに使用され、L3はプライバシーなどのカスタマイズ機能に使用されます。このビジョンでは、「スケーラビリティの二次的成長」を提供しようとはしていません；むしろ、スタック内にはアプリケーションの拡張を助ける層があり、異なるユースケースのカスタマイズ機能のニーズを満たすための独立した層があります。
L2は汎用スケーリングに使用され、L3はカスタマイズ可能なスケーリングに使用されます。カスタマイズ可能なスケーリングは異なる形を取る可能性があります：EVM以外のものを使用して計算を行う専用アプリケーション、特定のアプリケーションのデータ形式に最適化されたデータ圧縮を行うロールアップ（各ブロックで「データ」と「証明」を分け、単一のSNARKで証明を置き換えるなど）などです。
L2は信頼のない拡張（ロールアップ）に使用され、L3は弱い信頼の拡張（validiums）に使用されます。Validiumは、計算を検証するためにSNARKを使用するシステムですが、データ可用性は信頼された第三者または委員会に委ねられます。私の見解では、Validiumは過小評価されています：特に、多くの「企業ブロックチェーン」アプリケーションは、実際にはValidiumを運営する証明者によって提供され、定期的にハッシュをチェーンの集中サーバーに提出することで最適なサービスを提供するのが最良かもしれません。Validiumのセキュリティレベルはロールアップよりも低いですが、はるかに安価です。
私の見解では、これらの三つのビジョンは基本的に合理的です。専用データ圧縮が自分自身のプラットフォームを必要とするという考えは最も弱い主張かもしれません - - - 汎用の基盤層圧縮スキームを持つL2を設計するのは非常に簡単で、ユーザーはアプリケーション特有のサブ圧縮器を使用して自動的に拡張できますが、それ以外はこれらのユースケースは合理的です。しかし、依然として大きな問題が残ります：三層構造はこれらの目標を達成するための正しい方法でしょうか？検証、プライバシーシステム、カスタマイズ環境をL2に固定することは、単にL1に固定することと何の意味があるのでしょうか？この質問の答えはかなり複雑であることが判明しました。
L2のサブセットツリーにおいて、入金と出金はより安価で簡単になるのか？
三層モデルが二層モデルよりも優れている可能性のある議論の一つは、三層モデルが単一のロールアップ内に全体のサブエコシステムを存在させることを許可し、そのエコシステム内のクロスドメイン操作が非常に安価に行われることができるという点です。高価なL1を通過する必要がありません。
しかし、実際には、二つのL2やL3の間でも、入金と出金は非常に安価である可能性があります。その鍵は、トークンやその他の資産がルートチェーンで発行される必要がないことです。つまり、あなたはArbitrum上にERC20トークンを持ち、Optimism上にそのラッパーを作成し、L1取引なしで両者の間を往復することができます！
このようなシステムがどのように機能するか見てみましょう。二つのスマートコントラクトがあります：Arbitrum上の基礎コントラクトとOptimism上のラッピングトークンコントラクトです。ArbitrumからOptimismに移動するには、トークンを基礎コントラクトに送信する必要があり、これがレシートを生成します。Arbitrumが最終確定したら、そのレシートのMerkle証明を取得し、L1状態に根付かせ、次にOptimism上のラッピングトークンコントラクトに送信します。このコントラクトはそれを検証し、あなたにラッピングトークンを発行します。トークンを戻すには、同じ操作を逆に実行できます。
Arbitrum上の入金を証明するために必要なMerkleパスはL1状態を通過する必要がありますが、Optimismは入金を処理するためにL1状態のルートを読み取るだけで済みます - - - L1取引は必要ありません。ロールアップデータが最も希少なリソースであるため、このスキームの実際の実装は、スペースを節約するためにMerkle証明ではなくSNARKまたはKZG証明を使用します。
L1ベースのトークンと比較して、このスキームには致命的な弱点があります（少なくとも楽観的ロールアップにおいて）：入金は詐欺防止ウィンドウを待つ必要があります。トークンがL1に根付いている場合、ArbitrumまたはOptimismからL1に撤回するには1週間の遅延が必要ですが、入金は即時です。しかし、このスキームでは、入金と出金の両方に1週間の遅延が必要です。つまり、理想的なロールアップ上の三層アーキテクチャがより良いかどうかは不明です：詐欺防止ゲームが実行されているシステム内部で発生する詐欺防止ゲームが安全であることを保証するためには、多くの技術的複雑性が存在します。
幸いなことに、これらの問題はZKロールアップには影響しません。セキュリティ上の理由から、ZKロールアップは1週間の待機ウィンドウを必要としませんが、他の2つの理由から、より短いウィンドウが必要です（初代技術では12時間が必要かもしれません）。まず、特により複雑な汎用ZK-EVMロールアップは、ブロックの非並列計算時間をカバーするのにより長い時間が必要です。次に、経済的な理由から、証明取引に関連する固定コストを最小化するために、証明を提出する必要が少なくなります。専用ハードウェアを含む次世代ZK-EVM技術は、最初の問題を解決し、より良いアーキテクチャのバッチ検証が第二の問題を解決します。次に議論するのは、最適化とバッチ提出証明の問題です。
ロールアップとvalidiumsには確認時間と固定コストのトレードオフがあります。L3はこの問題を解決するのに役立ちますが、他に何ができるのでしょうか？
各取引のロールアップコストは非常に安価です：アプリケーションに応じて16-60バイトのデータです。しかし、ロールアップは毎回取引のバッチをチェーンに提出する際に高額な固定コストを支払わなければなりません：楽観的ロールアップは毎バッチ21000 L1ガスを必要とし、ZKロールアップは400,000ガスを超えます（量子安全なものをSTARKSで提供したい場合は数百万ガスが必要です）。
もちろん、ロールアップは単にL2取引の価値が1000万ガスになるまで待って全バッチ（取引）を提出することを選択できますが、これにより非常に長いバッチ間隔が生じ、ユーザーは高いセキュリティ確認を得るためにより長く待たなければなりません。したがって、彼らはトレードオフを必要とします：長いバッチ間隔と最適コスト、または短いバッチ間隔と大幅に増加したコスト。
具体的な数字を考えるために、バッチコストが600,000ガスのZKロールアップと、各取引コストが368ガスの完全に最適化されたERC20転送（23バイト）を考えてみましょう。このロールアップが採用の初期から中期にあり、TPSが5だと仮定します。各取引とバッチ間隔のガスを計算できます：
もし私たちが多くのカスタマイズされた検証と特定のアプリケーション環境を持つ世界に入るなら、その中の多くは1秒あたり5TPSを大きく下回るでしょう。したがって、確認時間とコストのトレードオフは非常に重要になります。実際、「L3」パラダイムはこの問題を解決します！ZKロールアップ内のZKロールアップは、たとえ単純な実装であっても、約8,000レイヤー1ガスの固定コスト（証明用に500バイト）しかありません。これにより、上の表が次のように変更されます：
問題は基本的に解決されましたが、L3は素晴らしいのでしょうか？おそらくそうです。しかし、この問題を解決する別の方法がERC 4337の集約検証からインスパイアを受けています。
戦略は次のとおりです。今日、各ZKロールアップまたはvalidiumが証明を受け取ると、証明S ~new~ = STF(S ~old~ ,D)：新しい状態ルートは、古い状態ルートの上で正しく取引データまたは状態の増分を処理した結果でなければなりません。この新しいスキームでは、ZKロールアップはバッチ検証者コントラクトからのメッセージを受け入れます。このメッセージは、バッチの文の証明を検証したことを示し、各文の形式はS ~new~ = STF(S ~old~ ,D)です。このバッチ証明は、再帰的SNARKスキームまたはHaloの集約によって構築できます。
これはオープンプロトコルになります：任意のZKロールアップが参加でき、任意のバッチ検証者が任意の互換性のあるZKロールアップから証明を集約し、集約者から取引手数料の補償を受けることができます。バッチ処理コントラクトは一度証明を検証し、その後、各ロールアップにメッセージを送信し、そのロールアップの(S ~old~ , S ~new~ , D) トリプルを含めます。バッチ処理コントラクトからのトリプルの事実は、変換が有効であることを証明する証拠として機能します。
適切に最適化されれば、このスキームでの各集約のコストは約8000に近づく可能性があり、そのうち5000は新しい更新の状態の書き込みに、1280は古いルートと新しいルートに、さらに1720は雑多なデータ処理に使用されます。したがって、私たちには同様の節約が得られます。Starkwareは実際にSHARPと呼ばれる類似のものを持っていますが、（まだ）許可のないオープンプロトコルではありません。
このアプローチに対する一つの反応は、しかしこれは実際には別の第3層スキームではないか？ということです。私たちはbase layer \<- batch mechanism \<- rollupまたはvalidiumを持ち、base layer \<- rollup \<- validiumに置き換えます。ある種の哲学的なアーキテクチャの観点からは、これは真実かもしれません。しかし、重要な違いがあります：中間層は複雑な完全なEVMシステムではなく、簡素化され高度に専門化されたオブジェクトであるため、より安全である可能性が高く、別の専用トークンなしで構築される可能性が高く、最低限のガバナンスであり、時間とともに変わることはありません。
結論：結局「レイヤー」とは何か？
自分自身の上に同じスケーリングスキームを積み重ねた三層スケーリングアーキテクチャは、通常うまく機能しません。ロールアップの上のロールアップ（ここで二層のロールアップは同じ技術を使用する）は期待外れです。しかし、L2とL3が異なる目的を持つ三層アーキテクチャは機能する可能性があります。ロールアップの上のValidiumは確かに意味がありますが、それが長期的に最良の方法であるかどうかは不明です。
しかし、どのアーキテクチャが意味を持つかの詳細に深入りし始めると、私たちは哲学的な問題に直面します：何が「レイヤー」であり、何がそうでないのか？base layer \<- batch mechanism \<- rollupまたはvalidiumとbase layer \<- rollup \<- rollupまたはvalidiumは同じ作業を行っていますが、その働き方に関しては、証明集約層はロールアップではなくERC-4337に近いように見えます。通常、私たちはERC-4337を「レイヤー2」とは呼びません。同様に、私たちはTornado Cashを「レイヤー2」とは呼びません。したがって、もし私たちが一貫性を保つなら、L2の上にあるプライバシー中心のサブシステムをL3とは呼ばないでしょう。したがって、何が最初に「レイヤー」と呼ばれるべきかについて、未解決の意味論的議論があります。
この点に関しては、多くの可能な思想流派があります。私個人の好みは、「レイヤー2」という用語を次の属性を持つものに制限することです：
彼らの目的はスケーラビリティを向上させることです。
彼らは「ブロックチェーン内のブロックチェーン」モデルに従います：彼らには独自の取引処理メカニズムと内部状態があります。
彼らはEthereumチェーンの全てのセキュリティを引き継ぎます。
したがって、理想的なロールアップとZKロールアップはL2ですが、検証、証明集約スキーム、ERC 4337、オンチェーンプライバシーシステム、Solidityは別の話です。それらのいくつかをL3と呼ぶことは意味があるかもしれませんが、すべてではないかもしれません；いずれにせよ、今定義を確定するのは早すぎるように思えますし、多くのロールアップエコシステムのアーキテクチャは決して固定されたものではなく、ほとんどの議論は理論的に行われています。
とはいえ、言語的な議論よりも、どの構造が実際に最も意味があるかという技術的な問題が重要です。明らかに、プライバシーなどの非スケーラビリティのニーズに応える特定の「レイヤー」は重要な役割を果たすことができ、証明集約の重要な機能を何らかの方法で埋める必要があります。できればオープンプロトコルを通じて埋めるべきです。しかし同時に、ユーザー環境とL1に向けたリンクをできるだけシンプルに保つための十分な技術的理由があります；多くのケースでは、EVMロールアップの「接着層」として機能することは正しい方法ではないかもしれません。私は、L2スケーリングエコシステムが成熟するにつれて、この記事で説明したより複雑（およびシンプル）な構造がより大きな役割を果たし始めると推測しています。
