Prover（証明者）

暗号資産におけるProverとは？

Proverとは、ある命題、計算、トランザクションのバッチ、または状態遷移が有効であることを示す暗号学的証明を生成する人、プログラム、ノード、サービス、ハードウェアシステムです。

暗号資産分野では、主にゼロ知識証明、Validity Rollup、zkVM、プライバシープロトコル、検証可能な計算システムで使われる用語です。

Proverは、別の当事者がより低いコストで検証できる証明を作るために必要な、負荷の大きい計算を担います。

証明を確認する側はVerifierと呼ばれます。

Proverは、すべてのVerifierに計算全体を再実行させることなく、計算が正しく行われたことを示せます。

公開ブロックチェーンでは、多数の参加者が有効な状態変更に合意する必要があるため、この仕組みはスケーリングにおいて重要です。

すべてのノードが各トランザクションを詳細に再実行しなければならない場合、ネットワークの処理が遅くなり、コストも増える可能性があります。

証明システムを使えば、Proverは大規模な処理をオフチェーンで実行または検証し、簡潔な証明をオンチェーンに送信できます。

Ethereumのゼロ知識証明に関するドキュメントでは、検証可能な計算によってノードがEthereum外でトランザクションを実行し、オフチェーンの実行が正しかったことを示す証明を提出できると説明されています。

簡単に言えば、Proverとは、計算が正しく行われたことを示す数学的な領収書を作る装置または主体です。

Proverの仕組み

Proverは、証明対象となる命題から処理を始めます。

秘密の値を知っていることを示すといった単純な命題もあれば、何千件ものLayer 2トランザクションがプロトコルのルールに従って処理されたことを示す複雑な命題もあります。

Proverは入力も使用します。

入力の一部は公開情報であり、Verifierが確認できます。

一方、非公開入力は、直接明かすことなくProverが使用します。

多くの証明システムでは、非公開入力をWitness（証人）と呼びます。

次にProverは証明アルゴリズムを使い、命題、制約、公開入力、Witnessから証明を生成します。

通常、証明は元の計算よりも大幅に小さく、検証も速く行えます。

Verifierは検証アルゴリズムで証明を確認します。

証明が有効であれば、Verifierは証明システムのルールに照らして命題が真であると認めます。

これにより、ブロックチェーンはProver本人を信頼することなく、計算結果を信頼できます。

ProverとVerifierの違い

証明システムにおけるProverとVerifierの役割は対照的です。

Proverは証明を生成します。

Verifierは証明を検証します。

証明生成には多くの計算が必要なため、通常はProverの作業のほうが負荷の高いものになります。

一方、証明の検証は高速かつ低コストになるよう設計されているため、Verifierの作業は通常より簡単です。

この非対称性はブロックチェーンに有用です。1つのProverが負荷の高い処理をオフチェーンで行い、多数のノードやスマートコントラクトが結果を効率的に検証できます。

たとえばZK-rollupでは、Proverが大量のトランザクションをまとめたバッチのValidity Proofを生成します。

その後、オンチェーンのVerifierコントラクトが証明を確認してから、Rollupの状態更新を受け入れます。

EthereumのZK-rollupに関するドキュメントでは、ZK-rollupがValidity Proofを使ってEthereum上のトランザクションを確定すると説明されています。

無効な証明は検証に失敗するはずなので、VerifierはProverが正直であると信頼する必要がありません。

ProverとSequencerの違い

ProverとSequencerは同じものではありません。

Sequencerはトランザクションを並べ替え、通常、Rollupシステムでバッチの構築を支援します。

Proverは、そのバッチまたは状態遷移が有効であることを示す暗号学的証明を生成します。

システムによっては、同じ組織がシーケンス処理と証明インフラの両方を運営することがあります。

一方、シーケンス処理と証明処理が、異なるサービス、ノード、市場、コミュニティ参加者に分かれているシステムもあります。

トランザクションの順序付けと正しさの証明は異なる権限であるため、この区別は重要です。

Sequencerは、トランザクションの順序、レイテンシー、ユーザー体験に影響を与える可能性があります。

Proverは、証明の可用性、ファイナリティまでの時間、インフラコストに影響を与える可能性があります。

Rollupの技術的な設計が適切でも、証明処理が単一の運営者に依存していれば、中央集権化のリスクに直面する可能性があります。

CrowdProveのコミュニティ証明に関する研究などの最近の研究では、中央集権的なインフラだけに依存せず、多数の小規模なProverにZK-rollupの証明処理を分散させる方法が検討されています。

ゼロ知識証明におけるProver

ゼロ知識証明では、Proverは命題が真であることをVerifierに納得させようとします。その際、命題の真偽以外の情報は明かしません。

Proverが知っている情報は、非公開の秘密、トランザクションデータ、本人確認情報、計算結果、またはWitnessである場合があります。

証明では、システムが開示するよう設計した情報だけを明らかにする必要があります。

たとえば、ユーザーはパスワードを明かさずに、有効なパスワードを知っていることを証明できます。

