Vitalik:どんなLayer 3が意味を持つのか

セキュリティを実現し、拡張性を高めるためにL 2プロトコルをL 1にアンカーすることができれば、L 3プロトコルをL 2にアンカーすることでセキュリティを実現し、拡張性を高めることができますか?

layer 2拡張議論でしばしば再浮上する話題の1つが「layer 3 s」の概念である。安全性を実現し、拡張性を高めることを主な目的としてlayer 2プロトコルをlayer 1にアンカーすることができれば、安全性を実現し、それ以上に拡張性を高めるために「layer 2にアンカーする」layer 3プロトコルを構築することで規模を拡大することはもちろんできますか?

このアイデアの簡単なバージョンは、2次成長を実現するためのシナリオがあれば、そのシナリオを自分の上に積み上げて指数的な成長を得ることができますか?似たような考えは私を含む  ;2015年の拡張性論文および  ;Plasma論文で取り上げられているmulti-layer拡張など。残念なことに、このような簡単なlayer 3 s概念は、実行可能なスキームを形成するのは容易ではありません。データの可用性の制限、緊急抽出されたlayer 1の帯域幅への依存性には他にも問題が多いかもしれないため、設計には常に積み重ねることができないものがあり、拡張性を向上させることができるのは1回だけです。

layer 3 sをめぐる比較的新しいアイデア、  ;Starkwareが提案したフレームワークは、同じものを自分の上に積み重ねるだけでなく、layer 2とlayer 3に異なる用途を割り当てています。もしそれが正しい方法で完成すれば、この方法の潜在的な形は通じるかもしれない。この記事では、3層構造の中で意味がある可能性があるものとない可能性があるものを詳しく紹介します。

なぜあなたはstacking rollupsを通じてrollupsの上で維持することができません容量拡張?

Rollups(ここでの長い記事を参照)は、ブロックチェーンを実行する2つの主要な拡張ボトルネック(計算とデータ)を解決するための異なるテクノロジーを組み合わせた拡張テクノロジーです。計算は「不正な証明」または  ;SNARKなどの方法では、各ブロックを処理し検証するためにごく少数の参加者に依存し、証明プロセスが正しく完了しているかどうかを確認するために、他の人が少量の計算のみを実行することを要求することが解決されました。これらのスキーム、特にSNARKは、ほとんど無限に拡張できます。さらに多くの計算を単一の証明に削減するために、「多くのSNARKのSNARK」を作成し続けることができます。

データが違います。Rollupsは一連の圧縮テクニックを使用して、取引に必要なチェーンに格納されるデータ量を削減します。簡単な通貨振替は約100バイトから約16バイトに減少し、EVM互換チェーンにおけるERC 20振替は  ;約180バイトから約  ;プライバシー保護ZK−SNARKトランザクションは約600バイトから約80バイトに圧縮できる23バイト。すべての場合に約8倍圧縮されています。しかし、rollupは、ユーザーがアクセスして検証できることを保証するメディアでデータをチェーン上で利用できるようにする必要があります。これにより、ユーザーはrollupの状態を独立して計算し、既存のアテスターがオフラインになったときにアテスターとして参加することができます。データは1回圧縮することはできますが、再圧縮することはできません--できれば、通常、2つ目の圧縮器の論理を1つ目の圧縮器に入れ、1回圧縮することで同じ利点を得る方法があります。そのため、「Rollups以上のRollups」は実際には拡張性の面で大きな利益を提供することはできませんが、下に見られるように、このモデルは他の目的にも使用できます。

では  ;layer 3の「sane」バージョンは何ですか。

では、Starkwareがlayer 3 sに関するスレッドで提唱していることを見てみましょう。Starkwareは非常に聡明な暗号学者で構成されており、彼らは理性的であるため、もし彼らがlayer 3 sを提唱すれば、彼らのバージョンは「rollupsがデータを8倍圧縮すれば、明らかにrollupsより上のrollupsがデータを64倍圧縮する」よりずっと複雑になるだろう。

これはStarkwareの投稿の図です:

image

引用句:

上図はこのような生態系の一例を示している。そのL 3は、

1、Validiumデータの可用性を持つStarkNet(例えば、価格設定に極めて敏感なアプリケーションによく使われる)。

