出典: Vitalik
編集：Odaily Planet Daily（ @OdailyChina ）
翻訳者: Wenser ( @wenser 2010 )
編集者注: イーサリアム ロールアップ セキュリティの 3 つの段階に関する議論は、常にイーサリアム エコシステム コミュニティの焦点でした。これは、Ethereum メインネットと L2 ネットワークの運用安定性だけでなく、L2 ネットワークの実際の開発状況にも関係します。最近、イーサリアムコミュニティのメンバーであるダニエル・ワン氏が、Xプラットフォーム上のL2ネットワークのステージ2に「#BattleTested」という命名タグを提案しました。彼は、現在のコードと構成を持ち、イーサリアム メインネット上で 6 か月以上オンラインであり、少なくとも 5,000 万ドルの ETH と主要なステーブルコインを含む 1 億ドル以上の総ロック値 (TVL) を維持している L2 ネットワークだけがこの称号を獲得できると考えています。タイトルは、「オンチェーンゴースト」の出現を避けるために動的に評価されます。その後、イーサリアムの共同創設者であるヴィタリック氏はこの質問に詳しく答え、自身の見解を述べた。その内容はOdaily Planet Dailyによって以下のようにまとめられている。
L2ネットワークの3つの主要な段階：0から1、そして2まで、セキュリティはガバナンスシェアによって決定される
イーサリアム ロールアップ セキュリティの 3 つのフェーズは、セキュリティ委員会が信頼できない (つまり、純粋に暗号化またはゲーム理論的な) コンポーネントをいつカバーできるかに基づいて決定できます。
フェーズ 0: セキュリティ委員会が完全な制御権を持ちます。証明システム（Optimism または ZK モード）が導入されている場合もありますが、セキュリティ委員会は単純な多数決でそれを覆すことができます。したがって、認証システムはあくまでも「助言的な性質」のものにすぎません。
フェーズ 1: 安全委員会は、運用システムをカバーするために 75% (少なくとも 6/8) の承認が必要です。プライマリ組織の外部にクォーラム ブロッキング サブセット (例: ≥ 3) が存在する必要があります。したがって、証明システムを制御する難しさは比較的高いですが、克服できないものではありません。
ステージ 2: 安全委員会は、エラーが証明できる場合にのみ措置を講じることができます。たとえば、証明可能なエラーとしては、2 つの冗長な証明システム (OP と ZK など) が互いに矛盾しているというものがあります。証明可能なエラーがある場合、提案された回答のいずれかを選択することしかできません。つまり、メカニズムに任意に応答することはできません。
安全委員会がさまざまな段階で持つ「議決権」を表すには、次の図を使用できます。
3段階のガバナンス投票構造
重要な質問は、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 でも重要です。
どちらの議論も、フェーズ 1 と 2 は図が示すよりも魅力的であることを示唆しています。
数学を信じるなら、フェーズ 1 の存在を正当化することはほとんど不可能です。フェーズ 1 に直接進むべきです。私が聞いた主な反対意見は、重大なバグが発生した場合、8 人の安全委員会メンバーのうち 6 人にすぐに署名してもらい、修正することが難しいかもしれないというものです。しかし、簡単な解決策があります。安全委員会のメンバーに撤退を 1 ～ 2 週間延期する権限を与え、他のメンバーが (是正) 措置を講じるのに十分な時間を与えるのです。
しかし同時に、フェーズ 2 への移行作業が基礎となる証明システムの強化作業を犠牲にする場合は特に、時期尚早にフェーズ 2 に飛びつくのは間違いです。理想的には、 L2Beatのようなデータ プロバイダーが、システム監査と成熟度メトリックの証明 (再利用できるように、集計メトリック全体ではなくシステム実装の証明が望ましい) を、付随するデモンストレーション フェーズとともに提示します。