暗号資産分野では、ユーザーがすべての非公開情報を開示せずに、トランザクションがルールに従っていることを証明できる場合があります。

Rollupで使われる証明がすべて、主にプライバシーを目的としているわけではありません。

多くのRollupは、すべてのトランザクション詳細を隠すためではなく、主にスケーラビリティと正確性のためにValidity Proofを使います。

そのため、証明が完全なプライバシーよりも正しい実行を示す場合、より広い意味を持つ「Validity Proof」という用語が使われることがあります。

いずれの場合も、証明を生成するのはProverです。

証明をプライバシー、スケーリング、またはその両方に使うかは、プロトコルの設計によって異なります。

ZK-rollupにおけるProver

ZK-rollupでは、Proverがオフチェーンのトランザクションバッチが正しく処理されたことを示す証明を生成します。

Rollupは、ベースチェーンの外部で多数のトランザクションを実行します。

その後、圧縮データとValidity Proofをベースチェーンに送信します。

ベースチェーンは、バッチ内のすべてのトランザクションを再実行する代わりに証明を検証します。

これにより、オンチェーンの計算量を減らし、スケーラビリティを向上させられる可能性があります。

ユーザーは証明を通じて状態更新を確定するため、ProverはZK-rollupの重要な構成要素です。

証明生成が遅ければ、ファイナリティが遅れる可能性があります。

証明生成にコストがかかれば、Rollupの運用コストが増加する可能性があります。

証明生成が中央集権化されていれば、Rollupが単一のインフラプロバイダーに過度に依存する可能性があります。

証明生成に失敗すると、Rollupは有効な新しい状態更新を送信できなくなるおそれがあります。

そのため、Proverの設計、性能、分散化、信頼性はLayer 2開発における主要なテーマです。

zkVMにおけるProver

zkVMは、プログラムが正しく実行されたことを証明できるゼロ知識仮想マシンです。

開発者はタスクごとに専用の回路を作る代わりに、仮想マシン上でコードを実行し、正しく実行されたことを示す証明を生成できます。

RISC Zeroの開発者向けドキュメントでは、検証可能な計算を、特定のデータ出力が特定のアルゴリズムによって生成されたことを暗号学的に確信する方法として説明しています。

zkVMでは、Proverがプログラムを実行し、その実行を記録して証明を生成します。

Verifierはプログラム全体を再実行せずに証明を確認できます。

この方式では、開発者が使い慣れたプログラミング言語や仮想マシンのターゲットを利用できるため、ZK開発をより身近にできる可能性があります。

zkVMのProverは、Rollup、ブリッジ、IDシステム、プライバシーアプリ、検証可能なAIワークフロー、検証可能なゲーム、オフチェーン計算などに利用できます。

ただし、zkVMの証明生成には多くのリソースが必要となる場合があります。

性能は、プログラムの規模、メモリ使用量、証明システム、ハードウェア、再帰設計、最適化方法によって変わります。

STARKシステムにおけるProver

STARKベースのシステムは、一部の他の証明システムで使われるものと同じ信頼設定の前提に依存せず、検証できる種類の証明を利用します。

STARKシステムでは、Proverが代数的制約と実行トレースに基づき、計算を証明に変換します。

この証明により、プログラムまたはトランザクションバッチが必要なルールに従ったことを示せます。

StarknetのSHARPに関するドキュメントでは、SHARPが生成したSTARK証明を検証するオンチェーンVerifierコントラクトについて説明されています。

SHARPは、複数のプログラムやアプリケーションの実行を集約して証明できる共有証明インフラの一例です。

STARKのProverは、優れたスケーラビリティ特性と透明性の利点で知られています。

構成によっては、一部のSNARKシステムより大きな証明を生成する場合もあります。

他の証明システムと同様、実用上のトレードオフは証明時間、検証コスト、証明サイズ、セキュリティ上の前提、開発者の使いやすさによって異なります。

Proverは技術的な複雑さの多くを引き受け、Verifierが簡潔な証明を確認できるようにします。

SNARKシステムにおけるProver

SNARKシステムは、非常に小さく、すばやく検証できる簡潔な証明を使います。

SNARKシステムでは、Proverが計算が一連の制約を満たすことを示す簡潔な証明を作成します。

多くのSNARKシステムでは信頼設定が必要ですが、新しい設計ではその要件を軽減または変更できる場合があります。

SNARKのProverは、セットアップ時に生成されるProving Keyを必要とすることがよくあります。

VerifierはVerification Keyを使って証明を確認します。

オンチェーンでの検証コストを非常に低く抑える必要がある場合、SNARKのProverが役立ちます。

ベースレイヤーのブロックチェーンでは、計算とストレージに手数料がかかるため、これは重要です。

低コストで検証できる小さな証明により、高度なアプリケーションがより実用的になる可能性があります。

ただし、Prover側では証明生成に依然としてコストがかかる場合があります。

