イーサリアム L2 における詐欺証明状態

1. 前書き

1.1. オプティミスティック・ロールアップの今後の方向性

2024 年 9 月、Vitalik は Rollup 標準を引き上げる必要性を [強調] (https://x.com/VitalikButerin/status/1834061075970683367) し、次のように述べています。

私はこれを非常に重視しています。来年からは、ブログやスピーチなどの場で、段階1以上に達したL2のみを公に言及する予定です。また、新しい興味深いプロジェクトには一時的な猶予期間があるかもしれません。

私が投資しているかどうか、またはあなたが私のフレンであるかどうかにかかわらず、第一段階に達する必要があります。そうでない場合は、ご提供できません。

Rollupの「段階」システムは、その安全性レベルを大まかに評価するためのフレームワークであり、ステージ0からステージ2まであります。現在の主流のRollupでは、ArbitrumとOptimismのみがステージ1に達しており、他の多くのOptimistic Rollupは現在もステージ0にあります。

このような状況では、いくつかの問題が発生しました。

• Optimistic Rollup がリリースされてから3年が経ちましたが、なぜまだプロジェクトが最高段階の2に到達していないのですか？
• Optimistic Rollupが段階2に到達するのはいつですか？

この記事では、Optimistic Rollupの詐欺証明とチャレンジメカニズムを分析し、それらの問題に答え、各プロジェクトがフェーズ2を実現するためにどのように取り組んでいるかを探求します。さらに、この記事では、Optimistic Rollupと詐欺証明システムの将来の発展についても見ていきます。

1.2. オプティミスティック ロールアップと ZK ロールアップ

ETH坊は知られているようにスピードが遅く、取引手数料が高いです。ETH坊のコミュニティの研究者や開発者たちは、この問題を解決するために長年取り組んできました。シャーディングやプラズマなどの解決策を探索した後、コミュニティは最終的にRollupが拡張性を実現する主要な手段であることを確認しました。そのため、Arbitrum、Optimism、zkSyncなどのRollupが次々と登場しています。L2Beatのデータによると、現在約40のRollupが稼働中であり、ValidiumやOptimumのような他の解決策はより高い拡張性を実現するためにalt-DAを採用しており、総数は約41です。さらに、約80の新しいRollupチェーンが登場する見込みです。

(現在の L2 ステータス |.) 源：L2Beat)

Rollup の核心コンセプトは、オフチェーンで取引を実行し、ETHのブロックチェーンに取引データと結果の状態ルートだけを提出することでスケーラビリティを実現することです。ユーザーは、特定のブリッジ契約に資金を預け入れ、その資金をRollup内に移動し、Rollup内で取引を行うことができます。取引データがETHブロックチェーンに提出され、一旦確認されるとETHブロックチェーンの安全性を損なうことなく変更することができないため、Rollupは「ETHブロックチェーンの安全性を継承している」と見なされています。

でも、それは本当なの？もしもRollup内でトランザクションを処理する提案者が悪意を持っていたらどうなるのか？悪意のある提案者はAliceの残高を改ざんし、自分のアカウントに移し、イーサリアムに引き出すことで、実質的にAliceの資金を盗む可能性があります。

このような状況を防ぐために、RollupからETHネットワークへの引き出し時には追加のセキュリティメカニズムが必要です。引き出しトランザクションが正しく処理され、L2チェーンに含まれていることをETHネットワークブリッジ契約に証明する必要があります。証明が提供されない限り、引き出しトランザクションは完了しません。

最も簡単な方法、そしてすべてのRollupで採用されている方法は、引き出しトランザクションのハッシュ値をRollupの状態ルートと比較し、引き出しトランザクションが正しくRollupの状態に含まれていることを証明することです。これには、引き出しトランザクションと状態ルートをEtherumのブリッジ契約に一緒に提出する必要があります。ユーザーは引き出しトランザクションを提出し、バリデータが状態ルートを計算して提出します。

しかし、もしステートルートをバリデータが悪意を持って誤ったものを提出した場合、ユーザーの資金の安全性が危険にさらされる可能性があります。このリスクをドロップするために、Optimistic RollupとZK Rollupは異なる2つの主要なメカニズムを提案しています。

1. **ZKロールアップ ZK Rollupでは、バリデータが状態ルートを提出するだけでなく、ZK証明を提供して状態ルートの計算の正確性を検証する必要があります。バリデータが誤った状態ルートを提出した場合、ZK証明はL1での契約の検証に合格できず、悪意のある状態ルートの提出を防止します。
2. **オプティミスティックロールアップ **Optimistic Rollupでは、指定されたバリデータが追加の保証なしに状態ルートを提出できるようになっていますが、これは提出が誠実であることが前提となっています。ただし、提出された状態ルートが正しくない場合、誰でも疑問を提出し、その状態ルートが引き出しプロセスで使用されるのを防ぐことができます。疑問を提出する人は詐欺証明と呼ばれる、状態ルートが誤っていることを証明する証拠をETHネットワークに提出する必要があります。

L1検証などの攻撃を安全に解決するために、Optimistic Rollupの引き出し時間は通常、約1週間のレイテンシーがあります。

1.3. なぜ詐欺証明が必要なのですか？

ZK Rollup とは異なり、Optimistic Rollup のバリデータは誤った状態ルートを提出し、引き出しトランザクションを操作しようとすることができます。詐欺証明はこれを効果的に防止し、ブリッジ契約内の資金の安全性を確保します。

強力な不正防止メカニズムがなければ、オプティミスティックロールアップはイーサリアムのセキュリティを完全に継承することはできません。 例えば、現在のArbitrumのライセンス制度では、全てのバリデータが共謀した場合、ブリッジ契約の資金を全て盗んでしまう可能性があります。 同様に、BaseなどのOPスタックベースのロールアップでは、メインネットにパーミッションレスフォールトプルーフメカニズムがまだ実装されていないため、単一の悪意のあるロールアップが資金を盗む可能性があります。

したがって、詐欺証明はOptimistic Rollupのセキュリティにおいて重要な役割を果たしており、完全な詐欺証明メカニズムを欠いたシステムはユーザーの資産にリスクをもたらします。

本文では、さまざまなオプティミスティックロールアップが直面するリスクを評価し、それらの詐欺証明メカニズムの実装と利点と欠点について検討します。

1.4. ステップ2への進展："補助輪の取り外し"

詐欺証明システムは、Optimistic Rollupの「フェーズ2」プロセスの実現において重要な役割を果たしています。Vitalikが提案したフェーズフレームワークは、現在L2Beatによって運営され、Rollupのセキュリティレベルを評価するために使用されています。

ETHフレームワークでは、この段階的なフレームワークは通常、自転車の乗り方に例えられます。段階0のRollupは最も信頼性の高い仮定に依存し、補助輪付きの三輪車に例えられます。一方、完全にETHのセキュリティを引き継いだ段階2のRollupは、補助輪を外した自転車に例えられます。

以下は段階0から段階2までの各段階の詳細な基準です:

前述のように、オプティミスティックロールアップを段階1または段階2に達するためには、適切な詐欺証明および挑戦メカニズムの実装が重要です。これらの基準を考慮すると、段階2の要件を満たす詐欺証明システムは以下の特徴を持つ必要があります。

• システムは正常に動作し、既知の欠陥はなく、「1-of-N」の特性を備えています。
• これは許可されていないシステムであり、誰でも証明を提出することができます。
• もし証明システムに欠陥があると証明できるはずです。

この記事の後半では、さまざまなプロトコルがこれらの機能をどのように実装しようとしているかを探ります。

2. 詐欺の証明 - 概念と誤解

2.1. 詐欺証明はどのように実施されますか？

詐欺証明は、オンチェーンで検証可能な証拠を提供し、提出されたステートルートが正しくないことを示しています。つまり、特定のL2の状態遷移関数が正しく実行されていないことを意味しています。簡単な方法は、前回確認されたステートルートから開始し、すべてのL2ブロックを実行して現在のステートルートまで証明することです。しかし、この方法はコストが高く、時間がかかります。

したがって、有効な詐欺証明を生成するには、特定の不正な状態遷移に縮小してから、その部分に対して証明を生成する必要があります。ほとんどの詐欺証明プロトコルは、この方法に従います。

詐欺証明と质疑プロトコルは通常、以下の手順を含みます：

1. バリデータ (proposer) は、L2 状態のルートを含むアウトプット (または宣言) を定期的に ETH に送信します。
2. もしバリデータ（质疑者）がその出力に同意しない場合、彼らは異議を申し立てます。
3. 提出者と質疑者は、二分法または解剖法と呼ばれるプロセスを通じて、意見の相違点を特定し、それを命令レベルまたはブロックレベル（ZK Rollup）まで詳細化します。
4. 質疑者はオンチェーンに詐欺証明を提出し、不正確な部分を証明します。通常、ArbitrumやOptimismなどのプロトコルは、疑わしい命令をオンチェーンで実行して検証します。
5. もし詐欺証明が検証された場合、不正確な出力は削除または置換されます。疑義プロトコルに基づき、申し立て人は罰せられ、疑義を呈した者は報酬を受け取ります。

2.2. よくある誤解:不正の証明とチャレンジはチェーンをロールバックしません

欺诈证明や疑問が生じた場合でも、チェーンはロールバックされませんのでご注意ください。欺诈証明は、「ブリッジ契約から資金が悪意を持って引き出されない」ことを保証しますが、不正な状態変更のロールバックは関与しません。

ロールバックしない主な理由は、必要がないからです。 Rollupで不正な状態遷移が発生した場合、核心的な問題は悪意のある行為者がユーザーの資金をブリッジから盗む可能性があることです。これを防ぐためには、L1に提出される状態のルートが正しいことを確認するだけです。このプロセスはチェーンのロールバックとは関係ありません。悪意のある状態のルートの最終的な確認を防ぐだけで、詐欺証明と疑問の仕組みは十分です。

また、もしステートルートの提案者とL2チェーンブロックの生成者が異なるエンティティである場合、ロールバックメカニズムは必要ありません。

したがって、疑問が解決されても、L2チェーンはロールバックされません。L1に提出されたステートルート（出力またはステートメント）のみが削除または置換されます。詐欺証明と疑問のメカニズムが正常に機能していれば、ユーザーのブリッジ資金の安全は保証されます。

2.3. 現実世界の事件:2024年4月のクロマの尋問

実際の疑問のケースを通じて、ロールバックされない全体のRollupチェーンは、出力ルートのみが置換または削除されることがわかります。現時点では、唯一既知の成功した疑問のケースは、2024年4月のKromaで発生しました。これはOP Stackに基づくハイブリッドRollupで、ZKフォールトプルーフを使用しています。

KromaはOPスタックベースのRollupで、独自のZK故障証明とパーミッションレスなバリデータシステムを持っています。2024年4月1日、KromaソータのL1ソースに問題が発生し、ソータが誤ったブロックを生成しました。さらに、この状況を見たバリデータが誤った出力ルートを提出しました。出力ルートの提出後間もなく、12人の異議申し立て者がその出力に異議を唱えました。

その中の1人の疑問者は、proveFault関数を呼び出して、誤った出力を削除しました。

質問者はproveFault関数の実行に成功しました | 源：etherscan

これはETH坊 Rollup メインネット歴史上初めての成功した異議申し立てのケースです。これは2021年5月に最初のOptimistic Rollup（Arbitrum）が導入されてから約3年後に、メインネット環境での故障証明の成功した最初の異議申し立てのケースです。この異議申し立てに関する詳細な概要は、Kromaが執筆した記事を参照してください。このケースでは、Kromaチェーンはロールバックされず、単に正しくない出力ルートが削除されました。

免責事項:詐欺の証明または失敗の証明?