2、より良いアプリケーション性能を得るためにカスタマイズされたアプリケーション固有のStarkNetシステムは、例えば、指定されたストレージ構造またはデータ可用性圧縮を採用することによって実現される。

3、StarkExシステム(例えば、dYdX、Sorare、Immutable、DeversiFiにサービスするシステム)はValidiumまたはRollupデータ可用性を持ち、StarkNetに長い試練を経た拡張性の利点をすぐにもたらす。

4、プライバシーStarkNetインスタンス(この例ではL 4としても)は、パブリックStarkNetに含めるのではなく、プライバシー保護タイプのトランザクションの存在を許可します。

記事を「L 3 s」の3つのビジョンに圧縮することができます。

  • L 2は拡張用であり、L 3はプライバシーなどの機能をカスタマイズするために使用される。このビジョンでは、「拡張性の二乗的成長」を提供しようとする試みはありません。代わりに、スタック内にアプリケーションの拡張を支援するレイヤーがあり、別のユースケースのカスタム機能要件を満たすために別のレイヤーがあります。

  • L 2は汎用拡張用であり、L 3はカスタマイズ可能な拡張用である。カスタマイズ可能な拡張は、EVM以外のものを使用して計算される専用アプリケーション、データ圧縮特定アプリケーションのデータフォーマットに最適化されたrollups(ブロックごとに「データ」と「証明」を分離し、証明を単一SNARKで置き換えることを含む)など、異なる形式である可能性があります。

  • L 2は信頼性のない拡張(rollups)に、L 3は信頼性の低い拡張(validiums)に使用されます。 Validium は、SNARKを使用して計算を検証するシステムですが、信頼されているサードパーティまたは委員会にデータの可用性を残します。私から見れば、Validiumは非常に過小評価されています。特に、多くの「エンタープライズブロックチェーン」アプリケーションは実際にはvalidiumを実行するアテスターによってサービスを提供し、定期的にハッシュをチェーンの集中型サーバに提出して最適なサービスを提供することが望ましいかもしれません。Validiumのセキュリティレベルはrollupsより低いが、はるかに安くすることができる。

私から見れば、この3つのビジョンは基本的に合理的です。専用データ圧縮には独自のプラットフォームが必要であるという考えは、最も弱い主張かもしれません。一般的な基礎層圧縮スキームを持つL 2を設計するのは非常に容易で、ユーザーはアプリケーション固有のサブ圧縮器を使用して自動的に拡張することができますが、それ以外の使用例はすべて合理的です。しかし、これはまだ大きな問題を残しています:3層構造はこれらの目標を実現する正しい方法ですか?検証、プライバシーシステム、カスタマイズされた環境をL 1だけではなくL 2にアンカーすることに何の意味がありますか。事実は、この問題の答えがかなり複雑であることを証明している。

image

L 2のサブセットツリーでは、預金や引き出しがより安く、容易になりますか。

3層モデルが2層モデルより優れている可能性のある論点は、3層モデルは、高価なL 1ではなく、生態系内のドメイン横断動作が非常に安価に発生することを可能にする、サブ生態系全体が単一のrollupに存在することを可能にすることである。

しかし、2つのL 2 s  ;L 3 sの間でも、預金と引き出しが非常に安くなります。この鍵は、トークンやその他の資産がルートチェーンで発行される必要がないことです。つまり、Arbitrum上にERC 20トークンを持ち、Optimism上にラッパーを作成し、L 1取引を必要とせずに2つの間を往復移動することができます!

このようなシステムがどのように機能しているのかを見てみましょう。Arbitrum上の基本契約とOptimism上のパッケージトークン契約の2つのスマート契約があります。ArbitrumからOptimismに転送するには、受領書を生成する基本契約にトークンを送信する必要があります。Arbitrumが最終的に決定すると、領収書のMerkle証明書を取得してL 1状態に植え付け、Optimism上の包装トークン契約に送信し、それを検証して包装トークンを発行することができます。トークンを戻すには、同じ操作を逆に実行できます。

image

Arbitrum上の預金を証明するために必要なMerkleパスはL 1状態を通過する必要がありますが、OptimismはL 1状態ルートを読み込んで預金を処理するだけで、L 1取引は必要ありません。rollupsデータは最も希少なリソースであるため、このシナリオの実装では、Merkle証明を直接使用するのではなく、SNARKまたはKZG証明を使用してスペースを節約することに注意してください。

