オリジナル｜日常
著者｜吾妻
レイヤ 3 を巡る論争はここ 2 日間で激化しています。
一方で、Degen Chain などの代表的なレイヤー 3 プロジェクトの関連トークンは、過去数日間で驚くべき増加を経験しました - DEGEN 自体は、Aavegotchi がベースベースのレイヤーへの変換を選択した後、毎週最大 143% 増加しました3、GHSTも歴史的高値を大幅に更新しました。
しかしその一方で、レイヤー 3 に対するコミュニティの疑念はますます大きくなり、今日ヴィタリック氏が個人的に名乗り出て反対の意を表明しました。「レイヤー 3 は魔法のようにスループットを向上させるわけではありません。」
昨日はエイプリルフールだったので、多くのプロジェクトがこれに焦点を当てて、レイヤー 4 とレイヤー 5 についてやや冗談めいたジョークを飛ばしていました。このジョークは一部のメディアでもニュースとして扱われた。
レイヤ 3 の実現可能性の仮定
では、なぜレイヤー 3 がこれほど疑問視されているのでしょうか? 「ロールアップ プラス ロールアップ」のマトリョーシカ ロジックが政治的に十分に正しくないのはなぜですか?コミュニティでの議論を見る限り、レイヤー3をめぐる疑問の焦点は主に「レイヤー3に本当に拡張意義があるのか」という点にあるようだ。
古典的な定義からすると、レイヤ 2 は、決済をイーサリアムのメイン ネットワークに依存し、スケーラブルなネットワークとして定義されることが多く、同様に、レイヤ 3 は、決済をレイヤ 2 に依存し、よりスケーラブルなネットワークとして定義されます。
レイヤ 2 環境では、いわゆる「決済にイーサリアムに依存する」ことは、技術的には次のように実装されます: 大量のレイヤ 2 トランザクション データをパッケージ化して圧縮し、それを Ethereum ネットワークと Calldate 経由で同期します (初期のソリューション)。またはストレージ用の BLOB (現在のスキーム) データ スペース。
理想的には、レイヤー 2 の決済ロジックが実現可能であれば、決済をレイヤー 2 に依存するレイヤー 3 のロジックも真実であるように見えます。その技術的な実装メカニズムは、大量のレイヤー 3 トランザクション データをパッケージ化して圧縮する必要があります。その後、レイヤー 2 ネットワークに同期されます...
この時点で、問題が発生し始めます。
レイヤ 2 自体はネットワークの「ファイナリティ」を確認する責任はなく、イーサリアムに依存しているため、理論的には、レイヤー 3 データは最終的にイーサリアムに送信される必要があり、イーサリアムが最終決定権を持ちます。
レイヤ 2 に送信されたレイヤ 3 圧縮データの場合、2 つの送信モード (圧縮を継続するか、圧縮を行わない) が考えられますが、残念ながら、当面はどのモードでも特定の問題が発生します。
レイヤ 3 データ送信の二重のパラドックス
1 つ目は、最初の潜在的な送信モードです。圧縮されたデータは再度圧縮され、他のレイヤー 2 トランザクション データとともにイーサリアム メイン ネットワークに送信されます。
それは素晴らしいことのように聞こえますが、現実は残酷です - いいえ。
Vitalik は 2022 年のレイヤー 3 に関する分析記事を書きました。どのようなレイヤ 3 が意味があるのでしょうか?」という記事で、トランザクションデータを複数回圧縮できない理由について説明しました。
ロールアップでは、一連の圧縮スキームを使用して、トランザクションに保存されるデータ量を削減します。単純な転送は約 100 バイトから約 16 バイトに圧縮でき、EVM 互換チェーン上の ERC 20 転送は約 180 バイトに圧縮できます。 ZK-SNARK トランザクションは約 23 バイトまで、約 600 バイトから約 80 バイトまで圧縮できます。上記のすべてのケースで、約 8 倍の圧縮効率を達成できます。ただし、ロールアップは、ロールアップのステータスを個別に計算するなど、ユーザーがすべてのデータにアクセスして検証できることを保証するために、チェーン上のデータの可用性を維持する必要があるためです。既存の検証ノードがオフラインの場合、新しい検証ノードとして参加します...データは一度圧縮できますが、繰り返し圧縮することはできませんこれは通常、可能であれば 2 番目のコンプレッサーのロジックを最初のコンプレッサーに組み込むことができることを意味しますが、1 回の圧縮だけで同じ効果を達成できた可能性があることも意味します。したがって、「ロールアップの上に別のロールアップを置く」ことには、実際の容量拡張ソリューションはありません。
簡単に言うと、データの可用性を考慮して、トランザクション データの圧縮には一定の制限があります。
この前提のもとでは、2 番目の圧縮のロジックを最初の圧縮プロセスに統合することでレイヤー 3 データの多重圧縮を実現できる場合、これは、レイヤー 2 データに対して直接多重圧縮を実行し、その後レイヤー 2 データに対して多重圧縮を実行することもできることを意味します。同じ拡張効果はレイヤー 3 でも達成できるのに、なぜレイヤー 3 が必要なのでしょうか?
その理由は、圧縮アルゴリズムは基本的にデータの冗長性をある程度削除し、データをよりコンパクトにするためですが、これらの冗長性が削除されると、すでに圧縮されたデータを再度圧縮することがより困難になるためです。削除できる冗長性。したがって、データ圧縮は無限に繰り返すことができるプロセスではなく、圧縮による利益は減少しています。
次に、2 番目の潜在的な送信モードを見ていきます。つまり、レイヤー 3 データは圧縮されなくなり、他のレイヤー 2 トランザクションとともにイーサリアムのメイン ネットワークに直接送信されます。
これも少し不可解に感じます。現在、イーサリアム エコシステムの拡大を制限している主なボトルネックは、レイヤー 2 (レイヤー 3 を含む) のブロック スペースの不足ではなく、メイン ネットワークのデータ可用性と伝送容量が限られていることです。——レイヤー 2 データの保存に使用される BLOB ストレージ容量は依然として限られています。
Monad の共同創設者 Keone Hon は以前、現在の BLOB 容量は 1 ブロック (12 秒) あたり約 3 つの 125 kb BLOB であり、これは 1 秒あたり 31.25 kb であると投稿しました。トランザクション数が約 100 バイトであることを考慮すると (指定された数よりわずかに多い) Vitalik 著)、これは、すべてのレイヤー 2 の共有 TPS が約 300 であることを意味します。
この前提の下では、すべてのレイヤ 2 (レイヤ 3 を含む) は同じデータ可用性の上限に従うことになり、これにより、レイヤ 2 とレイヤ 3 でどれだけのブロック スペースが提供されても、「ファイナリティ」の確認を完了することができなくなります。 . 場合によっては1人ずつ並ばなければならないこともあります。
これが、レイヤー 3 がイーサリアム エコシステムの拡大を魔法のように改善するものではないとヴィタリック氏が強調した理由です。
レイヤー3って意味ないの？
上記の分析に基づいて、圧縮効率とデータ可用性の上限の制限により、現在のレイヤー 3 は一般的な拡張において大きな効果を提供できないことがわかります。ということは、レイヤー 3 は純粋に「疑似概念」であり、実際的な意味はないということなのでしょうか?答えはそれほど絶対的なものではありません。
Starkware が「」で紹介されました。L2からL3への階層拡張》 では、レイヤー 3 の開発の方向性について、レイヤー 2 を汎用ネットワークとして運用し、レイヤー 3 をカスタマイズ機能を強化して専用ネットワークとして運用することや、レイヤー 2 をトラストレス拡張に注力する例などを示しています。次に、データの可用性などのより困難な問題に対処するために特定の外部信頼条件を導入することによって、弱い信頼の拡張に焦点を当てることができます。
最後にヴィタリックを塗布します。どのようなレイヤ 3 が意味があるのでしょうか?「ロールアップの上に別のロールアップを置くことは、特に 2 つのレイヤーが同じ技術メカニズムを使用している場合には、明らかに実現不可能です。ただし、レイヤー 2 とレイヤー 3 の設計が異なる場合、および目的が異なる場合、このような 3 層の拡張アーキテクチャは実現可能です。」