詐欺証明は故障証明とも呼ばれます。特にOptimismとOP Stackチェーンでは、"故障証明"という用語が使用されていますが、Arbitrum、Cartesi、L2Beatなどのプロジェクトでは"詐欺証明"という用語が使用されています。

上記のKromaにおける疑問のある事例を考慮すると、疑問は悪意的な引き出し操作ではなく「誤り」に由来することが推測されます。上記の事例では、主な原因はKromaバリデータが観察したL1クライアントの異常です。言い換えると、疑問は場合によってはバリデータの誤りや不適切なパッチによって引き起こされることがあり、この場合、「故障証明」という用語を使用することが適切かもしれません。

しかし、その目的をよりよく反映する用語は「詐欺証明」です。これまでに導入されたすべてのメカニズムおよび将来導入されるメカニズムは、悪意のある出力を通じてブリッジ内の資金を盗もうとする「詐欺行為」を検証するためのものです。

重要なのは、詐欺を防ぐことが目的であるものの、実際には誤解から生じる可能性があるということです。本文では、生態系でより広く使用されている「詐欺証明」という用語を使用します。

3. ハッカー攻撃！ - 利用詐欺証明メカニズム

3.1. デザイン経済紛争プロトコル

各Optimistic Rollupは、ユーザーの資金を保護するために独自の詐欺証明および疑問のメカニズムを実装しています。これらのメカニズムの共通の目標は、「少なくとも1人の正直な参加者がいる限り、プロトコルを安全に保つことができる」ということです。詐欺証明は、予約された状態遷移関数が正しく実行されたことを示す証明であり、検証プロセスを経て、最終的には正直な参加者が勝利する結果が得られます。

しかしながら、これは常に真実ではありません。実際、正直な参加者が存在していても、プロトコルが危険に陥る可能性があります。たとえば、詐欺証明が非常に複雑であり、予期しない欠陥が生じる場合があります。また、悪意のある参加者は、インセンティブメカニズムがアラインされていないため、経済的な優位性を正直な参加者よりも得ることができ、ユーザーが大幅にレイテンシーを経験したり、資金が盗まれたりする可能性があります。

そのため、詐欺証明と疑問のメカニズムを設計することは非常に困難なタスクです。特に、第2段階のロールアップになるためには、疑問のメカニズムは完璧であり、あらゆる攻撃ベクトルや欠陥に対処するための対策が必要です。

言い換えると、詐欺証明や疑問のメカニズムは、各攻撃ベクトルにどのように対処するか考慮する必要があります。各攻撃ベクトルを理解しなければ、なぜプロトコルがこのように設計される必要があるかを理解することはできません。01928374656574839201

したがって、このセクションでは、まず以下の攻撃ベクトルについて研究し、各プロトコルがこれらの攻撃にどのように対処するかを探究します：

• 争議のゲーム内の欠陥による攻撃;
• レイテンシー攻撃、ユーザーの引き出し時間を7日を超えるように延長する；
• シビル攻撃は誠実な参加者の資金とリソースを消費します；
• L1バリデータの審査によって引き起こされた攻撃；
• 不正防止仮想マシンの脆弱性を悪用する攻撃。

注意：以下の攻撃ベクトルはすべて公に知られており、いかなるメインネットのセキュリティにも影響を与えません。

次のセクションでは、次のような各プロトコルとその特徴について分析します:

3.2. 攻撃ベクトル #1: 経済論争のゲームを悪用する

詐欺証明メカニズムを実装したほとんどの楽観的ロールアップは、二分法を使用して最初の不一致点を見つけることが要求されます。プロトコルは参加者が誠実に行動するように促すインセンティブを提供する必要があります。これは非常に重要です。

実現する最も簡単な方法の1つは、参加者に行動を起こす際に一定額の資金を担保（証拠金）させることであり、彼らが悪意を持って行動すると見なされる場合、スラッシング証拠金が科される可能性があります。

博弈論の観点から見ると、プロトコルは、悪意のある参加者が攻撃に費やす資金が正直な参加者が防御に費やす資金を上回るようにする必要があります。しかし、これは非常に実現困難です。

ここでの鍵となる原因は、ゲームの環境では、疑問が解消されるまで、誰が悪意のある参加者であるかを事前に知ることはできないという点にあります。言い換えれば、出力を提出する主張者は悪意を持っている可能性があり、出力を疑問視する質問者も悪意を持っている可能性があります。したがって、プロトコルはどちらの側も悪意を持っている可能性があるという前提のもとで設計されなければなりません。さらに、様々な攻撃ベクトルが存在する可能性があるため、プロトコルの設計は非常に複雑になります。

各プロトコルは異なるメカニズムを採用しているため、各手法に対応する攻撃ベクトルと攻撃者のインセンティブモデルを定義する必要があります。また、これらのモデルが組み合わさっても安全性が保たれるように、経済的なセキュリティモデルを設計する必要があります。

この話題はまだ議論中です。このセクションでは、普遍的に発生する可能性のある攻撃ベクトルと、これらのシナリオでの参加者のインセンティブについて分析します。さらに、各プロトコルがどのようにこれらの攻撃に対処し、どの程度これらのインセンティブを制限しているかについても検討します。

3.2.1. 攻撃ベクトル #1-1：レイテンシー攻撃

レイテンシー攻撃は、悪意のある実体がRollup資金を盗むことを意図していないが、L1上の確認を妨げたり、レイテンシーを発生させる攻撃です。このような攻撃は、ほとんどの現行のOptimistic Rollupで発生する可能性があり、引き出しに追加の遅延をもたらし、ユーザーがL1からの引き出しに1週間以上かかる可能性があります。

これはL1バリデータの審査による攻撃とはやや異なりますが、後者は後で議論されます。審査はETHブロックチェーン上の正直な参加者が何の行動も起こせないようにし、悪意のある状態ルートが最終的に確認されることを可能にします。一方、レイテンシー攻撃は正直な参加者が積極的に参加している場合でも、レイテンシー状態ルートが最終的に確認される可能性があります。この場合、ユーザーの引き出しはレイテンシーによって可能性があり、さらに攻撃者の資金が防御者よりも多い場合、悪意のある状態ルートが最終的に確認され、ユーザーの資金が盗まれる可能性があります。

レイテンシー攻撃を防ぐ最も簡単な方法の1つは、システムの参加者に一定額の資金または証拠金を担保することを求めることです。彼らがレイテンシーを引き起こしたと見なされた場合、その証拠金をスラッシングすることができます。

ただし、考慮すべき要素がいくつかあります。 攻撃者が資金を没収されることを恐れず、それでも遅延攻撃を実行しようとしたらどうなるでしょうか?

この攻撃ベクトルは非常に厄介です。それがなぜArbitrumの詐欺証明システムが現在許可された構造で実行されている理由です。

Arbitrum OneとArbitrum Classicに適用される詐欺証明メカニズムは、フォークモデルを採用しています。参加者が不正な主張を疑問視するだけでなく、各参加者が正しいと考える主張を提出し、一定額の資金を添付してこれを「チェーンのフォーク」とみなします。主張は、チェーンの状態上のチェックポイントとも見なすことができます。

Arbitrumの分岐モデル

Arbitrum Classicでは、参加者は正しいと考える声明とチェーンブランチを提出し、疑問を投げかけて不正確なチェーンブランチを逐次削除し、最終的に正しい声明を確認します。01928374656574839201

ただし、一度の疑問が誰が正しいかを確定することはできません。 2人の悪意のある参加者が誤った方法で二分法を行い、無関係な点を不一致点と定義して正しい主張を排除する可能性があります。 したがって、Arbitrum は、特定の主張に関与者が資金を担保していないまで、疑問が持続することを確認し、少なくとも1人の誠実な参加者がいる場合に疑問が成功裏に解決できるようにします。

これはレイテンシー攻撃に悪用される可能性があります。正直な参加者とN-1人の悪意のある攻撃者が正しい主張に資金を担保し、1人の攻撃者が間違った主張に資金を担保していると仮定しましょう。攻撃者が常に正直な参加者よりも早くトランザクションを提出できる場合、彼らは最初に疑問を提起することができます。最悪の場合、彼らが誤って2分割して、一致している部分ではなく一致していない部分を分割すると、彼らは詐欺証明を提出することができます。もちろん、これにより正しい主張に資金を担保している側が失敗する可能性があります。

各クエリには最大 7 日かかる場合があるため、攻撃者はプロトコルの遅延を 7 * (N-1) 日に拡張できます。

アービトラムクラシックのディレイドアタック | 出典:[L2Beat Medium] (https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

このメカニズムの問題は、レイテンシー攻撃のコストがプロトコルのレイテンシー時間と線形に上昇することにあります。攻撃者がこの攻撃が利益をもたらすと気づいた場合、彼らはプロトコルのレイテンシー時間を可能な限り延長したいと考えるでしょう。そして総レイテンシー時間は攻撃者の資金総額に比例し、これによりユーザーの引き出しのレイテンシー時間が非常に長くなる可能性があります。

要するに、レイテンシー攻撃を効果的に防止するためには、詐欺証明プロトコルを設計する必要があります。最大レイテンシー時間を一定の範囲内に制限する機構、またはレイテンシーの実行コストが時間の経過とともに指数的に上昇する仕組みを採用することで、攻撃のコストが攻撃の報酬よりも高くなるようにする必要があります。

3.2.2. 攻撃ベクトル #1-2: Sybil 攻撃（リソースの枯渇攻撃）

別の攻撃ベクトルは、シビル攻撃（リソース枯渇攻撃、クジラ攻撃）です。攻撃者の資金または計算リソースが防御者を上回る場合、このような状況が発生します。攻撃者は、正しくない出力ルートを継続的に送信したり、意味のないチャレンジを作成したりして、防御者の資金または計算リソースを枯渇させることができます。ある時点で、防御者は資金または空いている計算リソースを枯渇させ、防御できなくなり、攻撃者は最終的に正しくない出力ルートを確定し、資金を窃取します。

一般に、上記の攻撃ベクトルは、次の 2 つの方法でパーミッションレス システムで発生する可能性があります。

1. 継続的に誤った出力を提出します。 攻撃者Bobの資金が正直な参加者（防衛者）Alice、Charlie、およびDavidの合計を超えると仮定します。 この状況では、Bobは継続して誤った出力ルートを提出します。 正直な参加者Alice、Charlie、およびDavidは、ガス料金とデポジットで対処し、ある閾値を下回ると、正直な参加者の資金がBobより先に枯渇します。 この時点で、Bobは別の誤った出力を提出し、正直な参加者には残りの資金がなくなるため、この出力は最終的に確定されて疑問視されることはありません。 このようにして、Bobは楽観的ロールアップから資金を盗むことができます。
2. 正直な参加者に複数の質問を提出する代わりに、悪意のある参加者は複数の質問を提出することで正直な参加者を攻撃することができます。同様に、攻撃は、正直な参加者がガス費用と担保金に使用するすべての資金を使い果たすまで続き、その後、悪意のある攻撃者が不正な出力を提出し、ブリッジからユーザーの資金を盗むまで続くでしょう。

このような攻撃を防ぐために、防御者は攻撃者に対して十分な優位性を持たなければなりません。すべての場合において、防御者は攻撃者よりも十分な優位性を持たなければなりません。これを実現する方法の一つは、デポジットを慎重に設計することです。Sybil攻撃は参加者ごとに利用可能な資金総額に関連しているため、デポジットが適切に設定されていれば、「攻撃者の総資金が防御者の総資金のN倍を超えない場合、システムは安全である」と確定できるはずです。

Sybil攻撃を防止するための別の既知の方法は、Sybilに対抗するプロトコルを実装することです。次の章では、Cartesi Daveについてさらに説明します。

それでは、各プロトコルがこれらのレイテンシーとシビル攻撃に対処するための設計をどのように行っているかを見てみましょう。

3.3. ソリューション＃1：経済的に健全な論争ゲーム

1) アービトラム BoLD