SNARKベースのアプリケーション設計では、証明サイズ、証明生成時間、信頼設定の前提、開発の複雑さのバランスを取る必要があります。

Witness、公開入力、非公開入力

Proverは通常、公開入力と非公開入力の両方を扱います。

公開入力は、Verifierに開示してもよい値です。

非公開入力は、Proverが使用するものの、直接開示しない値です。

非公開入力はWitnessと呼ばれることがよくあります。

たとえば、非公開のID証明では、公開入力が年齢のしきい値、非公開のWitnessがユーザーの実際の生年月日や資格情報となる場合があります。

Rollupの証明では、公開入力に旧状態ルート、新状態ルート、バッチのコミットメント、プロトコルパラメーターなどが含まれる場合があります。

設計によっては、Witnessにトランザクションの詳細、実行トレース、Merkleパス、署名、中間計算データなどが含まれます。

ProverはWitnessを使って証明を生成します。

Verifierは、証明が公開入力と一致するか確認します。

安全な証明システムでは、偽の命題に対してProverが有効な証明を作れないようにする必要があります。

回路と制約

多くの証明システムでは、計算を回路または制約の集合として表現する必要があります。

回路は、証明システムが理解できる形式で証明対象を記述します。

制約は、有効な入力や計算手順が満たすべきルールを定めます。

たとえば、ハッシュが正しく計算されたこと、署名が有効であること、残高更新がプロトコルのルールに従っていることを回路で求める場合があります。

Proverは、すべての制約を満たすWitnessが存在することを示さなければなりません。

Witnessが制約を満たさない場合、Proverは有効な証明を生成できないはずです。

回路の設計はZK開発における最も難しい作業の一つです。

回路の実装が不適切だと、意図と異なる内容を証明してしまう可能性があります。

回路が正しくても効率が悪ければ、証明生成が遅くなったり、コストが高くなったりすることがあります。

Proverの性能向上は、多くの場合、優れた回路設計から始まります。

実行トレース

一部の証明システムでは、アプリケーション固有の従来型回路の代わりに実行トレースを使います。

実行トレースとは、プログラムまたは仮想マシンが行った計算手順の記録です。

Proverはこのトレースを使い、各手順がマシンまたはプロトコルのルールに従ったことを証明します。

この方式はSTARKシステムやzkVMシステムでよく使われます。

大規模なプログラムは巨大なトレースを生成することがあるため、トレース生成が性能の大きなボトルネックになる場合があります。

近年のZK仮想マシン研究では、トレース生成、証明生成パイプライン、ハードウェアアクセラレーションの改善が重視されています。

効率的なトレースは、証明コストとレイテンシーの削減に役立ちます。

Rollupでは、トレース生成の高速化によって証明の送信と決済が速くなる可能性があります。

アプリケーションでは、トレースの高速化により、検証可能な計算が実際のユーザーにとってより実用的になる可能性があります。

Proverは、生の実行データを証明に利用できる形式に変換します。

Proverの性能

Proverの性能は、ゼロ知識を利用する暗号資産システムにおける最も重要な実務上の課題の一つです。

証明生成には、CPU、GPU、メモリ、ストレージ、専用ハードウェアなどの大きなリソースが必要となる場合があります。

証明生成は速いものの検証に時間がかかる証明システムもあります。

証明生成に時間がかかる一方、小型または低コストの証明を生成するシステムもあります。

Rollupの開発チームは、証明生成パイプラインの最適化に多くのエンジニアリング工数を費やすことがよくあります。

Proverが速ければ、決済の遅延を抑えられる可能性があります。

Proverのコストが低ければ、ユーザーのコストを削減できる可能性があります。

スケーラブルなProverは、より多くのトランザクションや複雑なアプリケーションに対応できます。

証明に非常に高価なハードウェアが必要であれば、Proverを運用できる参加者が限られるため、性能は分散化にも影響します。

その結果、ネットワークが少数の専門事業者により依存する可能性があります。

Proverの分散化

Proverの分散化とは、証明生成が単一の当事者に支配されない状態を指します。

初期のZKシステムでは、技術が複雑で運用コストも高いため、証明インフラが中央集権化されていることがよくあります。

時間の経過とともに、多くのプロジェクトが証明処理の分散化を目指しています。

分散型証明には、複数のProver、証明市場、共有証明ネットワーク、コミュニティによる証明、ハードウェアプロバイダー間の競争などが関わります。

証明処理の分散化は、検閲リスク、稼働継続性のリスク、単一運営者への依存を減らせる可能性があります。

ただし、調整上の課題も生じます。

システムは、証明タスクの割り当て、Proverの作業の検証、報酬の支払い、スパム対策、失敗したタスクへの対応、必要に応じた機密Witnessデータの保護を行わなければなりません。

コミュニティ証明の研究では、多数の小規模なマシンがRollupの証明生成に貢献できるかが検討されています。

経済性とセキュリティが十分に機能すれば、証明インフラがより開かれたものになる可能性があります。

