用語集

本書で使用する主要な用語の定義です。暗号・検証の基礎用語と実装・運用の主要用語に分けて掲載しています。

暗号プリミティブ

コミットメント（Vote Commitment）

ドメイン分離タグ、選挙 ID、投票選択肢、乱数を結合して SHA-256 でハッシュした値。投票内容を秘匿しつつ（隠蔽性）、後から変更できないことを保証する（束縛性）。投票の Cast-as-Intended 検証の起点となる。

詳細: コミットメントスキーム

Merkle ルート（Bulletin Root）

掲示板上の全投票コミットメントから RFC 6962 の規則に従って計算されるハッシュ値。掲示板の特定時点における状態を一意に表現する。新しい投票が追加されるたびに更新される。

Merkle パス（Audit Path）

特定のリーフ（投票コミットメント）からルートまでを再構成するために必要な兄弟ノードのハッシュ列。包含証明の構成要素であり、対数オーダーの検証コストを実現する。

包含証明（Inclusion Proof）

特定の投票コミットメントが掲示板に含まれていることを暗号学的に証明するデータ。リーフインデックス、監査パス、ツリーサイズから構成される。RFC 6962 のハッシュ規則に従い、リーフとパスからルートを再計算して期待値と照合する。

詳細: CT Merkle ツリー

整合性証明（Consistency Proof）

RFC 6962 で定義された、2 つの時点のツリーが追記関係にあることを暗号学的に証明するデータ。古いツリーが新しいツリーのプレフィックスであること（投票の削除・並べ替えが行われていないこと）を保証する。

詳細: CT Merkle ツリー

入力コミットメント（Input Commitment）

zkVM に渡される入力全体（全投票のインデックス、コミットメント、Merkle パス）を正準エンコーディングで結合し SHA-256 でハッシュした値。zkVM が公開入力と同一のデータを処理したことを保証するバインディングとして機能する。

詳細: 入力コミットメント

STH ダイジェスト（Signed Tree Head Digest）

掲示板のログ ID、ツリーサイズ、タイムスタンプ、ルートハッシュを結合して SHA-256 でハッシュした値。特定の時点における掲示板の状態を一意に識別し、複数の独立した監視者間で掲示板の一貫性を検証するために使用する。

詳細: STH ダイジェスト

包含ビットマップルート（Included Bitmap Root）

zkVM ゲストが生成するビットマップ（各投票インデックスが集計に含まれたか否か）の Merkle ルート。投票者は自分のインデックスに対応するビットが 1 であることを Merkle 証明で確認できる。

詳細: ビットマップ Merkle

ドメイン分離タグ（Domain Separation Tag）

ハッシュ計算において異なる用途のデータが衝突しないように付与するプレフィックス文字列。本システムでは、コミットメント、入力コミットメント、CT Merkle のリーフ・ノードハッシュにそれぞれ固有のタグを使用する。

STARK 証明

STARK（Scalable Transparent ARgument of Knowledge）

Trusted setup（信頼されたセットアップ）を必要としない暗号証明方式。ハッシュベースの構成により耐量子計算機性に優位がある。本システムでは RISC Zero zkVM によって投票集計の正当性を証明するために使用する。

RISC Zero zkVM

RISC-V アーキテクチャ上で通常の Rust コードを実行し、その実行が正しく行われたことの STARK 証明を生成するゼロ知識仮想マシン。ゲストプログラムとホストプログラムから構成される。

レシート（Receipt）

zkVM が生成する暗号証明オブジェクト。内部に Seal（STARK 証明本体）とジャーナル（公開出力）を含む。Receipt::verify(image_id) によって、特定のゲストプログラムが正しく実行されたことを第三者が検証できる。

ジャーナル（Journal）

zkVM ゲストプログラムの公開出力。検証済み集計結果、除外された投票数、入力コミットメント、包含ビットマップルート等を含む。レシートに暗号学的に束縛されており、改ざんできない。

Image ID

コンパイル済みのゲストプログラムバイナリを一意に識別するハッシュ値。レシート検証時に期待される Image ID と照合することで、意図したゲストプログラムによって生成された証明であることを確認する。プローバーイメージの更新時に同期して更新が必要。

詳細: Image ID

ゲストプログラム（Guest Program）