BoLDはArbitrum Classicの分散型モデルに基づいて、レイテンシー攻撃の脆弱性を防ぐために以下の3つの要素を導入しています:

• すべての疑問へのすべてのメカニズム。BoLDでは、疑問は対になって行われるのではなく、参加者は同意したブランチに資金を担保することができるすべての疑問へのすべてのシステムを並行して行います。これにより、以前の1対1の疑問によって生じるレイテンシー攻撃ベクトルを防ぎ、同じ紛争に複数の独立した疑問が発生しないようにします。
• 正しいステート計算に基づく証明により、悪意のある2分を防止します（履歴的なコミットメント）。Arbitrum Classicにおける問題は、悪意のある参加者が誤った方法で2分を行い、故意にレイテンシーを引き起こし、無論議論の余地のない部分を議論の余地のある部分としてマークできることです。そのため、BoLDは、状態ルートが正しく計算された2分プロセス中に状態ルートが正しく計算されたことを検証する証明を提出し、悪意のある2分が発生しないようにします。

BoLDでは、参加者は2分のプロセスで証明と状態のルートを提出する必要があります。この証明は、現在の状態ルートが以前に提出された状態ルートに基づいて正しく計算されたかどうかを検証します。悪意のある参加者が以前に提出された状態ルートとは関係のない任意のルートを2分のプロセス中に提出しようとすると、証明検証に失敗し、2分取引が失敗します。これにより、各声明が一種類の2分のみを行うことが確実になります。

したがって、攻撃者がBoLDで誠実な声明を複数回二分する場合、彼らは複数の声明を提出する必要があります。

しかし、この証明を生成するには、バリデータにかなりの計算リソースが必要です。内部的には、この証明を生成するために、すべてのステートを二分法でハッシュ化する必要があります。通常、Arbitrumでは約270個のハッシュ（約1.18 x 10²¹）が必要です。この問題を解決するために、BoLDは三つのレベルにクエリを分割し、計算する必要のあるハッシュの数を226個（約6.71 x 10⁷）に減らしました。

（この図は、合計269の命令があると仮定していますが、実際のデータは異なる場合があります）

• ポジションをステークする時間を制限するためのチェスクロックメカニズムを介して。

Arbitrum Classicでは、質問への継続時間に制限がなく、悪意のある参加者は資金が十分であれば無期限でレイテンシープロトコルを行うことができました。BoLDはチェスクロックメカニズムを導入し、質問の継続時間を効果的に制限しました。

2つの異なる主張を提出した2人の参加者がいると仮定します。各参加者はタイマー（チェスクロック）を持っており、時間は6.4日です。参加者が分割または証明を提出する番が来た場合、タイマーがカウントダウンを開始し、参加者がタスクを完了した後に停止します。

各参加者は6.4日間の時間を持っているため、個々の参加者がプロセスの最大遅延時間は6.4日です。したがって、BoLDでは、質問の最長継続時間は12.8日です（一部の場合では、セキュリティ委員会が介入すると、さらに2日増えます）。

これらのメカニズムにより、Arbitrum BoLDは疑問によるレイテンシーを効果的に制限しています。疑問の最大持続時間は2週間であり、ユーザーが経験する可能性のある追加の最大レイテンシーは約1週間です。

然而、これはレイテンシー攻撃に利用される可能性があります。悪意のある参加者は疑いを持ち、L1 バリデータと共謀し、Arbitrum 上の誠実なバリデータを審査することで、Arbitrum ユーザーの引き出しのレイテンシーを1週間にわたって延ばすことができます。このような状況では、この期間中に引き出しを要求するユーザーは資金がロックされるため、機会費用に直面する可能性があります。この攻撃は直接資金を得るものではありませんが、ユーザーに機会費用を与えるため、防止する必要があります。Arbitrum BoLD は、疑いを持つために必要な保証金を十分に高く設定することで、この問題に対処しており、このような攻撃を抑止しています。

Arbitrumは、BoLD Economic File(https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/Economics.pdf)でこの金額を計算します。 プロトコルの遅延の主な理由は、L1バリデーターのレビューです。 遅延攻撃の場合、シナリオは次のように展開します。

1. 攻撃者は、Arbitrumで既存のステートメントNを確認する前に、それとは異なるステートメントN'を提出します。
2. 防御者は2分トランザクションを送信しようとしましたが、L1 バリデータが防御者のクエリトランザクションを審査しているため、この操作は失敗しました。
3. BoLDの仮定審査が7日間を超えることはできないため、これによりNの最終確認が最大1週間遅れる可能性があります。

攻撃者の利益は、出力リクエストを疑問視し、ユーザーが引き出しを要求する機会コストから生じます。最悪の場合、Arbitrum内のすべての資金が1つの出力で引き出されるため、ユーザーの負担する機会費用は次のように計算されます。Arbitrum OneのTVLが154億ドルで、APYが5%であると仮定します。

機会費用 = 15,400,000 x (1.051/52 - 1) = $14,722,400

不正確な声明の提出は高い機会費用につながる可能性があるため、BoLDでの声明の提出者は同程度の保証金を提出するよう求められています。現在、BoLDでの声明の提出には3600 ETH（約940万米ドル相当）の保証金が設定されています。

このようにすることで、攻撃者がレイテンシーを利用してシステムに重大な損害を与えることを防ぐことができます。攻撃者は質問に答えることで担保金を失うため、最大で1470万ドルの機会費用を引き起こすことができますが、約940万ドルの資金を失うことになります。そのため、BoLDは、担保金が最悪の場合の機会費用に相当することを要求することで、レイテンシー攻撃を抑制しています。

しかし、3600 ETH の担保金は単にレイテンシー攻撃のために設定されたものではありません。Sybil攻撃を防ぐために、Arbitrum BoLD は、攻撃者の総資金が防御者の総資金の6.5倍になる前にシステムが安全であることを確認することができます。これが3600 ETHの担保金の決定根拠です。

Sybil攻撃の観点から、Arbitrum BoLDでは次の攻撃シナリオが発生する可能性があります。BoLDの疑問システムは3つのレベルで構成されており、ユーザーは正しいと考える主張を提出するために資金をロックしなければなりません。

正直な参加者であるアリスが、X ETHの有効な声明を提出したと仮定します。悪意のある参加者であるボブは、3600 ETHを所有しているため、複数の悪意のある声明を作成することができます。この場合、アリスはBobのそれぞれの声明に対して、Y ETHを低レベルでロックする必要があります。

Arbitrumの分岐モデルでは、資金のロックは、ジェネシスからステートメントまでのチェーンの状態に同意することを意味します。この機能により、参加者は抵当に入れた資金をステートメントAからサブステートメントA'およびA''に移動することができます。したがって、アリスは最初に抵当に入れたXETHをベースレイヤーに移動し、ボブの各悪意のステートメントに対してYETHをロックします。

もしBobの資金が明らかにAliceよりも多い場合、何が起こるでしょうか？ Bobは数多くの悪意のある主張を生成することができ、Aliceの資金が尽きてロックを続けることができなくなるまで続けることができます。その瞬間、Aliceは二分することができなくなり、Bobが誤った主張を確認することを許可します。

根本的に、この問題は、ゲームにおいて防御側が攻撃側よりも優位であるべきである程度に帰結します。

Arbitrumは、この指標をリソース比と呼んでいます。これは、正直な参加者が悪意のある参加者に対してどれだけ優位に立っているかを示しています。この比率は、参加者が支払わなければならないガス料金（G）と担保額（S）の比率で表されます。以下に示します：

BoLDの質問システムは3つのレベルに分かれており、それぞれのレベルでこのリソース比率を維持することにより、防御者が常に攻撃者よりも優位性をN倍持つことを保証しています。Arbitrumはこのリソース比率に基づいて、トップレベルに必要な担保金額を計算し、チャートを作成しています。

（トップレベルのディスピュート担保コストとArbitrum BoLDのリソース比率 | 出典：Desmos)

この図によると、リソース比率が100倍になると、トップ層の必要な担保金は100万ETH（約40兆ドル）を超えます。より高いリソース比率はSybil攻撃を防止するためにより安全なシステムを提供しますが、担保金は非常に高くなり、ほとんどの人がシステムに参加できなくなります。このため、中央集権的なシステムと区別がなくなります。バリデータのみが声明を提出するシステムと同様です。

そのため、BoLDでは、リソース比率を6.5倍に設定して、トップレベルの担保金を3600 ETH、1次および2次の担保金をそれぞれ555 ETHおよび79 ETHに設定しています。

BoLDは、計算リソースの比率を計算し、担保金額を設定することで、防御者が攻撃者に対して6.5倍の優位性を持つことを保証し、シビル攻撃を防止します。

2)デカルト・デイブ

CartesiのDaveは2022年12月に、BoLDの最初のホワイトペーパーよりも早く、『非許可審査トーナメント』という論文で初めて提案されました。それは、正直な参加者の計算リソースと資金が攻撃者に対して優位を保つことを目指しています。Daveの構造はBoLDに類似しており、次の2つの主要な特徴を持っています：

正しい状態の計算による証明（ヒストリカルコミットメント）により、悪意のある分割を防止します。

BoLDと同様に、Daveは参加者に証明を生成するように要求し、彼らが正しく計算を行っていることを示し、悪意のある二分を防ぐためです。したがって、Daveのクエスチョンシステムも複数のレベルに分かれ、バリデータのリソースを節約します。

大会の構造では、一対一の順序での疑問の仕組みが採用されています。

デイブの質問は一度に行われるのではなく、トーナメント形式で行われます。下の図のように。

図には、悪意のある攻撃者がネットワークに対して7つの誤った主張を提出し、疑問がどのように行われるかが示されています。正しい主張（緑色で表示）をサポートする誠実な参加者は、過去の約束の性質により、チームとして集まっています。ダウェイブでは、彼らはトーナメント形式で組織され、図に示されているように1対1の疑問を行います。同じ段階の疑問は並行して行われ、1週間後に疑問が完了すると、勝者は次のステージに進みます。図の中で、誠実な参加者のチームはトーナメントを勝ち取るために3ラウンドの疑問を経験する必要があります。

この機能は、Sybil攻撃を防止するために非常に効果的です。まず第一に、攻撃者はSybil攻撃を実行するために複数の主張を作成する必要がありますが、それぞれの主張は攻撃者の計算リソースと財源をかなり消費します。

Cartesiの論文によれば、防御者は常に攻撃者に対して指数的な優位を保つことが証明されています。つまり、デイブは対数的なリソースを使ってシビル攻撃から守ることができることを保証しています。これにより、デイブでのシビル攻撃は非常に困難になりますので、デイブの担保額はBoLDよりもはるかに低い最低1ETHに設定されています。

しかし、Daveはレイテンシー攻撃の影響を受けやすいです。トーナメントの各段階では、1つの疑問の解決に1週間の時間がかかるため、悪意のある主張が増えれば増えるほど、プロトコルのレイテンシーが長くなります。Daveが完全に1つの疑問を解決するために必要な時間は、以下の式で表されます：

Td = 7 x log2(1 + NA) (日)

ここで、NAN_ANA​は意図的な声明の数を表します。しかし、Daveの疑問は複数のレベルで構成されることがあり、有効なヒストリカルコミットメントを生成することができます。ここで、意図的な参加者は各クエリレベルでNAN_ANA​個の意図的な声明を生成できます。これにより、総レイテンシー時間が増加します：

Td = 7 x [log2(1 + NA)]L (日)

LLLは各疑問の階層数を表します。上図のように、7つの悪意のある宣言があり、L=2の場合、疑問を完全に解決するには最大9週間かかることがあり、ユーザーは追加の2ヶ月の出金レイテンシーを経験することになります。階層数や悪意のある宣言の数が増えると、レイテンシーは数ヶ月に延びる可能性があります。