Proverの分散化は技術だけの問題ではなく、インセンティブ、ガバナンス、ハードウェアへのアクセス、ソフトウェアの使いやすさにも左右されます。

Prover市場

Prover市場とは、アプリケーション向けの証明生成を複数のProverが競争または協力して行うシステムです。

Rollup、ブリッジ、zkVMアプリ、プライバシーシステムは、Proverのネットワークに証明タスクを依頼する場合があります。

Proverはタスクに入札するか、プロトコルのルールに従って選ばれます。

有効な証明を生成したProverは、報酬を受け取る場合があります。

Prover市場は競争を促し、コスト削減に役立つ可能性があります。

また、アプリケーションが単一の証明サーバーに限定されないため、信頼性の向上にもつながる可能性があります。

ただし、市場には厳格な検証が必要です。無効な証明を拒否し、失敗した作業に対処しなければなりません。

証明タスクに機密性の高いWitnessデータが含まれる場合は、プライバシー保護も必要です。

公開データだけを扱う証明タスクは、安全に外部委託できる場合があります。

一方、他のタスクでは、機密計算、暗号化されたWitness、信頼できるハードウェア、または慎重なプロトコル設計が必要です。

再帰的証明

再帰的証明とは、ある証明を使って別の証明を検証し、その検証自体を証明することです。

抽象的に聞こえますが、スケーリングシステムでは非常に有用です。

Proverは多数の小さな証明を生成し、それらを1つの大きな証明にまとめられます。

これにより検証コストを下げ、オンチェーンに送信するデータ量を減らせる可能性があります。

再帰的証明は、Rollupが多数のトランザクションバッチを集約するのに役立ちます。

また、zkVMが長時間の計算を小さな単位に分けて証明する際にも役立ちます。

再帰的証明はスケーラビリティを高める可能性がある一方、技術的な複雑さも増します。

Proverのパイプラインでは、証明の合成、検証回路、集約スケジュール、性能上のトレードオフを管理する必要があります。

最終証明の生成が先行する証明の完了に依存するため、再帰的証明の設計はレイテンシーにも影響します。

ユーザーが再帰的証明を意識することはほとんどありませんが、速度、手数料、ファイナリティに影響する場合があります。

証明の集約

証明の集約とは、複数の証明を1つの証明、または1回の検証処理にまとめることです。

Proverまたは集約器は、複数の個別証明を受け取り、それら全体を表す単一の証明を作成する場合があります。

ベースチェーンは多数の個別証明ではなく集約済みの証明を1つ検証すればよいため、オンチェーンの検証コストを削減できる可能性があります。

集約は、Rollup、プライバシープール、バッチ決済、クロスチェーンメッセージングシステムに有用です。

複数のアプリケーションが同じ証明生成パイプラインを利用する共有証明インフラにも活用できます。

ただし、十分な数の証明がそろうまで待つ場合、集約によって遅延が生じる可能性があります。

集約器や共有Proverサービスへの依存が生じる場合もあります。

優れた集約設計では、効率、レイテンシー、分散化、信頼性のバランスを取ります。

証明の集約は、Proverが暗号資産インフラの重要なレイヤーになりつつある理由の一つです。

ZK証明を利用するアプリケーションが増えるほど、効率的な集約の価値も高まります。

Proverの稼働継続性

Proverの稼働継続性とは、必要なときに証明を生成し続けられる能力です。

Rollupがバッチの確定に証明を必要とする場合、Proverの停止によって決済が遅れる可能性があります。

ブリッジが資金の払い出しに証明を必要とする場合、Proverの停止で出金が遅れる可能性があります。

プライバシーアプリがユーザーの操作に証明を必要とする場合、Proverの停止でトランザクションを完了できなくなることがあります。

稼働継続性は、証明システムが数学的に安全かどうかだけの問題ではありません。

実際のインフラが負荷、障害、攻撃、ハードウェア故障のもとでも稼働し続けるかどうかにも関わります。

冗長化、分散型証明、タスクキュー、代替Prover、監視、明確な緊急対応手順により、稼働継続性を高められる場合があります。

ZKシステムは正確性に関する信頼を最小化できても、タイムリーな処理には証明インフラに依存する場合があることを、ユーザーは理解しておく必要があります。

誰も証明を生成しなければ、有効な証明があっても役に立ちません。

そのため、Proverの運用はプロトコルの信頼性を構成する要素です。

Proverの健全性（Soundness）

Soundness（健全性）とは、不正なProverが偽の命題をVerifierに真だと信じ込ませられない性質です。

暗号資産では、偽の証明によって無効な状態遷移、偽の出金、不正確な残高、許可されていない操作が可能になるおそれがあるため、健全性は極めて重要です。

健全性の弱い証明システムは、処理が速くても危険です。

健全性は、暗号学的前提、実装品質、パラメーター選択、回路の正しさ、Verifierの正しさに左右されます。

Proverが悪意を持っていても、Verifierは無効な証明を拒否する必要があります。

これが証明システムの大きな強みです。