L 1ベースのトークンに比べて、このシナリオには致命的な弱点があります(少なくともoptimistic  ;  ; rullupsではそうです):預金には詐欺防止ウィンドウを待つ必要があります。トークンがL 1に根付いている場合は、ArbitrumまたはOptimismからL 1に戻すには1週間の遅延が必要ですが、預金は即時です。しかし、この案では、預金も引き出しも1週間の遅延が必要だ。つまり、理想的なrollups上の3層構造がより良いかどうかは不明です。詐欺防止ゲーム上で実行されているシステム内部で発生する詐欺防止ゲームが安全であり、多くの技術的複雑性が存在することを確認する必要があります。

幸いなことに、これらの問題はZK rollupsの問題にはなりません。セキュリティ上の理由から、ZK rollupsは最大1週間の待機ウィンドウを必要としませんが、他の2つの理由で、より短いウィンドウを必要とします(初代テクノロジーは12時間かかる場合があります)。まず、特により複雑な汎用ZK-EVM  ;rollupsはブロックの非並列計算時間をカバーするためにより長い時間を必要とする。次に、経済的な観点から、証明取引に関連する固定コストを最小化するために証明書を提出する必要は少ない。専用ハードウェアを含む次世代  ;ZK-EVM技術は第1の問題を解決するが、アーキテクチャのより良い一括検証は第2の問題を解決することができる。次に検討するのは、最適化と一括提出証明の問題です。

Rollupsとvalidiumsには、確認時間と固定コストのトレードオフがあります。L 3はこの問題を解決するのに役立つでも何があってもいいそれをするには

各トランザクションのrollupsコストは安い:アプリケーションに応じて16~60バイトのデータにすぎません。しかし、rollupsはチェーンに一括取引を送信するたびに高い固定コストを支払う必要があります:optimistic  ;rollupsは1ロットあたり21000 L 1 gas、ZK rollupsは400000 gasを超える(STARKSだけで量子安全なものを提供したい場合は数百万gasが必要)。

もちろん、rollupは簡単に1000万gasの価値があるL 2取引まで待って一括(取引)を提出することを選択することができますが、これは非常に長いロット間隔をもたらし、ユーザーにより長い時間を待たせて高い安全性確認を得ることができます。そのため、長いロット間隔と最適なコスト、または短いロット間隔と大幅に増加したコストのトレードオフが必要です。

具体的な数字を与えるために、各バッチコストが600000 gas ZK rollupであり、トランザクションコストが368 gasである完全に最適化されたERC 20伝送(23バイト)を処理することを考えてみましょう。このrollupsが採用の初期から中期であり、TPSは5であると仮定します。各取引とロット間隔のgasを計算できます。

カスタマイズされた検証と特定のアプリケーション環境が多数存在する世界に入ると、1秒あたりの処理量の多くは5 TPSをはるかに下回ることになります。そのため、時間とコストのトレードオフを確認することが重要になります。実は、「L 3」のパラダイムは確かにこの問題を解決しました!ZK rollupにおけるZK rollupは、単純な実装でも、約8000 layer-1 gasの固定コスト(証明のために500バイト)しかありません。これにより、上の表が次のように変更されます。

image

問題はほぼ解決したので、L 3 s  ;いいのではないでしょうか。そうかもしれない。しかし、この問題を解決するためにもう一つの方法がERC を受けていることに注意しなければならない。4337統合検証のヒント。

戦略は次のとおりです。今日、各ZK rollupまたはvalidiumが証明を受信した場合、証明  ;Snew = STF(Sold,D):新しいstate rootは、古い状態ルートの上でトランザクションデータまたは状態増分を正しく処理した結果でなければなりません。この新しいスキームでは、ZK rollupは、各文の形式が  ;Snew = STF(Sold,D)。このバッチ証明は、再帰SNARKスキームまたは  ;Halo 集約して構築します。

image

これはオープンなプロトコルになります。ZK-rollupはすべて参加でき、すべてのバッチアテスターは互換性のあるZK-rollupアグリゲーションアテステーションからアグリゲータから取引費用の補償を受けることができます。バッチハンドラ契約は、証明書を検証し、各rollupsにメッセージを渡し、sollupsの(Sold, SnewD) triple. Tripleがバッチハンドラ契約から来ていることは、変換が有効であることを証明する証拠となります。