Cartesiは、この問題を解決するためにゼロ知識証明（ZK）を活用することを目指しています。詳細な議論は、第4節の「実現可能な改善」で行われます。

3)楽観主義フォールトプルーフ(OPFP)

OPFPは許可されていない質問プロトコルであり、現在はOPメインネット上で利用されており、以下の特徴があります:

• すべての並列疑問機構に対するゲームツリーの使用

OPFPは誰でもいつでも出力（ルートステートメント）を提出できるようにします。提出された出力に同意しないバリデータは、二分プロセスを開始してその出力に異議を申し立てることができます。

OPFPゲームツリーのアーキテクチャと二分法プロセス | ソース: [Optimism Files] (https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html)

二分過程は、上図に示すゲーム木で並行して行われます。葉はL2の状態を表し、木の各ノードはL2の1つの状態に対応し、最も右の葉は最新のL2の状態を表します。たとえば、ノード1での主張の提出とノード31での状態の提出は同等です。

この構造により、二分を表すことができます。たとえば、あるバリデータがルートの宣言に同意しない場合（ノード1）、彼らはノード2に宣言を提出し、ノード2はノード16とノード31の中間にあるため、ノード23に対応します。ノード1の提出者は次にノード23のL2ステータスを確認し、同意すればノード6（ノード27）を提出し、同意しない場合はノード4（ノード19）を提出し、このプロセスを分岐点が見つかるまで続けます。

複数の二分方向がある博弈においても、それらは同時に進行することができ、出力提出者だけでなく、誰でも二分プロセスに参加できます。

OPFPゲームツリーの完全なアーキテクチャ | ソース: [Optimism Files] (https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html)

OPFPで使用されるゲームツリーは、ネスト構造であり、上位ツリーはブロックレベルのバイナリ分割を処理し、下位のサブツリーは命令レベルのバイナリ分割を処理します。

BoLDやDaveとは異なり、OPFPは正しいバイナリの強制実行を過去の約束に依存しません。なぜなら、このような約束を生成して提出するオフチェーン/オンチェーンのコストが高いためです。

• モジュール化されたカスタマイズ可能な対立ゲーム 現在、OPメインネットは許可された/許可されていない2種類の争議ゲームのみを提供しています。Optimismは、さまざまなタイプの争議ゲームを最終的に導入することを目指しており、この目標をサポートするための最小限のインターフェースを実現しています。指定された関数名とパラメータに従って、カスタムの争議ゲームを作成することができます。

• チェスクロックで疑問の時間を制限する

OPFP中、疑義が発生した場合、申立人と疑義申し立て人は共に二分法に使用される時を割り当てられます。声明が行われるたびに、時計が相手を計り始めます。Optimismはこれを「祖父の時計を継承する」と呼んでいます。

興味深いのは、各参加者が7日間ではなく、3.5日間の許容時間を持っていることです。つまり、誰も出力に疑問を投げかけなければ、その出力は3.5日以内に最終的に確定されます。

ただし、これにより即座に引き出すことはできません。最終的な出力が確定した後、OPFPには3.5日間の保護期間があり、この期間中にセキュリティ委員会が介入し、必要に応じて不正確な出力を無効にすることができます。