zkVM 内部で実行される Rust プログラム。投票データの検証と集計を行い、結果をジャーナルとして出力する。ゲストの実行内容は STARK 証明によって保証される。

ホストプログラム（Host Program）

zkVM の外部で動作し、ゲストプログラムの実行と証明生成を制御する Rust プログラム。入力データの読み込み、zkVM の起動、レシートとジャーナルの出力を担う。

検証サービス（Verifier Service）

Rust で実装された独立した STARK レシート検証プログラム。Receipt::verify(expected_image_id) を実行し、レシートの暗号学的正当性を確認する。結果は verification.json として保存される。

詳細: 検証サービス

フェイクレシート（Fake Receipt）

RISC0_DEV_MODE=1 で生成される暗号学的保証のないレシート。開発効率のためのモックであり、検証サービスは InnerReceipt::Fake を自動検出して dev_mode ステータスを返す。本番環境では使用してはならない。

検証パイプライン

E2E 検証可能投票（End-to-End Verifiable Voting）

投票者が自分の投票について「意図通りに投じた」「正しく記録された」「正しく集計された」の 3 段階を独立に検証できる投票方式。システム運営者を信頼せずとも投票の完全性を確認できることが目標。

Cast-as-Intended（意図通りの投票）

検証の第 1 段階。投票者が保持するレシート（選択肢、乱数、コミットメント）を再検証し、投票時に意図した選択が正しくコミットメントに反映されたことを確認する。クライアント側で完結する。

Recorded-as-Cast（記録通りの保存）

検証の第 2 段階。コミットメントが掲示板に正しく記録されたことを、RFC 6962 の包含証明と整合性証明によって確認する。掲示板が追記専用であること（投票が削除・改変されていないこと）を暗号学的に保証する。

Counted-as-Recorded（記録通りの集計）

検証の第 3 段階。掲示板に記録された全投票が zkVM の集計に過不足なく含まれたことを確認する。除外された投票がないこと（excludedCount == 0）は最重要不変条件。

STARK 検証（STARK Verification）

検証の第 4 段階。STARK レシートが暗号学的に正当であること、および期待される Image ID で生成されたことを確認する。ジャーナルの内容が正しい実行結果であることの最終的な保証。

検証チェック（Verification Check）

検証パイプラインを構成する個別の原子的な検証項目。20 個のチェックがあり、それぞれ一意の ID、所属する検証段階、証拠種別、重要度を持つ。

詳細: チェック一覧

ゲーティングロジック（Gating Logic）

検証チェックの結果を集約し、「Verified」「Verification Failed」「Warning」のいずれを表示するかを決定するロジック。必須チェックが 1 つでも failed であれば Verified は表示されない。

詳細: ゲーティングロジック

証拠種別

検証チェックに使用するデータの出所を示す分類。local（投票時に確定したユーザー固有データ）、public（掲示板や公開 API から取得可能なデータ）、zk（zkVM ジャーナルに含まれるデータ）、demo（教育用シミュレーション由来データ）の 4 種別がある。

重要度（Criticality）

検証チェックの必須性を示す分類。required（失敗すれば Verified をブロック）と optional（補助的で、単独では Verified をブロックしない）の 2 段階。

掲示板と透明性

掲示板（Public Bulletin Board）

全投票コミットメントを時系列で記録する追記専用のログ。RFC 6962 の Certificate Transparency モデルに基づき、包含証明と整合性証明によって第三者が監査可能な透明性を実現する。

詳細: CT Merkle ツリー

RFC 6962

Certificate Transparency（証明書の透明性）の標準規格。追記専用の Merkle ツリー、リーフハッシュ（0x00 プレフィックス）とノードハッシュ（0x01 プレフィックス）のドメイン分離、包含証明、整合性証明の仕様を定義する。本システムの掲示板は、この規格のハッシュ規則と証明アルゴリズムを参照した CT スタイル実装を採用している。

STH（Signed Tree Head）

掲示板の特定時点における状態の要約。ログ ID、ツリーサイズ、タイムスタンプ、ルートハッシュを含む。複数の独立したソースからの STH を比較することで、サーバーが異なるクライアントに異なるツリーを提示するスプリットビュー攻撃を検出する。

スプリットビュー攻撃（Split-View Attack）