プロトコルはProverの誠実さを信頼する必要がありません。

必要なのは、証明システムとVerifierが安全であることです。

ただし、回路が誤った命題を証明するよう設計されていれば、証明自体は回路に対して有効でも、アプリケーションを保護できない場合があります。

健全性は、証明システムのレベルとアプリケーション設計のレベルの両方で検討する必要があります。

Proverの完全性（Completeness）

Completeness（完全性）とは、命題が真であれば、誠実なProverが証明を生成できる性質です。

計算が有効でProverが正しいWitnessを持っていれば、検証に合格する証明が生成される必要があります。

有効な証明を拒否したり、安定して生成できなかったりするシステムは実用にならないため、完全性は重要です。

Rollupで完全性が不十分だと、有効なトランザクションバッチを確定できない可能性があります。

プライバシーアプリでは、誠実なユーザーが有効な操作を証明できないおそれがあります。

zkVMでは、実装上のバグやリソース制限によって、正しいプログラムを証明できない場合があります。

完全性は、正しいソフトウェア、十分なメモリと計算能力、互換性のある証明パラメーター、安定したインフラに左右されます。

実際には、開発者は有効な処理を安定して証明できるよう、証明システムを十分にテストします。

Proverには、偽の証明に対する安全性と、真の命題を実用的に証明できる能力の両方が求められます。

優れたProver設計では、セキュリティと使いやすさのバランスを取ります。

Proverとゼロ知識性

ゼロ知識性とは、証明対象の命題が真であること以外に、不要な情報を証明が明かさない性質です。

Witnessに非公開データが含まれる場合、この性質が重要になります。

Proverが知っている情報には、秘密鍵、非公開のトランザクション値、本人確認情報、機密性の高い計算入力などがあります。

ゼロ知識証明では、Proverが秘密を明かさずに必要な主張を証明できる必要があります。

暗号資産で利用されるすべてのValidity Proofに、高度なプライバシーが必要なわけではありません。

一部のシステムは、主に検証コストを下げるために証明技術を使います。

プライバシーが必要な場合、開発者は回路、公開入力、メタデータの処理、ユーザーインターフェースを慎重に設計する必要があります。

証明がゼロ知識でも、周辺データから情報が漏れることがあります。

たとえば、タイミング、ウォレットアドレス、IPデータ、トランザクションのパターンから、ユーザーの行動が推測される可能性があります。

ProverはWitnessを数学的に保護できますが、アプリケーション全体で運用上のプライバシーを守る必要があります。

Prover向けハードウェア

証明システムや処理内容に応じて、ProverはCPU、GPU、FPGA、ASIC、クラウドインフラを利用します。

証明生成では、有限体演算、多項式コミットメント、ハッシュ、Fast Fourier Transform、トレース処理など、大規模な数学的演算が必要となる場合があります。

これらの処理は、並列化や専用ハードウェアによって効率化できる可能性があります。

ハードウェアアクセラレーションは、証明生成の時間とコストを削減できます。

一方、最高性能の証明用ハードウェアを購入できる資金力のある運営者しか参加できなくなれば、中央集権化の圧力が高まる可能性があります。

ソフトウェアの効率を改善したり、一般的なハードウェアに対応したりして、この問題を軽減しようとするプロジェクトもあります。

高いスループットを実現するため、専用の証明クラスターを使うプロジェクトもあります。

ハードウェアの選択はネットワークの目的によって異なります。

最大スループットを目指すシステムでは、より専門的な証明インフラを受け入れる場合があります。

幅広い参加を目指すシステムでは、より利用しやすいマシンで稼働するProver設計を優先する可能性があります。

Proverの手数料と経済性

Proverの運用には費用がかかります。

ハードウェア、電力、帯域幅、エンジニアリング、保守、監視が必要です。

Rollupでは、証明コストがトランザクション手数料、プロトコル収益、補助金、運営者資金によって賄われる場合があります。

Prover市場では、完了した証明タスクに対してProverに直接報酬が支払われることがあります。

証明コストが高いとユーザーの手数料が増える可能性があるため、Proverの経済性は重要です。

また、実用化できるアプリケーションが限られるおそれもあります。

ゲーム、ソーシャルアプリ、少額決済システムでは、すべての操作に高コストの証明生成が必要だと、うまく機能しない可能性があります。

開発者は、回路の最適化、処理のバッチ化、証明の集約、再帰の活用によって、トランザクションあたりの証明コストを削減することがよくあります。

ユーザーがProverの手数料を直接目にすることはなくても、トランザクションコスト、決済の遅延、アプリケーションの制限を通じて影響を受ける場合があります。

効率的な証明生成は、ZKアプリケーションを普及させる鍵の一つです。

Proverのセキュリティリスク

1つ目のリスクは実装上のバグです。

バグのあるProverは、不正確な証明を生成したり、負荷に耐えられなかったり、機密性の高いWitnessデータを漏えいしたりする可能性があります。

2つ目は証明処理の中央集権化です。