「ハッピーパス」におけるユーザーの退会手続き | 出典: [OP Labs Blog] (https://blog.oplabs.co/unpacking-progress-in-baseline-decentralization/)

これらの機構に基づいて、OPFP および他の楽観的ロールアップと同様に、ユーザーは少なくとも7日後に引き出しを行うことができることを保証しています。ただし、疑義が生じた場合、ユーザーは出力を引き出すまでに7日を超えることがあります。OPFPの時間制限モデルは、各参加者が二分プロセスに費やすことができる時間を制限していますが、疑義解決までの総時間は厳格に制限されていません。

これは1つの問題を引き起こします：もしOPFPで疑問が生じた場合、ユーザーの引き出しはレイテンシーが1週間以上かかる可能性があり、BoLDの場合と同様の状況になるでしょうか？答えは「はい」です。BoLDやDaveとは異なり、Optimismはユーザーに疑問に対処するための選択肢を提供します。これはプロトコルの独自の特徴に基づいています。

OPFPは、「不正確な声明を提出した参加者は証拠金を失う」という前提の下で動作します。しかし、OPFPには「乗り物に乗る声明」と呼ばれる例外が存在し、この前提が破られる可能性があります。この状況は次のシーンで発生する可能性があります。

1. Aliceは正しい状態ルートの宣言を提出しました。
2. Bobは反証を提出し、一方でAliceは彼女の元の主張を守るために行動を起こしました。
3. ボブはほぼ時間切れ（3.5日）になるまで待ち、そして自分の主張を疑問視しました。

この時点で、アリスはボブの証拠金を返答し、請求する必要がありますが、彼女はボブの時計に残っている時間を継承しています。これでは彼女が彼の主張に反論するのに十分ではないかもしれません。そのため、ボブは「乗りました声明」を提出することで、彼の証拠金を失うことを回避することができるかもしれません。

楽観主義のフォルトプルーフにおけるフリーライダーの声明 | 源：L2Beat

これは疑問を解決するのに影響を与えることはありませんが、「スラッシング証拠金を提出しないで正しくない声明を提出した」という状況を表していることは確かです。インセンティブの観点からは、このような状況は避けるべきです。

したがって、提案者または質問者の残り時間が3時間未満の場合、OPFPは時計を3時間にリセットすることでこの問題を解決します。これにより、乗り物に乗る声明に対して反論する十分な時間が確保されます。しかし、次の2つの期間で3時間以上行動が取られない場合、質問は終了します。

私たちは、レイテンシー攻撃を行うためにこのメカニズムが使用されるシナリオを想像することができます。正直な参加者であるアリスが正しい出力を提出したとします。アリスが提出した時点から、質問者の時計が開始されます。悪意のある参加者であるボブは、質問者の時計が期限切れの1秒前に不正な出力を提出します。この時点で、OPFPのルールにより、ボブの時間が3時間延長されます。アリスは応答し、ボブは毎回のバイナリ提供に対して追加の3時間を利用し続けます。

これはレイテンシーに疑問を抱く可能性があります。Bobは最大の二分回数を3.5日+3時間×最大ゲーム深度で計算して、最長で8日間のプロセスレイテンシーを持つことができます。OPFPのMAX_GAME_DEPTHは73であり、これはBobが最長で3.5日+3時間×36=8日間のプロセスレイテンシーを持つことを意味します。もしAliceも同様の対策をとってレイテンシーを疑問視する場合、二分プロセスには16日間が必要になるかもしれません。

これは、ユーザーが16日以内に出金できないことを意味しますか? 実際には、楽観主義の撤退論理がこれを支持できないため、これは当てはまりません。 出金が特定のL2ブロックに含まれていることを証明する必要があるArbitrumとは異なり、OP Stackは、出金リクエストがL2のL2ToL1MessagePasserコントラクトに記録されるプルーフ・オブ・ストレージ・メカニズムを使用します。 つまり、特定のアウトプットが長時間疑問視された場合でも、ユーザーは次のアウトプットが完了するのを待ち、そのアウトプットに含まれるコントラクトストレージルートに基づいて引き出しを行うことができます。 したがって、要求した引き出しが疑問視された場合でも、ユーザーは次の出力を使用できるため、長いレイテンシーを経る必要はありません。

しかし、これはユーザーが迅速に行動した場合にのみ成立します。ほとんどの場合、ユーザーは数日のレイテンシーを経験する可能性があります。これは、OPスタックの引き出し手順に起因するもので、主に次の3つのステップが含まれます:

1. L2で出金を開始します(initiateWithdrawal)。
2. L1での引き出しトランザクションの証明（proveWithdrawalTransaction）には、引き出しの出力も含まれます。
3. 1週間のプルーフ満期遅延を待ってから、最終的に引き出しを完了します(finalizeWithdrawalTransaction)。

ポイントは、出金の証明から最終的な出金完了まで、ユーザーは1週間待たなければならないことです。もしAliceが出力Bでの出金を証明し、疑問が生じた場合、彼女は出力Cに対して別の証明を送信し、1週間後に出金を完了させることができます。この場合、Aliceは出力Bと出力Cの間のレイテンシーのみを経験することになります。

したがって、疑問を持たなかったり遅れて応答したユーザーは、最大9日間の追加の引き出し遅延を経験する可能性があります01928374656574839201

また、OPFPには追加のレイテンシー攻撃ベクトルが存在し、すべてのアウトプットに対して連続的なステークが必要です。この状況では、次のアウトプットで証明することでレイテンシーを回避することができず、結果としてプロトコル全体がレイテンシーによって影響を受けます。OPFPは、参加者に対して各二分レベルでの証拠金のステークを要求することでこれに対処しており、証拠金の金額は指数関数的に増加しています（下図参照）。

OPFP証拠金額 | ソース: [Optimism File] (https://specs.optimism.io/fault-proof/stage-one/bond-incentives.html)

言い換えれば、攻撃者はOPFP内でレイテンシーに疑いを持つ解決策に時間をかけるほど、必要な証拠金コストが高くなります。証拠金要件が指数関数的に上昇するため、時間とともにレイテンシー攻撃を行う動機が減少します。また、OPFP内のアウトプットはいつでも提出できるため、攻撃者はレイテンシー攻撃に必要なリソースを見積もるのが難しいです。最初の証拠金は0.08 ETHに設定されていますが、完全な疑いの場合、合計で約700 ETHを提出する必要があります。

要するに、OPFP は一度の疑いの場合にレイテンシーの長さをユーザーの決定に任せ、連続的な疑いによるレイテンシー攻撃を緩和するために指数型証拠金要件を使用します。ただし、OPFP はSybil攻撃を受けやすいです。OPFPでは、攻撃者の資金が防御者よりも多い場合、Sybil攻撃が発生する可能性があります。

OPFPには以下のシビル攻撃ベクトルが存在する可能性があり、これらはすべてユーザーの資金の盗難につながる可能性があります。

1. 攻撃者が複数の疑問を作成し、防御者がすべての資金を証拠金とガス費用に使用するように誘導する。
2. 攻撃者は継続的に正しくない出力を提出し、防御者が応答を行うまで強制し、証拠金やGas費用の資金を使い果たすまで続けます。

OPFP中では、攻撃者と防御者が必要とする総証拠金額がほぼ同じであり、防御者が使用するリソース（たとえば、Gas料金やコンピューティングパワーなど）が攻撃者よりも著しく少ないため、これは可能です。

しかし、これは現在のOPメインネットのユーザー資金が危険にさらされていることを意味するものではありません。OPFPはまだ段階1にあり、セキュリティ委員会は不適切な結果を是正する権限を持っています。したがって、このような攻撃が発生しても、セキュリティ委員会は介入し、OPメインネットのブリッジ上のユーザー資金を保護することができます。

ただし、OPFPをフェーズ2に移行するためには、Optimismはメカニズムを変更する必要があり、防御者が攻撃者に対してより大きな優位性を持つようにする必要があります。Optimismはこの問題を解決するために、争議ゲームV2を準備しています。詳細はセクション4の「実現可能な改善」で説明されます。

4) Kroma ZK フォールトプルーフ (Kroma ZKFP)

Kroma は OP Stack ベースの L2 で、OPFP 導入前に、2023 年 9 月にメインネットで許可されていない ZK プルーフシステムを導入しました。Kroma ZKFP は OPFP に類似した特徴を持っていますが、ブロックレベルのプルーフを生成するために ZK を使用し、二分割ではなく分解を利用することで、挑戦プロセスでの相互作用の必要な回数を大幅に減らしました。Kroma ZKFP の主な特徴は以下の通りです：

• ZKと分割によって相互作用回数を減らします

Kroma ZKFPは、参加者が4回の対話の中で相違点を見つけることを許可します。疑問が発生すると、Kroma ZKFPは1,800のブロックでその疑問を処理し、以前の出力から現在の出力までをカバーします。バイナリサーチとは異なり、分割では提案者と疑問を持つ者が範囲をN分割します。プロセスは次のようになります:

各参加者が2つのトランザクションを提出した後、彼らは彼らの異議のあるブロックを特定し、異議を唱える者は、提案者の主張が間違っていることを示すZKフォールトプルーフを生成することができます。Kroma ZKFPでは、バイナリ分割のタイムアウトは1時間に設定され、ZKプルーフの生成タイムアウトは8時間です。

*インセンティブによるバリデータの分散化

BoLDとOPFPは質問者にインセンティブを提供しますが、出力提出者に具体的なインセンティブを提供しません。実際には、資金を引き出したい人は誰でも出力を提出し、バリデータになることができます。ただし、引き出しを希望するユーザーにとって、バリデータクライアントを自分で操作することは現実的ではありませんし、定期的に出力を提出して活動性を維持する必要があります。これはリソース集中型のタスクであるため、出力の提出とバリデータクライアントの運用にはガス料金が必要です。したがって、適切なインセンティブがなければ、バリデータとして参加する人はほとんどいない可能性があります。これは中央集権化や障害時の応答不足を引き起こす可能性があります。

そのため、KromaはOP Stackを変更し、オンチェーンで生成されたGas費用の半分を提出されたバリデータに割り当てます。さらに、KromaはTGEの後、この報酬メカニズムをネイティブトークンKROに移行し、DPoSのようなバリデータシステムを導入する計画です。これにより、一般のユーザーも自分自身のクライアントを実行せずに、チェーンの安全性と活性化に貢献することができます。

Kromaの証拠金額は現在0.2 ETHに設定されており、ZK証明の生成および二分のコストよりも高くなるように設定されています。この証拠金は将来のバリデータシステムでKROのステークに変換されます。

• 並行の1対1チャレンジシステム

インセンティブが公平かつ一貫して分配されるようにするために、Kroma は出力コミット間隔を 1 時間に固定し、事前に登録されたバリデータのプールから提案者としてバリデータをランダムに選択します。 これにより、過度な競争がガス料金の無駄につながるのを防ぎ、取引注文権を持つブロックビルダーが報酬を独占する状況を回避します。

このメカニズムにより、Kroma ZKFPは並列して1対1のクエスチョンシステムを実行します。ランダムに選択されたバリデータが出力を提出すると、誰でもクエスチョンを発行できますが、クエスチョンは出力提出者とクエスチョンの発行者の間でのみ行われます。複数のクエスチョンを同時に行うことができ、最初に有効なZKプルーフを提出したクエスチョナーがクエスチョンを獲得します。

厳密に設定されたタイムアウトは、レイテンシー攻撃を試みる悪意のある質疑者でも、すべての二分と証明の生成を10時間以内に完了する必要があります。さらに、質疑者は全ての操作を6日間で完了する必要があり（1日の保護期間を除く）、Kromaでは一般的なレイテンシー攻撃を行うことは不可能です。

しかし、攻撃者の資金が防御者を上回る場合、Kroma ZKFPはまだSybil攻撃に対して脆弱であり、OPFPと同様です。Kroma ZKFPでは、Sybil攻撃のシナリオは以下のようになる可能性があります：

• 攻撃者は、有効な出力に疑問を投げかけ続け、出力の提出者の資金が尽きるまで、その後攻撃者がZK証明を提出して疑問を解消する。

OPFPに似たKroma ZKFPは、成功した質問に続いて対応する出力を削除します。したがって、攻撃が発生した場合、この出力は削除され、ユーザーが資金を引き出すレイテンシーが1時間に達する可能性があります。攻撃が継続すると、すべての正直なバリデータが資金を使い果たし、誤った出力が最終的に確認され、攻撃者がユーザーの資金を盗むことができるようになります。

また、Kroma ZKFPはまだ段階0にあり、その証明システムはまだ完全ではありません。その理由は以下の通りです:

1. バイナリ分割の起点は、最終的に提出された出力に基づくものであり、最終的に確認された出力に基づいていません。

OPFPにおいて、二分法の起点は通常、約1週間前の最終確定出力です。しかし、Kroma ZKFPでは、起点は最後に提出された出力であり、約1時間前に提出されました。二分法は1,800ブロックで実行されます。

これにより、疑問者は以前の出力が疑問視されて削除された場合でも疑問を勝ち取る可能性があります。この場合、バイナリは疑問者が提出した以前の出力情報に基づいて行われ、疑問者がこれらの情報を悪意を持って操作すると、彼らは疑問を勝ち取ることができるかもしれません。

2. 各バリデータが正しいバッチデータに基づいて疑問を投げかけているかどうかは、検証されていません。

Kroma ZKFPがZK回路に欠陥がないことを確認しても、Kroma ZKFPはZK証明の生成が正しいバッチデータに基づいているかどうかを検証していません。したがって、一部の取引が除外されたり誤った取引がバッチに含まれていても、ZK証明は検証を通過する可能性があります。

したがって、誤ったデータに基づいたZKプルーフを使用して疑問を解消することができ、ユーザーの引き出し取引がバッチ処理から除外された場合、彼らの引き出しがレイテンシーされる可能性があります。

ただし、実際には、セキュリティ委員会が介入して、偽のチャレンジの結果を撤回したり、無効な出力を削除したりできるため、これらの攻撃ベクトルはKromaメインネットユーザーの資金に影響を与えません。 ただし、フェーズ 2 に到達するには、Kroma ZKFP はこれらの脆弱性に対する防御メカニズムを実装する必要があります。 Kroma は、これらの問題に対処するための改善を提案しており、セクション 4 「可能な改善点」で詳細に説明されています。

3.4 攻撃ベクトル #2：L1 审査

以前に述べたように、Rollup は Ethereum のセキュリティを継承しています。つまり、Ethereum のセキュリティが損なわれると、Rollup も影響を受けます。

イーサリアムの状況は、Rollupのセキュリティに2つの影響を与える可能性があります。

1. イーサリアムバリデーターによるロールアップの不正証明取引のレビュー **もしETHフィニティ検証者または構築者が共謀し、Optimistic Rollupで悪意のある出力ルートを提出し、同時に詐欺証明に関連するすべての取引を検討した場合、何が起こるのでしょうか？疑問が指定期間内に解決されない場合、出力は確認され、ユーザーの資金がリスクにさらされる可能性があります。 これは弱い検証と呼ばれます。Optimistic Rollupの場合、この検証が規定の時間（通常は7日間）を超えると、ユーザーの資金にリスクが生じる可能性があります。
2. イーサリアムは51％攻撃に遭い、すべての詐欺証明取引が審査されました **この状況には2つの可能な攻撃経路が関係しています：

• 首先、ある実体がETHブロック総ステークの2/3以上を取得することができると、彼らは自由にブロックを確認することができます。この場合、攻撃者は詐欺証明取引を検査したり、さらにそれらの取引を自由に生成したりすることができます。 *第二の方法には、ETHブロック全体の1/3を超えるステークを持つ参加者が行う"秘密"攻撃が関わります。これは、詐欺証明ベースのLayer2プロトコルに対する追跡不能な検閲攻撃"で説明されています。この場合、1/3のETHブロックステークを持つ攻撃者は、好ましくないブロックの確認を阻止できます。攻撃者が通常のブロックに投票し続け、一方で詐欺証明を含むブロックに対しては沈黙を守ると、悪意のある出力ルートを確認し、Optimistic Rollupから資金を盗む可能性があります。これが詐欺証明ベースのL2に対する追跡不能な検閲攻撃です。この攻撃は、2/3以上のステークを獲得し、すべてのETHブロックを制御するよりも検出が難しいです。

これらのレビューに基づく攻撃は、Rollup レイヤーで対処するのが難しいです。なぜなら、それらはETH坊プロトコル層で発生し、ETH坊自体を改善する必要があるからです。しかし、Rollup はこの間にいくつかの戦略を採用することができます。

3.5 ソリューション＃2： 7日間の引き出しのレイテンシーと半自動の51％攻撃の回復

これらの攻撃ベクトルに対応するために、Optimistic Rollup では現在、7日間の提供レイテンシーが実施されています。この7日間は、当初Vitalikが提案したものであり、検閲攻撃に対応するための「十分な」期間として考えられました。

Optimistic Rollupの7日間の疑問期間が検閲攻撃に耐えるのに十分かどうかを分析しましょう。弱い検閲攻撃と強い検閲攻撃の2つのタイプの検閲を考慮します。

第1種顧客リストの弱い確認については、オプティミスティックロールアップが検閲攻撃に対抗する能力を7日間付与するかどうかを確率計算を使用して調べることができます。これには、特定のバリデータがロールアップトランザクションを疑問視するときに詐欺を成功裏に疑問視する確率を計算する必要があります。

ここでは、2つの要素を考慮する必要があります：

1. 7日以内に異議申し立てを成功させるためには、複数の取引が成功している必要があります。

大抵のプロトコルでは、正直な参加者からの取引が1週間以内に1つしか含まれていない場合、疑問は成功しない。したがって、詐欺証明を提出するために必要なすべての取引が7日以内に含まれる確率を計算する必要があります。

2. バリデータの審査に関与する割合を適切に仮定する必要があります。 現在、ほとんどのETHブロック構築者（中央集権的として知られています）は検証を行っていませんが、ETHチェーン上の単独ステーカーの割合を考慮すると、99.9％のバリデータが共謀して検証する可能性はほぼありません。

(イーサリアムの主要なブロックビルダーによるレビュー|.) 出典:[Justin Drake's tweet] (https://x.com/drakefjustin/status/1813871949564772732?s=46&t=tS5tUnp3JbKDOzdjOqzBwQ))

これらの2つの点を考慮すると、99.5%のバリデータ（依然として極端な仮定ですが）が審査に参加し、誠実な参加者が30から40取引所に必要な疑問のプロトコル（BoLDやOPFPなど）を送信する成功率を計算すると、すべてのケースで成功率はほぼ100％に近づきます。さらに、将来的な解決策（たとえば、リストへの組み込みや複数の同時提案者、BRAID、APS + FOCILなど）の登場に伴い、審査への抵抗力がさらに強化され、弱い審査によるOptimistic Rollupがユーザー資金を失うリスクが低減する可能性があります。

その場合、厳しい検閲の状況下で、7 日間は十分ですか？前述の 51% 攻撃は、ソーシャルフォークでのみ解決できます。特に起因の検閲攻撃は検出が非常に困難であり、リスト入りなどの弱い検閲に対する設計された解決策では防ぐことができません。

クライアントソフトウェアに半自動の51％攻撃回復ツールを開発するという提案があります。これは、Vitalikが提案した構造に基づいています。ETHリサーチャーズは、この監査検出ソリューションをさらに開発し、2つのステップに分けました。

1. ライトクライアント监控内存池，检测某些交易在ブロック中未被包含的时间是否过长。
2. もし特定の取引がメモリープールで一日滞在し、ブロックに含まれない場合、「あなたはソーシャルフォークに参加することに同意しますか？」ボタンがトリガーされ、コミュニティはこのコンセンサスに基づいたハードフォークを開始することができます。

もしツールが51%攻撃を検出した場合、次のステップは攻撃者の資金を無効にするためにソーシャルフォークを介して新しいオンチェーンに移行することです。

このような場合、51%攻撃の影響を受けた資金は、社会的フォークが完了するまでロックされたままでなければなりません。The DAOのハードフォーク中に、同様の状況が発生し、ハッカーの資金がサブDAOにロックされ、27日間引き出せなかった。その間、イーサリアムコミュニティはハードフォークを成功させ、ハッカーが資金を現金化するのを防止しました（詳細については、VitalikがRedditで投稿した投稿を参照してください）。

言い換えれば、51%攻撃が発生しても、資金はソーシャルフォークが行われるまでロックされたままでなければなりません。この場合、Optimistic Rollup内の7日間の引き出し期間がバッファとして機能します。この1週間内にソーシャルフォークが行われない場合、Optimistic Rollup内のユーザーの資金は盗まれる可能性があり、または中央集権型取引所に引き出される可能性があります。またはTornado Cashを介して混合され、ソーシャルフォーク後にユーザーにほぼ返されない可能性があります。

要するに、Optimistic Rollupの7日間の引き出し期間は、元々は弱い監査に対応するために設けられたものですが、実際には弱い監査が起こる可能性は低く、この7日間の期間は強い監査が必要な社会的なフォークの場合には緩衝期間として機能します。

この観点からは、OPFP がこの期限を 3.5 日に短縮したことで強力な検閲攻撃を受けやすくなったとの批判がある。しかし、この批判には根拠がありません。Optimism はまだ段階1にあり、ガーディアンには状態ルートの正当性を検証するための十分な猶予期間があり、出金は追加の 3.5 日の監視期間が終了してからのみ行われます。したがって、強力な検閲攻撃が発生しても、攻撃者は出金まで 7 日待たなければなりません。さらに、攻撃者は悪質な出力の確認を中断することを防ぐために、ガーディアンも審査されるため、疑問の余地のある取引をすべて1週間中に審査する必要があります。

しかし、重要なのは、ETHエーテルは社会的なフォークを7日以内に処理できることを確保しなければならないことです。これは、51%攻撃を検出するためのツールが準備され、十分な研究とシミュレーションが行われ、7日以内に社会的なフォークが実施できるかどうかを確認する必要があることを意味します。この場合にのみ、Optimistic Rollupの7日間の引き出しレイテンシーは有効な保証と見なされます。

3.6 攻撃ベクトル #3: 不正防止システムの脆弱性の悪用

多数のプロトコルでは、参加者が特定のポイント（命令またはブロック）を見つけ、そのポイントで意見が一致しないと証明を生成して、他の参加者の主張が誤っていることを示します。この証明を生成するために使用される仮想マシンは、詐欺証明仮想マシン（Fraud Proof VM）と呼ばれ、証明を生成するために使用されるソフトウェアはプログラムと呼ばれます。各プロトコルは、異なる詐欺証明仮想マシンとプログラムを使用します。以下に示します：

すべての詐欺証明システムは、EVM内の特定の実行結果がオンチェーン上で正しいことを証明するためにあります。しかし、そのシステム（仮想マシンであろうとプログラムであろうと）にバグがある場合、どうなりますか？

この問題は、Yoav WeissによってOVMで見つかった攻撃ベクトルによって議論されることができます。OVMのロールバック機能には脆弱性があり、攻撃が可能になりますが、「詐欺トランザクション」を作成するために攻撃の実施には前提条件が必要です。詐欺トランザクションは、Rollupで正常に処理されるトランザクションであり、詐欺証明仮想マシンとプログラムを使用して質問されると異なる結果が生じます。詐欺証明システムはEVMと同じ結果を生成するはずなので、詐欺トランザクションを作成できるということは、詐欺証明システムに脆弱性があることを意味します。

Yoavは、OVMの詐欺証明システムの複数の脆弱性を発見し、この攻撃をシミュレートするために詐欺トランザクションを生成することができました。彼が見つけた簡単な攻撃例は、OVMのStateManagerで、状態を保存および読み取るために使用されるオペレーションコードSSTOREとSLOADのガスコストが誤って記録されていることです。つまり、値を保存または読み取る契約のトランザクション（単純なETH送金以外のほとんどのトランザクション）は、正しくRollupで実行されていても、詐欺トランザクションとして疑われる場合があります。

要するに、システムに脆弱性がある場合、正しく実行された状態変更が疑問の余地がある間に誤って無効とマークされる可能性があり、その結果、正直な参加者が提出した出力が誤ってマークされることがあります。

これはまた、OP Mainnetが最近、無許可モードから認証された参加者のみが参加できるモードに障害証明システムを変更した理由の一つです。OPFPがメインネットに導入された後、セキュリティ監査によってCannonとop-programの詐欺証明システム、および争議ゲームチャレンジプロトコルにいくつかの脆弱性が公開されました。システムが悪用されるのを防ぐために、Optimismは8月17日に権限システムに切り替えることを発表しました。

もちろん、仮想マシンの脆弱性を利用して、段階0または段階1のロールアップに重大な影響を与える可能性は低いです。なぜなら、セキュリティ委員会が疑問の結果を修正するためにいつでも介入できるからです。これは、OP Labsが以前に提案した意見です。実際に、OP LabsはOptimismフォーラムで、外部セキュリティレビューが必要な基準を概説した監査フレームワークを共有しています。

(OP Labs 監査フレームワーク | 出典: [Optimism Forum] (https://gov.optimism.io/t/op-labs-audit-framework-when-to-get-external-security-review-and-how-to-prepare-for-it/6864))

このフレームワークでは、最近の状況は第四象限に属しており、「補助段階の障害証明」になります。これらの状況はチェーンのセキュリティに関連していますが、直接ユーザーの資金に影響を与えるものではないため、監査範囲には含まれません。これは、脆弱性が悪用されたとしても、セキュリティ委員会が結果を是正できるということを意味しています。

しかしながら、脆弱性が特定された以上、これらの問題を解決する必要があります。OptimismはGraniteネットワークのアップグレードでこれらの問題を修正し、OP Mainnetを段階1に復帰させることができました。

一方、システム上の欠陥は、フェーズ2のRollupで致命的なものとなる可能性があります。フェーズ2では、セキュリティ委員会はオンチェーンで証明された欠陥の場合にのみ介入できます。オンチェーンで「システムの欠陥による疑念の結果が誤っている」と証明することはほぼ不可能なため、フェーズ2のRollupで欠陥が発生した場合、ユーザーの資金がリスクにさらされる可能性があります。

3.7 解決策 #3: 多要素証明

このような問題を防ぐために、本番投入前に全面的な監査を行うことが非常に重要です。ただし、詐欺証明仮想マシンやプログラムは複雑なソフトウェアシステムであり、システムが複雑であるほど、欠陥が生じる可能性が高くなります。したがって、厳格な監査を行っても、欠陥が生じる可能性があります。監査以外の追加戦略を探る必要があります。

1つの方法は、同じシステム内で複数の証明システムを使用することです。疑問が生じた場合、システムは単一のシステムだけでなく、異なる仮想マシンとプログラムを使用して複数の詐欺証明を生成し、その結果を比較することができます。これにより、脆弱性が発生した場合でも安全性を維持できるシステムが作成されます。

たとえば、Optimism の Cannon と asteriscZK Proof of Failures 仮想マシン (Risc-V を使用) の両方を使用するマルチプルーフ システムを想像してみてください。 チャレンジの場合、次のようになります。

1. エラー出力が検出された場合、疑問を持つ者は疑問を生成し、二分法を開始します。
2. 二分法で分岐ブロックを見つけた後、2つのサブゲームが同時に発生します：

Cannonのサブゲームを伝統的なOPFP方法で使用します。 asteriscを使用してZK障害証明のサブゲームを生成します。

3. 2つのゲームが終了すると、これら2つの異なる詐欺証明が検証されます。

もし2つの証明が両方とも検証に合格した場合、質問者の勝利です。両方の証明が合格しない場合、質問者の失敗です。しかし、1つが合格し、もう1つが合格しない場合、それは証明生成プロセス中に予期しないバグが仮想マシンまたはプログラムに発生していることを意味します。

この場合、セキュリティ委員会などの組織が介入し、疑問の結果を調整することになります。これにより、システムが脆弱性を持たず、かつ「セキュリティ委員会はオンチェーンで証明された脆弱性のみに介入できる」という条件を満たすことが保証されます。01928374656574839201

これはOptimismのフェーズ2の達成のための持続的な取り組みの1つです。これをサポートするために、OPFPのコンテストゲームは、モジュール化された、複数の詐欺証明システムの自由な実装を可能にし、この点をサポートするための最小限のインターフェースを定義しています。

4. 実現可能な改善

前のセクションでは、オプティミスティック ロールアップ プロトコルの設計と、その質問と不正防止の検証プロセスで発生する可能性のある脆弱性について説明しました。 このセクションでは、各プロトコルの問題点と解決策、および不正防止システムとオプティミスティックロールアップの将来の見通しについて説明します。

4.1 各プロトコルの改善余地

1) アービトラム BoLD

BoLDは、最大プロトコルレイテンシーを1週間に制限し、攻撃者の資金が防御者の6.5倍を超える前にSybil攻撃を効果的に防ぐことを確実にします。しかし、BoLDには2つの重要な問題があります。

• 6.5 倍のリソース比率は防御者の優位性があまりにも小さいです。
• 提出された根の声明には、3,600 ETHの預金が必要ですが、この金額は大きすぎます。

最初の問題はZK技術を用いて解決することができます。BoLDは照会を複数のレベルに分割し、歴史的なコミットメントの計算に必要なリソースを削減します。ZKを使用することで、これを単一のレベルにまで減らすことができます。

この概念は、CartesiのGabrielが提案したBoLD++と似ています。質問が複数のレベルに分かれると、リソース比率の増加により、最高レベルのデポジットの規模が指数的に上昇します。ただし、単一のレベルを使用する場合、リソース比率をより簡単に増やすことができ、プロトコルがシビル攻撃により強力に抵抗できるようになります。

2つ目の問題は、3,600ETHの預託金が必要ということで、より解決が困難です。BoLDの預託金の規模は、シビル攻撃に対処するためだけでなく、レイテンシー攻撃に対する抑止力としても機能します。預託金の規模は、総ロックバリュー（TVL）の関数であり、ZKを使用しても、それを著しく低下させることはできません。この問題を解決するために、BoLDは預託金の鉱山化メカニズムを導入し、複数の参加者が預託金を共同で負担することを許可しています。

2)デカルト・デイブ

Daveは、トーナメントの構造を活用してシビル攻撃に対処していますが、前述のように、レイテンシー攻撃の影響を受けやすいです。最大レイテンシー時間は、悪意のある宣言の数NAとステークのレベルの数Lを含む関数であり、計算式は次のとおりです： Td = 7 x [log2(1 + NA)]L (日)

もしNA＝7かつL＝3である場合、プロトコルは最大4か月のレイテンシーに直面する可能性があり、引き出しはレイテンシーによって遅れるため、ユーザーに明らかな不便と損失をもたらすことになります。

ZKはこの問題を軽減するのに役立ちます。レベルLを1に固定することで（たとえばBoLD++の行のように）、最大のレイテンシー時間を減らすことができます。 Td = 7 x log2(1 + NA) (日)

報道によると、CartesiはRISC ZeroのZK技術を利用してこの改善を行っています。しかし、完全にレイテンシー攻撃を防止するには、この改善が十分かどうかについての懸念がまだ存在しています。NA = 7の場合、プロトコルは依然として2週間にわたる追加のレイテンシーに直面する可能性があり、攻撃者のコストはわずか7 ETHのデポジットに加えて、Gas費用とオフチェーンの過去の約束費用がかかります。高価値のロックアップポジションを持つチェーンでは、この種のペナルティはレイテンシー攻撃を抑止するには十分ではないかもしれません。

(Dave: BoLDスタイルのサブクエスチョニングメカニズム |.) 出典: [L2Beat Medium] (https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a))

Daveには、BoLDスタイルの質疑メカニズムを採用する提案があります。 1対1の対戦ではなく、8人の参加者でラウンドごとに競技を行うようにし、伝統的なトーナメントのようにします。 この場合、レイテンシー時間の計算式は次のとおりです：

Td = 7 x log8 (1 + NA) (日)

この構造では、攻撃者は少なくとも64 ETHの証拠金を提供する必要があり、疑問のレイテンシーが2週間を超えると、総証拠金要件は64 ETHになり、多額のオンチェーンおよびオフチェーンのコストを負担する必要があります。

ただし、この方法の欠点は、Sybil攻撃に対する防御者の利点を弱めることです。BoLDは、防御者が攻撃者に対してN倍の利点を持つ構造を提供しますが、Daveは防御者が指数関数的に攻撃者を上回る利点を持つ方法を作り出しました。

要するに、DaveはZK詐欺証明を使用してレイテンシー攻撃のベクトルを効果的に制限できます。BoLDのような構造を使用することで、レイテンシー攻撃に対する耐性を高めることができますが、これによりシビル攻撃に対して防御側の利点がドロップする可能性があります。

3)オプティミズム・フォールト・プルーフ(OPFP)