最適化されている場合、このシナリオの1回の要約コストは8000近くになる可能性があります。5000は新しい更新のステータス書込みを追加するために使用され、1280は古いルートと新しいルートのために使用され、追加の1720はその他のデータ処理のために使用されます。そのため、同じように節約してくれます。スタークウェアには実際に似たようなものがあり、  ;SHARP、ライセンス不要のオープンプロトコルではありませんが。

この方法に対する応答の1つは、しかしこれは実際には別のレイヤ3スキームではないでしょうか。base layer< ;-batch mechanism <- rollupまたは  ;base layer< ;-の代わりにvalidiumrollup <- validium。ある哲学的アーキテクチャの観点から見ると、これは本当かもしれない。しかし、重要な違いがあります:中間層は複雑な完全なEVMシステムではなく、簡略化された高度に専門化されたオブジェクトであるため、それはより安全である可能性が高く、それはさらに別の専門的なトークンがない場合に構築される可能性が高く、それは最も低い限度の管理される可能性があり、時間の経過とともに変化することはありません。

結論:一体何が「Layer”?

自身の上に同じスケールスキームを積み重ねて構成された3層スケールアーキテクチャは、通常はうまく動作しません。rollupsの上にあるrollups(うち2層のrollupsは同じ技術を使用している)の形式もあまり意味がありません。しかし、L 2とL 3の異なる目的を持つ3層アーキテクチャを実行することができます。rollups以上のValidiumsは確かに意味があり、長期的に最適なやり方であるとは確定できなくても。

しかし、どのアーキテクチャの意味ある詳細を深く理解し始めると、「レイヤー」とは何か、そうではないかという哲学的な問題に入ります。base layer <- batch mechanism <- rollupまたはvalidiumとbase layer< ;-rollup <- rollup or validiumは同じ仕事をしていますが、その働き方では、重合層がrollupsではなくERC-4337のように見えることが証明されています。通常、ERC-4337を「layer  ; 2」とは呼びません。同様に、Tornado Cashを「Layer  ; 2」、  ;したがって、もし私たちが一致しているならば、私たちはL 2の上に位置するプライバシー中心のサブシステムをL 3と呼ぶことはありません。そのため、何が最初に「Layer」と呼ばれるべきかについては、未解決の意味論争が存在します。

この方面では多くの可能性のある思想流派がある。個人的な好みは、用語「Layer  ; 2」を次の属性を持つものに制限することです。

1、彼らの目的は拡張性を高めることです

2、彼らは「ブロックチェーンにおけるブロックチェーン」モデルに従う:彼らは自分の取引処理メカニズムと自分の内部状態を持っている

3、彼らはイーサ坊チェーンのすべての安全性を継承している

したがって、理想的なrollupsとZK rollupsはL 2であるが、統合スキーム、ERC 4337、チェーン上プライバシーシステム、Solidityを検証、証明することは別のことである。これらのいくつかをL 3と呼ぶのは意味があるかもしれないが、すべてではないかもしれない。いずれにしても、定義を確定するのはまだ早いようだが、生態系のアーキテクチャを多く集約するのは一定ではなく、ほとんどの議論は理論的にしか行われていない。

つまり、言語上の議論はどの構造よりも実際に最も意義のある技術問題が重要である。プライバシーなどの非拡張ニーズにサービスを提供する一部の「layers」は重要な役割を果たすことができ、統合を証明する重要な機能を何らかの方法で充填する必要があることは明らかで、オープンプロトコルで充填することが望ましい。しかし同時に、ユーザー環境とL 1の中間層に向けてリンクをできるだけ簡単にするための十分な技術的理由があります。多くの場合、EVMとしてまとめられた「接着層」は正しい方法ではない可能性がある。L 2拡張生態系が成熟するにつれて、本文で説明したより複雑な(およびより簡単な)構造がより大きな役割を果たし始めると思います。

ソース:チェーンキャッチャー

執筆:Vitalik、『What kind of layer 3 s make sense?』

董一鳴、チェーンキャッチャー

 特にGeorgios Konstantopoulos、Karl Floersch、Starkwareチームからのフィードバックとレビューに感謝します。