拡張希望はそれとも偽概念か？Layer3はなぜ論争を呼んでいるのか？

オリジナル｜Odaily星球日报

著者｜Azuma

Layer 3を巡る議論がここ数日、ますます激化しています。

一方で、Degen ChainなどのLayer 3の代表的なプロジェクトの関連トークンは、過去数日間で驚異的な上昇を見せています ------ DEGEN自体の週ごとの上昇率は143.%に達し、AavegotchiはBase系Layer 3への転換を選択した後、GHSTも強力に歴史的高値を更新しました。

しかし一方で、コミュニティ内ではLayer 3に対する疑問の声もますます大きくなっており、Vitalikは今日、自ら反対の意見を表明しました：「Layer 3は魔法のようにスループットを向上させるわけではない。」

ちょうど昨日はエイプリルフールで、多くのプロジェクトがこれを焦点にして、Layer 4やLayer 5に関する少し皮肉を込めたジョークを交わしました。例えば、dYdXは「新しいバージョンはL4を基に構築される」と冗談を言ったことがあり、このジョークは一部のメディアによってニュースとして伝えられました。

では、なぜLayer 3はこれほど疑問視されるのでしょうか？「Rollupの上にさらにRollupを重ねる」というロシアのマトリョーシカの論理がなぜ政治的に正しくないのか？コミュニティの議論を総合すると、Layer 3に対する疑問の焦点は主に「Layer 3は本当に拡張の意義を持つのか」に集中しています。

Layer 3の実現可能性の仮定

古典的な定義から見ると、Layer 2は通常、イーサリアムのメインネットに依存して決済を行い、拡張性を持つネットワークとして定義されます。それに対してLayer 3の定義は、Layer 2に依存して決済を行い、より高い拡張性を持つネットワークです。

Layer 2の環境下で、いわゆる「イーサリアムに依存して決済を行う」という技術的な実現メカニズムは、Layer 2の大量の取引データをパッケージ化し圧縮し、それをイーサリアムネットワークに同期させ、Calldate（初期の提案）またはBlob（現在の提案）のデータスペースに保存することです。

理想的には、Layer 2のこの決済ロジックが機能するならば、Layer 3がLayer 2に依存して決済を行うロジックも成立するはずで、その技術的な実現メカニズムは、Layer 3の大量の取引データをパッケージ化し圧縮し、それをLayer 2ネットワークに同期させることになるでしょう……

この段階で、問題が発生し始めます。

Layer 2自体はネットワークの「最終性」の確認を担当せず、イーサリアムに依存しているため、理論的にはLayer 3のデータも最終的にイーサリアムに提出され、イーサリアムが「一発で決定」するべきです。

Layer 2に提出されたLayer 3の圧縮データに関しては、ここで2つの潜在的な提出モード（圧縮を続ける or 圧縮しない）が存在しますが、残念ながらどちらのモードも一時的に問題を抱えています。

Layer 3データ提出の二重の逆説

まず第一の潜在的な提出モードは、すでに圧縮されたデータを再度圧縮し、他のLayer 2の取引データと一緒にイーサリアムのメインネットに提出することです。

聞こえは良いですが、現実の状況は非常に厳しい ------ できません。

Vitalikは2022年にLayer 3に関する分析記事《どのようなLayer 3が意味を持つのか》を書き、なぜ取引データを何度も圧縮できないのかを説明しました。

Rollupは取引データの保存量を減少させるために一連の圧縮スキームを使用しています。単純な送金は約100バイトを約16バイトに圧縮でき、EVM互換チェーン上のERC 20の送金は約180バイトを約23バイトに圧縮でき、ZK-SNARK取引は約600バイトを約80バイトに圧縮できます。上記のすべてのケースは約8倍の圧縮効率を実現できます……しかし、Rollupは依然としてチェーン上でデータの可用性を保持する必要があり、ユーザーがアクセスし検証できるすべてのデータを保証する必要があります。たとえば、Rollupの状態を独立して計算することや、既存の検証ノードがオフラインのときに新しい検証ノードとして参加することなどです……データは一度圧縮できますが、再度圧縮することはできません。もしできるなら、通常は2番目の圧縮器のロジックを1番目に組み込むことができることを意味しますが、これはつまり、1回の圧縮で同じ効果を得られることを意味します。したがって、「Rollupの上にさらにRollupを重ねる」ことは、真の拡張効果を持つ解決策ではありません。

簡単に言えば、データの可用性を考慮すると、取引データの圧縮には一定の制限が存在します。

この前提のもとで、もし私たちが2回目の圧縮のロジックを最初の圧縮プロセスに統合することでLayer 3データの多重圧縮を実現できるなら、それはLayer 2データの多重圧縮も可能であり、Layer 2レベルで直接同じ拡張効果を達成できることを意味します。それなら、なぜ私たちはLayer 3が必要なのでしょうか？

その理由は、圧縮アルゴリズムは本質的にある程度データの冗長性を取り除くことでデータをよりコンパクトにするため、これらの冗長性が取り除かれると、すでに圧縮されたデータを再度圧縮することが難しくなります。なぜなら、取り除くことができる冗長性はますます少なくなるからです。したがって、データ圧縮は無限に繰り返すことができるプロセスではなく、圧縮の利益も減少していきます。

次に、第二の潜在的な提出モードを見てみましょう。Layer 3データを圧縮せず、他のLayer 2の取引と一緒に直接イーサリアムのメインネットに提出することです。

これもまた、少し不可解に思えます。なぜなら、現在、イーサリアムエコシステムの拡張効果を制限している主なボトルネックはLayer 2（Layer 3を含む）上のブロックスペースの不足ではなく、メインネットのデータ可用性のキャパシティが限られているからです ------ つまり、Layer 2データを保存するためのBlobストレージスペースは依然として限られています。

Monadの共同創設者Keone Honは以前、現在のBlobの容量状況について、各ブロック（12秒）で3つの125kbのBlobが生成されると述べており、つまり毎秒31.25kbです。取引のサイズが約100バイト（Vitalikが示した数字よりやや高い）であることを考えると、すべてのLayer 2の共有TPSは約300程度であることを意味します。

この前提のもとで、すべてのLayer 2（Layer 3を含む）は同じデータ可用性の上限に制約されるため、Layer 2とLayer 3が提供するブロックスペースがどれだけ増えても、「最終性」の確認を完了する際には一つずつ順番に処理しなければなりません。

これがVitalikがLayer 3がイーサリアムエコシステムの拡張状況を神秘的に改善することはないと強調する理由です。

Layer 3は全く意味がないのか？

上記の分析を総合すると、圧縮効率やデータ可用性の上限などの制約から、現在のLayer 3は汎用的な拡張において顕著な効果を提供できないことがわかります。それでは、Layer 3は単なる「偽の概念」であり、実践的な意味が全くないのでしょうか？答えはそれほど明確ではありません。

Starkwareは《階層的拡張、L2からL3へ》において、Layer 3のいくつかの潜在的な発展方向を概説しています。例えば、Layer 2は汎用ネットワークとして機能し、Layer 3はカスタマイズ機能を強化することで専用ネットワークとして機能することができます。また、Layer 2は信頼のない拡張に焦点を当て、Layer 3は弱い信頼の拡張に焦点を当て、一定の外部信頼条件を導入してデータの可用性などの厄介な問題を処理することができます。

最後に、Vitalikの《どのようなLayer 3が意味を持つのか》の原文を引用して締めくくりましょう。「Rollupの上にさらにRollupを重ねること、特にこの2層が同じ技術メカニズムを採用している場合、明らかにうまくいきません。しかし、Layer 2とLayer 3が異なる設計と異なる目標を持っている場合、そのような三層の拡張構造は実現可能です。」