OPFPの欠点はシビル攻撃に対して脆弱であることです。攻撃者と防御者のコストが同じであるためです。OP Labsは争議ゲームV2でこの問題の解決策を提案しています。

元のOPFPとは異なり、後者は毎回の二分時に証拠金を提出する必要がありますが、争議ゲームV2では参加者には二分が開始される時点での証拠金の提出が要求されます。さらに、争議ゲームV2では二分法が導入され、参加者は分岐点で複数のリクエストを同時に提出することができるため、ほとんどの場合、相互作用回数が減少します。

(Controversy Game V2 のブランチ ステートメント |.) ソース: Optimism Specs GitHub)

以前のOPFPでは、シビル攻撃のベクトルには以下が含まれています：

1. 大量の疑問を持ち、防御者の証拠金とガス料金を使い果たす。
2. 虚偽な出力を繰り返し提出し、防御側に反応させ、そのリソースを使い果たさせる。

分岐宣言の導入により、これら2つのベクトルの問題が解決されました。まず、誠実な参加者は2分プロセス中に追加の証拠金を提出する必要がありませんが、悪意のある質問者は彼らが作成した各新しい質問に対してデポジットを提出する必要があります。デポジットの金額が適切に設定されていれば、攻撃者が大量に質問を作成することは持続不可能になります。