単一の運営者しか証明を生成できない場合、その運営者の障害によってシステムが停止したり、検閲されたりするおそれがあります。

3つ目はWitnessの漏えいです。

証明サービスに非公開入力を渡す場合、セキュリティが不十分だとユーザーデータが漏れる可能性があります。

4つ目は回路のバグです。

回路が意図したルールを強制していない場合、Proverは誤った回路に対して有効な証明を生成できます。

5つ目はハードウェアの侵害です。

侵害された証明用マシンは、秘密を漏えいさせたり、タスクを遅延させたり、アプリケーションインフラを攻撃したりする可能性があります。

6つ目は経済的な破綻です。

報酬が不十分であれば、証明処理の容量が不足するおそれがあります。

7つ目はアップグレードのリスクです。

証明ソフトウェア、回路、Verifierコントラクトの変更によって、新たな脆弱性が生じる可能性があります。

Proverとデータ可用性

Proverは正しさを証明しますが、データ可用性を自動的に保証するわけではありません。

データ可用性とは、システムの状態を再構築または検証するために必要なトランザクションデータや状態データを、ユーザーやノードが利用できることです。

この区別はRollupで重要です。

Validity Proofによって状態遷移が有効だと示せても、ユーザーが残高を把握したり、出金したり、状態を再構築したりするための十分なデータが必要です。

データ可用性への対応は、Rollupやスケーリングの設計によって異なります。

ベースチェーンにデータを投稿する方式もあります。

独立したデータ可用性レイヤーを使う方式もあります。

委員会などを利用するモデルもあります。

Proverの役割は命題の証明であり、あらゆる可用性の問題を単独で解決することではありません。

安全なスケーリングシステムには、有効な証明と利用可能なデータの両方が必要です。

Proverとファイナリティ

ファイナリティとは、ネットワークのルールに従ってトランザクションまたは状態更新が決済済みとして受け入れられることです。

Validity Proofを使うシステムでは、証明生成がファイナリティまでの時間に影響する可能性があります。

Layer 2でバッチがすばやく実行されても、ベースチェーン上での最終決済は証明を待つ場合があります。

Proverが速ければ、決済も早くなる可能性があります。

Proverの処理が遅い、または過負荷の場合、最終確認や出金までの待ち時間が延びる可能性があります。

再帰的証明や証明の集約は効率を高められる一方、バッチ処理による遅延を生む場合があります。

ファイナリティは、ベースチェーンのブロック時間、承認ルール、Verifierコントラクトの実行にも左右されます。

Proverはファイナリティの処理工程の一部にすぎません。

それでも、Proverの速度はZKシステムで特に目立つボトルネックとなることがよくあります。

Proverの性能向上により、ZKアプリケーションの速度と信頼性が高まる可能性があります。

Proverとブリッジ

ブリッジでは、一方のチェーンで発生したイベント、状態遷移、メッセージを証明するためにProverを利用できます。

証明ベースのブリッジでは、中央の署名者グループを信頼することなく、あるチェーンが別のチェーンに関する事実を検証できる場合があります。

たとえばProverは、特定のトランザクション、状態ルート、メッセージが送信元チェーン上で有効だったことを示す証明を生成します。

送信先チェーンのVerifierコントラクトが、その証明を確認します。

一部のブリッジモデルと比べて、信頼上の前提を減らせる可能性があります。

ただし、証明ベースのブリッジにも複雑な課題があります。

チェーンの再編成、ファイナリティの前提、Verifierの正しさ、データ可用性、証明コスト、アップグレードのリスクに対処する必要があります。

Proverはブリッジの信頼上の前提を改善できる場合がありますが、ブリッジ設計を自動的に安全にするものではありません。

ユーザーは、クロスチェーンシステムを引き続き高リスクのインフラとして扱う必要があります。

ブリッジの安全性はProverの有無だけではなく、アーキテクチャ全体に左右されます。

Proverとプライバシー

プライバシーを重視する暗号資産アプリケーションでは、機密情報を隠したまま、ユーザーがルールを満たしていることを示すのにProverが役立ちます。

たとえばユーザーは、資格情報全体を明かさずに、それを保有していることを証明できます。

すべての非公開トランザクション詳細を開示せずに、残高が有効であることを証明できる場合もあります。

グループ内の誰であるかを明かさずに、そのグループの一員であることを証明することもできます。

Proverは非公開入力を使って証明を作成します。

Verifierは公開ルールに基づいて証明を確認します。

これにより、必要な情報だけを選択的に開示できます。

ただし、プライバシーは証明だけで決まるものではありません。

メタデータ、ネットワーク上の活動、タイミング、アドレスの再利用、ブラウザーのフィンガープリント、アプリケーションのログから情報が漏れる可能性があります。

強固なプライバシーシステムには、暗号学的Witnessだけでなく、ユーザーの利用プロセス全体を保護する設計が必要です。

Proverとコンプライアンス

