執筆者: ヴィタリック・ブテリンコンピレーション:ウェンサー、Odailyプラネットデイリー編集者注:長い間、イーサリアムのロールアップセキュリティの3つのフェーズに関する議論は、イーサリアムのメインネットとL2ネットワークの運用安定性だけでなく、L2ネットワークの実際の開発にも関連するイーサリアムエコロジカルコミュニティの焦点でした。 最近、イーサリアムコミュニティのメンバーであるダニエル・ワンは、Xプラットフォーム上のL2ネットワークのステージ2フェーズの命名ラベル #BattleTested を提案し、現在のコードと構成を持つL2ネットワークのみが、イーサリアムのメインネット上で6か月以上オンラインになり、合計ロックアップ値(TVL)が1億ドル以上、ETHと主要なステーブルコインで少なくとも5,000万ドルを維持しているもののみがこのタイトルを取得できると主張し、タイトルは「オンチェーンゴースト」を避けるために動的に評価されます。」。 その後、イーサリアムの共同創設者であるヴィタリック氏は、この質問に詳細な回答をし、以下のOdaily Planet Dailyがまとめた彼の見解を共有しました。L2ネットワークの3つの段階：0から1、そして2へ、安全性はガバナンスシェアによって決まります。イーサリアムロールアップのセキュリティの3つの段階は、セキュリティ委員会がいつ信頼のない（つまり純粋な暗号またはゲーム理論）コンポーネントをカバーできるかに基づいて判断できます：フェーズ0：セキュリティ委員会は完全な権限を持っています。稼働中の証明システム（OptimismまたはZKモード）が存在する可能性がありますが、セキュリティ委員会は単純な多数決メカニズムでそれを覆すことができます。したがって、証明システムは「参考的な性質」となります。ステージ 1：安全委員会は、運用システムを覆すために 75%（少なくとも 6/8）の承認を必要とします。主要な組織の外でサブセット（例えば ≥ 3）が阻止されるためには、法定人数が必要です。したがって、証明システムを制御することの難易度は相対的に高いですが、不可能ではありません。ステージ2：セキュリティ委員会は、証明可能なエラーがある場合にのみ行動を取ることができます。たとえば、証明可能なエラーは、2つの冗長な証明システム（たとえば、OPとZK）が相互に矛盾する場合です。証明可能なエラーがある場合、それは提案された回答の1つを選択することしかできません：特定のメカニズムに恣意的に応答することはできません。以下のグラフを使用して、安全委員会が異なる段階で持っている「投票シェア」を示すことができます：三つの段階のガバナンス投票構造重要な問題は、L2ネットワークがフェーズ0からフェーズ1に移行する最適なタイミングと、フェーズ1からフェーズ2に発展する最適なタイミングはそれぞれ何かということです。ステージ2にすぐに移行しない唯一の有効な理由は、証明システムを完全に信頼できないからです——これは理解できる懸念です：このシステムは大量のコードで構成されており、コードに脆弱性が存在する場合、攻撃者がすべてのユーザーの資産を盗む可能性があります。証明システムに対する信頼が強いほど（または逆に、安全委員会に対する信頼が弱いほど）、ネットワーク全体のエコシステムを次のステージに進めたいと考えるようになります。実際には、私たちはこの点を定量化するために簡略化された数学モデルを使用できます。まず、仮定を列挙しましょう：各安全委員会のメンバーには10%の「単独故障」の可能性があります；私たちは、活性障害（契約の署名を拒否することやキーが使用できないこと）と安全性障害（誤った事項に署名することやキーがハッキングされること）を同等に可能な事象と見なします。実際には、私たちは「失敗」というカテゴリーだけを仮定しており、その「失敗」の安全理事会メンバーは、誤った事項に署名しただけでなく、正しい事項を進めることに失敗したのです；フェーズ0では、安全委員会の判断基準は4/7であり、フェーズ1では6/8です；私たちは、単一のモノリシックプルーフシステムがあると仮定します(2つの意見が一致しない場合に安全委員会が氷を砕くことができる2/3の設計メカニズムとは対照的です)。 したがって、フェーズ2では、安全委員会の存在はまったく関係ありません。これらの仮定の下で、証明システムが崩壊する特定の確率を考慮すると、L2ネットワークの崩壊の可能性を最小化したいと考えています。私たちはこの作業を完了するために二項分布を使用できます:もし各安全理事会のメンバーが 10% の独立故障の機会を持っている場合、7 人中少なくとも 4 人が故障する確率は ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 です。したがって、フェーズ 0 の統合システムには固定の 0.2728% の失敗確率があります。ステージ 1 の統合も失敗する可能性があり、証明システムが失敗し、セキュリティ委員会の検証メカニズムが ≥ 3 回失敗した場合、ネットワーク計算のカバレッジを行うことができません（確率 ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 乗じる証明システムの失敗率）、またはセキュリティ委員会が 6 回以上失敗した場合、不正な計算結果を強制的に生成することができます（固定 ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 確率）;ステージ2でのマージ失敗の確率は、証明システムの失敗の確率と一致します。ここに図表形式で表示します：L2ネットワークの異なる段階における証明システムの障害確率上記の推測結果に従い、証明システムの品質が向上するにつれて、最適な段階は段階0から段階1に移行し、次に段階1から段階2に移行します。段階0の品質の証明システムを使用して段階2のネットワークを運用することは、最も悪い結果です。現在、上記の簡略化モデルにおける仮定は完璧ではないことに注意してください：現実の世界では、安全委員会のメンバーは完全に独立しているわけではなく、（彼らの間には）「共通モード障害」が存在する可能性があります：彼らは共謀するか、同じ脅迫やハッキング攻撃を受ける可能性があります。このような事態を避けるために、主要な組織の外に法定人数を持ち、サブセットを阻止することが求められていますが、完璧ではありません。証明システム自体は、複数の独立したシステムの組み合わせで構成される可能性があります（私は以前のブログでこれを提唱したことがあります）。この場合、（i）証明システムが崩壊する確率は非常に低く、（ii）ステージ2でも安全委員会は重要です。なぜなら、それは紛争を解決するための鍵だからです。これらの2つの主張は、図に示されているものと比較して、フェーズ1とフェーズ2がより魅力的であることを示しています。あなたが数学を信じるなら、ステージ1の存在はほとんど正当化されません:あなたはステージ1に直行すべきです。 私が聞いた主な反対意見は、重大なエラーが発生した場合、セキュリティ委員会の8人のメンバーのうち6人から迅速に署名を得て修正するのは難しいかもしれない、というものです。 しかし、簡単な解決策があります:セキュリティ委員会のメンバーに引き出しを1〜2週間遅らせる権限を与え、他のメンバーに(是正)措置を講じるのに十分な時間を与えます。同時に、しかし、段階2に早すぎる段階でジャンプすることも誤りであり、特に段階2への移行の作業が基礎となる証明システムの強化作業を犠牲にしている場合はそうです。理想的には、L2Beatのようなデータプロバイダーが、証明システムの監査と成熟度指標（可能であれば、全体の集約ではなく、証明システムの実装指標を示すことで再利用できるように）を示し、段階を伴って表示するべきです。
Vitalikの新しい記事: A Brief Introduction to the Mathematics of Rational Classification of L2 Phases
執筆者: ヴィタリック・ブテリン
コンピレーション:ウェンサー、Odailyプラネットデイリー
編集者注:長い間、イーサリアムのロールアップセキュリティの3つのフェーズに関する議論は、イーサリアムのメインネットとL2ネットワークの運用安定性だけでなく、L2ネットワークの実際の開発にも関連するイーサリアムエコロジカルコミュニティの焦点でした。 最近、イーサリアムコミュニティのメンバーであるダニエル・ワンは、Xプラットフォーム上のL2ネットワークのステージ2フェーズの命名ラベル #BattleTested を提案し、現在のコードと構成を持つL2ネットワークのみが、イーサリアムのメインネット上で6か月以上オンラインになり、合計ロックアップ値(TVL)が1億ドル以上、ETHと主要なステーブルコインで少なくとも5,000万ドルを維持しているもののみがこのタイトルを取得できると主張し、タイトルは「オンチェーンゴースト」を避けるために動的に評価されます。」。 その後、イーサリアムの共同創設者であるヴィタリック氏は、この質問に詳細な回答をし、以下のOdaily Planet Dailyがまとめた彼の見解を共有しました。
L2ネットワークの3つの段階：0から1、そして2へ、安全性はガバナンスシェアによって決まります。
イーサリアムロールアップのセキュリティの3つの段階は、セキュリティ委員会がいつ信頼のない（つまり純粋な暗号またはゲーム理論）コンポーネントをカバーできるかに基づいて判断できます：
フェーズ0：セキュリティ委員会は完全な権限を持っています。稼働中の証明システム（OptimismまたはZKモード）が存在する可能性がありますが、セキュリティ委員会は単純な多数決メカニズムでそれを覆すことができます。したがって、証明システムは「参考的な性質」となります。
ステージ 1：安全委員会は、運用システムを覆すために 75%（少なくとも 6/8）の承認を必要とします。主要な組織の外でサブセット（例えば ≥ 3）が阻止されるためには、法定人数が必要です。したがって、証明システムを制御することの難易度は相対的に高いですが、不可能ではありません。
ステージ2：セキュリティ委員会は、証明可能なエラーがある場合にのみ行動を取ることができます。たとえば、証明可能なエラーは、2つの冗長な証明システム（たとえば、OPとZK）が相互に矛盾する場合です。証明可能なエラーがある場合、それは提案された回答の1つを選択することしかできません：特定のメカニズムに恣意的に応答することはできません。
以下のグラフを使用して、安全委員会が異なる段階で持っている「投票シェア」を示すことができます：
三つの段階のガバナンス投票構造
重要な問題は、L2ネットワークがフェーズ0からフェーズ1に移行する最適なタイミングと、フェーズ1からフェーズ2に発展する最適なタイミングはそれぞれ何かということです。
ステージ2にすぐに移行しない唯一の有効な理由は、証明システムを完全に信頼できないからです——これは理解できる懸念です：このシステムは大量のコードで構成されており、コードに脆弱性が存在する場合、攻撃者がすべてのユーザーの資産を盗む可能性があります。証明システムに対する信頼が強いほど（または逆に、安全委員会に対する信頼が弱いほど）、ネットワーク全体のエコシステムを次のステージに進めたいと考えるようになります。
実際には、私たちはこの点を定量化するために簡略化された数学モデルを使用できます。まず、仮定を列挙しましょう：
各安全委員会のメンバーには10%の「単独故障」の可能性があります；
私たちは、活性障害（契約の署名を拒否することやキーが使用できないこと）と安全性障害（誤った事項に署名することやキーがハッキングされること）を同等に可能な事象と見なします。実際には、私たちは「失敗」というカテゴリーだけを仮定しており、その「失敗」の安全理事会メンバーは、誤った事項に署名しただけでなく、正しい事項を進めることに失敗したのです；
フェーズ0では、安全委員会の判断基準は4/7であり、フェーズ1では6/8です；
私たちは、単一のモノリシックプルーフシステムがあると仮定します(2つの意見が一致しない場合に安全委員会が氷を砕くことができる2/3の設計メカニズムとは対照的です)。 したがって、フェーズ2では、安全委員会の存在はまったく関係ありません。
これらの仮定の下で、証明システムが崩壊する特定の確率を考慮すると、L2ネットワークの崩壊の可能性を最小化したいと考えています。
私たちはこの作業を完了するために二項分布を使用できます:
もし各安全理事会のメンバーが 10% の独立故障の機会を持っている場合、7 人中少なくとも 4 人が故障する確率は ∑𝑖= 47( 7 𝑖)∗ 0.1 𝑖∗ 0.97 −𝑖= 0.002728 です。したがって、フェーズ 0 の統合システムには固定の 0.2728% の失敗確率があります。
ステージ 1 の統合も失敗する可能性があり、証明システムが失敗し、セキュリティ委員会の検証メカニズムが ≥ 3 回失敗した場合、ネットワーク計算のカバレッジを行うことができません（確率 ∑𝑖= 38( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.03809179 乗じる証明システムの失敗率）、またはセキュリティ委員会が 6 回以上失敗した場合、不正な計算結果を強制的に生成することができます（固定 ∑𝑖= 68( 8 𝑖)∗ 0.1 𝑖∗ 0.98 −𝑖= 0.00002341 確率）;
ステージ2でのマージ失敗の確率は、証明システムの失敗の確率と一致します。
ここに図表形式で表示します：
L2ネットワークの異なる段階における証明システムの障害確率
上記の推測結果に従い、証明システムの品質が向上するにつれて、最適な段階は段階0から段階1に移行し、次に段階1から段階2に移行します。段階0の品質の証明システムを使用して段階2のネットワークを運用することは、最も悪い結果です。
現在、上記の簡略化モデルにおける仮定は完璧ではないことに注意してください：
現実の世界では、安全委員会のメンバーは完全に独立しているわけではなく、（彼らの間には）「共通モード障害」が存在する可能性があります：彼らは共謀するか、同じ脅迫やハッキング攻撃を受ける可能性があります。このような事態を避けるために、主要な組織の外に法定人数を持ち、サブセットを阻止することが求められていますが、完璧ではありません。
証明システム自体は、複数の独立したシステムの組み合わせで構成される可能性があります（私は以前のブログでこれを提唱したことがあります）。この場合、（i）証明システムが崩壊する確率は非常に低く、（ii）ステージ2でも安全委員会は重要です。なぜなら、それは紛争を解決するための鍵だからです。
これらの2つの主張は、図に示されているものと比較して、フェーズ1とフェーズ2がより魅力的であることを示しています。
あなたが数学を信じるなら、ステージ1の存在はほとんど正当化されません:あなたはステージ1に直行すべきです。 私が聞いた主な反対意見は、重大なエラーが発生した場合、セキュリティ委員会の8人のメンバーのうち6人から迅速に署名を得て修正するのは難しいかもしれない、というものです。 しかし、簡単な解決策があります:セキュリティ委員会のメンバーに引き出しを1〜2週間遅らせる権限を与え、他のメンバーに(是正)措置を講じるのに十分な時間を与えます。
同時に、しかし、段階2に早すぎる段階でジャンプすることも誤りであり、特に段階2への移行の作業が基礎となる証明システムの強化作業を犠牲にしている場合はそうです。理想的には、L2Beatのようなデータプロバイダーが、証明システムの監査と成熟度指標（可能であれば、全体の集約ではなく、証明システムの実装指標を示すことで再利用できるように）を示し、段階を伴って表示するべきです。