次に、V2の議論ゲームでは、より高いレベルの証拠金が大きくなるため、攻撃者にとって虚假の出力を継続的に提出するコストは防御者よりも高くなります。

したがって、OPFP は Sybil 攻撃に効果的に対処するために、V2 で導入されたブランチ宣言を利用できます。

4)Kroma ZKフォールトプルーフ(Kroma ZKFP)

Kroma ZKFPはSybil攻撃と不完全な証明システムの脆弱性の2つの課題に直面しています。Kroma ZKFPはステージ1に進むために、以下の2つの問題を解決する必要があります:

1. 二分法の始点は最終提出の出力に基づきます。最終的な出力に基づきます。
2. バリデータ未検証のため、正しいバッチデータに基づいているかどうかに疑問があります。

Kroma は、両方の問題に対処し、フェーズ 1 に進むために、Scroll の Halo2 zkEVM から Succinct SP1 zkVM に切り替える予定です。

Kromaは、Optimismの争議ゲームインターフェイスに合わせ、その異議申し立てプロセスを変更することを計画しています。この調整については、Kromaの標準仕様書（https://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html）で詳しく説明されており、出力が確定された最後の1週間前に二分された開始点を移動できるようにすることで、最初の問題を解決することができます。

第二の問題について、Kroma は ZK ベースの信頼できない導出を使用します。具体的な動作は以下の通りです：