必要以上の非公開データを明かさずに事実を証明できるため、Proverはコンプライアンスに配慮した暗号資産設計を支援する場合があります。

たとえば、ユーザーは本人確認書類全体をオンチェーンで開示せずに、参加要件を満たしていることを証明できます。

プロトコルは、機密性の高い事業データを公開せずに、計算が定められたルールに従ったことを証明できます。

金融アプリケーションは、内部記録をすべて公開せずに、状態遷移が会計上の制約を満たすことを証明できる場合があります。

ただし、ゼロ知識証明によってすべてのコンプライアンス上の問題が自動的に解決されるわけではありません。

法的要件は、法域や利用目的によって異なります。

記録の保持、監査、本人確認、報告、情報開示が引き続き必要となるルールもあります。

Proverは不要なデータの公開を減らせますが、法的分析に取って代わるものではありません。

適切なコンプライアンス設計では、暗号技術、方針、ガバナンス、ユーザーの同意を組み合わせます。

Proverは選択的な検証を可能にしますが、何を証明する必要があるかは人が決めます。

Proverのメリット

1つ目のメリットはスケーラビリティです。

Proverは大規模な計算を、より低コストで検証できる証明に圧縮できます。

2つ目はプライバシーです。

ゼロ知識に対応するよう設計された証明システムでは、データ自体を明かさずに、非公開データに関する事実を証明できます。

3つ目は信頼の最小化です。

無効な証明が拒否されるなら、VerifierはProverの誠実さを信頼する必要がありません。

4つ目は相互運用性です。

証明を使うことで、あるシステムが別のシステムに関する事実を検証できる場合があります。

5つ目は監査可能性です。

証明は、計算が定められたルールに従ったことを示す数学的な根拠となります。

6つ目は自動化です。

スマートコントラクトは証明を検証し、人手による確認なしで処理を実行できます。

7つ目は効率性です。

証明の集約と再帰によって、多数のトランザクションやアプリケーションにわたる検証コストを削減できる可能性があります。

Proverの限界

1つ目の限界はコストです。

証明生成には多くの計算コストがかかる場合があります。

2つ目はレイテンシーです。

証明生成に時間がかかり、決済や出金が遅れる可能性があります。

3つ目は複雑さです。

Proverシステムには、専門的な暗号技術、エンジニアリング、セキュリティレビューが必要です。

4つ目は中央集権化の圧力です。

高いハードウェア要件により、多数の独立した主体がProverを運用しにくくなる可能性があります。

5つ目は回路への依存です。

証明できるのは、回路またはプログラムが実際に検証する内容に限られます。

6つ目は、証明の外部でのプライバシー漏えいです。

ゼロ知識証明を使っても、メタデータや不適切なアプリケーション設計が自動的に隠されるわけではありません。

7つ目はアップグレードのリスクです。

証明ソフトウェア、回路、Verifierコントラクトの変更により、新たなセキュリティ上の前提が生じる場合があります。

ユーザーがProverについて知っておくべきこと

ほとんどのユーザーはProverを直接操作しません。

ユーザーが利用するウォレット、Rollup、ブリッジ、プライバシーアプリ、分散型アプリケーションの背後でProverが使われています。

それでもProverは速度、手数料、ファイナリティ、信頼上の前提に影響するため、その役割を理解しておくことが重要です。

Rollupが中央集権型のProver1つに依存している場合、そのProverが停止したときに何が起こるか確認しましょう。

プライバシーアプリがリモートの証明サービスを使う場合、非公開データがそのサービスに送信されるか確認しましょう。

ブリッジが証明に依存している場合、その証明が何を検証し、何を検証しないのか確認しましょう。

Verifierコントラクトが監査されているか、証明システムに明確なセキュリティモデルがあるかも確認してください。

Proverが存在するだけで安全性が保証されるわけではありません。

証明システム、回路、Verifier、データ可用性、ガバナンスが適切に設計されて初めて、Proverの価値が発揮されます。

証明処理はセキュリティの一つのレイヤーであり、システム全体ではないと考えてください。

開発者向けのベストプラクティス

開発者は、Proverが何を証明するのかを明確に定義する必要があります。

意図したルールを正確に強制する回路またはプログラムを設計してください。

十分にレビューされた証明システムを使い、専門家のレビューなしに独自の暗号技術を実装するのは避けましょう。

現実的な負荷、エッジケース、障害条件を含めて証明生成をテストしてください。

Proverの処理時間、メモリ使用量、ハードウェア要件、検証コストをベンチマークしてください。

証明処理に機密性の高いユーザーデータが関わる場合は、非公開のWitnessを保護してください。

Verifierが実際に何を確認するのかをユーザーや監査担当者が理解できるよう、公開入力を文書化してください。

可能であれば、Proverインフラと信頼された管理者権限を分離してください。

Proverの停止、タスクの再試行、監視、緊急時の代替手段を計画してください。

回路、Proving Key、Verifierコントラクト、Proverソフトウェアを変更する際は、アップグレードのリスクを伝えてください。