掲示板サーバーが異なるクライアントに異なるツリー状態を提示する攻撃。特定の投票者に対してのみ投票を除外したツリーを見せることで、不正を隠蔽しようとする。整合性証明と STH の第三者検証によって検出される。

ルート履歴（Root History）

掲示板のルートハッシュ、ツリーサイズ、タイムスタンプの時系列記録。投票時のルートが最終ツリーの有効なプレフィックスであることを、整合性証明で検証する際に参照する。

改ざんシナリオ

改ざんシナリオ（Tamper Scenario）

検証システムが不正をどのように検出するかを教育的に示すシミュレーション。S0（正常）から S5（複合改ざん）まで 6 種類が定義されている。

詳細: 改ざんシナリオ

投票除外（Vote Exclusion）

一部の投票を集計から意図的に除外する攻撃。zkVM ジャーナルの excludedCount > 0 として検出される。本システムの最重要不変条件により、投票除外がある場合は「Verified」を表示しない。

主張集計改ざん（Claimed-Tally Tampering）

公開表示する集計値（claimed tally）を、zkVM が証明した実際の集計値と異なる値に書き換える攻撃の教育的シミュレーション。zkVM の入力・レシート・ジャーナルは正常なまま、公開表示のみを改ざんする。counted_tally_consistent チェックで検出される。

excludedCount

zkVM ジャーナルに含まれる、集計から除外された投票数。0 でなければならない。0 より大きい場合は投票除外が発生しており、いかなる場合も「Verified」を表示してはならない。

インフラストラクチャ

ECS Fargate

AWS のサーバーレスコンテナ実行環境。本システムでは STARK 証明生成に必要な大量のメモリ（32 GB）と CPU（16 vCPU）を提供するために使用する。アイドル時のコストは 0。

詳細: 非同期プローバー

Step Functions

AWS のワークフローオーケストレーションサービス。イメージ署名検証 → ECS プローバー実行 → コールバックの一連のフローを管理する。

非同期証明モード（Async Proving）

SQS → Step Functions → ECS Fargate の経路で STARK 証明を非同期に生成するモード。集計リクエスト（POST /api/finalize）は 202 Accepted を返し、クライアントはステータスポーリングで完了を待つ。

同期証明モード（Sync Proving）

ローカルプロセスで zkVM ホストバイナリを直接実行し、STARK 証明を同期的に生成するモード。開発環境で使用される。

イメージ署名検証（Image Signing）

ECS タスクで使用するプローバーコンテナイメージが、信頼できるビルドパイプラインから生成されたことを検証する仕組み。AWS Signer を使用し、Step Functions のゲートとして機能する。

詳細: イメージ署名

証明バンドル（Proof Bundle）

zkVM の実行結果を検証可能な形で保存・配布するためのアーティファクト群。公開許可リストに基づいて bundle.zip が作成され、非公開ファイルは含まれない。現行実装では、非同期バンドルは public-input.json / receipt.json / journal.json を含み、同期バンドルはこれに加えて metadata.json などの公開補助ファイルを含む場合がある。

詳細: バンドル構造

セッションと API

セッション（Session）

一連の投票フロー（セッション作成 → 投票 → 集計 → 検証）を管理する単位。一意の sessionId（UUID v4）で識別される。投票・集計中は 30 分、検証中は 24 時間の有効期限を持つ。

選挙（Election）

投票の論理的な単位。一意の electionId（UUID v4）で識別され、コミットメントのドメイン分離に使用される。選挙設定ハッシュ（electionConfigHash）が期待投票数などの設定を束縛する。

集計確定（Finalization）

全投票の収集後に zkVM 入力を構築し、STARK 証明を生成するプロセス。同期モード（ローカル実行）と非同期モード（ECS Fargate）の 2 つの実行パスがある。

X-Session-ID

多くの API リクエストで付与される HTTP ヘッダー。セッションスコーピングに使用され、異なるセッション間のデータアクセスを防止する。POST /api/session は新規セッション作成のため不要で、/api/verification/bundles/:sessionId/:executionId 系はパスパラメータで参照対象を指定する。

Turnstile

Cloudflare が提供する CAPTCHA サービス。/api/vote と /api/finalize で Bot による不正アクセスを防止するために使用する。開発環境では TURNSTILE_BYPASS=1 でバイパス可能。

定数