diff --git a/GEMINI.md b/GEMINI.md new file mode 100644 index 0000000..61726df --- /dev/null +++ b/GEMINI.md @@ -0,0 +1,73 @@ +# Project Overview + +This is a Rust project for benchmarking the "VOLE in the Head" (VOLEitH) zero-knowledge proof system. The primary goal is to evaluate the feasibility and performance of on-chain verification for VOLEitH proofs. The project is structured as a Rust library and a command-line interface (CLI) application. It uses various cryptographic libraries, including `ark-groth16`, `ark-bn254`, and a custom `schmivitz` library, to implement and benchmark the proof system. + +The project also includes a benchmarking suite using `criterion` to measure performance metrics such as proof generation time, verification time, proof size, and computational load (CPU and memory usage). + +# Building and Running + +## Building the Project + +To build the project, use the standard Cargo command: + +```bash +cargo build --release +``` + +## Running the CLI + +The project includes a CLI for generating proofs. The following command can be used to generate a proof using the `keccak_f` algorithm: + +```bash +cargo run --release -- prove --algorithm keccak_f +``` + +## Running the Benchmarks + +To run the performance benchmarks, use the following command: + +```bash +cargo bench +``` + +The benchmark results, including detailed reports, will be available in the `target/criterion` directory. + +# Development Conventions + +## Code Style + +The project follows standard Rust conventions. Code is formatted using `rustfmt`. + +## Testing + +The project uses a combination of unit tests and integration tests. The core logic is tested through the benchmarking suite in the `benches` directory. + +## Dependencies + +The project's dependencies are managed using `Cargo.toml`. Key dependencies include: + +- `schmivitz` and `schmivitz-snark`: Core libraries for VOLEitH proofs. +- `arkworks` libraries (`ark-groth16`, `ark-bn254`, etc.): For zero-knowledge proof implementations. +- `criterion`: For performance benchmarking. +- `clap`: For the command-line interface. + +# Paper Writing Guidelines + +This section outlines the guidelines for writing the research paper located in the `paper/` directory. + +## Target Publication + +The paper is to be submitted to the **SCIS (Symposium on Cryptography and Information Security)**, a Japanese security conference. + +## Target Audience + +The intended audience is individuals who are **not deeply familiar with Ethereum or zero-knowledge proofs**. + +## Writing Style and Structure + +- The paper must be structured as a formal academic paper. +- The language and structure should be tailored to clearly convey the significance of this research to the target audience. +- Use logical explanations, mathematical formulas, and diagrams to explain complex concepts. +- The paper should be written in Japanese. +- All necessary information for writing the paper is located within this directory. +- If more precise or detailed information is needed, please ask. diff --git a/improve.md b/improve.md new file mode 100644 index 0000000..b73573e --- /dev/null +++ b/improve.md @@ -0,0 +1,58 @@ +# 論文「EthereumにおけるVOLE-in-the-Headの検証コスト評価」改善案 + +## 総合評価 + +本論文は、VOLE-in-the-HeadとSNARKを組み合わせたハイブリッドアーキテクチャの性能と課題を定量的に示した、技術的に価値の高い研究である。論理構成は明晰であり、データに基づく分析は詳細かつ説得力がある。 + +一方で、ターゲット読者として「Ethereumとゼロ知識証明の初心者」を想定する場合、専門用語の密度と概念の抽象度の高さが、読者の理解を妨げる可能性がある。研究の貢献をより広い読者層に的確に伝えるため、以下の改善を提案する。 + +## 優先的に取り組むべき改善点 + +### 1. 概念の段階的導入と具体例による補足 + +専門用語や抽象的な概念を提示する際に、読者の理解を助けるための工夫を導入する。 + +* **背景・目的の先行提示**: + 各技術概念（例：ゼロ知識証明, VOLE, コミットメント）を定義する前に、まず「なぜその技術が必要とされるのか」という動機付けや、解決しようとしている課題を平易な言葉で説明する。例えば、ゼロ知識証明であれば、プライバシーを保護したID検証や金融取引といった具体的なユースケースを先に示す。 + +* **機能的な比喩・具体例の活用**: + 抽象的な定義の後には、その概念の機能を説明する簡潔な具体例を添える。「コミットメント」であれば、「後から変更できないように、情報をデジタルな封筒に入れて封印し、必要に応じて開封して中身を示す仕組み」のように、その役割を直感的に理解できる表現を用いる。 + +* **基本用語の脚注による補足**: + 「ガス代」「スマートコントラクト」「有限体」など、特定の技術領域に固有の基本用語については、本文の記述の流れを維持しつつ、脚注（`\footnote`）を用いて簡潔な定義を補足する。 + +### 2. 論文構成のナビゲーション強化 + +読者が論文全体の論理構成や、各章・各節の役割を把握しやすくするための工夫を施す。 + +* **章・節の冒頭での要旨提示**: + 各章（`\section`）および主要な節（`\subsection`）の冒頭に、そのセクションで論じる内容、目的、そして導かれる結論を要約した短いパラグラフを設ける。これにより、読者は詳細な議論に入る前にその位置付けと要点を理解できる。 + +* **論理的接続の明確化**: + セクション間の繋がりを強化するため、「前節では〜という課題を明らかにした。本節では、この課題に対し〜というアプローチで評価を行う」といった、論理の流れを示す接続表現を効果的に使用する。 + +### 3. 視覚的要素と参考文献管理の高度化 + +論文の可読性と学術的な体裁を向上させる。 + +* **図・表の効果的な活用**: + * **アーキテクチャ図**: 提案するハイブリッドアーキテクチャ（VOLEitH + SNARK）の全体像を示す概念図は、システムの構成要素とデータフローを読者が直感的に理解するために不可欠である。 + * **結果の可視化**: 性能測定結果（例：SNARKの制約数と証明生成時間の関係）は、グラフを用いて視覚的に示すことで、数値データだけでは伝わりにくい傾向や相関関係を明確に伝えられる。 + +* **参考文献管理の自動化**: + 現在の手動による参考文献リスト（`thebibliography`）の管理は、項目数の増加に伴い、フォーマットの不統一やエラーを引き起こす可能性が高い。BibTeXやBibLaTeXといった文献管理システムを導入し、`.bib`ファイルで文献情報を一元管理することを強く推奨する。これにより、引用スタイルの一貫性が保証され、論文の学術的信頼性が向上する。 + +## セクションごとの具体的な改善案 + +* **Introduction (`intro.tex`)**: + * ゼロ知識証明、オンチェーン検証、クライアントサイドプルービングといった核心的な課題について、初学者にも理解可能な平易な言葉で説明を加える。 + +* **Preliminaries (`preliminaries.tex`)**: + * VOLE, VOLE-in-the-Head, Groth16などの技術解説において、数式や専門用語を提示する前に、それぞれの技術が「何をするためのものか」という目的・役割を記述する。 + +* **Results and Analysis (`results_analysis.tex`)**: + * 各サブセクションの冒頭で、「この分析から何が明らかになったか」という結論を簡潔に要約する。 + * 「Field Mappingに起因する制約数爆発」のような複雑な現象については、その原因と結果の関係性をより丁寧に解説する。 + +* **Conclusion (`conclusion.tex`)**: + * 研究全体の結論を再確認した上で、「今後の展望」で提示される各研究課題が、「なぜ重要なのか」という文脈（例：ポスト量子耐性の必要性）を補足する。 diff --git a/paper/abstract.tex b/paper/abstract.tex index 31c28fd..2cf6f0d 100644 --- a/paper/abstract.tex +++ b/paper/abstract.tex @@ -1,6 +1,6 @@ \begin{abstract} -Vector Oblivious Linear Evaluation (VOLE) を用いたMPC-in-the-Head型ゼロ知識証明 VOLE-in-the-Head (VOLE-itH) は、線形演算をVOLEプリプロセスに置き換えることで証明生成コストを大幅に削減する。 +Vector Oblivious Linear Evaluation (VOLE) は、二者間で線形関係を秘匿したまま、ある種の相関を生成するための暗号学的プリミティブであり、これを応用したゼロ知識証明 VOLE-in-the-Head (VOLE-itH) は、従来のゼロ知識証明と比較して線形演算をVOLEプリプロセスに置き換えることで証明生成コストを大幅に削減する。 一方、Ethereum での公開検証ではオンチェーン検証コストが実用性のボトルネックとなる。本研究は、VOLE-itH のオンチェーン適用に向けた実装ベースの評価として、(1) 証明生成・検証の計算量と証明サイズを測定し、(2) SNARK (Groth16) で圧縮した上で Ethereum verifier を実装し、そのガスコストを評価した。 -SHA-256／Keccak-F／基本論理回路でベンチマークした結果、VOLE-itH の証明生成は Circom 実装より最大 15.5× 高速だが証明サイズは 6000× 増大した。SNARK で圧縮すると証明サイズを 1,055 バイトに固定でき、オンチェーン検証は実測で xxx gas で完了した。 +SHA-256／Keccak-F／基本論理回路でベンチマークした結果、VOLE-itH の証明生成は Circom 実装より最大 15.5× 高速だが証明サイズは 6000× 増大した。SNARK で圧縮すると証明サイズを 1,055 バイトに固定でき、オンチェーン検証は実測で 208,967 gas で完了した。 これらの結果から、VOLE-itH をブロックチェーン応用に適用する際のコスト・圧縮トレードオフと実用条件を明らかにする。 \end{abstract} diff --git a/paper/analysis.tex b/paper/analysis.tex new file mode 100644 index 0000000..3b69483 --- /dev/null +++ b/paper/analysis.tex @@ -0,0 +1,155 @@ +\subsection{SNARK統合に関する洞察} +VOLEitHの証明をGroth16で包むと、証明サイズと検証コストは一定になる一方で、R1CS制約数が急増する。 +ここでは制約数の内訳と、制約爆発の要因および緩和策を整理する。 + +\subsubsection{制約数の分解} +SNARK回路における制約数の増加は、主にVOLEitH検証ロジック内の特定の計算ステップに起因する。全体として、制約数は主に検証対象となるゲートの数に比例する線形項と、検証プロトコル全体で固定的に発生する定数項から構成される。 +$n$ をVOLEitH検証における主要な変数（例えば、秘密入力数や乗算ゲート数に関連する拡張witnessの長さ）とすると、全体の制約数は概ね +\begin{align*} +16,640 \times n + 2,113,664 +\end{align*} +と表せる。線形項に寄与する主要な処理は表\ref{tab:linear_constraints}の通りであり、特に**検証値の集約計算**が支配的である。 + +\begin{table}[H] + \centering + \caption{線形に増加する処理の制約数} + \label{tab:linear_constraints} + \begin{tabular}{|l|r|} + \hline + 処理内容 & 制約数 \\ + \hline + $d$値の計算 & $128n$ \\ + マスクされたwitnessの計算 & $256n$ \\ + 検証値の集約計算 & $16,512n$ \\ + \hline + 合計 & $\approx16,640n$ \\ + \hline + \end{tabular} +\end{table} + +また、回路サイズに依存しない定数項も無視できない（表\ref{tab:constant_constraints}）。乗算ゲートが増えると線形項が支配するが、ベースラインとして約200万制約が常に必要になる。 + +\begin{table}[H] + \centering + \caption{定数項として加算されるガジェット} + \label{tab:constant_constraints} + \begin{tabular}{|l|r|} + \hline + ガジェット & 制約数 \\ + \hline + $combine$ & $\sim2,097,152$ \\ + $compute_actual_validation$ & $\sim16,384$ \\ + 最終整合性チェック & $\sim128$ \\ + \hline + 合計 & $\sim2,113,664$ \\ + \hline + \end{tabular} +\end{table} + +\subsubsection{フィールド変換がもたらす制約爆発} +VOLEitHは、$\mathbb{F}_2$、$\mathbb{F}_{2^8}$、$\mathbb{F}_{2^{64}}$、$\mathbb{F}_{2^{128}}$といった2進拡大体上で演算を行う。 +一方で、Groth16のような多くのzk-SNARKシステムが利用するR1CS（Rank-1 Constraint System）は、BN254のような素数体上で定義される。この根本的な体構造の違いが、制約爆発の最大の要因となる。 +2進拡大体の要素をSNARK回路内で扱うためには、各ビット列を素数体上のBoolean変数列として表現する**フィールド変換**が必要となる。 +この変換により、VOLEitHの検証ロジックにおける各ビット演算（ANDやXORなど）が素数体上の制約として展開され、もともと単一の体要素で表現できた計算が数百ビットのAND/XORに分解されるため、制約数が爆発的に増加する。 + +\subsubsection{乗算（ANDゲート）処理の検証コスト} +VOLEitH検証ロジックにおいて、特に**乗算処理**（R1CSにおけるANDゲートに相当）の検証は高コストとなる。これは、2進拡大体上の乗算をSNARKの素数体上で表現する際に、ビットごとのAND/XOR演算が多数必要となるためである。 +例えば、128ビットの2つの要素の乗算を検証する際には、ビットレベルで$128 \times 128$のANDおよびXOR演算が必要となり、これが**ANDゲート1つあたり$2^{14}$規模の制約を追加する主要因**となる。 +加算処理（ADDゲート）の検証では、このようなビットレベルの複雑な乗算処理が不要なため制約数は一定に保たれるが、乗算処理が増えるほど、全体としての検証ロジックの複雑性がSNARKフェーズ全体のボトルネックとなる。 + +\subsection{技術的ボトルネックと解決策} +上記の分析から、Field MappingとGGMツリー再構成が制約爆発の主要因であることが分かる。 +本節では、これらを緩和するための具体的な研究方向を整理する。 + +\subsubsection{Field Mapping最適化とLookup Table} +Mystique\cite{eprint:2021:730}は、機械学習向けに$\mathbb{F}_2$と$\mathbb{F}_p$のデータ変換を効率化するVOLEベースZKであり、Lookup Table (LUT) を導入することでさらに高速化できることが最新研究\cite{eprint:2025:507}で示されている。 +表\ref{tab:mystique_lut}に示す通り、LUTを用いた場合には実行時間が61--130倍短縮し、通信量も最大2.9倍削減できる。 +VOLEitHのField MappingにMystique型LUTを適用できれば、SNARKフェーズの制約数削減に直結すると期待される。 + +\begin{table}[H] + \centering + \caption{MystiqueとLUT拡張の性能比較} + \label{tab:mystique_lut} + \begin{tabular}{|l|l|r|r|} + \hline + 関数 & プロトコル & 実行時間 (s) & 通信量 (MB) \\ + \hline + 指数関数 & Mystique with LUT & 8.696 & 99.020 \\ + & Mystique & 1130.020 & 291.435 \\ + 除算 & Mystique with LUT & 9.837 & 110.684 \\ + & Mystique & 617.690 & 160.428 \\ + 逆平方根 & Mystique with LUT & 11.836 & 147.903 \\ + & Mystique & 824.639 & 212.211 \\ + \hline + \end{tabular} +\end{table} + +\subsubsection{GGMツリー最適化とFolding} +Schmivitzでは、VOLEitH検証で最もコストの高いGGMツリー再構成を簡略化しているが、SNARKで完全に検証する場合はこの部分が制約増大を引き起こす。 +著者らはGGMツリーを効率化する手法\cite{eprint:2024:490}に加え、FAESTを改良したFAESTERを提案しており、署名サイズと計算量をともに改善している（表\ref{tab:faester}）。 +本研究で検討したFoldingスキームとこれらの最適化を組み合わせれば、将来的にGGMツリー再構成部の制約数を抑制できる。 + +\begin{table}[H] + \centering + \caption{FAESTとFAESTERの比較（セキュリティ128ビット）} + \label{tab:faester} + \begin{tabular}{|l|l|r|r|r|} + \hline + スキーム & バージョン & 署名サイズ (B) & 署名時間 (ms) & 検証時間 (ms) \\ + \hline + FAEST & Slow & 50,063 & 4.3813 & 4.1023 \\ + & Fast & 63,363 & 0.4043 & 0.3953 \\ + FAESTER & Slow & 45,943 & 3.2823 & 4.4673 \\ + & Fast & 60,523 & 0.4333 & 0.6103 \\ + \hline + \end{tabular} +\end{table} + +\subsection{総合考察とトレードオフ分析} +これまでの分析結果を統合し、VOLEitHとSNARKを組み合わせたアーキテクチャ全体の有効性とトレードオフについて考察する。 + +本研究で採用したアーキテクチャは、\textbf{図2}に示すように、証明者側（Prover）で2段階のプロセスを経て、検証者側（Verifier）であるブロックチェーン上で効率的な検証を実現するものである。 + +\begin{figure}[htbp] + \centering + % ここにVOLEitH + SNARKによる証明圧縮プロセスの概念図を挿入 + % 例: [Prover: 回路] -> [VOLEitH証明 (数MB)] -> [SNARK証明 (1KB)] -> [Verifier (オンチェーン)] + \caption{VOLEitH + SNARKによる証明圧縮プロセスの概念図} + \label{fig:proof_compression_flow} +\end{figure} + +図\ref{fig:proof_compression_flow}が示す通り、本アーキテクチャは、VOLEitHが生成する巨大な証明（数MBオーダー）を、SNARKを用いてオンチェーン検証に適したコンパクトな証明（1KBオーダー）に圧縮する点に核心がある。 +このアプローチにより、以下の2つの大きな利点を両立することが可能となる。 + +\begin{enumerate} + \item \textbf{高速な証明者計算}: VOLEitHは、証明生成時間がマイクロ秒からミリ秒オーダーと非常に高速である（表\ref{tab:vole_phase}参照）。 +これにより、計算能力が限られるクライアントデバイス（例: Webブラウザ、スマートフォン）でも、複雑な計算の証明を現実的な時間で生成できる可能性が広がる。 + \item \textbf{低コストなオンチェーン検証}: SNARK化された証明は、サイズが小さく、検証コストが回路の複雑さによらず一定であるため、ブロックチェーン上での検証コスト（ガス代）を大幅に削減し、予測可能なものにできる（表\ref{tab:snark_phase}参照）。 +\end{enumerate} + +一方で、このアーキテクチャには考慮すべきトレードオフも存在する。最大のトレードオフは、証明者側の計算負荷である。 +証明者は、高速なVOLEitH証明生成に加えて、SNARK証明を生成するための追加の計算コストを負担する必要がある。 +特に、回路が多くの乗算（ANDゲート）を含む場合、SNARKの制約数が急増し、SNARK証明の生成時間が全体のボトルネックとなる（図\ref{fig:snark_constraints_time}参照）。 + +したがって、本アーキテクチャは、以下のような特性を持つユースケースにおいて特に有効であると考えられる。 +\begin{itemize} + \item \textbf{クライアントサイドでの証明生成}: ユーザー自身のデバイスで証明を生成し、サーバーやブロックチェーンに送信するアプリケーション。 +例えば、プライバシーを保護した上での本人確認（分散型ID）、プライベートな状態を持つゲーム、機密データを用いた計算の検証などが挙げられる。 + \item \textbf{オンチェーンコストの最小化が重要}: ブロックチェーンのスケーラビリティが重視され、トランザクションコストを可能な限り抑えたいアプリケーション。 +\end{itemize} + +結論として、VOLEitHとSNARKを組み合わせたハイブリッドアプローチは、「証明者の高速性」と「検証者の低コスト」という、一見すると相反する要求を両立させるための有望なアーキテクチャである。 +その性能は回路の特性、特に乗算の数に大きく依存するため、アプリケーションを設計する際には、このトレードオフを十分に理解することが重要となる。 + +\subsection{実用アプリケーションへの適用可能性} +本研究のベンチマーク結果と、既存の代表的なzk-SNARKアプリケーションであるTornado Cashのデータを比較することで、本ハイブリッドアーキテクチャの実用アプリケーションへの適用可能性について考察する。 +Tornado CashのGroth16検証回路の制約数は、典型的なMerkle木の深度（例: 20）において約2.8万制約と報告されており、これはZKPに最適化されたハッシュ関数を用いた効率的な設計がなされているためである。 +一方、本研究におけるVOLEitH検証ロジックをSNARK化した際の制約数は、ADDゲート回路では約8.6万制約（100/1000ゲート）であり、ANDゲート回路では100ANDゲートで約350万制約、1000ANDゲートで約3400万制約となった。 +この比較から、本ハイブリッドアーキテクチャの実用アプリケーションへの適用性について以下の結論が導かれる。まず、本研究のハイブリッドアーキテクチャは、VOLEitHの汎用的な検証ロジックをSNARK化する際に、Tornado Cashのような最適化されたZKPアプリケーションと比較して高い制約数を生じる傾向にある。 +特に、ADDゲートのみで構成される比較的シンプルな回路の場合でも約8.6万制約となり、Tornado Cashの約2.8万制約よりも高い。 +このため、極めて制約数に敏感なアプリケーションではさらなる最適化が必要となるだろう。加えて、多くの乗算処理（算術回路におけるANDゲートに相当）を含む複雑なアプリケーションにおいては、制約数が数百万から数千万に達し、Tornado Cashの制約数と比較して**桁違いに大きい**。 +例えば、SHA-256のような暗号学的ハッシュ関数、デジタル署名の検証（ECDSAなど）、機械学習モデルの推論といったアプリケーションは、内部で多数の乗算やビット演算を必要とするため、このカテゴリに該当する。 +この「制約爆発」は、SNARK証明生成時間を著しく長期化させ、クライアント側の計算資源を過度に消費するため、現在の実装はこのような**複雑な実用アプリケーションには、現状では耐え得ない**と結論せざるを得ない。 +実際、SHA-256のような複雑なハッシュ関数の検証回路のSNARK化は、制約数の爆発により実装を断念した経緯がある。 +この結果は、本研究が、Tornado CashのようなSNARKフレンドリーに設計されたアプリケーションとは異なり、VOLEitHの汎用的な検証ロジック（特にビット単位の乗算処理）をSNARK化する際の根本的な技術的課題を定量的に浮き彫りにしたことを意味する。 +実用アプリケーションへの適用には、Field Mappingの最適化やGGMツリー再構成の効率化といった、本論文で提案されたボトルネック解決策の導入が不可欠である。 diff --git a/paper/conclusion.tex b/paper/conclusion.tex index f6a2e46..d8f7cfc 100644 --- a/paper/conclusion.tex +++ b/paper/conclusion.tex @@ -1,11 +1,12 @@ \section{結論と今後の展望 (Conclusion and Future Work)} +本論文では主にGroth16を採用したが、今後の展望として、FAEST/FAESTER（高速なポスト量子署名スキーム）、Binius（二進演算に特化したZKPシステム）、およびUniversal SNARK（単一のセットアップで任意の回路に対応可能なSNARKs、例：Plonk/Halo2）などの代替技術の検討が挙げられる。 \subsection{結論} 本研究では、証明者効率の高いVOLE-in-the-Head（VOLEitH）プロトコルと、証明圧縮に優れたSNARKを組み合わせたハイブリッドアーキテクチャを構築し、そのオンチェーン検証における実現可能性と性能を定量的に評価した。 ベンチマークを通じて、以下の主要な知見が得られた。 \begin{enumerate} - \item \textbf{VOLEitHの基本的なトレードオフ}: VOLEitHは、CircomのようなR1CSベースのシステムと比較して、証明者の計算を最大15.5倍高速化する一方で、生成される証明サイズが6000倍以上も増大することが確認された。 + \item \textbf{VOLEitHの基本的なトレードオフ}: VOLEitHは、証明者の計算をマイクロ秒からミリ秒オーダーで実行可能であり、その高速性が確認された。一方で、生成される証明サイズは、基本的な回路であっても数十KBから数百KBに達し、オンチェーン検証に用いられるSNARK証明（1KB）と比較して依然として大きく、その圧縮の必要性が再確認された。 この巨大な証明は、単体ではオンチェーン検証の大きな障壁となる。 \item \textbf{SNARK圧縮の有効性}: VOLEitHの証明をSNARK（Groth16）で圧縮することにより、回路の複雑さに関わらず、最終的な証明サイズを1,055バイト、オンチェーン検証コストを約21万ガスに固定化できることを示した。 これにより、VOLEitHのオンチェーン応用の道が拓かれる。 @@ -18,13 +19,12 @@ \subsection{今後の展望} 本研究の成果を踏まえ、特に優先度の高い研究課題は以下の3点である。 \begin{enumerate} \item \textbf{Field Mapping最適化}: Mystique型のデータ変換やLookup TableをVOLEitHに取り入れ、$\mathbb{F}_2$と$\mathbb{F}_p$間の射像コストを削減する。 - \item \textbf{GGM木再構成の高度化}: FAESTERのような最適化とFoldingスキームを組み合わせ、検証フェーズに必要な制約数を抑制する。 + \item \textbf{GGMツリー再構成の高度化}: FAESTERのような最適化とFoldingスキームを組み合わせ、検証フェーズに必要な制約数を抑制する。 \item \textbf{代替SNARK/証明システムの検討}: BiniusやRecursive SNARKなど、二進演算に適した新しい証明システムを評価し、ボトルネックの抜本的解決を目指す。 \end{enumerate} これらに加えて、以下のエンジニアリング課題にも継続的に取り組む必要がある。 \begin{itemize} \item \textbf{SNARK証明生成の最適化}: VOLEitHからR1CSへの変換フローを高速化し、Plonk/Halo2といったUniversal SNARKやSolidity verifierのガス最適化を検討する。 - \item \textbf{アプリケーション駆動の評価}: 分散型ID、プライベートトランザクション、オンチェーンゲームなど実アプリケーションでエンドツーエンド評価を行い、制約プロファイルとUX要件を明確化する。 - \item \textbf{セキュリティ整合性の確保}: VOLEitHはLPN仮定に基づくポスト量子耐性を持つ一方で、Groth16は量子攻撃に脆弱である。STARK系などPQ耐性を備えた証明との組み合わせや、アーキテクチャ全体の形式的安全性解析が求められる。 + \item \textbf{アプリケーション駆動の評価}: 分散型ID、プライベートトランザクション、オンチェーンゲームなど実アプリケーションでエンドツーエンド評価を行い、制約プロファイルとユーザー体験の要件を明確化する。 \end{itemize} diff --git a/paper/intro.tex b/paper/intro.tex index e667663..cac43b7 100644 --- a/paper/intro.tex +++ b/paper/intro.tex @@ -1,13 +1,41 @@ \section{序論} -\subsection{ゼロ知識証明の進化とオンチェーン検証の課題} -ゼロ知識証明は、ある計算が正しく実行されたことを、その計算に関する入力情報を一切明らかにすることなく検証者に証明する暗号学的プロトコルである。 -この性質はプライバシー保護が強く求められる現代のデジタル社会において極めて重要であり、ブロックチェーン技術の分野でもその応用が期待されている。 -特にスマートコントラクトプラットフォームにおいては、計算の正当性をトランザクションとしてオンチェーンで検証する能力が、スケーラビリティとプライバシーの両方を向上させる鍵となる。 -しかし、ZKPをオンチェーンで検証する際には、証明サイズ、検証計算量、そしてそれに伴うガス代という、ブロックチェーン特有の厳しい制約が大きな課題となる。 +\subsection{Ethereumにおけるプライバシーとゼロ知識証明の役割} +Ethereumは、\textbf{スマートコントラクト}\footnote{契約の条件確認や履行を自動的に強制するコンピュータプログラム。ブロックチェーン上で実行される。}と呼ばれるプログラムを実行できる分散型プラットフォームであり、世界中の誰もがアクセスできる巨大な共有コンピュータに例えられる。 +この透明性はシステムの信頼性を担保する一方で、すべての取引記録が公開台帳（ブロックチェーン）に恒久的に記録されることを意味する。 +これにより、どのアドレスからどのアドレスへ、いつ、どれだけの資産が移動したかを誰でも追跡できるため、ユーザーの金融活動におけるプライバシーが本質的に欠如するという深刻な課題を抱えている。 + +このプライバシーの欠如という課題に対する強力な解決策として、\textbf{ゼロ知識証明（Zero-Knowledge Proof, ZKP）} が注目されている。 +ZKPは、「ある秘密の情報を知っている」という事実を、その秘密情報自体を一切明らかにすることなく相手に納得させることができる暗号学的なプロトコルである。 +この性質を利用することで、ユーザーは自身の取引の詳細を秘匿したまま、その取引が正当であることだけを証明できる。 +Ethereum上でZKPを活用した代表的なアプリケーションに、プライバシーミキサーである\textbf{Tornado Cash}がある。 +Tornado Cashでは、ユーザーは資産を共通のプールに預け入れ、後で全く新しいアドレスから同額を引き出すことができる。 +このとき、ユーザーは「自分がある金額をプールに預け入れた正当な預金者である」ことをZKPを用いて証明する。 +この証明には、預け入れ時のどのアドレスとも結びつく情報が含まれないため、預け入れと引き出しの間の繋がりが暗号学的に断ち切られ、送金経路のプライバシーが保護される。 + +このようなアプリケーションを実現するには、Ethereum上でZKPを検証する仕組み、すなわち\textbf{オンチェーン検証}が不可欠である。 +しかし、このオンチェーン検証には二つの大きな技術的・経済的課題が存在する。 + +第一の課題は、\textbf{オンチェーン検証のコストと制約}である。 +Ethereum仮想マシン（EVM）上でスマートコントラクトを実行するには、\textbf{ガス代}\footnote{Ethereumネットワーク上でトランザクションを実行するために必要な手数料。計算が複雑であるほど高額になる。}と呼ばれる手数料が発生する。 +検証アルゴリズムが複雑であったり、証明のデータサイズが大きかったりすると、ガス代は著しく高騰し、アプリケーションの実用性が失われてしまう。 +さらに、ブロックには含められるデータ総量（ブロックガスリミット）に上限があるため、証明自体が大きすぎると、検証トランザクションがブロックに収まらず、事実上検証が不可能になる。 +これらの制約から、オンチェーンでの利用には、\textbf{証明サイズが極めて小さく（簡潔、Succinct）}、かつ\textbf{検証計算が非常に高速}な証明システムが不可欠である。 +この文脈でGroth16のようなzk-SNARKが広く採用されるのは、その証明サイズが回路の規模に関わらず一定かつBN254曲線で約1KBと非常に小さく、検証も高速であるためである。 +Ethereumでは、この検証を効率化するために、BN254曲線におけるペアリング演算を高速に実行する\textbf{プリコンパイル済みコントラクト}が用意されている。 + +第二の課題は、\textbf{クライアントサイドでの証明生成の負荷}である。 +アプリケーションが広く普及するためには、エンドユーザーが自身のデバイス（PCやスマートフォン）で特別な高性能ハードウェアを必要とせず、証明を生成できることが望ましい。 +しかし、多くの既存のZKP技術、特にペアリングなどの公開鍵暗号に基づくzk-SNARKsは、検証の軽量性と引き換えに、証明生成に膨大な計算リソースと時間を要求する。 +複雑なアプリケーションの証明を生成しようとすると、数分から数十分の時間がかかったり、モバイルデバイスではメモリ不足で実行不可能になったりするケースも少なくない。この「証明生成の重さ」は、ユーザー体験を損なう大きな障壁となる。 +この課題に対し、VOLE-in-the-Head（VOLEitH）のような対称鍵暗号に基づく証明システムは、AESなどハードウェアで高速に実行可能なプリミティブを計算基盤とするため、証明生成が著しく高速かつ軽量である。この特性から、クライアントサイドプルービングを実現する有望な技術と見なされている。 + +したがって、理想的な証明システムは、これら二つの課題を同時に解決する必要がある。すなわち、クライアントにとっては\textbf{軽量な証明生成}を、ブロックチェーンにとっては\textbf{効率的なオンチェーン検証}を両立させなければならない。 +本研究は、このトレードオフ関係にある要求を、VOLEitHとzk-SNARKを組み合わせることでどのように解決できるかを評価するものである。 \subsection{VOLEベースZKPとVOLE-in-the-Head} -この課題に対し、証明者の計算効率を大幅に向上させる新しいZKPの系統として、VOLE（Vector Oblivious Linear Evaluation）ベースのプロトコルが登場した。 -これらのプロトコルは、従来のSNARKs（Succinct Non-Interactive Argument of Knowledge）で主流であったR1CS（Rank-1 Constraint System）とは異なるアプローチを取り、特に証明者の計算負荷を軽減することに成功している。SNARKsは証明サイズが小さく検証が高速なためオンチェーン検証で広く利用されており、Groth16\cite{groth16}やPLONK\cite{plonk}のような多くの証明システムが提案されている。 +VOLE（Vector Oblivious Linear Evaluation）は、セキュア多者計算（MPC: Secure Multi-Party Computation）の分野、特にYao's Garbled Circuit (GC) とOblivious Transfer (OT) の研究から派生した暗号学的プリミティブである。 +これは、二者間で線形関係を秘匿したまま特定の相関を生成することを可能にする。その後、このVOLEの特性、特にその高い計算効率がゼロ知識証明に応用され、証明者の計算負荷を大幅に軽減する新しいZKPの系統が発展した。 +これにより、従来のSNARKs（Succinct Non-Interactive Argument of Knowledge）で主流であったR1CS（Rank-1 Constraint System）とは異なるアプローチを取り、特に証明者の計算負荷を軽減することに成功している。 その中でもVOLE-in-the-Head (VOLE itH) は、VOLEベースの対話型プロトコルにFiat-Shamir変換を適用することで、誰でも検証可能な公開証明（publicly verifiable proof）を生成可能にした画期的な手法である\cite{voleith}。 これにより、証明者側の高い計算効率という利点を維持しつつ、オンチェーン検証への道が拓かれた。 @@ -23,4 +51,4 @@ \subsection{研究の目的と貢献} \item 証明者と検証者の計算負荷（CPU、メモリ） \item 最終的なオンチェーン検証にかかるガス代 \end{itemize} -本研究は、VOLEitHのオンチェーン応用における実現可能性と技術的なトレードオフを明らかにすることで、将来的なZKPシステムの設計と最適化、そしてブロックチェーンアプリケーションにおけるプライバシーとスケーラビリティの向上に貢献することを目指す。 +本研究は、VOLEitHのオンチェーン応用における実現可能性と技術的なトレードオフを明らかにすることで、将来的なZKPシステムの設計と最適化、そしてブロックチェーンアプリケーションにおけるプライバシーの向上に貢献することを目指す。 diff --git a/paper/main.tex b/paper/main.tex index 7c23f7f..34f75ce 100644 --- a/paper/main.tex +++ b/paper/main.tex @@ -33,7 +33,8 @@ \input{intro.tex} \input{preliminaries.tex} \input{our_approach.tex} -\input{results_analysis.tex} +\input{results.tex} +\input{analysis.tex} \input{conclusion.tex} diff --git a/paper/our_approach.tex b/paper/our_approach.tex index 8e30497..d898b0d 100644 --- a/paper/our_approach.tex +++ b/paper/our_approach.tex @@ -1,30 +1,81 @@ \section{ベンチマーク設計} 本章では、VOLEitHとSNARKを組み合わせたアーキテクチャの性能を定量的に評価するために設計したベンチマークの詳細について述べる。 +\subsection{提案アーキテクチャ：VOLEitH証明のSNARKによる圧縮} +\label{subsec:our_approach} +ブロックチェーン上でのプライバシー保護に不可欠なゼロ知識証明技術において、VOLE-in-the-Head（VOLEitH）は極めて高速な証明生成を可能にする一方で、その証明サイズが数MBから数十MBに及ぶため、Ethereumのようなリソース制約の厳しいオンチェーン環境での直接検証には適さないという課題を抱えている。一方、zk-SNARKsは証明の簡潔性と検証効率に優れるが、証明生成に高い計算コストを要する。 +本研究で評価するアーキテクチャは、この両者の課題を解決し、VOLEitHが生成する巨大な証明サイズの問題を解決しつつ、オンチェーン検証に適したコンパクトな形式に圧縮することを目的としている。 +このため、証明者効率に優れたVOLEitHと、証明の簡潔性および検証効率に優れたzk-SNARK（本研究ではGroth16\cite{groth16}を採用）を組み合わせたハイブリッドアプローチを採用する。 +本アプローチの究極的な目的は、VOLEitHの利点である「クライアントサイドでの高速な証明生成」と、SNARKの利点である「低コストかつ予測可能なガス代でのオンチェーン検証」を両立させ、Web3アプリケーションにおけるプライバシー保護の課題を解決するための実用的なソリューションを提供することにある。 + +% \todo{提案アーキテクチャのフローを示すブロックダイアグラムを挿入} +% 図のキャプション例: 図1: VOLEitH証明のSNARKによる圧縮アーキテクチャの概要 +% 図の説明例: 本図は、VOLEitHとSNARKを組み合わせたハイブリッド証明生成・検証プロセスの全体像を示している。クライアント側でVOLEitH証明が生成された後、その検証ロジックがSNARK回路として表現され、コンパクトなSNARK証明が生成される。最終的に、SNARK証明のみがオンチェーンで検証されることで、効率的なプライバシー保護型計算の検証を実現する。 + +証明者が最終的なオンチェーン検証用の証明を生成するまでのプロセスは、以下の4つのステップで構成される。 + +\begin{enumerate} + \item \textbf{ステップ1：VOLEitH証明の生成} + まず、証明者は与えられた計算（算術回路）に対し、VOLEitHプロトコルを用いて証明\(\pi_{\text{VOLEitH}}\)を生成する。 + このプロセスは、対称鍵暗号ベースの軽い計算で構成されるため非常に高速だが、生成される証明\(\pi_{\text{VOLEitH}}\)のサイズは数MBオーダーと非常に大きい。 + + \item \textbf{ステップ2：VOLEitH検証回路のR1CS化} + 次に、ステップ1で生成された\(\pi_{\text{VOLEitH}}\)の正当性を検証するアルゴリズム自体を、一つの計算と見なす（いわゆる「証明の証明」の概念）。これは、既存の巨大なVOLEitH証明を直接オンチェーンで検証する代わりに、その「検証ロジックが正しく実行されたこと」をSNARKで証明するための重要な中間ステップである。 + VOLEitH検証プロトコルは、主に以下のような具体的な計算処理で構成される： + \begin{itemize} + \item \textbf{コミットメントの検証}: 証明者が行ったコミットメントが正しく開示されているか、またはあるプロパティを満たしているかの検証。 + \item \textbf{ハッシュ関数の計算}: チャレンジ生成やメッセージダイジェストの一致性確認のために、KeccakやSHAなどのハッシュ関数を再計算し、その出力を比較する。 + \item \textbf{VOLE相関の検証}: VOLEプロトコルによって生成された相関が、その数学的特性（例：線形性）を満たしているかの検証。これには有限体上の加算、乗算などの算術演算が含まれる。 + \item \textbf{ランダム性の検証}: プロトコル中に使用されたランダムネスが正しく利用されているかの確認。 + \end{itemize} + これらの検証ロジックを、SNARKが扱うことができる形式であるR1CS（Rank-1 Constraint System）の算術回路として表現する。このR1CS化のプロセスでは、VOLEitH検証プロトコルを構成する多数の論理ゲートや算術演算を、SNARKが解釈可能な制約形式に変換する必要があり、回路の効率的な設計がSNARK証明生成のパフォーマンスに大きく影響する。 + この「検証回路」は、\(\pi_{\text{VOLEitH}}\)を入力として受け取り、それが有効であれば真を、無効であれば偽を出力する。 + \item \textbf{ステップ3：SNARK証明の生成} + 証明者は、ステップ2で構築した「VOLEitH検証回路」に対して、Groth16プロトコルを用いて証明\(\pi_{\text{SNARK}}\)を生成する。 + この\(\pi_{\text{SNARK}}\)は、「ある有効な\(\pi_{\text{VOLEitH}}\)を知っており、その証明に対する検証計算が正しく実行されたこと」を簡潔に証明するものである。 + Groth16の重要な特性は、証明される計算の複雑さ（回路のゲート数）に関わらず、生成される\(\pi_{\text{SNARK}}\)のサイズが常に一定（約1KB程度）である点にある。この固定された小さな証明サイズは、ブロックチェーン上でのデータ保存コストを最小化し、検証の効率性を最大限に高める上で極めて有利である。 + \item \textbf{ステップ4：オンチェーン検証} + 最終的に、コンパクトなSNARK証明\(\pi_{\text{SNARK}}\)と、計算の公開入力のみがEthereum上の検証者スマートコントラクトに送信される。 + スマートコントラクトは、事前にデプロイされた検証鍵を用いて\(\pi_{\text{SNARK}}\)を検証する。この検証は、数回のペアリング演算で完了するため、極めて少ないガス代で実行可能である。 +\end{enumerate} + +この一連のプロセスにより、クライアント側では証明生成の大部分を軽量なVOLEitHプロトコルが担い、ブロックチェーン側では検証コストの高い計算がコンパクトなSNARK証明の検証に置き換えられる。 +本研究では、この革新的なハイブリッドアーキテクチャをRust言語で実装した。VOLEitHの実装には\texttt{schmivitz}ライブラリを、SNARK回路の構築と証明生成には\texttt{arkworks}エコシステムを利用し、オンチェーン検証用のSolidityコントラクトは\texttt{ark-groth16}の機能を用いて生成した。これにより、理論的に提唱されてきたVOLEitHとSNARKの連携による効率化を、具体的なシステムとして構築・評価する初の試みの一つとして、その実用性とパフォーマンスを定量的に明らかにする。本研究の成果は、リソース制約の厳しい環境下でのゼロ知識証明の適用範囲を大きく広げるものである。 + +\subsection{評価対象回路} +本ベンチマークでは、プロトコルの基本的な性能を評価するため、以下の回路セットを用いた。これらの基本的な算術回路は、VOLEitHが生成する証明サイズの特性を明確に把握するために選定された。なぜなら、これらの単純な回路でさえ、VOLEitHの証明サイズはオンチェーン検証に用いられるGroth16のコンパクトな証明サイズと比較して依然として大きく、その圧縮の必要性を定量的に示す上で不可欠であったためである。 +\begin{itemize} + \item \textbf{評価用基本回路}: + \begin{itemize} + \item 内容: \textbf{100ゲート}および\textbf{1000ゲート}の\textbf{ADD（加算）回路}と\textbf{AND（乗算）回路}。これらの単純な算術回路は、ゼロ知識証明システムにおける基本的な演算の性能を評価するために広く用いられる。 + \item 目的: VOLEitHフェーズおよびSNARKフェーズを合わせた性能評価において、回路の規模（ゲート数）と種類（加算/乗算）が、VOLEitHフェーズとSNARKフェーズの各メトリクスにどのような影響を与えるかを詳細に分析するために用いる。特に、加算ゲートと乗算ゲートはZKPプロトコルにおいて異なる計算コストを持つことが多いため、それぞれのゲートタイプに特化した評価を行うことで、本ハイブリッドアーキテクチャのボトルネックや最適化の機会を特定するための重要な知見を得ることを目指す。 + \end{itemize} +\end{itemize} + \subsection{測定項目} 本研究では、証明システムの性能と実用性を多角的に評価するため、以下のメトリクスを測定対象とした。 \begin{table}[hbtp] \centering - \begin{tabular}{|l|l|l|} + \begin{tabular}{|l|l|l|l|} \hline - \textbf{メトリクス} & \textbf{説明} & \textbf{単位/備考} \\ + \textbf{メトリクス} & \textbf{説明} & \textbf{単位/備考} & \textbf{測定の意義} \\ \hline - 証明生成時間 & 証明者が、ある計算に対する証明を生成するために要する時間 & ms または $\mu$s \\ + 証明生成時間 & 証明者が、ある計算に対する証明を生成するために要する時間 & ms または $\mu$s & クライアントサイドの性能、ユーザー体験への影響 \\ \hline - 証明検証時間 & 検証者が、与えられた証明の正当性を検証するために要する時間 & ms または $\mu$s \\ + 証明検証時間 & 検証者が、与えられた証明の正当性を検証するために要する時間 & ms または $\mu$s & 証明の正当性確認に要する計算量 \\ \hline - 証明サイズ & 生成された証明データの大きさ & バイト（B） \\ + 証明サイズ & 生成された証明データの大きさ & バイト（B） & オンチェーンでのデータ保存コスト、通信量 \\ \hline - 通信オーバーヘッド & 非対話型証明において、証明者が検証者に送信する必要がある総データ量。基本的に証明サイズとほぼ同等 & バイト（B） \\ + 通信オーバーヘッド & 非対話型証明において、証明者が検証者に送信する必要がある総データ量。基本的に証明サイズとほぼ同等 & バイト（B） & ネットワーク負荷、証明の運搬コスト \\ \hline - 計算負荷 & 証明生成および検証プロセス中に消費されるCPU使用率および最大メモリ使用量 & CPU使用率（\%）、メモリ（MB） \\ + 計算負荷 & 証明生成および検証プロセス中に消費されるCPU使用率および最大メモリ使用量 & CPU使用率（\%）、メモリ（MB） & リソース消費、ハードウェア要件の評価 \\ \hline - SNARK制約数 & VOLEitHの証明をSNARKに変換する際に生成されるR1CSの制約数。証明生成時間に大きく影響 & - \\ + SNARK制約数 & VOLEitHの検証ロジックをSNARK回路に変換した際に生成されるR1CSの制約数 & - & SNARK証明生成時間とオンチェーン検証ガス代に大きく影響 \\ \hline - オンチェーン検証ガス代 & 生成されたSNARK証明をEthereumのスマートコントラクトで検証する際に消費されるガス量 & gas \\ + オンチェーン検証ガス代 & 生成されたSNARK証明をEthereumのスマートコントラクトで検証する際に消費されるガス量 & gas & ブロックチェーン上での運用コスト、経済合理性 \\ \hline \end{tabular} - \caption{ベンチマーク測定項目一覧} + \caption{ベンチマーク測定項目一覧}\label{tab:bench_metrics} \end{table} \subsection{評価環境} @@ -38,25 +89,6 @@ \subsection{評価環境} \item \textbf{ソフトウェア}: \begin{itemize} \item 言語: Rust - \item ベンチマークツール: \texttt{cargo bench} - \item VOLEitH実装: \texttt{soft\_spoken} ライブラリ - \item スマートコントラクト開発・テスト: Foundryフレームワーク - \item Solidityバージョン: 0.8.20 - \end{itemize} -\end{itemize} - -\subsection{評価対象回路} -本ベンチマークでは、プロトコルの基本的な性能と、より実践的な応用における性能の両方を評価するため、2種類の回路セットを用いた。 -\begin{itemize} - \item \textbf{SHA256回路}: - \begin{itemize} - \item 内容: \textbf{SHA-256} 。これらは暗号技術で広く利用される標準的なハッシュ関数であり、複雑な計算の代表例として用いた。なお、本研究では標準的なハッシュ関数を評価対象としたが、近年ではPoseidonのようにSNARK証明系に特化して算術化を効率化したZKフレンドリーなハッシュ関数も提案されている\cite{poseidon}。 - \item 形式: これらの回路は、\href{https://github.com/GaloisInc/swanky/tree/dev/bristol-fashion/circuits}{Bristol Fashion}形式で記述されたものを、本研究で利用するVOLEitHライブラリに適した形式に変換して使用した。 - \item 目的: VOLEitHプロトコル単体の性能と、既存のZKP実装（Circom）との比較評価に用いる。 - \end{itemize} - \item \textbf{E2E評価用基本回路}: - \begin{itemize} - \item 内容: \textbf{100ゲート}および\textbf{1000ゲート}の\textbf{ADD（加算）回路}と\textbf{AND（乗算）回路}。 - \item 目的: エンドツーエンド（E2E）の性能評価、特に回路の規模（ゲート数）と種類（加算/乗算）が、VOLEitHフェーズとSNARKフェーズの各メトリクスにどのような影響を与えるかを詳細に分析するために用いる。 + \item VOLEitH実装: \texttt{schmivitz} ライブラリ \end{itemize} \end{itemize} diff --git a/paper/out/main.pdf b/paper/out/main.pdf index 1814ea8..296e3aa 100644 Binary files a/paper/out/main.pdf and b/paper/out/main.pdf differ diff --git a/paper/preliminaries.tex b/paper/preliminaries.tex index 94f5aff..065a318 100644 --- a/paper/preliminaries.tex +++ b/paper/preliminaries.tex @@ -1,64 +1,139 @@ \section{前提知識と関連研究} -本章では、後続のベンチマークと考察を理解するために必要な暗号学的前提を、簡潔に整理する。 +本章では、後続のベンチマークと考察を理解するために必要な暗号学的前提を簡潔に整理する。 +\subsection{本研究の背景と目的} +近年、ブロックチェーン技術の発展に伴い、そのスケーラビリティとプライバシー保護が重要な課題となっている。ZKPは、これらの課題に対する有効な解決策として注目されており、特にブロックチェーン上での計算負荷を軽減し、プライベートな情報を守りながら取引を検証する手段として期待されている。 + +しかし、多くの既存のZKPプロトコルは、公開検証可能性（Public Verifiability）を達成するために、複雑なTrusted Setupや高コストなペアリング計算を必要とする場合があった。このような背景の中、VOLE-in-the-Head (VOLEitH) プロトコルは、指定検証者証明の課題を克服し、非対話かつ公開検証可能な証明を効率的に構築する新しいアプローチとして提案された。 + +本研究の目的は、このVOLEitHプロトコルがブロックチェーン環境において実際にどの程度の性能を発揮するかを評価することである。具体的には、証明生成時間、証明検証時間、証明サイズ、およびそれらのオンチェーン検証におけるガス消費量などの主要な性能指標をベンチマークし、その実用性や効率性を検証することを目的とする。 \subsection{Vector Oblivious Linear Evaluation (VOLE)} -VOLEは、二者間で線形関係を隠したままMAC相関を生成するプリミティブである。 -有限体 $F$ 上で、送信者はベクトル $\mathbf{u}, \mathbf{v} \in F^m$ を、受信者はグローバル鍵 $\mathbf{\Delta} \in F^m$ を入力とする。 -プロトコル終了後、受信者は -\begin{equation} - \mathbf{q} = \mathbf{u} \circ \mathbf{\Delta} - \mathbf{v} \in F^m -\end{equation} -を満たすペア $(\mathbf{u}, \mathbf{q})$ を得る（$\circ$ は要素積）。 -$\mathbf{q}$ は $\mathbf{u}$ に対する情報理論的MACとなり、$\mathbf{\Delta}$ を知らずに $\mathbf{q}$ を固定したまま $\mathbf{u}$ を改ざんすることはできない（binding）。 -この性質が後述の健全性担保に直接利用される。 - -\paragraph{サブフィールドVOLE} -FAESTなどでは、入力 $\mathbf{u}$ を $\mathbb{F}_2$ に制限しつつ、$\mathbf{v}, \mathbf{q}, \mathbf{\Delta}$ を拡大体 $\mathbb{F}_{2^\lambda}$ 上に置くサブフィールドVOLEが用いられる。 -これはビット演算を保ちつつ、MACは大きな体で保持することで効率と安全性を両立するためである。 - -\subsection{MPC-in-the-Head (MPCitH)} -MPCitHは、NPリレーションの知識証明を「頭の中で」実行するMPCに還元し、ビュー開示で健全性を担保するZKフレームワークである。 -NPリレーション $R(x, w)$ に対し、証明者 $P$ は証人 $w$ を $N$ 份のシェア $w_i$ に分割し（加法秘密分散等）、$f(x, w_1,\dots,w_N)=R(x,\bigoplus_i w_i)$ を計算する半正直MPC $\Pi_f$ を頭の中でエミュレートする。 -識別プロトコルは次の4段階で構成される。 -\begin{enumerate} - \item \textbf{ビュー生成とコミット}: $\Pi_f$ の各仮想パーティのビュー $V_1,\dots,V_N$ にコミットする。 - \item \textbf{チャレンジ}: 検証者 $V$ はインデックス $i^* \in \{1,\dots,N\}$ をランダムに選ぶ。 - \item \textbf{開示}: $P$ は $i^*$ を除く $N-1$ 個のビューを開示する。 - \item \textbf{検証}: $V$ は開示ビューの整合性と、$\Pi_f$ の実行規則への準拠を検査する。 -\end{enumerate} -$\Pi_f$ が $(N-1)$-privacy を満たすとき、開示されなかった $V_{i^*}$ を偽造しない限り不正な $P$ は受理されないため、健全性が得られる。 -通信量は回路サイズ $s$ に線形（$O(s) + \mathrm{poly}(k,\log s)$）で、汎用性が高い。 - -\subsection{QuickSilver} -QuickSilverは、VOLE MACの準同型性を用いて乗算制約を検査するLine-Point系ゼロ知識プロトコルであり、VOLE相関を前提に軽量な検証を実現する。 -QuickSilverはLine-Point Zero-Knowledgeパラダイムを用い、VOLE MACの加法準同型性で乗算制約 $w_\alpha \cdot w_\beta = w_\gamma$ を検査する。 -証明者は応答を $\tilde{a}_0,\tilde{a}_1,\tilde{b}$ にマスクし、検証者は VOLE 関係 +Vector Oblivious Linear Evaluation（VOLE）は、送信者が複数の秘密データの中から受信者が選択した一つのみを伝え、かつ送信者には何が選択されたかを知られないという性質を持つOblivious Transfer (OT) の算術形式と見なされる暗号学的プリミティブであり、証明者と検証者の間で、秘密裡に線形代数的な相関関係を確立する二者間プロトコルである。 + +$k$をセキュリティパラメータ、$\mathbb{F}_{2^k}$を要素数$2^k$の有限体とする。プロトコル完了後、証明者は秘密のベクトル $\mathbf{u} \in \mathbb{F}_2^\ell$ とランダムなVOLEタグ $\mathbf{v} \in \mathbb{F}_{2^k}^\ell$ を保持し、検証者はグローバルキー $\Delta \in \mathbb{F}_{2^k}$ とVOLEキー $\mathbf{q} \in \mathbb{F}_{2^k}^\ell$ を保持する。これらの値は、以下のVOLE相関式を満たす。 \begin{equation} - \tilde{b} = \tilde{a}_0 + \tilde{a}_1 \cdot \Delta + q_i = u_i \cdot \Delta + v_i \quad (i=0, \dots, \ell-1) \end{equation} -が成立することを確認するだけで健全性を得る。 -VOLEitHは、このQuickSilver型の検査をGGMベースのVCと組み合わせ、公開検証を実現している。 +この相関は、証明者が持つランダムビット $u_i$ に対する\textbf{線形準同型コミットメントスキーム}として機能する。 +一般にコミットメントスキームとは、暗号プリミティブである。この線形準同型コミットメントは以下の性質を持つ。 +\begin{description} + \item[秘匿性 (Hiding)] 検証者は、$q_i$と$\Delta$から$u_i$の情報を得られない。これは、証明者が知るランダムな値$v_i$が$u_i$の値をマスクするためである。 + \item[拘束性 (Binding)] 証明者は、検証者の持つ秘密$\Delta$を知らない限り、一度コミットした$u_i$を不正な値に開示することができない。その成功確率は計算論的に無視できるほど小さい。 +\end{description} +VOLEの最も強力な特性は、その線形準同型性にある。同じグローバルキー$\Delta$を持つ複数のVOLE相関 $(u_i, v_i, q_i)$ と公開定数 $c, c_1, \dots, c_n \in \mathbb{F}_{2^k}$ が与えられたとき、証明者と検証者は新しい値 $u' = c + \sum_{i=1}^{n} c_i u_i$ に対するVOLE相関 $(u', v', q')$ を、追加の通信なしにローカルで計算できる。 +\begin{description} + \item[証明者の計算] 証明者は新しいVOLEタグ$v'$を以下のように計算する。 + \begin{equation} + v' = \sum_{i=1}^{n} c_i v_i + \end{equation} + \item[検証者の計算] 検証者は新しいVOLEキー$q'$を以下のように計算する。 + \begin{equation} + q' = c \cdot \Delta + \sum_{i=1}^{n} c_i q_i + \end{equation} +\end{description} +算術回路とは、加算や乗算などの算術演算を表すゲートで構成される計算モデルであり、暗号学的証明システムにおいてプログラムの検証対象として用いられる。VOLEが有するこの強力な線形準同型性は、算術回路の検証コストに直接的な影響を及ぼす。 +VOLE相関 ($q_i = u_i \cdot \Delta + v_i$) は、その構造自体が線形な関係式である。そのため、加算やスカラー乗法といった\textbf{線形演算}は、VOLEと高い親和性を持つ。例えば、2つの値に対するVOLE相関が与えられたとき、それらの和に対する新しいVOLE相関は、証明者と検証者がそれぞれ手元で対応する値を足し合わせるだけで構築可能である。これは、線形演算がVOLEの線形構造を保存するためであり、追加の通信を一切要しない。 + +一方で、乗算のような\textbf{非線形演算}は、この線形構造を破壊する。2つのVOLE相関を乗算しても、その結果が有効なVOLE相関となることはない。そのため、証明者は、自身が正しく乗算を実行したことを検証者に納得させるための、ないしは検証させるための追加のプロトコル、すなわち次節で詳述する\textbf{乗算検定}を実行する必要がある。この検定は、非線形な乗算関係の検証を、追加の通信を伴う線形なチェックへと帰着させるものである。したがって、VOLEベースのゼロ知識証明における主要な計算・通信コストは、この非線形演算を処理するための乗算検定に集約される。 + +\subsection{VOLE-based ZKと乗算検定} +ゼロ知識証明とは、VOLEが有する線形性（加法準同型性）を利用することで、効率的なゼロ知識証明プロトコル（VOLE-based ZK）を構築可能である。このパラダイムは、QuickSilver\cite{quicksilver}などのプロトコルで採用されている。 + +乗算ゲート、例えば $w_\gamma = w_\alpha \cdot w_\beta$ の検証は、特別な\textbf{乗算検定プロトコル}を必要とする。このプロトコルは、証明者と検証者が保持するVOLE相関が、実際の乗算関係を正しく反映しているかを、検証者の秘密キー$\Delta$を利用して確認するものである。 +\begin{description} + \item[証明者の役割] 証明者は、乗算ゲートに関わる自身の秘密値（$u_\alpha, v_\alpha, u_\beta, v_\beta$など）に基づいて、中間値である$a_0$と$a_1$を計算し、検証者に送信する。 + \item[検証者の役割] 検証者は、自身が持つVOLEキー（$q_\alpha, q_\beta, q_\gamma$）から特定の値$b$を計算する。その後、証明者から受け取った$a_0, a_1$と、自身の秘密キー$\Delta$を用いて、以下の線形な等式が成立するかを検証する。 + \begin{equation} + b \stackrel{?}{=} a_0 + a_1 \cdot \Delta + \end{equation} + このチェックが成功すれば、証明者が正直に計算を行ったことが高い確率で保証される。もし証明者が不正を働いていた場合、この等式を成立させるには$\Delta$の値を推測する必要があり、その成功確率は計算論的に無視できるほど小さい。 +\end{description} + +しかし、この仕組みは、検証者がグローバルキー$\Delta$の値を秘密に保つことを前提としている。このため、証明を検証できるのが特定の検証者に限定される\textbf{指定検証者証明（Designated Verifier Proof）}となり、第三者が検証できる\textbf{公開検証可能性（Public Verifiability）}を持たないという課題を有していた。 \subsection{VOLE-in-the-Head} -VOLEitHは、MPC-in-the-Headの開示構造にQuickSilver型のVOLE検査を組み込み、指定検証者型VOLEを公開検証可能に拡張した手法である。 -VOLEitHは、MPCitHの「開示しない1パーティ」を、VOLEのグローバル鍵 $\mathbf{\Delta}$ に対応付けることで、指定検証者型のVOLE系プロトコルを公開検証可能にする。 -鍵となるのが、長さ倍増PRGから構成するGGM木に基づく All-but-One ベクトルコミットメント (VC) である。 -\begin{itemize} - \item 高さ $h=\log N$ のGGM木の根シードから $N$ 個の葉シード $sd_i$ を生成し、各葉にVOLE用の乱数列 $r_i$ を割り当てる。 - \item 開示しないインデックス $j^*$ を除き、$P$ は各葉への経路で必要な兄弟ノードのシードを開示するだけで $N-1$ 個の $r_i$ を再現させられる（通信量は $O(\log N)$）。 - \item 開示されない $r_{j^*}$ が $\mathbf{\Delta}$ に対応し、$V$ は公開された $r_i$ の線形結合から $\mathbf{q}=\mathbf{u}\circ\mathbf{\Delta}-\mathbf{v}$ を再構成する。 -\end{itemize} -この構成により、OTを用いずに非対話でVOLE相関を生成し、MACのbinding性を保ったままFiat--Shamir変換を適用できる。 +前節で述べた指定検証者問題を解決し、公開検証可能性を実現するものがVOLE-in-the-Head (VOLEitH) と呼ばれるコンパイラである。 +VOLEitHは、SoftSpokenOT \cite{softspokenot} のような効率的なVOLE相関生成プロトコルを、MPC-in-the-Head \cite{mpc-in-the-head} の手法と組み合わせることで、非対話（Non-interactive）かつ公開検証可能な証明を構築する。 + +VOLEitHの効率性の根幹を支えるのは、\textbf{SoftSpokenOT}\cite{softspokenot}と呼ばれるプロトコルである。これは、少数の高価なベースOT（Oblivious Transfer）から、擬似乱数を用いて極めて多数の安価なOTインスタンスを生成するOT拡張技術の一種である。 +特に、相関のある乱数を利用してOTをバッチ処理することに特化しており、VOLE相関を生成する上で必要となる「$N$個のシードの中から、チャレンジで指定された1個のシードを除いた$N-1$個の情報を効率的に転送する」という処理（All-but-One OT）と高い親和性を持つ。 +結果として、SoftSpokenOTはVOLEitHにおけるVOLE相関の生成エンジンとして機能し、プロトコル全体の通信・計算コストを大幅に削減する役割を担う。 + +その核心は、検証者が秘密のグローバルキー$\Delta$を持つ代わりに、証明者自身がプロトコルの中で$\Delta$の元となる情報にコミットし、後からFiat-Shamir変換によってチャレンジとして$\Delta$を導出する点である。Fiat-Shamir変換とは、対話型の証明プロトコルを、チャレンジがハッシュ関数によって生成される非対話型の証明に変換する一般的な手法である。 +このプロセスは、GGMツリー（Goldreich-Goldwasser-Micali Tree, GGM）\cite{ggm}を用いたAll-but-One Oblivious Transfer (OT) の技術を用いて効率的に実装される。 -\subsection{SNARKとオンチェーン検証の概観} -Groth16を例に、オンチェーン検証は (i) 証明と公開入力をcalldataで受領、(ii) 回路固有の検証鍵をコントラクトに格納、(iii) 公開入力とICベクトルのMSMで\(\mathrm{vk\_x}\)を計算、(iv) ペアリングprecompileで等式を判定、の4段階からなる。 -ガスは主にペアリング（1回あたり\(\sim\)34k gas、合計15--20万gas規模）と公開入力数に比例するMSMで支配され、calldata課金は16 gas/非ゼロバイトで証明サイズ1055バイトなら約1.7万gasとなる。 -コードサイズは24KB上限のため検証鍵の配置も設計上の制約となる。 +\paragraph{GGMツリーによるAll-but-Oneコミットメント} -\subsection{設計指針（本稿で用いる前提）} +GGMツリーは、短い入力（シード）から長い擬似乱数系列を効率的に生成するための仕組みであり、特に擬似乱数生成器（PRG）を繰り返し適用することで構築される木構造である。 +このツリーの各ノードは、親ノードのシードからPRGを用いて計算され、再帰的に展開される。 +最終的に最下層に到達した「葉」（リーフノード）には、一連の擬似乱数が対応付けられる。 +GGMツリーの重要な特性は、この構造を利用して、ある特定の一つのリーフノード以外の全てのリーフノードの値を効率的に開示できる点にある。この性質が、All-but-Oneコミットメントスキームを構築する上で不可欠となる。 + +All-but-Oneコミットメントは、コミッターが複数の値の集合（例えば、$N$個の値）に対してコミットメントを行い、後からその集合内の任意の一つの値**以外**の全ての値を公開できる暗号プリミティブである。このとき、公開されなかった一つの値については、コミットメントの受信者には全く情報が漏洩しないことが保証される。 + +VOLE-in-the-Head (VOLEitH) プロトコルでは、このGGMツリーを用いたAll-but-Oneコミットメントが、特に$N$個のシードの中から、チャレンジで指定された1個のシードを除いた$N-1$個の情報を効率的に転送する（All-but-One OTの文脈で）ために利用される。 +これにより、検証者が秘密のグローバルキー$\Delta$を持つ代わりに、証明者自身が$\Delta$の元となる情報にコミットし、公開検証可能性を実現する。 + +プロトコルは以下のように進行する。 +\begin{description} + \item[ステップ1: GGMツリー構築とコミットメント] + まず、セキュリティパラメータ$\lambda$に対して、入力シードを2倍の長さの出力に拡張するPRG $G: \{0,1\}^\lambda \to \{0,1\}^{2\lambda}$ を定義し、$G(s) = (s_0, s_1)$ とする。証明者は、ランダムなルートシード$s_{root} \in \{0,1\}^\lambda$を選択する。 + 深さ$d = \log N$のGGMツリーは、このルートシードからPRGを再帰的に適用することで構築される。各ノードは、その親ノード$s_{parent}$から$G(s_{parent})$によって2つの子ノードシード（$s_0, s_1$）が生成される形で展開される。具体的には、インデックス$i \in \{0, \ldots, N-1\}$の$d$ビット表現を$i_1i_2\dots i_d$とすると、リーフ（葉）シード$sd_i$は、ルートからパス$i_1\dots i_d$を辿って$sd_i = s_{i_1\dots i_d}$として計算される。 + 証明者は、こうして得られた$N$個の全てのリーフシード$\{sd_i\}_{i=0}^{N-1}$に対してハッシュ関数$H$を適用し、ハッシュ値$h_{com}=H(sd_0, \ldots, sd_{N-1})$を計算して、これをコミットメントとして公開する。 + + \item[ステップ2: VOLE値の計算] + 証明者は、各リーフシード$sd_i$をさらに別のPRG（$G'$とする）で展開してランダムな文字列$r_i = G'(sd_i)$を得て、自身の秘密VOLE値$\mathbf{u}, \mathbf{v}$を以下のように計算する。 + \begin{align} + \mathbf{u} &= \sum_{i=0}^{N-1} r_i \\ + \mathbf{v} &= \sum_{i=0}^{N-1} i \cdot r_i + \end{align} + + \item[ステップ3: チャレンジと開示 (All-but-One OT)] + 証明の主要部分が構成された後、Fiat-Shamir変換により、証明全体のトランスクリプトからチャレンジ$\Delta \in \{0, \ldots, N-1\}$が導出される。この$\Delta$が開示を免除される（すなわち秘匿される）インデックスとなる。 + 証明者は、GGMツリーにおいて$sd_\Delta$を隠したまま残りの全てのシードを開示するため、ルートから$sd_\Delta$に至るパス上の各ノードの\textbf{兄弟ノード}（sibling node）のシードを開示情報$pdecom$として証明に含める。$\Delta$のビット表現を$\Delta_1\dots\Delta_d$とすると、$pdecom$は以下の$\log N$個のシードの集合である。 + \begin{equation} + pdecom = \{ s_{\Delta_1\dots\Delta_{j-1}\bar{\Delta}_j} \}_{j=1}^d, \quad \text{ここで } \bar{\Delta}_j = 1-\Delta_j + \end{equation} + この$pdecom$に含まれる兄弟ノードのシードは、$\Delta$に続くパスとは異なる全てのパスを再構築するのに必要な情報を提供する。 + + \item[ステップ4: 検証] + 検証者は、まず証明者と同様にFiat-Shamir変換で$\Delta$を導出する。次に、$pdecom$に含まれる$\log N$個の兄弟ノードのシードを用いて、$\Delta$以外の全てのインデックス$i \neq \Delta$に対応するリーフシード$sd_i$を再計算する。この再計算が可能であるのは、$i$と$\Delta$のビット表現が最初に異なる位置を$j$とすると、$sd_i$の計算に必要なプレフィックス$i_1\dots i_j$を持つノードのシードが$pdecom$に含まれる$s_{\Delta_1\dots\Delta_{j-1}\bar{\Delta}_j}$（ここで $i_j = \bar{\Delta}_j$）から計算を開始できるためである。 + 検証者は、復元した$N-1$個のリーフシードと、公開されている$h_{com}$が正しく再構成できることを確認し、開示の正当性を検証する。最後に、これらのシードと$\Delta$を用いてVOLEキー$\mathbf{q}$を計算し、VOLE相関$q_i = u_i \Delta + v_i$の検証へと進む。 +\end{description} + +VOLEitHプロトコルによって生成される非対話証明は、ここまで説明したGGMツリーのコミットメント $h_{com}$ と、チャレンジ $\Delta$ に対応する開示情報 $pdecom$ に加えて、算術回路全体の計算の正当性を示すための情報を含んでいる。 +VOLEの準同型性により、加算のような線形演算の検証は追加の証明情報を必要としない。一方で、回路内の\textbf{全ての乗算ゲート}については、その一つ一つが2.3節で述べた\textbf{乗算検定}をパスすることを証明しなければならない。 +そのため、VOLEitHの証明には、回路内の全乗算ゲートに対応する検証情報（各ゲートの $a_0, a_1$ に相当する値）が埋め込まれることになる。 + +結果として、VOLEitHの証明サイズは、GGMツリーのパラメータに依存する比較的小さな固定部分と、\textbf{検証対象の算術回路に含まれる乗算ゲートの数にほぼ比例して増加する可変部分}から構成される。この特性は、計算が複雑になるほど証明が長くなることを意味し、次節で述べるGroth16のように、回路の規模によらず証明サイズが一定となるSNARKsとは対照的である。本研究におけるベンチマークでは、この証明サイズのスケール特性を定量的に評価する。 + +\subsection{Groth16} +まず、Groth16を理解するために、zk-SNARKs（zero-knowledge Succinct Non-interactive ARguments of Knowledge）について説明する。 +zk-SNARKsは、以下の性質を持つ暗号学的証明システムである。 \begin{itemize} - \item \textbf{証明サイズの固定性}: Groth16の証明サイズは一定（本稿では1055バイト）で、回路規模が増えてもcalldata課金は増えない。 - \item \textbf{公開入力の削減}: MSMコストは公開入力数に線形。ハッシュ圧縮等で項目数を抑える。 - \item \textbf{検証鍵の配置}: コントラクトサイズ上限を考慮し、検証鍵を分離・共有する設計をとる。 - \item \textbf{フィールド整合性}: 証明生成・検証ともBN254を用いる。別曲線を選ぶ場合は専用プリコンパイルやロールアップを前提とする。 + \item \textbf{ゼロ知識 (Zero-Knowledge)} + \item \textbf{簡潔性 (Succinctness)} + \item \textbf{非対話性 (Non-interactive)} + \textbf{知識の論拠 (ARgument of Knowledge)} \end{itemize} +Groth16は、このようなzk-SNARKsの中でも特に効率的で広く利用されている方式の一つであり、特にその証明サイズの小ささと検証の速さで知られている。 +ブロックチェーンのように検証コストが重視される環境においては、特に強力な選択肢となる。 + +Groth16プロトコルは主に3つのアルゴリズムから構成される： +Groth16は、算術回路として表現された計算を、R1CS（Rank-1 Constraint System）と呼ばれる制約システムに変換し、さらにこれをQuadratic Arithmetic Program (QAP) へと変換することで証明を構築する。QAPは、ある多項式が特定の根を持つかどうかを検証する問題に帰着され、これにより複雑な計算の正当性を効率的に検証可能となる。 + +このプロトコルは、楕円曲線上のペアリングの性質を最大限に活用し、高い効率性を実現している。 +\begin{description} + \item[Setup ($\mathcal{C} \to (\text{pk}, \text{vk})$)] + このフェーズでは、証明対象の計算をR1CS形式で表現された算術回路 $\mathcal{C}$ から、証明鍵（Proving Key, pk）と検証鍵（Verification Key, vk）を生成する。このプロセスは回路ごとに一度だけ実行され、通常Trusted Setupとして知られる。このセットアップでは、ランダムに選択された秘密のパラメータ $s, \alpha, \beta, \gamma, \delta \in \mathbb{F}_p^*$ を用いて、Common Reference String (CRS) が生成される。このCRSには、$G_1, G_2$ 上の様々な群要素の組 $([s^i]_1, [s^i]_2)$, $([\alpha]_1, [\alpha]_2)$, $([\beta]_1, [\beta]_2)$, $([\gamma]_1, [\gamma]_2)$, $([\delta]_1, [\delta]_2)$, $([\beta s^i]_1)$, $([\gamma s^i]_1)$, $([s^i \text{poly}(x)]_1)$ などが含まれる。ここで $\mathbb{G}_1, \mathbb{G}_2$ は楕円曲線上の点からなる群であり、$[X]_1, [X]_2$ はそれぞれ $\mathbb{G}_1, \mathbb{G}_2$ における $X$ の楕円曲線乗算を意味する。このCRS生成時に用いられた秘密のパラメータ（toxic waste）が漏洩すると、不正な証明を生成可能になるため、その破棄が極めて重要である。 + \item[Prove ($\text{pk}, x, w \to \pi$)] + 証明者は、証明鍵 pk、公開入力 $x$、および秘密入力 $w$ を用いて、命題が真であることの証明 $\pi = (A, B, C)$ を生成する。この証明は、QAPの解に対応する特定の多項式 $h(s)$ やその他のランダム性 $r, t \in \mathbb{F}_p^*$ を用いて、$\mathbb{G}_1$ および $\mathbb{G}_2$ 上の3つの群要素 $A \in \mathbb{G}_1, B \in \mathbb{G}_2, C \in \mathbb{G}_1$ として構築される。具体的には、$A = [A_w(s) + r\delta]_1$, $B = [B_w(s) + t\delta]_2$ または $B = [B_w(s) + t\delta]_1$, $C = [C_w(s) + (h(s)T(s) + \frac{A_w(s) \beta + B_w(s)\alpha + \gamma}{r\delta})]_1$ のような形式をとる（具体的な形式はGroth16論文参照）。ここで $A_w(s), B_w(s), C_w(s)$ は公開入力と秘密入力 $w$ から導出される多項式である。 + \item[Verify ($\text{vk}, x, \pi \to \{\text{True}, \text{False}\}$)] + 検証者は、検証鍵 vk、公開入力 $x$、および証明 $\pi = (A, B, C)$ を受け取り、その正当性を検証する。検証は、CRSに含まれる要素と証明 $\pi$ の群要素を用いて、以下のペアリング方程式が成立するかどうかを確認することによって行われる。 + \begin{equation} + e(A, B) = e([\text{A_input}(x)]_1, [\text{B_input}(x)]_2) \cdot e(C, [\delta]_2) + \end{equation} + ここで $e$ は楕円曲線上の双線形ペアリング演算を意味する。この検証は、回路の規模に関わらず固定長の証明と数回のペアリング演算で行われるため、極めて高速である。 +\end{description} + +Groth16の証明は常に一定のサイズであり、通常3つの群要素（$\mathbb{G}_1$の元2つ、$\mathbb{G}_2$の元1つ）で構成される。この効率性の代償として、回路ごとに異なるTrusted Setupが必要であり、汎用性（universality）に欠けるというトレードオフが存在する。 diff --git a/paper/references.tex b/paper/references.tex index 6ca6bfe..7c8a220 100644 --- a/paper/references.tex +++ b/paper/references.tex @@ -46,4 +46,30 @@ \section*{参考文献 (References)} One Tree to Rule Them All: Optimizing GGM Trees and OWFs for Post-Quantum Signatures. \textit{Cryptology ePrint Archive}, Paper 2024/490, 2024. \url{https://eprint.iacr.org/2024/490}. + +\bibitem{quicksilver} +Yang, K., Kohl, P., and Song, D. +QuickSilver: Efficient and Affordable Zero-Knowledge Proofs for Circuits and Polynomials. +In \textit{Proceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS '21)}, pp. 233-250, 2021. +DOI: \url{10.1145/3460120.3484550}. + +\bibitem{fiatshamir} +Fiat, A., and Shamir, A. +How to Prove Yourself: Practical Solutions to Identification and Signature Problems. +In \textit{Advances in Cryptology -- CRYPTO '86}, pp. 186-194, 1987. +DOI: \url{10.1007/3-540-47721-7_12}. + +\bibitem{yellowpaper} +Wood, G. +Ethereum: A Secure Decentralised Generalized Transaction Ledger. +\textit{Ethereum Project Yellow Paper}, 2024. +\url{https://ethereum.github.io/yellowpaper/paper.pdf}. + +\bibitem{schmivitz} +adust09. +Swanky: A suite of tools for developing zero-knowledge circuits and applications. +GitHub Repository. +\url{https://github.com/adust09/swanky}. +Accessed: 2025-12-01. + \end{thebibliography} diff --git a/paper/results.tex b/paper/results.tex new file mode 100644 index 0000000..96f1cf5 --- /dev/null +++ b/paper/results.tex @@ -0,0 +1,79 @@ +\section{結果と分析 (Results and Analysis)} +\label{sec:results_analysis} +本章では、設計したベンチマークに基づき、VOLEitHとSNARKを組み合わせたハイブリッドアーキテクチャの性能を多角的に評価する。まず4.1節でVOLEitHプロトコル単体の性能を評価し、その基本的な特性（特に証明サイズと生成・検証速度）を明らかにする。 +次に4.2節で、VOLEitHの証明をSNARKで圧縮しオンチェーン検証するまでのプロセス全体の性能を評価する。最後に4.5節でこれらの結果を統合し本アーキテクチャ全体の有効性とトレードオフについて考察し、4.6節で実用アプリケーションへの適用可能性について論じる。 + +\subsection{VOLEitHフェーズおよびSNARKフェーズの性能評価} +前節（4.1節）で、VOLEitHプロトコル単体では基本的なADD/AND回路においても証明サイズが依然として大きく、そのままではオンチェーン検証に適さないという課題が明らかになった。 +この課題を解決するため、本節ではVOLEitHの証明をSNARKで圧縮しオンチェーン検証するまでのVOLEitHフェーズおよびSNARKフェーズを合わせたプロセス全体の性能を評価する。 +ベンチマークは、100ゲートおよび1000ゲートのADD回路とAND回路を用いて実施した。 + +まず、VOLEitHフェーズの性能を\textbf{表\ref{tab:e2e_vole_phase}}に示す。 + +\begin{table}[htbp] + \centering + \caption{VOLEitHフェーズおよびSNARKフェーズのベンチマーク - VOLEフェーズの性能} + \label{tab:vole_phase} + \begin{tabular}{|l|l|l|l|l|} + \hline + \textbf{メトリクス} & \textbf{100 add} & \textbf{100 and} & \textbf{1000 add} & \textbf{1000 and} \\ + \hline + 証明生成時間 & 279.012~\ensuremath{\mu\mathrm{s}} & 476.5~\ensuremath{\mu\mathrm{s}} & 790.062~\ensuremath{\mu\mathrm{s}} & 1.649~ms \\ + 証明検証時間 & 68.75~\ensuremath{\mu\mathrm{s}} & 274.566~\ensuremath{\mu\mathrm{s}} & 585.6~\ensuremath{\mu\mathrm{s}} & 1.082~ms \\ + 証明サイズ & 21,361 B & 42,491 B & 21,319 B & 233,175 B \\ + 通信オーバーヘッド & 21,426 B & 42,556 B & 21,384 B & 233,240 B \\ + \hline + \end{tabular} +\end{table} + +表\ref{tab:e2e_vole_phase}から、VOLEフェーズにおいては、回路のゲート数が増加するにつれて、証明生成時間、検証時間、証明サイズ、通信オーバーヘッドが増加することがわかる。 +特に、ANDゲート回路はADDゲート回路と比較して、同程度のゲート数であっても証明生成時間、検証時間、証明サイズが大幅に増加する傾向にある。 +これは、\texttt{soft\_spoken}の実装において、ANDゲートのような乗算処理がADDゲートのような加算処理よりも多くのVOLEプロトコルラウンドや計算を必要とすることに起因すると考えられる。 + +次に、SNARKフェーズの性能を\textbf{表\ref{tab:e2e_snark_phase}}に示す。このフェーズでは、VOLEitHの証明をSNARK（Groth16）形式に変換し、オンチェーン検証に適した形に圧縮する。 + +\begin{table}[htbp] + \centering + \caption{VOLEitHフェーズおよびSNARKフェーズのベンチマーク - SNARKフェーズの性能} + \label{tab:snark_phase} + \begin{tabular}{|l|l|l|l|l|} + \hline + \textbf{メトリクス} & \textbf{100 add} & \textbf{100 and} & \textbf{1000 add} & \textbf{1000 and} \\ + \hline + 証明生成時間 & 272 ms & 1,794 ms & 324 ms & 8,003 ms \\ + 制約数 & 86,080 & 3,471,680 & 86,080 & 33,942,080 \\ + 証明サイズ & 1,055 B & 1,055 B & 1,055 B & 1,055 B \\ + ガス消費量 & 208,967 & 208,967 & 208,967 & 208,967 \\ + \hline + \end{tabular} +\end{table} + +表\ref{tab:e2e_snark_phase}から、SNARKフェーズではVOLEフェーズとは異なる特性が明らかになる。 +最も注目すべきは、最終的なSNARK証明のサイズが、回路のゲート数や種類に関わらず\textbf{1,055バイト}に固定されている点である。 +また、オンチェーン検証のガス代も\textbf{208,967 gas}で一定であり、これはSNARKの検証が固定コストで行われることを示している。 +これにより、前節で課題となったVOLEitHの巨大な証明サイズが大幅に圧縮され、オンチェーン検証の実現可能性が飛躍的に向上する。 + +一方で、SNARK証明の生成時間と制約数には、回路の複雑性が大きく影響している。特に、ANDゲート回路はADDゲート回路と比較して、制約数が大幅に増加し、それに伴い証明生成時間も急増している。 +例えば、1000 ANDゲート回路では、制約数が33,942,080に達し、証明生成に8,003 ms（約8秒）を要している。 + +この関係性をより視覚的に示すため、\textbf{図1}にSNARKの制約数と証明生成時間の関係を示す。 + +\begin{figure}[htbp] + \centering + % ここにSNARKの制約数と証明生成時間の関係を示すグラフを挿入 + \caption{SNARKの制約数と証明生成時間の関係} + \label{fig:snark_constraints_time} +\end{figure} + +図\ref{fig:snark_constraints_time}は、SNARKの証明生成時間が、回路の制約数、特に乗算ゲートに起因する制約数の増加に強く相関していることを明確に示している。 +これは、SNARKの証明生成における主要な計算ボトルネックが、回路の複雑性、特に乗算の多さに起因することを示唆している。 + +\paragraph{主な観測事項} +本章で得られたVOLEitHフェーズおよびSNARKフェーズの測定結果から、以下の特徴が明らかになった。 +\begin{itemize} + \item ANDゲートはADDゲートよりも大幅に制約数と証明時間を増加させ、VOLEフェーズでも証明サイズを押し上げる。 + \item ADDのみの回路では制約数がほぼ一定であるのに対し、ANDゲート数に比例してSNARK制約が増える。 + \item SNARKフェーズの証明生成時間が、VOLEフェーズの生成・検証時間を大きく上回り、全体のボトルネックとなる。 + \item SNARK証明サイズおよびオンチェーン検証ガスは1,055バイトと約209k gasで一定であり、回路規模に依存しない。 + \item 総証明時間はSNARKフェーズの制約増加に強く影響されるため、複雑な回路ではクライアントデバイスでの実行が難しくなる。 +\end{itemize} diff --git a/paper/results_analysis.tex b/paper/results_analysis.tex deleted file mode 100644 index 4cbd3dc..0000000 --- a/paper/results_analysis.tex +++ /dev/null @@ -1,305 +0,0 @@ -\section{結果と分析 (Results and Analysis)} -\label{sec:results_analysis} -本章では、設計したベンチマークに基づき、VOLEitHの性能を多角的に評価する。まず4.1節でVOLEitHプロトコル単体の性能を評価し、既存実装との比較を通じてその基本的な特性を明らかにする。 -次に4.2節で、VOLEitHの証明をSNARKで圧縮しオンチェーン検証するまでのエンドツーエンド（E2E）プロセス全体の性能を評価する。最後に4.3節で、これらの結果を統合し、本アーキテクチャ全体の有効性とトレードオフについて考察する。 - -\subsection{VOLEitH単体性能評価} -VOLEitHプロトコル自体の性能を評価するため、標準的な暗号学的ハッシュ関数であるSHA-256とKeccak-Fの回路を用いてベンチマークを実施した。 -これらの回路はBristol Fashion形式で記述されたものを本研究用に変換したものである。 - -\textbf{表1}に、Apple M1（メモリ16GB）環境で測定した両回路のベンチマーク結果を示す。 - -\begin{table}[htbp] - \centering - \caption{VOLEitH単体性能ベンチマーク (SHA-256 vs Keccak-F)} - \label{tab:voleith_standalone_benchmark} - \begin{tabular}{|l|l|l|} - \hline - \textbf{Metric} & \textbf{sha256} & \textbf{keccak\_f} \\ - \hline - Proof Generation Time & 95 ms & 143 ms \\ - Proof Verification Time & 51 ms & 74 ms \\ - Proof Size & 4,927,342 B (\textasciitilde4.9 MB) & 8,416,569 B (\textasciitilde8.4 MB) \\ - Communication Overhead & 4,927,407 B (\textasciitilde4.9 MB) & 8,416,634 B (\textasciitilde8.4 MB) \\ - Prover Computation Load & 0.02\% CPU, 118.23 MB & 0.04\% CPU, 154.14 MB \\ - Verifier Computation Load & 0.04\% CPU, 138.89 MB & 0.04\% CPU, 158.1 MB \\ - \hline - \end{tabular} -\end{table} - -表\ref{tab:voleith_standalone_benchmark}から、回路の複雑性が性能に直接的な影響を与えることがわかる。 -Keccak-FはSHA-256よりも複雑な回路構造を持つため、証明生成時間、検証時間、そして証明サイズのいずれにおいてもSHA-256を上回るコストが必要となった。 -特筆すべきは証明サイズであり、SHA-256で約4.9MB、Keccak-Fでは約8.4MBにも達する。この巨大なデータサイズは、そのままではブロックチェーンのブロックサイズ制限やガス代の観点から、オンチェーンでの検証を著しく困難にする。 - -次に、VOLEitHの性能特性をより明確にするため、既存のZKP実装であるCircom（\cite{eprint:iacr:2023:681}より）によるSHA-256実装との比較を行う。 -\textbf{表2}に両者の性能比較を示す。 - -\begin{table}[htbp] - \centering - \caption{SHA-256実装の性能比較 (VOLEitH vs Circom)} - \label{tab:sha256_comparison} - \begin{tabular}{|l|l|l|} - \hline - \textbf{実装} & \textbf{証明生成時間} & \textbf{証明サイズ} \\ - \hline - \textbf{VOLEitH (本研究)} & \textbf{95 ms} & \textbf{\textasciitilde4.9 MB} \\ - Circom (先行研究) & \textasciitilde1,473 ms & \textasciitilde821 Bytes \\ - \hline - \end{tabular} -\end{table} - -表\ref{tab:sha256_comparison}は、VOLEitHの基本的なトレードオフを明確に示している。証明生成時間において、VOLEitHはCircom実装の約15.5倍高速である。 -これは、証明者の計算効率を重視するVOLEベースのプロトコルの特性を強く反映している。 -一方で、証明サイズに目を向けると、VOLEitHの証明は約4.9MBであるのに対し、Circom（Groth16）の証明は約821バイトと、VOLEitHが6000倍以上も大きい。 - -この結果から、VOLEitHはクライアントデバイスのような計算資源が限られた環境での高速な証明生成には適しているものの、生成された証明はオンチェーン検証には不向きであることがわかる。 -この「証明は高速だが、証明自体が巨大」という課題が、本研究でSNARKによる証明圧縮アプローチを採用する動機となった。 - -\subsection{エンドツーエンド（E2E）性能評価} -前節でVOLEitH単体では証明サイズが大きすぎるという課題が明らかになったため、本節ではVOLEitHの証明をSNARKで圧縮し、オンチェーンで検証するまでのエンドツーエンド（E2E）プロセス全体の性能を評価する。 -ベンチマークは、100ゲートおよび1000ゲートのADD回路とAND回路を用いて実施した。 - -まず、VOLEitHフェーズの性能を\textbf{表3}に示す。 - -\begin{table}[htbp] - \centering - \caption{E2Eベンチマーク - VOLEフェーズの性能} - \label{tab:e2e_vole_phase} - \begin{tabular}{|l|l|l|l|l|} - \hline - \textbf{Metric} & \textbf{100 add} & \textbf{100 and} & \textbf{1000 add} & \textbf{1000 and} \\ - \hline - Proof Gen. Time & 279.012~\ensuremath{\mu\mathrm{s}} & 476.5~\ensuremath{\mu\mathrm{s}} & 790.062~\ensuremath{\mu\mathrm{s}} & 1.649~ms \\ - Proof Ver. Time & 68.75~\ensuremath{\mu\mathrm{s}} & 274.566~\ensuremath{\mu\mathrm{s}} & 585.6~\ensuremath{\mu\mathrm{s}} & 1.082~ms \\ - Proof Size & 21,361 B & 42,491 B & 21,319 B & 233,175 B \\ - Comm. Overhead & 21,426 B & 42,556 B & 21,384 B & 233,240 B \\ - \hline - \end{tabular} -\end{table} - -表\ref{tab:e2e_vole_phase}から、VOLEフェーズにおいては、回路のゲート数が増加するにつれて、証明生成時間、検証時間、証明サイズ、通信オーバーヘッドが増加することがわかる。 -特に、ANDゲート回路はADDゲート回路と比較して、同程度のゲート数であっても証明生成時間、検証時間、証明サイズが大幅に増加する傾向にある。 -これは、\texttt{soft\_spoken}の実装において、ANDゲートのような乗算処理がADDゲートのような加算処理よりも多くのVOLEプロトコルラウンドや計算を必要とすることに起因すると考えられる。 - -次に、SNARKフェーズの性能を\textbf{表4}に示す。このフェーズでは、VOLEitHの証明をSNARK（Groth16）形式に変換し、オンチェーン検証に適した形に圧縮する。 - -\begin{table}[htbp] - \centering - \caption{E2Eベンチマーク - SNARKフェーズの性能} - \label{tab:e2e_snark_phase} - \begin{tabular}{|l|l|l|l|l|} - \hline - \textbf{Metric} & \textbf{100 add} & \textbf{100 and} & \textbf{1000 add} & \textbf{1000 and} \\ - \hline - Proof Gen. Time & 272 ms & 1,794 ms & 324 ms & 8,003 ms \\ - Constraints & 86,080 & 3,471,680 & 86,080 & 33,942,080 \\ - Proof Size & 1,055 B & 1,055 B & 1,055 B & 1,055 B \\ - Gas Cost & 208,967 & 208,967 & 208,967 & 208,967 \\ - \hline - \end{tabular} -\end{table} - -表\ref{tab:e2e_snark_phase}から、SNARKフェーズではVOLEフェーズとは異なる特性が明らかになる。 -最も注目すべきは、最終的なSNARK証明のサイズが、回路のゲート数や種類に関わらず\textbf{1,055バイト}に固定されている点である。 -また、オンチェーン検証のガス代も\textbf{208,967 gas}で一定であり、これはSNARKの検証が固定コストで行われることを示している。 -これにより、前節で課題となったVOLEitHの巨大な証明サイズが大幅に圧縮され、オンチェーン検証の実現可能性が飛躍的に向上する。 - -一方で、SNARK証明の生成時間と制約数には、回路の複雑性が大きく影響している。特に、ANDゲート回路はADDゲート回路と比較して、制約数が大幅に増加し、それに伴い証明生成時間も急増している。 -例えば、1000 ANDゲート回路では、制約数が33,942,080に達し、証明生成に8,003 ms（約8秒）を要している。 - -この関係性をより視覚的に示すため、\textbf{図1}にSNARKの制約数と証明生成時間の関係を示す。 - -\begin{figure}[htbp] - \centering - % ここにSNARKの制約数と証明生成時間の関係を示すグラフを挿入 - \caption{SNARKの制約数と証明生成時間の関係} - \label{fig:snark_constraints_time} -\end{figure} - -図\ref{fig:snark_constraints_time}は、SNARKの証明生成時間が、回路の制約数、特に乗算ゲートに起因する制約数の増加に強く相関していることを明確に示している。 -これは、SNARKの証明生成における主要な計算ボトルネックが、回路の複雑性、特に乗算の多さに起因することを示唆している。 - -\paragraph{主な観測事項} -本章で得られたE2E測定結果から、以下の特徴が明らかになった。 -\begin{itemize} - \item ANDゲートはADDゲートよりも大幅に制約数と証明時間を増加させ、VOLEフェーズでも証明サイズを押し上げる。 - \item ADDのみの回路では制約数がほぼ一定であるのに対し、ANDゲート数に比例してSNARK制約が増える。 - \item SNARKフェーズの証明生成時間が、VOLEフェーズの生成・検証時間を大きく上回り、全体のボトルネックとなる。 - \item SNARK証明サイズおよびオンチェーン検証ガスは1,055バイトと約209k gasで一定であり、回路規模に依存しない。 - \item 総証明時間はSNARKフェーズの制約増加に強く影響されるため、複雑な回路ではクライアントデバイスでの実行が難しくなる。 -\end{itemize} - -\subsection{SNARK統合に関する洞察} -VOLEitHの証明をGroth16で包むと、証明サイズと検証コストは一定になる一方で、R1CS制約数が急増する。 -ここでは制約数の内訳と、制約爆発の要因および緩和策を整理する。 - -\subsubsection{制約数の分解} -$n$ を拡張witnessの長さ（秘密入力数と乗算ゲート数の合計）とすると、全体の制約数は -\begin{align*} -16,640 \times n + 2,113,664 -\end{align*} -と表せる。線形項に寄与するガジェットは表\ref{tab:linear_constraints}の通りであり、\texttt{compute\_validation\_aggregate}が支配的である。 - -\begin{table}[H] - \centering - \caption{線形に増加するガジェットの制約数} - \label{tab:linear_constraints} - \begin{tabular}{|l|r|} - \hline - ガジェット & 制約数 \\ - \hline - $compute\_d\_delta$ & $128n$ \\ - $compute\_masked\_witness$ & $256n$ \\ - $compute\_validation\_aggregate$ & $16,512n$ \\ - \hline - 合計 & $\approx16,640n$ \\ - \hline - \end{tabular} -\end{table} - -また、回路サイズに依存しない定数項も無視できない（表\ref{tab:constant_constraints}）。乗算ゲートが増えると線形項が支配するが、ベースラインとして約200万制約が常に必要になる。 - -\begin{table}[H] - \centering - \caption{定数項として加算されるガジェット} - \label{tab:constant_constraints} - \begin{tabular}{|l|r|} - \hline - ガジェット & 制約数 \\ - \hline - $combine$ & $\sim2,097,152$ \\ - $compute\_actual\_validation$ & $\sim16,384$ \\ - 最終整合性チェック & $\sim128$ \\ - \hline - 合計 & $\sim2,113,664$ \\ - \hline - \end{tabular} -\end{table} - -\subsubsection{Field Mappingがもたらす制約爆発} -SchmivitzにおけるVOLEitHは、$\mathbb{F}_2$、$\mathbb{F}_{2^8}$、$\mathbb{F}_{2^{64}}$、$\mathbb{F}_{2^{128}}$といった2進拡大体上で計算を行う。 -一方で、Groth16のR1CSはBN254の素数体上で定義されるため、各ビット列をBoolean変数列に持ち上げる必要がある。 -実装では以下のように、証明内の各値を逐一Boolean配列に射影している。 - -\begin{verbatim} -pub fn build_circuit( - cs: ConstraintSystemRef, - proof: Proof, -) -> VoleVerificationBoolean { - let witness_commitment_booleans: Vec>> = proof - .witness_commitment - .iter() - .map(|value| f64b_to_boolean_array(cs.clone(), value).unwrap()) - .collect(); - - let witness_challenges_booleans: Vec>> = proof - .witness_challenges - .iter() - .map(|value| f128b_to_boolean_array(cs.clone(), value).unwrap()) - .collect(); - // ... -} -\end{verbatim} - -この変換により、もともと単一の体要素で表現できた計算が数百ビットのAND/XORに展開され、制約数が爆発的に増加する。 - -\subsubsection{ANDゲートと\texttt{witness\_challenge}} -特にANDゲートを検証する際には、\texttt{witness\_challenge}と\texttt{masked\_witness}の全ビットについてANDおよびXOR演算を行い、部分積を合成する必要がある。 -実装の核心は以下の通りであり、128ビット平方の積をBooleanレベルで計算するため、ANDゲート1つあたり$2^{14}$規模の制約が追加される。 - -\begin{verbatim} -for (i, challenge_bit) in challenge.iter().enumerate() { - if i >= 128 { break; } - for (j, masked_bit) in masked_witness.iter().enumerate() { - if j >= 128 || i + j >= 128 { continue; } - let and_result = Boolean::and(challenge_bit, masked_bit)?; - product[i + j] = Boolean::xor(&product[i + j], &and_result)?; - } -} -\end{verbatim} - -ADDゲートでは\texttt{witness\_challenge}が不要なため制約数は一定だが、ANDゲートが増えるほど\texttt{compute\_validation\_aggregate}が繰り返し呼ばれ、SNARKフェーズ全体のボトルネックとなる。 - -\subsection{技術的ボトルネックと解決策} -上記の分析から、Field MappingとGGM木再構成が制約爆発の主要因であることが分かる。 -本節では、これらを緩和するための具体的な研究方向を整理する。 - -\subsubsection{Field Mapping最適化とLookup Table} -Mystique\cite{eprint:2021:730}は、機械学習向けに$\mathbb{F}_2$と$\mathbb{F}_p$のデータ変換を効率化するVOLEベースZKであり、Lookup Table (LUT) を導入することでさらに高速化できることが最新研究\cite{eprint:2025:507}で示されている。 -表\ref{tab:mystique_lut}に示す通り、LUTを用いた場合には実行時間が61--130倍短縮し、通信量も最大2.9倍削減できる。 -VOLEitHのField MappingにMystique型LUTを適用できれば、SNARKフェーズの制約数削減に直結すると期待される。 - -\begin{table}[H] - \centering - \caption{MystiqueとLUT拡張の性能比較} - \label{tab:mystique_lut} - \begin{tabular}{|l|l|r|r|} - \hline - 関数 & プロトコル & 実行時間 (s) & 通信量 (MB) \\ - \hline - 指数関数 & Mystique with LUT & 8.696 & 99.020 \\ - & Mystique & 1130.020 & 291.435 \\ - 除算 & Mystique with LUT & 9.837 & 110.684 \\ - & Mystique & 617.690 & 160.428 \\ - 逆平方根 & Mystique with LUT & 11.836 & 147.903 \\ - & Mystique & 824.639 & 212.211 \\ - \hline - \end{tabular} -\end{table} - -\subsubsection{GGM木最適化とFolding} -Schmivitzでは、VOLEitH検証で最もコストの高いGGM木再構成を簡略化しているが、SNARKで完全に検証する場合はこの部分が制約増大を引き起こす。 -著者らはGGM木を効率化する手法\cite{eprint:2024:490}に加え、FAESTを改良したFAESTERを提案しており、署名サイズと計算量をともに改善している（表\ref{tab:faester}）。 -本研究で検討したFoldingスキームとこれらの最適化を組み合わせれば、将来的にGGM木再構成部の制約数を抑制できる。 - -\begin{table}[H] - \centering - \caption{FAESTとFAESTERの比較（セキュリティ128ビット）} - \label{tab:faester} - \begin{tabular}{|l|l|r|r|r|} - \hline - スキーム & バージョン & 署名サイズ (B) & 署名時間 (ms) & 検証時間 (ms) \\ - \hline - FAEST & Slow & 50,063 & 4.3813 & 4.1023 \\ - & Fast & 63,363 & 0.4043 & 0.3953 \\ - FAESTER & Slow & 45,943 & 3.2823 & 4.4673 \\ - & Fast & 60,523 & 0.4333 & 0.6103 \\ - \hline - \end{tabular} -\end{table} - -\subsection{総合考察とトレードオフ分析} -これまでの分析結果を統合し、VOLEitHとSNARKを組み合わせたアーキテクチャ全体の有効性とトレードオフについて考察する。 - -本研究で採用したアーキテクチャは、\textbf{図2}に示すように、証明者側（Prover）で2段階のプロセスを経て、検証者側（Verifier）であるブロックチェーン上で効率的な検証を実現するものである。 - -\begin{figure}[htbp] - \centering - % ここにVOLEitH + SNARKによる証明圧縮プロセスの概念図を挿入 - % 例: [Prover: 回路] -> [VOLEitH証明 (数MB)] -> [SNARK証明 (1KB)] -> [Verifier (オンチェーン)] - \caption{VOLEitH + SNARKによる証明圧縮プロセスの概念図} - \label{fig:proof_compression_flow} -\end{figure} - -図\ref{fig:proof_compression_flow}が示す通り、本アーキテクチャは、VOLEitHが生成する巨大な証明（数MBオーダー）を、SNARKを用いてオンチェーン検証に適したコンパクトな証明（1KBオーダー）に圧縮する点に核心がある。 -このアプローチにより、以下の2つの大きな利点を両立することが可能となる。 - -\begin{enumerate} - \item \textbf{高速な証明者計算}: VOLEitHは、Circomのような従来のR1CSベースのシステムと比較して、証明者の計算が非常に高速である（表\ref{tab:sha256_comparison}参照）。 - これにより、計算能力が限られるクライアントデバイス（例: Webブラウザ、スマートフォン）でも、複雑な計算の証明を現実的な時間で生成できる可能性が広がる。 - \item \textbf{低コストなオンチェーン検証}: SNARK化された証明は、サイズが小さく、検証コストが回路の複雑さによらず一定であるため、ブロックチェーン上での検証コスト（ガス代）を大幅に削減し、予測可能なものにできる（表\ref{tab:e2e_snark_phase}参照）。 -\end{enumerate} - -一方で、このアーキテクチャには考慮すべきトレードオフも存在する。最大のトレードオフは、証明者側の計算負荷である。 -証明者は、高速なVOLEitH証明生成に加えて、SNARK証明を生成するための追加の計算コストを負担する必要がある。 -特に、回路が多くの乗算（ANDゲート）を含む場合、SNARKの制約数が急増し、SNARK証明の生成時間が全体のボトルネックとなる（図\ref{fig:snark_constraints_time}参照）。 - -したがって、本アーキテクチャは、以下のような特性を持つユースケースにおいて特に有効であると考えられる。 -\begin{itemize} - \item \textbf{クライアントサイドでの証明生成}: ユーザー自身のデバイスで証明を生成し、サーバーやブロックチェーンに送信するアプリケーション。 - 例えば、プライバシーを保護した上での本人確認（分散型ID）、プライベートな状態を持つゲーム、機密データを用いた計算の検証などが挙げられる。 - \item \textbf{オンチェーンコストの最小化が重要}: ブロックチェーンのスケーラビリティが重視され、トランザクションコストを可能な限り抑えたいアプリケーション。 -\end{itemize} - -結論として、VOLEitHとSNARKを組み合わせたハイブリッドアプローチは、「証明者の高速性」と「検証者の低コスト」という、一見すると相反する要求を両立させるための有望なアーキテクチャである。 -その性能は回路の特性、特に乗算の数に大きく依存するため、アプリケーションを設計する際には、このトレードオフを十分に理解することが重要となる。 diff --git a/simple_vole.md b/simple_vole.md new file mode 100644 index 0000000..f174bd9 --- /dev/null +++ b/simple_vole.md @@ -0,0 +1,83 @@ +お客様のクエリに基づき、**SoftSpokenOT**を前提とした基本的なVector Oblivious Linear Evaluation (VOLE) の仕組みについて、提供された情報源を参照しながら詳細に解説します。 + +VOLEは、Vector Oblivious Linear Evaluationの略であり、証明者（Prover, P）と検証者（Verifier, V）の間で、秘密裡に線形代数的な相関関係を確立する二者間プロトコルです。VOLEは、Oblivious Transfer (OT) の算術形式と見なされます。 + +VOLE相関は、有限体$F_{2^k}$上で、以下の線形方程式によって定義されます。 + +$$q_i = u_i \cdot \Delta + v_i \quad (\text{for } i = 0, \ldots, \ell - 1) $$ + +ここで、Pは秘密の値 $u_i$ とランダムなVOLEタグ $v_i$ を知り、Vはグローバルキー $\Delta$ とVOLEキー $q_i$ を知ります。 + +VOLEは、Pがランダムビット $u_i$ に対してコミットするための**線形準同型コミットメントスキーム**として機能します。このコミットメントは、ランダムな $v_i$ によって $u_i$ がマスクされるため「秘匿性（hiding）」を持ち、Pが$\Delta$を知らない限り不正な値に開示できないため「拘束性（binding）」を持ちます。 + +### 1. プロトコル全体を各ステップごとに説明する + +SoftSpokenOT は、VOLE相関を効率的に実現するための基盤となるプロトコルであり、特にFAESTやzkPassで用いられるVOLE-in-the-Head (VOLEitH) の中核技術として統合されています。 + +この構築は、OTの特性である**オール・バット・ワン（$N-1$ out of $N$）**の秘密開示メカニズムを、擬似乱数生成器（PRG）とベクトルコミットメント（VC）の構造に組み込むことで実現されます。 + +以下に、VOLE相関を生成する主要なステップを示します（$N=2^k$とします）。 + +#### ステップ 1: Pによるシードの生成とコミットメント +1. **シードの生成:** P（証明者/署名者）は、$N$個の擬似乱数シード$sd_0, \ldots, sd_{N-1}$を生成します。 +2. **コミットメント:** Pは、これらのシードに対して**All-but-One Vector Commitment (VC)** スキームを用いてコミットします。VCは、長さ倍増PRGのツリー構造（GGM構成）を使用して構築されます。 +3. **ハッシュの送信:** Pは、生成されたコミットメントから単一のハッシュ値$h_{com}$を計算し、V（検証者）に送信します。 + +#### ステップ 2: PによるVOLE値（uとv）の計算 +1. **PRGによる展開:** Pは、コミットした各シード$sd_i$をPRGで展開し、長さ$\hat{\ell}$の文字列$r_i \in \{0, 1\}^{\hat{\ell}}$を得ます。 +2. **VOLE値の計算:** Pは、これらの$N$個の文字列$r_i$を用いて、自身のVOLE値である$u$（ベクトル）と$v$（ベクトルまたは行列$V$）を有限体$F_{2^k}$上で計算します。 + $$u = \sum_{i=0}^{N-1} r_i$$ + $$v = \sum_{i=0}^{N-1} i \cdot r_i$$ + この$u$と$v$は、Pの秘密の入力となります。 + +#### ステップ 3: Vによるチャレンジ ($\Delta$) の決定と開示要求 +1. **チャレンジの決定:** Vは、ランダムなグローバルキー$\Delta \in F_{2^k}$を決定します。OTの文脈では、この$\Delta$はPが$N$個のシードのうちで「開示しない」インデックス$j^*$に対応します。 +2. **開示要求:** VはPに対し、$\Delta$に対応するインデックス$j^*$を除く、すべての$N-1$個のシードの開示（Open）を要求します（FAESTの非対話的設定では、$\Delta$はFiat-Shamir変換によって決定されます）。 + *注: $\Delta$は、VOLEの拘束性を維持するため、ゼロ知識証明の主要なステップが実行された後にのみPに知らされることが重要です。* + +#### ステップ 4: VによるVOLEキー ($q$) の再構成 +1. **Pによる開示:** Pは、VC.Openアルゴリズムを用いて、$\Delta$に対応するシード$sd_{\Delta}$以外のすべてのシードを開示情報$pdecom$としてVに送ります。 +2. **Vによる再構成:** Vは、Pから受け取った$N-1$個のシードを再構成し、$\Delta$とこれらの情報を用いて、以下の計算を実行します。 + $$q = \sum_{x \in F_{2^k}, x \neq \Delta} t_x (\Delta - x) = u\Delta + v$$ + この結果、Vは$q$と$\Delta$を知り、Pは$u$と$v$を知るというVOLE相関 $q = u\Delta + v$ が確立されます。 + +### 2. 加法と乗法の計算方法の解説 + +VOLE相関の最も強力な特性は、線形準同型性です。これにより、PとVは、認証された秘密の値$u$に対して、通信をせずに計算を実行できます。 + +#### 加法とスカラー乗法（線形演算） + +VOLE MACは**加法準同型性**を持ちます。同じグローバルキー$\Delta$を持つ$n$個のVOLE MACs $(u_i, v_i, q_i)$と公開定数$c, c_1, \ldots, c_n \in F_{2^k}$が与えられたとき、PとVは、新しいMAC $(u', v', q')$をローカルに計算できます。 + +1. **新しい秘密の値 $u'$ の計算:** + $$u' = c + \sum_{i=1}^{n} c_i \cdot u_i$$ + +2. **P（証明者）による計算（VOLEタグ $v'$ の計算）:** + Pは、新しいVOLEタグ$v'$を計算します。この計算には、公開定数$c$は**含まれません**。 + $$v' = \sum_{i=1}^{n} c_i \cdot v_i$$ + +3. **V（検証者）による計算（VOLEキー $q'$ の計算）:** + Vは、新しいVOLEキー$q'$を計算します。 + $$q' = c \cdot \Delta + \sum_{i=1}^{n} c_i \cdot q_i$$ + +$q'$と$u', v'$の関係は、$q' = u' \cdot \Delta + v'$というVOLE相関を引き続き満たします。 + +また、定数$c$自体を認証する場合（認証された定数）は、Pが$v := 0$とし、Vが$q := c \cdot \Delta$とすることで、VOLE MACを生成できます。 + +#### 乗法（非線形演算） + +乗法（例: $w_\gamma = w_\alpha \cdot w_\beta$）のような非線形演算は、線形準同型性だけでは処理できないため、**QuickSilver**プロトコルなどのVOLEベースのゼロ知識証明システム内で、特別な乗法ゲートチェックを通じて検証されます。 + +乗法チェックは、PとVが保持するVOLE MACsが、対応する値$w_\alpha, w_\beta, w_\gamma$の乗算関係を正しく満たしているかを、$\Delta$の秘密性を利用して確認するものです。 + +1. **Pによる証明値の計算と送信:** + Pは、乗法ゲートに関わるVOLEタグ$v$と秘密の値$w$に基づいて、中間値$a_{0}$と$a_{1}$を計算し、Vに送信します。 + +2. **Vによる検証:** + Vは、自身のVOLEキー$q$とグローバルキー$\Delta$、そしてPから受け取った$a_0, a_1$を用いて、以下の等式が成立するかを確認します。 + $$b \stackrel{?}{=} a_{0} + a_{1} \cdot \Delta$$ + ここで$b$は、Vが持つ$q$値から計算される値です。 + +このチェックが成功すれば、Pが正直に計算を行ったことが高確率で保証されます。もしPが不正な$w$でコミットしようとした場合、この線形等式を満たすためにはVの秘密キー$\Delta$を推測する必要があり、成功確率は$2^{-k}$でしかありません。 + +VOLEは、線形操作を無料で（通信なしで）行えるため、複雑な回路計算を非常に効率的にゼロ知識証明する基盤となります。これは、**「秘密の定規と分度器（VOLE MAC）を使って、誰も見ていない場所で、安全に線形計算を何度でも行うことができる」**ようなものです。ただし、非線形な「掛け算」が必要な場合は、特別な証明手続きを介して、計算結果が不正ではないことを確認する必要があります。 diff --git a/vole.md b/vole.md new file mode 100644 index 0000000..c71ac19 --- /dev/null +++ b/vole.md @@ -0,0 +1,65 @@ +VOLE in the Head（VOLEitH）に関する解説を、指定された流れと学術的な要件に従い、以下に記述します。 + +--- + +## 予備知識：Vector Oblivious Linear Evaluation (VOLE) および VOLE-in-the-Head + +本稿では、ゼロ知識証明システムを構築するために用いられる、Vector Oblivious Linear Evaluation（VOLE）、VOLEベースゼロ知識（VOLE-ZK）、および VOLE-in-the-Head（VOLEitH）の概念について解説する。 + +### 1. Vector Oblivious Linear Evaluation (VOLE) + +VOLE は、情報理論的安全性を基盤としたゼロ知識証明の構成要素として重要な役割を果たす。特に、VOLEは線形準同型コミットメントスキームの一種として利用される。 + +$k$ をセキュリティパラメータとし、$\mathbb{F}_{2^k}$ を有限体とする。VOLE（Vector Oblivious Linear Evaluation）相関は、長さ $\ell$ のベクトルに対して定義される。VOLE相関は、以下のパラメータによって特徴づけられる: + +1. **グローバルキー** ($\Delta \in \mathbb{F}_{2^k}$): ランダムに選択される。 +2. **ランダムビット**（$u_i \in \mathbb{F}_2$）の集合。 +3. **VOLEタグ**（$v_i \in \mathbb{F}_{2^k}$）の集合。 +4. **VOLEキー**（$q_i \in \mathbb{F}_{2^k}$）の集合。 + +これらの要素は、以下の**VOLE相関式**を満たす: + +$$ +q_i = u_i \cdot \Delta + v_i \quad \text{for } i = 0, \ldots, \ell-1 \quad (1) +$$ + +ここで、**証明者（Prover, P）**は $u_i$ および $v_i$ の値を知り、**検証者（Verifier, V）**は $q_i$ および $\Delta$ の値を持つ。 + +このVOLE相関は、証明者がランダムビット $u_i$ にコミットするための**線形準同型コミットメントスキーム**として機能する。 + +* **秘匿性（Hiding）**: 検証者の持つ $q_i$ の値において、ランダムな $v_i$ が $u_i$ をマスクするため、秘匿性が保証される。 +* **拘束性（Binding）**: 証明者が $\Delta$ の知識なしに、コミットした値 $u_i$ と異なる値 $u'_i$ に開示するためには、$\Delta$ を推測する必要がある。これは $\mathbb{F}_{2^k}$ において確率 $2^{-k}$ でしか起こり得ないため、拘束性が保証される。 + +### 2. VOLEベースゼロ知識証明 (VOLE-ZK) の課題 + +VOLE相関の線形準同型性（加法準同型性）は、効率的なゼロ知識証明（VOLE-ZK）を構築する上で特に有用である。VOLE-ZKプロトコルは、事前に準備されたランダムなVOLE相関を用いて、コミット・アンド・プルーフ型の構造で、非常に効率的な証明を可能にする。例えば、QuickSilverプロトコル は、このパラダイムに基づいている。 + +しかし、従来のVOLE-ZKプロトコルは本質的に**指定検証者証明**（designated verifier proofs）であった。これは、プロトコルの健全性（Soundness）を確保するために、**検証者（V）が秘密の状態**、すなわち $\Delta$ と $q_i$ の値を保持し続ける必要があったためである。この制約により、証明が第三者による検証を可能とする**公開検証可能性**（public verifiability）を持たなかった。 + +### 3. VOLE-in-the-Head (VOLEitH) による公開検証可能性の獲得 + +VOLE-in-the-Head（VOLEitH）は、VOLE-ZKプロトコルを非対話形式に変換し、公開検証可能性を達成するための新しい手法である。 + +VOLEitHは、指定検証者設定のゼロ知識プロトコルを、非対話型かつ公開検証可能（NIZK）なプロトコルへと変換する**コンパイラ**として機能する。この変換は、OT（Oblivious Transfer）ベースのZKプロトコルをコンパイルする一般的なアプローチに基づいており、VOLE相関を生成するプロセスを、**計算的に秘匿性があり、直線的に抽出可能なオール・バット・ワンベクトルコミットメント**に基づいたメカニズムで置き換えることにより実現される。 + +#### VOLEitHのメカニズム：秘密のコミットメントと遅延されたチャレンジ + +VOLEitHが公開検証可能性を獲得する鍵は、検証者と秘密の状態を共有することなく、証明者が自己完結的にVOLE相関をコミットメントできる点にある。 + +1. **シード生成とコミットメント**: 証明者（P）はまず、自身の値 $u_i$ と $v_i$ を生成する。これらの値は、擬似乱数シードのベクトルコミットメント（**オール・バット・ワンベクトルコミットメント**）を用いてコミットされる。 + * このコミットメントは、長さ倍増PRGの木構造（GGM構成）を利用して構築される。 + * 証明者（P）は、単一のハッシュ値（コミットメント）を送信する。これにより、Pは $N$ 個のシード（擬似乱数）にコミットする。 +2. **VOLE相関への変換**: Pは、このベクトルコミットメントをVOLE相関に変換する。 +3. **チャレンジの遅延と非対話化**: 重要な点として、VOLE相関の**グローバルキー $\Delta$ は、ゼロ知識証明の主要なステップが実行された後でなければ、Pに与えられてはならない**。 + * $\Delta$ が事前に知られると、VOLEコミットメントの**拘束性**が破られてしまうためである。 + * VOLEitHでは、検証者（V）からのチャレンジ $\Delta$ は、Fiat-Shamir変換を用いて、証明のトランスクリプトのハッシュ値から導出される。 +4. **開示と検証**: チャレンジ $\Delta$ が確定した後、Pはベクトルコミットメントの開示（opening）を送信する。この開示は、コミットされた $N$ 個のシードのうち $N-1$ 個を、わずか $O(\log N)$ の通信量で開示する。 + * Vは、この開示と $\Delta$ を用いて、VOLE相関式 (1) を満たす $q_i$ の値を再構築し、Pの計算が正しいことを検証できる。 + +このようにして、VOLEitHは、検証者が秘密の状態を事前に保持することなく、プロトコル全体を非対話型に変換することを可能とし、**誰でも検証可能な公開検証可能性**を実現する。 + +### 4. VOLE in the Headの応用 + +VOLEitHは、その効率性と公開検証可能性から、様々な暗号学的構成要素に応用されている。 + +VOLEitHの重要な応用の一つとして、**FAEST**が挙げられる。FAESTは、VOLEitH構成に基づくポスト量子署名スキームであり、VOLEitHとQuickSilver情報理論的証明システムを組み合わせることにより、非対話型署名アルゴリズムを構築している。FAESTは、AES（Advanced Encryption Standard）のプリイメージの知識を証明することに基づいて設計されており、対称鍵プリミティブのみに依存する保守的なセキュリティ仮定を用いている。FAESTは、その効率的な設計により、他のポスト量子署名スキームと比較して、署名サイズが最小クラスとなることを実現している。FAESTのゼロ知識証明システムは、VOLEitHにより、公開検証可能となっている。