Vitalik新記事：L2ステージの合理的な区分に関する数学的原理についての簡単な考察
TechFlow厳選深潮セレクト
Vitalik新記事：L2ステージの合理的な区分に関する数学的原理についての簡単な考察
人治とメカニズムを組み合わせることで、L2の第二段階はより反脆弱性を持つことができる。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Vitalik Buterin
翻訳：Wenser、Odaily 星球日報
編集者注：これまで、イーサリアムのロールアップ安全性に関する3つの段階についての議論は、イーサリアムエコシステムコミュニティの注目点であり続けている。これは単にイーサリアムメインネットおよびL2ネットワークの運用安定性に関わるだけでなく、L2ネットワークの真の発展状況とも深く関係している。最近、イーサリアムコミュニティのメンバーであるDaniel WangがXプラットフォーム上でL2ネットワークのステージ2に対するネーミングラベル#BattleTestedを提唱した。彼は、Ethereumメインネット上で6ヶ月以上実行され、1億ドル以上の総ロック価値（TVL）を持ち、そのうち少なくとも5000万ドルはETHおよび主要なステーブルコインで構成されるL2ネットワークのみがこの称号を得るべきだと主張した。また、この称号は動的に評価され、「チェーン上でのゴーストチェーン」の発生を防ぐべきだとした。その後、イーサリアム共同創設者のVitalikがこの問題について詳細な解説と見解を示しており、以下にOdaily 星球日報がそれを翻訳する。
L2ネットワークの3段階：ゼロからワン、そしてツーへ――安全性はガバナンスシェアによって決まる
イーサリアムロールアップの安全性における3つの段階は、セキュリティ委員会が信頼不要（すなわち純粋な暗号的またはゲーム理論的）コンポーネントを上書きできるタイミングによって判断できる：
-
ステージ0：セキュリティ委員会が完全な支配権を持つ。動作中の証明システム（Optimism方式またはZK方式）が存在する可能性があるが、セキュリティ委員会は単純過半数の票でこれを覆すことができる。したがって、証明システムは「諮問的」にすぎない。
-
ステージ1：セキュリティ委員会が稼働システムを上書きするには75％（最低6/8）の承認が必要となる。主要組織以外に法定数阻止サブセット（例：≥3）が存在しなければならない。そのため、証明システムを支配するのは比較的難しくなるが、不可能ではない。
-
ステージ2：セキュリティ委員会は、証明可能なエラーの場合にのみ行動できる。例えば、証明可能なエラーとは、二重化された証明システム（OPとZKなど）が互いに矛盾する場合である。証明可能なエラーが発生した場合、委員会は提示された回答のいずれかを選択するしかない——任意のメカニズムに対して恣意的に反応することはできない。
以下の図表は、各段階におけるセキュリティ委員会の「投票シェア」を示している：
三段階におけるガバナンス投票構造
重要な疑問は、L2ネットワークがステージ0からステージ1へ、そしてステージ1からステージ2へ移行する最適なタイミングがそれぞれいつかということである。
即座にステージ2に入らない唯一妥当な理由は、証明システムを完全に信頼できないことだ——これは理解できる懸念である：このシステムは大量のコードから構成されており、もしバグがあれば攻撃者がすべてのユーザ資産を盗む可能性がある。証明システムに対する信頼が強いほど（あるいは逆に、セキュリティ委員会に対する信頼が弱いほど）、ネットワーク全体を次の段階へ進めようとするだろう。
実際、この関係を単純化された数学モデルで定量化することができる。まず前提条件を列挙しよう：
-
各セキュリティ委員会メンバーは、個別に故障する確率が10％である；
-
可用性の故障（契約署名拒否または鍵の欠如）と安全性の故障（誤った事項への署名または鍵のハッキング）を同等に起こりうるものとして扱う。実際には、「故障」という単一のカテゴリのみを仮定し、「故障」した委員会メンバーは誤った事項に署名すると同時に、正しい進行を妨げるために署名もしないものとする；
-
ステージ0では委員会の判定基準は4/7、ステージ1では6/8とする；
-
単一の統合証明システムが存在すると仮定する（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の存在が正当化されることはほとんどない：直ちにステージ2へ進むべきである。私が耳にする主な反論は、「重大なバグが発生した場合、8人の委員のうち6人に迅速に署名をもらうのが難しいかもしれない」というものだ。しかし、これには簡単な解決策がある：各委員に引き出しを1〜2週間遅延させる権限を与え、他のメンバーが補救措置を取る時間を確保すればよい。
同時に、基礎的な証明システムの強化作業を犠牲にしてまで早期にステージ2へ移行するのは誤りである。理想としては、L2Beatのようなデータプロバイダーが、証明システムの監査状況および成熟度指標（できればロールアップ全体ではなく証明システム実装単位の指標で、再利用可能なもの）とともに、現在の段階を併記すべきである。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@VitalikButerin
