VitalikはRollupの「完全な分散化」プロセスについて語る：十分なシステムセキュリティが鍵となる

この記事を読むのに必要な時間は 12 分

ワン氏は、コードは実戦テストを受ける必要があると強調したが、ヴィタリック氏は、システムの信頼性が証明されたときに分散化が達成されるべきだと考えている。

原題：「Vitalik の数学的モデルが明らかに：Rollup はいつ「完全な分散化」に向かうのか、鍵となるのはシステムが十分に安全であることだ」

原著者：Editor Jr.、BlockTempo Dynamic Zone Trend

Loopring プロトコルの創設者 Daniel Wang 氏は、5 月 4 日に X プラットフォーム上で Ethereum L2 Rollup の分散型セキュリティ問題について自身の見解を表明し、Ethereum 創設者 Vitalik Buterin 氏から反応がありました。二人は、Rollup が集中化または部分的な分散化 (ステージ 0 またはステージ 1) から完全な分散化 (ステージ 2) に移行する時期と、このプロセスのセキュリティを確保する方法について議論しました。

Daniel Wang: コードの成熟度が Rollup セキュリティの鍵

Daniel Wang 氏は、システムの安定性を確保するにはコードの実際的な成熟度が極めて重要であると強調しました。同氏は、たとえロールアップが完全な分散化の第2段階（ステージ2）に到達したとしても、そのコードが実際の環境でストレステストされていない場合、脆弱性が残る可能性があり、国家の支援を受けたラザルス・グループなどの営利目的のハッカーによる攻撃に抵抗できないと考えている。

そのため、ダニエル・ワン氏は、Rollup は大量の資産を管理しており、高い経済的プレッシャーの下でコードの信頼性を証明しなければならないと指摘しました。これを受けて氏は、コードの成熟度に着目し、L2Beatのステージモデル（ステージ0～2）とは別に評価する独立した評価基準として「#BattleTested」タグを提案しました。具体的な基準は次のとおりです:

· コードが Ethereum メインネット上で 6 か月以上実行されていること。

· 少なくとも 1 億ドルの総ロック価値 (TVL) を継続的に保護します。そのうち少なくとも 5,000 万ドルは ETH と主要なステーブルコインです。

· コードをアップグレードするたびに、ラベルを保持するために再度テストに合格する必要があります。

Daniel Wang 氏は次のようにツイートしました:

1/ すべてのコードが同じように作成されるわけではありません。 ロールアップはステージ 2 に到達しても、実際のストレス下でテストされたことのない新しいコードを実行する場合があります。

2/ 別のタグを提案します: #BattleTested。ロールアップは、現在のコードと構成が Ethereum メインネット上で 6 か月以上実行されており、一貫して 1 億ドルを超える総ロック値 (TVL) を保護し、そのうち少なくとも 5,000 万ドルが ETH と主要なステーブルコインである場合、#BattleTested と呼ばれることができます。

3/ #BattleTested は永続的なものではありません。 アップグレードを行うとタイマーがリセットされます。ロールアップは、実際の価値をもって本番環境での動作を実証することで、このラベルを再び獲得する必要があります。

4/ このタグは、@l2beat の位相モデルとは独立しています。 ロールアップはフェーズ 2 に到達しても #BattleTested されない場合もあれば、#BattleTested されてもフェーズ 2 に到達しない場合もあります。1 つは分散化に関するもので、もう 1 つはコードの成熟度に関するものです。

5/ @taikoxyz はフェーズ 2 に到達し、 #BattleTested コードを使用してアップグレードすることを目指しています (別の Ethereum テストロールアップが必要になる可能性があります...)。

ヴィタリック・ブテリン氏：分散化には、システムが十分に信頼できるという証明が必要

ダニエル・ワン氏の見解に応えて、ヴィタリック氏は、ロールアップの分散化のタイミングは証明システムの信頼性に基づくべきであり、障害の確率が集中化のリスクよりも低い場合にのみステージ2に入るのが適切であると強調しました。彼は、セキュリティ委員会のメンバーが 10% の独立した失敗確率 (生存障害またはセキュリティ障害を含む) を持つと仮定して、簡略化された数学モデルを提案し、ステージ 0 (4/7 マルチ署名)、ステージ 1 (6/8 マルチ署名)、ステージ 2 の個々のセキュリティを比較しました。

Vitalik はさらに、現実には、セキュリティ委員会は共謀や同時攻撃により「共通モード障害」に見舞われ、ステージ 0 とステージ 1 のセキュリティがモデルの予測よりも低くなる可能性があるため、実際にはステージ 2 に早く入るはずだと指摘しました。彼は、失敗の確率を減らすために証明システムをマルチ署名構造として設計することを提唱し、L2Beat が証明システムに監査と成熟度の指標を組み込んでプロジェクト間の評価の効率を向上させることを提案しました。

以下は、第 2 段階に入るタイミングを示す簡略化された数学モデルです。

>仮定: 安全委員会の各メンバーは、独立して 10% の「失敗」の確率を持ちます。

>活性障害 (署名拒否またはキーへのアクセス不可) は、安全性障害 (間違ったコンテンツへの署名またはキーの侵害) と同等の可能性があるものとして扱います。

>目的: 上記の仮定の下でプロトコル失敗の確率を最小限に抑えます。

>フェーズ 0 安全委員会では 7 名中 4 名の同意が必要であり、フェーズ 1 安全委員会では 8 名中 6 名の同意が必要です。

これらの仮定は非常に不完全であることに注意してください。現実には、セキュリティ委員会のメンバーには「共通の失敗パターン」があります。つまり、共謀していたり、全員が強要されていたり、同じ方法でハッキングされたりしている可能性があります。これにより、ステージ 0 とステージ 1 はモデルが示唆するよりも安全性が低くなります。そのため、ステージ 2 に入る最適な時期は、モデルが示唆するよりも早くなります。

さらに、証明システム自体を複数の独立したシステムによる多重署名とすることで、証明システムが失敗する確率を大幅に減らすことができます。最初の数年間のすべてのフェーズ 2 展開はこのように行われるのではないかと考えています。それを念頭に置いて、ここにチャートを示します。 X 軸はシステム障害が発生する確率、Y 軸はプロトコル障害が発生する確率です。

証明システムの品質が向上するにつれて、最適なステージはステージ 0 からステージ 1 に移行し、さらにステージ 1 からステージ 2 に移行します。ステージ 2 にステージ 0 品質の証明システムを使用するのは最悪のことです。簡単に言うと、@l2beat は理想的には、証明システムの監査と成熟度メトリック (再利用性を可能にするために、ロールアップ全体ではなく証明システムの実装が望ましい) をステージとともに表示する必要があります。