Proverに関するよくある誤解

誤解の一つは、Proverを信頼しなければならないというものです。

適切に設計された証明システムでは、Proverが不正でも、Verifierは無効な証明を拒否する必要があります。

もう一つの誤解は、Proverが常にプライバシーを提供するというものです。

一部のProverは、トランザクションデータ全体を隠すことなく、スケーラビリティのためにValidity Proofを生成します。

証明生成が安価だという誤解もあります。

証明生成は検証よりはるかに高コストとなる場合があり、専用インフラが必要になることもあります。

有効な証明がアプリケーションのすべてを証明するというのも誤解です。

証明できるのは、回路またはプログラムに記述された特定の命題だけです。

Proverの分散化があらゆる場所ですでに実現しているという誤解もあります。

多くのシステムでは、より開かれた分散型証明インフラの実現に向けた取り組みが続いています。

ユーザーがProverを気にする必要はないという誤解もあります。

ユーザー自身がProverを運用しなくても、Proverの設計は出金、ファイナリティ、手数料、プライバシー、アプリケーションの信頼性に影響する可能性があります。

FAQ

暗号資産におけるProverとは何ですか？

Proverとは、命題、計算、状態遷移が有効であることを示す暗号学的証明を生成する主体、プログラム、ノード、またはサービスです。

ゼロ知識証明におけるProverとは何ですか？

ゼロ知識証明では、Proverは不要な非公開情報を明かさずに命題が真だとVerifierに納得させる証明を作成します。

ProverとVerifierの違いは何ですか？

Proverは証明を生成し、Verifierは証明が有効かどうかを確認します。

ZK-rollupでProverが重要なのはなぜですか？

ProverはValidity Proofを生成し、すべてのノードが全トランザクションを再実行しなくても、トランザクションバッチをベースチェーン上で決済できるようにします。

ProverはSequencerと同じですか？

いいえ。Sequencerはトランザクションを並べ替え、Proverは正しい実行または有効な状態遷移を示す暗号学的証明を生成します。

Proverは常に非公開データを隠しますか？

いいえ。スケーラビリティと正確性を主な目的とするProverもあります。プライバシーは、証明システムとアプリケーションがゼロ知識に対応するよう設計されているかによって異なります。

不正なProverは偽の証明を作れますか？

安全な証明システムでは、不正なProverが偽の命題に対して有効な証明を作れないようにする必要があります。

証明生成にはなぜコストがかかるのですか？

証明生成には、大規模な計算、メモリ負荷の高いトレース生成、多項式演算、ハッシュ、再帰、専用ハードウェアが必要となる場合があるためです。

証明生成におけるWitnessとは何ですか？

Witnessとは、Verifierに必ずしも開示することなく、Proverが証明生成に使う非公開データまたは内部データです。

再帰的証明とは何ですか？

再帰的証明とは、別の証明が有効であることを証明する方法です。多数の証明を、より小さく効率的な証明にまとめるのに役立ちます。

RollupのProverが停止するとどうなりますか？

RollupがそのProverに依存している場合、証明処理能力が回復するか、バックアップのProverが使われるまで、証明の送信と最終決済が遅れる可能性があります。

Proverの分散化は可能ですか？

可能です。分散型証明は活発に開発・研究されていますが、タスクの割り当て、報酬、信頼性、プライバシー、検証に関する解決策が必要です。

まとめ

Proverは、現代の暗号資産証明システムにおいて最も重要なインフラ上の役割の一つです。

Verifierが基盤となる処理をすべて再実行しなくても、命題、計算、トランザクションバッチ、状態遷移を確認できるよう、暗号学的証明を生成します。

Proverは、ゼロ知識証明、ZK-rollup、zkVM、STARKシステム、SNARKシステム、証明の集約、再帰的証明、プライバシープロトコル、ブリッジ、検証可能な計算の中核を担います。

Proverの主な価値は、重い計算をVerifierから切り離しながら、信頼できる検証を維持できることです。

これにより、スケーラビリティの向上、オンチェーン処理の削減、プライバシーの支援、新しいアプリケーション設計の実現につながる可能性があります。

一方で、Proverには現実的な課題もあります。

証明生成は高コスト、低速、ハードウェア集約型となる場合があり、運用も複雑で、中央集権化されることもあります。

証明の有用性は、証明対象の命題、確認する回路やプログラム、検証するVerifier、証明処理を稼働させ続けるインフラに左右されます。

ユーザーにとって重要なのは、Proverによって暗号学的検証を効率化できても、Rollup、ブリッジ、プライバシーアプリ、スマートコントラクトシステムのあらゆるリスクがなくなるわけではないという点です。

開発者にとって重要なのは、Proverを安全かつ効率的に設計し、十分にテストし、プライバシーに配慮して、明確に文書化することです。

簡単に言えば、Proverは難しい数学的処理を担い、暗号資産ネットワークの他の参加者が結果をすばやく、信頼を最小限に抑えて検証できるようにします。