本文へ移動
Financial Context Wiki

有効性証明

有効性証明、公開入力、証人、証明システムの前提、ロールアップの状態遷移、データ可用性、ファイナリティ、運用障害を検証中心に解説するガイド。

更新日

教育目的のみであり、投資またはセキュリティ上の助言ではありません。有効性証明の信頼性は、命題、公開入力の結合、証明システム、検証器、データ可用性経路、コントラクト、運用者、ガバナンス、決済チェーンに依存します。

直接の答え

有効性証明は、主張された計算が厳密に定義された関係を満たすことを示す暗号学的証拠です。検証器は検証鍵と公開入力に対して証明を確認します。ロールアップでは通常、以前の状態ルート、提案された新しい状態ルート、取引バッチのコミットメントを入力に結び付けます。検証に成功すれば、決済コントラクトは全取引を再実行せず新しいルートを受理できます。

保証は「システム全体が正しい」より限定的です。健全な暗号、意図したプログラムや回路、正しい公開入力の符号化、真正な検証鍵、正しい検証器と状態更新コントラクトに依存します。検証だけでは、データ取得、証明者の稼働、決済ブロックの確定、アップグレードの安全性、出金経路の動作は証明されません。ゼロ知識方式を使えても、有効性自体はプライバシーを意味しません。

1
実行

証明者がバッチまたは計算を実行し、状態遷移を得ます。

仕組み

  1. 正確なデプロイを特定します。L1・L2 チェーン ID、バージョン、状態更新コントラクト、検証器のアドレスとバイトコード、検証鍵ハッシュ、証明方式、回路・プログラム版、データモード、管理権限、停止状態、確定方針を記録します。validity proof は共通仕様ではありません。
  2. 結果を解釈する前に関係を定義します。健全性の前提の下で Verify(vk, x, proof) = 1 は、R(x, w) = 1 を満たす証人 w の存在を意味する必要があります。vk は検証鍵、x は完全な公開入力、R は符号化された規則です。証明の対象はこの関係だけです。
  3. 公開入力を独立に再構築します。以前のルートがコントラクトで受理済みか確認し、正規データからバッチ・データコミットメント、ID、新ルート、メッセージ・出金ルート、パラメータを導出します。誤った対象に結び付いた有効な証明は、誤った主張の証明です。
  4. 証明とコントラクト経路を検証します。独立した互換検証器を実行し、オンチェーン呼出し、レシート、イベント、受理バッチ、ストレージ変更を確認します。アップグレードや特権分岐による迂回、模擬、置換がないことも確認します。
  5. データ可用性を別に検証します。必要な取引、状態差分、blob sidecar、委員会認証データを取得し、コミットメントを照合して状態遷移や退出証人を再現します。特に validium では、有効な証明と取得不能なデータが両立し得ます。
  6. 生成、送信、包含、証明検証、状態受理、決済安全、決済確定、出金完了を分けます。証明待ち、費用、稼働性、L1 包含、再編、ブリッジ遅延、強制包含、退出手順を測ります。
  7. 再現可能な証拠を保存します。アドレスとコードハッシュ、鍵・プログラムハッシュ、完全な入力、証明バイトまたは永続参照、バッチデータ、検証コマンドと版、レシート、確定ブロック、成功した退出テストです。アップグレード後に再確認します。

計算例

  • バッチ主張。 ロールアップが 8,192 transfers を処理し、証明が R0、R1、B7 を結び付けます。成功は B7 について R0 から R1 への証人を支持しますが、B7 の取得、全取引の包含、R1 の確定は証明しません。
  • 再帰集約。 集約器が親回路内で 16 child proofs を検証し、親証明を送信します。各子証明、順序、公開入力対応は別途確認が必要で、個数だけでは結合を証明できません。
  • 仮想 Gas 台帳。 再実行が 24,000,000 gas、検証が 600,000 gas、データ公開が 180,000 gas なら、合計は 600,000 + 180,000 = 780,000 gas、モデル上の削減率は (24,000,000 - 780,000) / 24,000,000 = 96.75% です。ハードウェア、集約、失敗、保存、ブリッジ、保持費用は除外します。

リスク

  • 誤ったチェーン、デプロイ、バッチ、検証器、鍵、回路を確認する。
  • 健全な方式が不完全または誤った回路を忠実に証明する。
  • 公開入力が ID、ルート、バッチ、ドメイン、パラメータを欠落・誤符号化する。
  • 検証器、プリコンパイル、安全でないライブラリ、非互換実装の不具合。
  • セットアップ素材の侵害または暗号学的前提の破綻。
  • 更新可能コントラクトやガバナンスが検証器、鍵、プログラム、規則を置換する。
  • 特権迂回、緊急モード、停止、許可リストが経路を弱める。
  • 証明生成の不具合、非決定性、クライアント間の証人不一致。
  • 証明者の集中、検閲、停止、滞留、機器故障が更新を止める。
  • 取引、状態差分、blob、原像、履歴が欠落する。
  • 委員会署名やコミットメントを現在のデータ取得と同一視する。
  • 安全でない、再編済み、非正規ブロックの証明を受理する。
  • 証明受理を即時出金または経済的確定とみなす。
  • 状態遷移、残高、メッセージ、退出証人を独立再現できない。
  • Gas、データ料、遅延、ブリッジ待ち、復旧費用を過小評価する。
  • あるロールアップのモデルを別のデプロイへ適用する。

よくある誤解

  • 検証済み証明は全実装詳細と表示残高を保証する。
  • すべての有効性証明はゼロ知識で取引を隠す。
  • 証明はデータ、シーケンサー稼働性、検閲リスクをなくす。
  • 検証後は決済が即時確定し出金できる。
  • 証明が小さい、または検証器が速いほど自動的に安全で安価になる。

関連トピック

出典

ナビゲーション

Wiki を検索...