(ZK |を使用したトラストレス導出。 ソース: [Lightscale Notion] (https://www.notion.so/Complete-Trust-less-Derivation-for-Zero-Knowledge-Dispute-Game-bfaebd36375d48169424064237986dea?pvs=4))

特定のL2ブロックTが正しく実行されていることを証明したいと思ってください。ZK証明を生成する前に、ブロックTのトランザクションデータがL1のバッチデータに基づいて正しく構築されているかを検証する必要があります。

ここでは、Kroma は ZK を使用して、バッチデータが L1 から正しく取得されたかどうかを検証することを意図しています。データが ZK プログラムの外部から信頼できる RPC を介してのみ取得される場合、バッチデータが改ざんされていないかどうかを確認することはできません。ブロックハッシュの連結性 ZK 証明を生成して、プログラムが正しいブロックにアクセスし、バッチデータを抽出したかどうかを検証することができます。これらのブロックは、ブロック O（L2 ブロック T の L1 ソース）からブロック C（L1 ブロックの照会時）までです。もし疑問を持つ者が誤ったバッチデータを用いて L2 ブロック T を構築した場合、疑問を持つ者が抽出したバッチデータが参照する L1 ブロックハッシュは実際にバッチデータ（T1 を含む）を含む L1 ブロックハッシュと異なり、またブロック C とも接続されません。したがって、ハッシュの競合がない限り、ZK を使用して L1 ブロックの連結性を検証することで、疑問を持つ者が正しいバッチデータから L2 ブロックを構築したことを証明できます。

Kromaプロジェクトは、ZKを使用して一括データの正確性を検証することを計画しています。これにより、L1ブロックOからCへのブロックハッシュの連結性を確認できます。もし疑問を持つ者が間違った一括データに基づいてL2ブロックTを構築した場合、彼らが引用するL1ブロックハッシュは正しい一括データを含むL1ブロックと異なり、ブロックCに接続されません。ハッシュの衝突がないため、疑問のプロセスはこの方法を使用して正しい一括データを検証できます。

これらの改良により、Kroma ZKFP は段階1に入ることができます。しかし、段階2に達するには、Sybil攻撃を防止するための追加のソリューションが必要であり、すべて対すべて（All-vs-All）に変更することを含む、質問プロトコルを再設計する必要があります。証拠金メカニズム。

4.2. 概要

5. 不正防止の未来

5.1. ステージ2ロールアップ - あなたの資金は安全です

上記のように、Optimistic Rollupsは第2段階に向けて進化しています。ArbitrumはBoLDに基づいて第2段階を実現するために努力しています。BoLDの実装計画はガバナンスフォーラムで公開され、多くの支持を受けており、現在はテストネットで展開されています。重大なセキュリティの問題がなければ、Arbitrumはおそらく今年の年末までにBoLDを通じて第2段階を実現するでしょう。

Optimism は段階 2 の達成に向けて努力しています。OP メインネットが段階 2 に到達するには、争議ゲーム V2 を完了し、複数のプルーフをサポートするために複数のプルーフ機構が必要です。標準はまだ改善されていますが、争議ゲーム V2 は既存の OPFP の弱点を効果的に解決し、強力な保護を提供して Sybil 攻撃に耐えるようになり、段階 2 により近づくようになりました。さらに、OP Labs、Succinct、Kroma、Kakarot を含む多くのチームが、多様な OP スタックのプルーフ方法を作成するために多大な研究開発リソースを投入しています。したがって、重大な問題が発生しない限り、Optimism は来年上半期に段階 2 に向けて進むと予想されています。

これらの2つのRollupは段階2への移行により、Rollupエコシステムに重大な影響を与える可能性があります。ArbitrumとOptimismは、それぞれ独自のRollupフレームワーク、Arbitrum OrbitとOP Stackを持っています。これらのフレームワークを使用しているすべてのRollupも段階2に移行できることを意味します。

したがって、今年の年末から来年にかけて、ArbitrumやOPメインネット、Baseなどの主要なRollupユーザーベースが段階2に移行し、イーサリアムの完全なセキュリティを継承することが予想されています。これにより、「Rollupは単なるマルチサイン」や「Rollupはいつでも資金を引き出せる」などの批判が沈静化する可能性が非常に高いです。

5.2. ZK詐欺が未来を証明

ほとんどの議論は、ZK詐欺証明の実装によって利益を得ることができるプロトコルに焦点を当てています。たとえば、Arbitrum BoLDにZKを適用すると、リソース比率が向上し、Sybil攻撃に対する耐性が向上します。一方、Cartesi Daveは、レイテンシー攻撃を受けにくくします。OPFPもZKを導入することで、マルチプルーフシステムをサポートし、証拠金額を減らし、プロトコルのセキュリティを向上させる可能性があります。

ZK詐欺証明には、バリデータ間の相互作用が減少するだけでなく、バリデータが必要とするリソースも大幅に削減され、証拠金額も減少するため、より多くの参加者がプロトコルに参加できることを意味します。さらに、最大のレイテンシーも減少し、全体的なプロトコルのセキュリティが向上します。

この方法により、ZK 詐欺証明はOptimistic Rollupのセキュリティと分散化において重要な役割を果たしています。

5.3. ZK Rollup のパフォーマンスはどうですか？詐欺証明は弱くなりますか？

この時、一部の読者は尋ねるかもしれません： 詐欺証明や疑問のあるメカニズムが複雑である場合、ZKロールアップはより良い選択肢になるのでしょうか？ ある程度、これは正しいです。ZKロールアップでは、段階2に到達する際、複雑な経済要因を考慮する必要はありません。ユーザーの資金はL1レビューイベントで盗難のリスクにさらされることはありません、ユーザーは数時間で資金を引き出すことができます。

Optimistic Rollups が ZK Rollups への移行は予想以上に速くなる可能性があります。これは、ZK Rollups の主な欠点である非常に高い証明生成コストと時間が急速に改善されているためです。最近、Succinct Labs が OP Succinct を発表し、これは OP Stack に基づく ZK バージョンで、ZK Rollups を簡単に開始するためのフレームワークを提供しています。

OP Sucinct の紹介 | 出典:簡潔なブログ

ただし、考慮すべき要素がいくつかあります。まず、コストです。OP Succinctでは、ブロックの証明を生成するコストは約$0.005〜$0.01であり、オペレーターの実行コストは月間で$6,480〜$12,960と推定されています。チェーンのトランザクション処理能力（TPS）が高い場合、これらのコストはさらに増加する可能性があります。

(各ネットワークの証明コスト基準 |.) 出典:簡潔なブログ)

例えば、OP SuccinctのBaseネットワークでは、ブロックごとの平均証明生成コストは約$0.62です。この数字から計算すると、月間のコストは$803,520になります。これはOptimistic Rollupsにはない追加コストであり、ZK Rollupsの運営コストも常にOptimistic Rollupsよりも高くなります。

第二つの考慮事項は分散化への影響です。ZKロールアップでは、バリデータは詐欺証明プログラムを実行するOptimistic Rollupsよりも困難でコストが高くなります。さらに、ZKシステムでは証明生成に時間がかかるため、ユーザーは取引をリアルタイムで検証できません。証明生成速度を向上させるためにはより高いハードウェア規格が必要ですが、これはバリデータが高い計算環境を必要とすることを意味します。理想的な状況では、誰もがノードを実行してチェーンの安全性を確保できるはずですが、ZKは現時点でこの水準に達していません。

最後に、ZK Rollupsは高度に複雑な数学と暗号技術に基づいています。この複雑さは詐欺証明や疑問視プロトコルの範囲を超えています。したがって、ZKシステムは安全に本番で使用できるようになる前に、広範なテストが必要です。

Arbitrumは、ZKとOptimisticの方法を組み合わせたハイブリッドプロトコルを最終目標として追求しています。このプロトコルは、主にOptimistic Rollupとして機能し、高速な引き出しを必要とする場合にのみZKプルーフを生成します。これは、資金をチェーン間で迅速にリバランスする必要があるシーン（例：取引所やクロスチェーンブリッジなど）に非常に役立ち、また、チェーン間の相互運用性の実現にも貢献します。

要するに、現時点ではOptimistic Rollup方法が効果的であり、ZKを混合手法として採用しています。ただし、ZK証明の生成コストと速度が継続的に改善されると、将来的にはより多くのOptimistic RollupsがZKに移行する可能性があります。

5.4. 詐欺証明はRollupのみに適用されますか？

私たちは、イーサリアムのオプティミスティックロールアップとその詐欺証明機構について調査しました。では、この詐欺証明には他にどのような応用シーンがあるのでしょうか？

1. 再ステークプロトコル 詐欺証明はステークプロトコルで積極的に活用されます。Eigenlayerを例に取ると、これはETHブロックチェーン上で代表的な再ステーキングサービスです。

Eigenlayer は、ETH をステークしたり、ユーザーの LST を預けたりすることができる、安全なサービスを可能にするものです。Eigenlayer では、オペレーターは委任契約に基づいて ETH またはユーザーの LST を預け、複数の AVS（アクティブ検証サービス）を選択して検証に参加できます。Eigenlayer を使用することで、プロトコルは簡単に AVS を構築し、初期バリデータの誘導コストを削減することができます。

他らが悪意のある行為を取る場合、AVSは成功した検証者に報酬を与え、スラッシングプロセスで詐欺証明を使用する必要があります。他のすべてのブロックチェーンと同様に。

**AVSスラッシングの例 | ソース: Eigenlayer GitHub

例えば、ブリッジ AVSを取り上げます。ブリッジAVSの前提条件は、ユーザーの資金を正しくターゲットチェーンに移動することであり、取引を悪意のある操作から守るために、運営者はいかなる場合でもスラッシングの対象になります。このような操作が行われた場合、不適切な行動が発見された質疑者は、詐欺証明を伴う質疑を紛争解決契約で作成することができ、運営者がブリッジ操作で不適切な処理を行ったと主張することができます。詐欺証明が有効であると認められた場合、AVSはEigenlayerのスラッシング契約を呼び出して、運営者のすべての報酬を一時停止することができます。

Eigenlayerにおけるスラッシング機能はまだ実装されていませんが、彼らは最近共有セキュリティモデルを発表し、次のバージョンにスラッシング機能を含める予定です。 これにより、詐欺証明がスラッシングに使用されることができます。

2. データ可用性レイヤー** **詐欺証明もデータ可用性（DA）レイヤーに使用できます。その代表的な例として、Celestiaが提案し実装した詐欺証明があります。Celestiaには、データ可用性サンプリングに基づいてライトノードがデータの正しい保存を検証するための技術があります。この概念を注意深く理解しましょう。

ライトクライアントは、ブロックチェーンのすべてのデータをダウンロードせずに、ブロックが大多数（67％以上）のバリデータによって承認されたかどうかを検証できる必要があります。ただし、すべてのバリデータの署名をブロックごとに検証することは困難であり、バリデータ数が増加するにつれて、ほぼ不可能になります。

この点において、Celestiaは興味深いコンセプトを提案しています。Celestiaでは、ほとんどのバリデータが悪意を持っていても、単一の誠実なフルノードによって欠陥のあるブロックを拒否するようライトクライアントに通知する方法が提案されています。この単一の誠実なフルノードは詐欺証明によってその「誠実性」を保証することができます。

Celestiaの詐欺証明には2つのタイプがあります:

*状態遷移の不正防止

まず、詐欺証明の仕組みは次のようになります：Celestiaでは、ライトノードがブロック内のすべてのデータを直接ダウンロードせずに、バリデータが正しいデータを持っているかどうかを検証することができます。これを実現するために、Celestiaではデータ可用性サンプリング（Data Availability Sampling、DAS）という技術を使用しています。

Celestiaのデータ可用性サンプリング | ソース: [Celestia Files] (https://docs.celestia.org/learn/how-celestia-works/data-availability-layer)

Celestia のバリデータは、取引データを k x k の行列に構造化し、それを 2D Reed-Solomon コーディングと呼ばれる技術を使用して 2k x 2k の行列に拡張します。その後、彼らは各行と列の合計 4k 個のメークルルートを計算し、これらのメークルルートをさらにハッシュして、その結果をブロックヘッダーに含めて伝播します。

ブロックヘッダー中のメークルルート情報だけで、ライトノードは Celestia のバリデータが正しいデータを持っているかどうかを検証できます。ライトノードは2k x 2k行列のランダムなポイントからデータをリクエストし、バリデータから対応する行と列のメークルルートも取得します。これらのデータがブロックヘッダーの値と検証できれば、これらのバリデータが正しいデータを持っていると信頼できます。

然而、重要な考慮事項が生じました：もしバリデータが悪意を持ってReed-Solomonエンコーディングを実行した場合はどうなるでしょうか？Celestiaは、この問題を解決するために「悪いエンコーディング詐欺証明」と呼ばれるメカニズムを実施しています。もしCelestiaのフルノードがブロックの復元プロセス中にエンコーディングが正しくないことを発見した場合は、そのフルノードはブロックの高さ、エラーのエンコーディング部分、および故障証明を含む詐欺証明を生成し、それを軽ノードに伝播します。軽ノードはこの証明を検証し、データが確かにエンコーディングエラーであることを確認し、それによって誤ったデータの使用を停止します。

さらに、Celestiaは状態遷移の不正防止メカニズムを提案しています。

Celestiaブロックのアーキテクチャ | 出典:【寄稿DAOブログ】(https://mirror.xyz/contributiondaoblog.eth/_VknA2qiU0AF2aHcfCRxNjNQ2zLgOOWDnDXjs7fQR1o)

Celestia のブロック構造には、さまざまな時間間隔での取引のトラッキングデータが含まれています。これにより、フルノードは詐欺証明を簡単に構築でき、また、ライトノードはブロック全体を実行せずに不正な状態変化を検出できます。しかし、複雑さの問題から、このメカニズムはまだ Celestia メインネットに実装されていません。

要するに、データ可用性レイヤーの詐欺証明は、コンセンサスに依存せずに、誤ったデータや状態変換をフィルタリングすることができます。

3. 機械学習 人工知能とブロックチェーンは2024年に注目のトピックとなり、この分野で多くの研究開発が行われました。その中でも最も注目すべき点の一つは、ブロックチェーンと機械学習の組み合わせです。

ブロックチェーンに機械学習を適用する主な理由は次のとおりです：

• 数据可靠性：ブロックチェーンは分散型でデータを管理し、すべての取引は公開透明に記録されます。機械学習モデルがブロックチェーンのデータから学習する場合、データの信頼性が高く、改ざんの可能性が低くなります。
• モデルの透明性と検証可能性：機械学習モデルがオンチェーンで実行されるとき、モデルの更新と結果はオンチェーンに記録され、検証が可能になります。これにより、中央集権的な環境での結果の操作やバイアスが防止されます。

ここでの重要な要素は、機械学習モデルが正しくトレーニングされているかを検証することです。ただし、機械学習の計算は非常に密集しているため、これらの計算を完全に実行することはブロックチェーンの実行環境ではほぼ不可能です。そのため、opMLやzkMLなどのフレームワークがブロックチェーン環境での機械学習モデルのトレーニングを効果的に検証するために開発されました。opMLは楽観的な方法でモデルをトレーニングし、結果をブロックチェーン上に記録し、疑問のメカニズムを通じてエラーを修正します。

ORAは、ブロックチェーン上で人工知能インフラを提供するプロジェクトであり、opMLのチャレンジプロセスは、ロールアップのチャレンジと非常に似ており、次の3つのキーコンポーネントで構成されています。

Fraud Proof VM: この VM は機械学習の推論を実行し、Arbitrum の WAVM や Optimism の Cannon と同様に機能します。

• opML スマートコントラクト：この契約は詐欺証明を検証し、Optimism の MIPS.sol 契約と同様の機能を果たします。
• バリデータ：疑問を提起したバリデータは、仮想マシンとのやり取りにおいて二分法を使用して個々の誤ったステップを特定し、その後に詐欺証明を生成し、opML契約に提出します。

ORA opMLでの検証ゲーム | 出典:ORAドキュメント

この詐欺証明メカニズムにより、opML はブロックチェーンの安全性と信頼性を利用して、機械学習モデルのトレーニングと検証に費用対効果の高い環境を提供しています。

6. 結論

Optimistic Rollupは、詐欺証明とプロトコルの改善に多くのエネルギーを注いでおり、さらなるイーサリアムのセキュリティの継承と、より信頼性の低いチェーンの作成を目指しています。Arbitrumは、今年の年末までにBoLDを使用してフェーズ2に到達する予定であり、OptimismもV2の論争ゲームとマルチプルーフメカニズムに依存してフェーズ2に向けて取り組んでいます。来年までに、Optimistic Rollupのユーザーはより高いセキュリティでネットワークと対話し、自分たちの資金が「Rollupによって取られる可能性」を心配する必要がなくなるでしょう。さらに、Vitalikは彼のブログで、フェーズ1以上のRollupの数も増えると述べています。

しかし、すべてのプロトコルには改善の余地があり、多くの側面でZK詐欺証明を利用して強化できます。Kromaはこの基盤の上でプロトコルを推進しており、Arbitrum、Optimism、Cartesiなどの他のプロトコルもZK詐欺証明を利用して、より安全で分散化された方法で保持できます。

詐欺証明の領域では、Rollupだけでなく、他のプロトコルも大量の研究開発リソースを投入しています。詐欺証明とZKを組み合わせることで、「正直な参加者だけが必要」という前提のもと、信頼度を最小限に抑えたブロックチェーンアーキテクチャの構築を支援し、その影響は私たちが身を持って感じる現実となるでしょう。

7. リソース

(https://l2beat.com/scaling/summary)[L2Beat]

[詐欺は戦争を証明する|.] ルカ・ドンオウ at L2Beat](https://medium.com/l2beat/fraud-proof-wars-b0cb4d0f452a)

アービトラムファイル

楽観主義記事。

楽観仕様

[審判権限のない試合|.] Cartesi](https://arxiv.org/pdf/2212.12439)

【クロマ仕様】(https://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html)

BoLD:迅速で低コストな紛争解決

BoLDの経済学

オプティミスティック ロールアップのチャレンジ期間が 7 日間なのはなぜですか? Kelvin Fichter at OP Labs

[詐欺の証拠がクラッシュしました|.] ガブリエル・コウチーニョ・デ・パウラ(カルテシ)(https://ethresear.ch/t/fraud-proofs-are-broken/19234)

[楽観的タイムトラベル|.] ヨアヴ・ヴァイス』(https://medium.com/infinitism/optimistic-time-travel-6680567f1864)

Kroma's Mainnet's Mainnet's First Successful Challengeの紹介

[ベースライン分散化の進捗状況の解釈 |.] OPラボ](https://blog.oplabs.co/unpacking-progress-in-baseline-decentralization/)

Fraud Proofに基づくLayer 2 Protocolに対するUnattributable Censorship Attack

OP Labs監査フレームワーク

[トラストレス導出|.] クロマ](https://www.notion.so/Complete-Trust-less-Derivation-for-Zero-Knowledge-Dispute-Game-bfaebd36375d48169424064237986dea?pvs=4)

[OP Succinctの紹介:OPスタックでの有効性の完全な証明|.] 簡潔](https://blog.succinct.xyz/op-succinct/)

Eigenlayer GitHub

セレスティアファイル

寄稿DAOブログ

ORAドキュメント

免責事項:

1.この記事は[research.2077からの転載であり、すべての著作権は原作者に帰属します[sm-stackおよびBTC Penguin]。 この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。 2.免責事項:この記事で表明された見解や意見は、著者の個人的な見解を表しているにすぎず、投資アドバイスを構成するものではありません。 3. Gate Learn チームは記事を他の言語に翻訳します。別途指示がない限り、記事のコピー、配布、または翻訳の盗用は禁止されています。