Vitalikの最新の長文：各種L2の違いを整理する
避けられない結果の一つは、L2プロジェクトがますます異種化していることです。原文タイトル：《Different types of layer 2s》
原文著者：Vitalik Buterin
原文翻訳：BlockBeats
エコシステムは過去1年間で急速に拡大しました。従来、StarkNet、Arbitrum、Optimism、Scrollを代表とするZK-EVMロールアップエコシステムは急速に進展し、その安全性を高め続けています。L2beatのページは、各プロジェクトの状況をうまくまとめています。
さらに、いくつかのチームがサイドチェーンを構築しているのを見ており、同時にロールアップソリューション（Polygonなど）を構築し始めています。一部のL1プロジェクトは、有効性検証の方向に進もうとしています（Celoなど）、そして全く新しい試み（Linea、Zethなど）もあります。
避けられない結果の一つは、L2プロジェクトがより異種混合化（すなわち「ヘテロジニティ」）に向かっていることです。私はこの傾向が続くと予想しています。その理由は以下の通りです：
現在、一部の独立したL1プロジェクトは、Ethereumエコシステムとのより密接な接触を求めており、L2プロジェクトに転換する可能性があります。これらのプロジェクトは、段階的な移行を希望するかもしれません。全体的な移行を即座に行うと、技術がすべてをロールアップソリューションに入れる準備が整っていないため、可用性が低下します。そして、遅れて全体的な移行を行うと、勢いを失い、実際的な意味を持たなくなる可能性があります。
一部の中央集権的プロジェクトは、ユーザーにより多くの安全保障を提供したいと考えており、ブロックチェーンに基づくアプローチを模索しています。多くの場合、これらのプロジェクトは以前は「許可されたコンソーシアムチェーン」を研究していたかもしれません。実際には、彼らは「半中央集権」のレベルに達するだけで済むかもしれません。さらに、彼らは通常非常に高いスループットを持ち、少なくとも短期的にはロールアップソリューションを使用するには適していません。
ゲームやソーシャルメディアのような非金融アプリケーションは、分散化を望んでいますが、ある程度の安全性だけが必要です。
ソーシャルメディアの場合、実際にはアプリケーションの異なる部分を異なる方法で処理することが関与しています：ユーザー名の登録やアカウントの復元のような稀で高価値の活動はロールアップソリューションで行うべきですが、投稿や投票のような頻繁で低価値の活動は、より少ない安全保障が必要です。もしブロックチェーンの失敗があなたの投稿を消失させることになっても、それは受け入れられる代償です。しかし、ブロックチェーンの失敗があなたのアカウントを失わせることになれば、それはより大きな問題です。
重要なテーマの一つは、現在Ethereum L1にあるアプリケーションやユーザーが短期的には小さくても目に見えるロールアップ手数料を支払う意欲がある一方で、非ブロックチェーンの世界からのユーザーはそうではないということです：もしあなたが以前に1ドルを支払ったなら、0.10ドルを支払うことはより受け入れやすいですが、もし以前に0ドルを支払ったなら、それは受け入れがたいことです。
これは、今日もなお中央集権的なアプリケーションや、通常はユーザー群が小さいために非常に低い手数料を持つ小さなL1プロジェクトにも当てはまります。
自然に浮かび上がる質問は、特定のアプリケーションにとって、ロールアップソリューション、バリディウム（有効性検証）、および他のシステム間のこれらの複雑なトレードオフの中で、どれが合理的であるかということです。
ロールアップ vs バリディウム vs 切り離されたシステム
私たちが探求する安全性とスケーラビリティの最初の次元は次のように説明できます：あなたがL1で発行された資産を持ち、それをL2に預け、再びあなたの手に移す場合、あなたはどの程度の保証を得られるでしょうか？
同時に関連する問題があります：どの技術選択がこの保証の程度をもたらし、その技術選択のトレードオフは何ですか？
この問題を簡単な図で説明できます：
言及すべきは、これは多くの中間オプションが存在する簡略化されたスキームであるということです。例えば：
ロールアップとバリディウムの間：バリディウムでは、誰でもオンチェーンで支払いを行い取引手数料を支払うことができ、その際、オペレーターは一部のデータをオンチェーンに提供することを強いられ、さもなければデポジットを失います。
プラズマとバリディウムの間：プラズマシステムはロールアップに類似した安全性を提供し、オフチェーンデータの可用性を持っていますが、限られた数のアプリケーションのみをサポートします。あるシステムは完全なEVMを提供し、これらのより複雑なアプリケーションを使用しないユーザーにはプラズマレベルの保証を提供し、これらのアプリケーションを使用するユーザーにはバリディウムレベルの保証を提供します。
これらの中間オプションは、ロールアップとバリディウムの間のスペクトルとして見ることができます。しかし、アプリケーションがこのスペクトル上の特定の点を選択する理由は何でしょうか？ここには二つの主要な要因があります：
1. Ethereumのネイティブデータ可用性のコストは、技術の進展とともに時間とともに低下します。 Ethereumの次のハードフォークDencunはEIP-4844（別名「proto-danksharding」）を導入し、約32kB/秒のオンチェーンデータ可用性を提供します。
今後数年で、完全なダンクシャーディングが導入されるにつれて、このデータ可用性は徐々に向上し、最終的な目標は約1.3MB/秒のデータ可用性です。同時に、データ圧縮の改善により、同じデータ量でより多くの機能を実現できるようになります。
2. アプリケーション自身のニーズ：ユーザーが高い手数料に対して失うものは、アプリケーションに問題が発生した場合に比べてどれほど深刻ですか？ 金融アプリケーションは、アプリケーションの障害によってより多くの損失を被ります。ゲームやソーシャルメディアは大量のユーザー活動を含み、相対的に低価値の活動を伴うため、彼らにとっては異なる安全性のトレードオフが意味を持ちます。
このトレードオフは大まかに次のように見えます：
もう一つ言及すべきタイプは、事前確認（pre-confirmations）です。事前確認は、ロールアップまたはバリディウム内の参加者のグループによって署名されたメッセージで、「私たちはこれらの取引がこの順序で含まれていることを証明し、ポストステートルートはこれです」と示します。これらの参加者は現実と一致しない事前確認に署名することもありますが、もしそうであれば、彼らのデポジットは失われます。
これは低価値のアプリケーション（消費者の支払いなど）に非常に役立ちますが、高価値のアプリケーション（数百万ドルの金融送金など）は、システムの完全な安全性によってサポートされる「通常の」確認を待つことになるかもしれません。
**事前確認は、上記で言及した「プラズマ/バリディウム混合」の別の混合システムの例と見なすことができますが、今回は完全な安全性を持つが高遅延のロールアップ（またはバリディウム）と、低い安全レベルを持つが低遅延のシステムとの間での混合です。低遅延が必要なアプリケーションは低い安全性を得ますが、最大の安全性を得るために高遅延を受け入れることを望むアプリケーションと同じエコシステム内で共存することができます。
信頼なしにEthereumを読み取る
もう一つあまり考慮されていないが非常に重要な接続形式は、システムがEthereumブロックチェーンを読み取る能力に関係しています。具体的には、これはシステムがEthereumでロールバックが発生した場合にロールバックできる能力を含みます。なぜこれが価値があるのかを理解するために、以下の状況を考えてみてください：
図に示すように、Ethereumブロックチェーンがロールバックされると仮定します。これは、ある時代内の一時的な中断であり、その時点でブロックチェーンがまだ最終確定されていない場合や、過剰なバリデーターがオフラインになり、ブロックチェーンが長期間最終確定されない非活動漏洩期間が発生する可能性があります。
この結果として生じる最悪のシナリオは次のようになります：トップチェーンの最初のブロックがEthereumチェーンの最左側のブロックから何らかのデータを読み取ると仮定します。例えば、誰かがEthereumに100 ETHをトップチェーンに預けました。その後、Ethereumがロールバックされますが、トップチェーンはロールバックされません。結果として、トップチェーンの将来のブロックは新しい、正しいEthereumブロックチェーン上のブロックに正しく従いますが、誤った取引（すなわち100 ETHの預金）がトップチェーンに残ります。この脆弱性は通貨の増発を引き起こし、トップチェーン上のブリッジETHを部分的な準備金に変える可能性があります。
この問題を解決する方法は二つあります：
トップチェーンはEthereumが最終確定したブロックのみを読み取ることができるため、ロールバックする必要はありません；
Ethereumがロールバックされた場合、トップチェーンもロールバックされる可能性があります。どちらもこの問題を防ぐことができます。前者は実装が容易ですが、Ethereumが非活動漏洩期間に入ると、機能が長期間失われる可能性があります。後者は実装が難しいですが、常に最適な機能を確保できます。
第一の方法には特別な状況が存在します。もしEthereumが51%攻撃を受け、二つの新しい不整合なブロックが同時に現れ、どちらも最終確定されたように見える場合、トップチェーンは誤ったブロック（すなわちEthereum社会の合意が最終的に支持しないブロック）を選択し、正しいブロックに切り替えるためにロールバックする必要があります。このような状況を処理するために事前にコードを書く必要はないと言えます；トップチェーンをハードフォークすることでこの問題を処理できます。
ブロックチェーンが信頼なしにEthereumを読み取る能力には二つの重要な理由があります：
まず、この能力はEthereum（または他の第二層ソリューション）上で発行されるトークンをそのチェーンにブリッジする際に関与するセキュリティ問題を低減します；
次に、この能力は、共有鍵ストレージ構造を使用するアカウント抽象化ウォレットが、そのチェーン上の資産を安全に保持できることを意味します。
議論の余地はありますが、第一の方法の重要性は広く認識されています。同様に、第二の方法も重要です。なぜなら、それはあなたが鍵を簡単に変更し、さまざまなチェーン上で資産を保持できるウォレットを持つことができることを意味するからです。
ブリッジがvalidiumになることは可能か？
トップチェーンが最初に独立したチェーンとして立ち上げられ、その後Ethereum上にブリッジコントラクトがデプロイされたと仮定します。ブリッジコントラクトは、トップチェーンのブロックヘッダーを受け入れるコントラクトであり、提出されたブロックヘッダーがトップチェーンの合意に受け入れられたことを証明する有効な証明書を伴っているかどうかを検証し、そのブロックヘッダーをリストに追加します。
アプリケーションはこの基盤の上に機能を構築できます。例えば、トークンの預金や引き出しなどです。このようなブリッジが構築されると、それは私たちが前述した資産の安全保障を提供するのでしょうか？
これまでのところ、まだありません！二つの理由があります：
私たちはブロックの署名を検証していますが、状態遷移が正しいかどうかは検証していません。したがって、あなたがEthereum上で発行された資産をトップチェーンに預け、トップチェーンのバリデーターが不誠実になった場合、彼らは無効な状態遷移に署名し、これらの資産を盗むことができます；
トップチェーンは依然としてEthereumを読み取ることができません。したがって、あなたは他の（おそらく安全でない）第三者のブリッジに依存しない限り、Ethereumのローカル資産をトップチェーンに預けることができません。
さて、私たちがブリッジを検証型ブリッジとして構築するとしましょう：それは合意を検証するだけでなく、ZK-SNARK証明を使用して計算された新しいブロックの状態が正しいかどうかも検証します。
このステップが完了すると、トップチェーンのバリデーターはあなたの資金を盗むことができなくなります。彼らは利用できないデータを含むブロックを発行し、全員が資金を引き出すのを妨げることはできますが、資金を盗むことはできません（ユーザーに身代金を要求して資金を引き出すためのデータを明らかにしようとしない限り）。これはバリディウムと同じ安全モデルを持っています。
しかし、私たちはまだ第二の問題を解決していません：トップチェーンはEthereumのデータを読み取ることができません。これを実現するためには、次のいずれかの方法を取る必要があります：
トップチェーンにEthereumの最終確定したブロックを検証するブリッジコントラクトを配置する；
トップチェーンの各ブロックに最近のEthereumブロックのハッシュを含め、ハッシュリンクを強制するためのフォーク選択ルールを採用します。つまり、非主チェーンにリンクされたEthereumブロックのトップチェーンブロック自体が非主チェーンである必要があります。もしトップチェーンブロックがリンクされたEthereumブロックが最初に主チェーンにあったが、後に非主チェーンになった場合、トップチェーンブロックも非主チェーンでなければなりません。
これらの紫色のリンクはハッシュリンクであるか、Ethereumの合意を検証するブリッジコントラクトである可能性があります。
これで十分でしょうか？実際には、まだ不十分です。なぜなら、いくつかの小さなエッジケースが存在するからです：
Ethereumが51%攻撃を受けた場合、何が起こるでしょうか？
Ethereumのハードフォークアップグレードをどう処理しますか？
あなたのチェーンのハードフォークアップグレードをどう処理しますか？
Ethereumへの51%攻撃は、トップチェーンへの51%攻撃と類似の結果をもたらしますが、逆の状況です。Ethereumのハードフォークは、トップチェーン内のEthereumブリッジを無効にする可能性があります。社会的コミットメント（social commitment）として、Ethereumが最終確定したブロックを復元した場合は復元し、Ethereumがハードフォークした場合はハードフォークするというのが、この問題を解決する最もクリーンな方法です。
このようなコミットメントは、実際には本当に実行される必要がないかもしれません：もしトップチェーンのガバナンス機関が攻撃やハードフォークが発生する可能性の証拠を発見した場合、ガバナンス機関を起動し、ガバナンス機関が失敗した場合にのみトップチェーンをハードフォークすることができます。
第三の質問に対する唯一の実行可能な答えは、Ethereum上に何らかの形のガバナンス機関を設置し、Ethereum上のブリッジコントラクトがトップチェーンのハードフォークアップグレードを認識できるようにすることです。
まとめ： 双方向検証ブリッジは、ブロックチェーンをバリディウムにするのにほぼ十分です。主に残っている要素は、Ethereumに異常が発生してブリッジコントラクトが正常に機能しなくなった場合、別のブロックチェーンがハードフォークして対応するという社会的コミットメントです。
結論
「Ethereumとの接続」には二つの重要な次元があります：
Ethereumへの引き出しの安全性；
Ethereumを読み取る安全性。
この二つは非常に重要であり、異なる考慮事項があります。この二つのケースには連続的なスペクトルが存在します：
各次元には二つの異なる測定方法（実際には四つの次元）があることに注意してください：引き出しの安全性は（i）安全レベルと（ii）最高の安全レベルの恩恵を受けるユーザーまたは使用状況の数によって測定できます；
一方、読み取りの安全性は（i）リンクがEthereumのブロックをどれだけ早く読み取れるか、特に最終確定したブロックと任意のブロックの違い、そして（ii）リンクが51%攻撃やハードフォークなどのエッジケースを処理する際の社会的コミットメントの程度によって測定できます。
この設計空間の多くの領域にはプロジェクトの価値があります。特定のアプリケーションにとって、高度な安全性と緊密な接続は非常に重要です。他のアプリケーションにとっては、より大きなスケーラビリティを得るために、より緩い条件を受け入れることができます。多くのケースでは、今日からより緩い条件を使用し、技術の改善に伴い、今後10年間でより緊密な結合に徐々に移行することが最適な選択かもしれません。
