原題: ステージ 1 とステージ 2 が意味を成す場合の計算

原著者: Vitalik Buterin

原訳者: Wenser、Odaily Planet Daily

編集者注: Ethereum ロールアップ セキュリティの 3 つのステージに関する議論は、常に Ethereum エコシステム コミュニティの焦点でした。これは、Ethereum メインネットと L2 ネットワークの運用安定性だけでなく、L2 ネットワークの実際の開発状況にも関係します。最近、イーサリアムコミュニティのメンバーであるダニエル・ワン氏が、Xプラットフォーム上のL2ネットワークのステージ2に「#BattleTested」という命名タグを提案しました。彼は、現在のコードと構成がイーサリアム メインネット上で 6 か月以上オンラインになっており、合計ロック値 (TVL) が 1 億ドル以上、ETH と主要ステーブルコインが少なくとも 5,000 万ドル維持されている L2 ネットワークだけがこの称号を獲得できると考えています。タイトルは、「オンチェーンゴースト」の出現を避けるために動的に評価されます。その後、イーサリアムの共同創設者であるヴィタリック氏はこの質問に詳しく答え、自身の見解を述べた。その内容はOdaily Planet Dailyによって以下のようにまとめられた。

L2 ネットワークの 3 つの主要ステージ: 0、1、2 では、セキュリティはガバナンスのシェアによって決定されます

Ethereum ロールアップ セキュリティの 3 つのステージは、セキュリティ委員会が信頼できない (つまり、純粋な暗号またはゲーム理論) コンポーネントをカバーできる時期に基づいて決定できます。

· フェーズ 0:セキュリティ委員会が完全に制御します。証明システム（Optimism または ZK モード）が導入されている場合もありますが、セキュリティ委員会は単純な多数決でそれを覆すことができます。したがって、この認証制度はあくまでも「助言的な性質」のものである。

· フェーズ 1:安全委員会は、運用システムをカバーするために 75% (少なくとも 6/8) の承認が必要です。プライマリ組織の外部にクォーラム ブロッキング サブセット (例: ≥ 3) が存在する必要があります。したがって、証明システムを制御する難しさは比較的高いですが、克服できないものではありません。

· フェーズ 2:安全委員会は、エラーが証明できる場合にのみ措置を講じることができます。たとえば、証明可能なバグとしては、2 つの冗長な証明システム (OP と ZK など) が互いに矛盾することが考えられます。証明可能なエラーがある場合、提案された回答のいずれかを選択することしかできません。つまり、メカニズムに任意に応答することはできません。

セキュリティ委員会がさまざまな段階で持つ「議決権」を表すには、次の表を使用できます。

3 段階のガバナンス投票構造

重要な質問は、L2 ネットワークがステージ 0 からステージ 1 に、そしてステージ 1 からステージ 2 に移行するのに最適な時間はいつなのかということです。

すぐにフェーズ 2 に移行しない唯一の正当な理由は、証明システムを完全に信頼できないことです。これは当然の懸念です。システムは大量のコードで構成されており、そのコードに脆弱性があると、攻撃者がすべてのユーザーの資金を盗む可能性があります。証明システムへの信頼が高まるほど（または逆に、セキュリティ委員会への信頼が低下するほど）、ネットワーク エコシステム全体を次の段階に押し進めたいという欲求が高まります。

実際、単純化された数学モデルを使用してこれを定量化することができます。まず、仮定を列挙しましょう: セキュリティ委員会の各メンバーは、「個人失敗」の確率が 10% あります。 · 活性障害 (契約への署名の拒否またはキーが利用できない) と安全性障害 (間違ったものに署名する、キーがハッキングされる) は、同等の可能性があるものとして扱います。実際には、私たちが想定しているのは「失敗した」クラス 1 つだけです。そのクラスでは、「失敗した」安全保障理事会メンバーが間違った事柄に署名し、正しい事柄を進めることにも署名しませんでした。 · フェーズ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 のようなデータ プロバイダーが、システム監査と成熟度メトリックの証明 (再利用できるように、集計メトリック全体ではなくシステム実装の証明が望ましい) を、付随するデモンストレーション フェーズとともに提示します。

元のリンク

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia