用語集

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

カテゴリ: 暗号プリミティブ / STARK 証明 / 検証パイプライン / 掲示板と透明性 / 改ざんシナリオ / インフラストラクチャ / セッションと API / 定数

暗号プリミティブ

コミットメント（総称）

本書で「コミットメント」と書く場合、文脈に応じて次のいずれかを指します。 両者は対象とドメイン分離タグが異なるため、明示が必要な箇所では下位用語（投票コミットメント / 入力コミットメント）を使います。

投票コミットメント（Vote Commitment）

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

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

Merkle ルート（Bulletin Root）

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

Merkle パス（Audit Path）

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

包含証明（Inclusion Proof）

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

詳細: CT Merkle ツリー

整合性証明（Consistency Proof）

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

詳細: CT Merkle ツリー

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

zkVM が処理した公開可能な入力フィールドの一部を、固定のドメインタグと version を含む正準エンコーディングで SHA-256 ハッシュした値です。 現行実装では electionId、bulletinRoot、treeSize、totalExpected、votesCount、各投票の index、コミットメント、Merkle パスを束縛します。 対象は public-input.json より狭い部分集合です。

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

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

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

詳細: STH ダイジェスト

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

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

詳細: ビットマップ Merkle

提示ビットマップルート（Seen Bitmap Root）

zkVM ゲストに提示された投票インデックスを表すビットマップの Merkle ルートです。 includedBitmapRoot と組み合わせることで、自票が「counted された」「提示されたが無効だった」「そもそも prover に提示されなかった」のどれに該当するかを説明できます。

詳細: ビットマップ Merkle

正準エンコーディング（Canonical Encoding）

固定のドメインタグ、バージョン番号、フィールド順を含む決定論的なバイト列表現です。 同一の入力から常に同一のバイト列が得られることを保証します。 本システムではコミットメントと入力コミットメントの計算に使用します。

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

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

投票レシート（Vote Receipt）

投票受理時にサーバーが返す応答データです。 voteId、commitment、bulletinIndex、bulletinRootAtCast を含みます。 検証では voteReceipt として参照されます。 投票者がローカルに保持する投票時データ（選挙 ID、選択肢、乱数）とは別物であり、zkVM が生成する STARK レシート（Receipt）とも別物です。 Cast-as-Intended 検証では、投票時データからコミットメントを再計算し、投票レシートのコミットメント値と照合します。

詳細: コミットメントスキーム、4 段階検証モデル

STARK 証明

STARK（Scalable Transparent ARgument of Knowledge）

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

詳細: zkVM の基礎

RISC Zero zkVM

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

詳細: zkVM の基礎

レシート（Receipt）

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

ジャーナル（Journal）

zkVM ゲストプログラムの公開出力です。 現行契約は methodVersion=14 で、検証済み集計結果、missingSlots / invalidPresentedSlots / excludedSlots、inputCommitment、includedBitmapRoot、seenBitmapRoot などを含みます。 レシートに暗号学的に束縛されており、改ざんできません。

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 ステータスを返します。 本番環境では使用してはなりません。

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

ジャーナル契約（Journal Contract）

methodVersion で識別されるジャーナル出力構造の仕様です。 ゲストプログラムが出力するフィールドの集合と意味を定義します。 現行契約は methodVersion=14（v1.4）です。 ゲストプログラムの変更は新しい Image ID の生成を伴い、検証時には期待 Image ID との一致が確認されます。

レシートラッパー JSON

ホストバイナリが出力する { "receipt": ..., "image_id": "0x..." } 形式のラッパー JSON です。 STARK レシート本体を image_id と一緒に運ぶための受け渡し形式で、検証サービスはこの形式を読み込んで Receipt::verify(expected_image_id) を実行します。 配布対象アーカイブ内のファイル名は receipt.json です。 本書では「レシート」「STARK レシート」「receipt.json」「レシートラッパー JSON」を次のように使い分けます。

詳細: ホストと証明生成

検証パイプライン

「検証」と「監査」の使い分け 本書では、/verify 画面と内部パイプラインによる判定を 検証、第三者が bundle.zip をローカルに取得して独立に行う確認作業を 監査 と呼び分けます。 reproducibility/ 章は主に「監査」の文脈で書かれており、verification/ 章は「検証」の文脈で書かれています。

fail-closed

検証 API と検証パイプラインが、データ不在や未解決状態を成功側に倒さず、not_run、失敗、Warning 側へ確定させる方針です。 要求された証拠が揃わない限り Verified に到達させない設計姿勢を指します。 cast-time 証跡の not_run 扱い、ゲーティングロジックの不変条件、重要度の required 扱いは、いずれもこの方針の具体化です。

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

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

詳細: 4 段階検証モデル

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

検証の第 1 段階です。 投票者がローカルに保持する投票時データ（選挙 ID、選択肢、乱数）からコミットメントを再計算し、投票レシート（voteReceipt）のコミットメント値と照合します。 これにより、投票時に意図した選択が正しくコミットメントに反映されたことを確認します。 クライアント側で完結します。

詳細: 4 段階検証モデル

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

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

詳細: 4 段階検証モデル

cast-time 証跡（Cast-Time CT Artifact）

投票受理時に CT ツリーへ書き込んだ時点の証跡です。 具体的には voteReceipt（投票レシート）と userVote.proof（包含証明パラメータ: leafIndex、treeSize、auditPath）の 2 つを指します。 Recorded-as-Cast の検証では両方が必要で、Cast-as-Intended では voteReceipt のみを使用します。 取得経路と fail-closed 挙動の詳細は設計と実行フローを参照してください。

詳細: 4 段階検証モデル

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

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

詳細: 4 段階検証モデル

STARK 検証（STARK Verification）

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

詳細: 4 段階検証モデル

検証チェック（Verification Check）

検証パイプラインを構成する個別の原子的な検証項目です。 それぞれ一意の ID、所属する検証段階、証拠種別、重要度を持ちます（現行のチェック数と内訳は チェック一覧 を参照）。 Counted-as-Recorded には counted_election_manifest_consistent と counted_close_statement_consistent も含まれ、公開監査アーティファクトとの整合も required 条件です。

詳細: チェック一覧

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

検証チェックの結果を集約し、「Verified」「Verification Failed」「Warning」のいずれを表示するかを決定するロジックです。 required 扱いのチェックが 1 つでも failed なら Verified は表示されず、not_run / pending / running や必須証拠欠落でも Verified にはなりません。 Stage のステータスも、その Stage で required 扱いになるチェック群全体から導出されます。

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

公開監査アーティファクト

election-manifest.json（選挙設定の公開監査用スナップショット）と close-statement.json（集計締切時点のログ境界を表す公開監査レコード）の総称です。 Counted-as-Recorded 段階の必須チェック（counted_election_manifest_consistent、counted_close_statement_consistent）で整合性が検証されます。

詳細: チェック一覧、バンドル構造

締切ステートメント（close-statement.json）

集計締切時点のログ境界を表す公開監査レコードです。 logId、treeSize、bulletinRoot、sthDigest、timestamp を宣言し、counted_close_statement_consistent チェックで検証入力やジャーナルとの整合が確認されます。 本書では close-statement.json の和訳呼称として「締切ステートメント」を使います。

詳細: チェック一覧、バンドル構造

公開可能アーティファクト

秘密データを含まず、第三者検証や監査に利用できるアーティファクトの機密性区分です。 ここでの「公開可能」は無認証で取得できることを意味しません。 通常の配布や取得は capability 保護 API が担当し、対象が S3 にある場合も API が読み出して返します。

詳細: 公開境界、バンドル構造

配布対象アーカイブ（bundle.zip）

公開許可リストに基づいて作成される ZIP アーカイブです。 証明バンドル のうち公開可能アーティファクトだけを束ねた部分集合で、bundle.zip というファイル名で配布されます。 現行構成は public-input.json、election-manifest.json、close-statement.json、receipt.json、journal.json などを含みます。 input.json、verification.json、included-bitmap.json、seen-bitmap.json は含まれません。 bundle.zip が公開可能アーティファクトだけを含むことは、無認証公開を意味しません。

詳細: バンドル構造

保護された検証レポート（verification.json）

サーバー側検証の詳細結果を記録する protected report artifact です。 配布対象アーカイブ bundle.zip には含まれず、通常のブラウザ / CLI 契約では capability 保護された GET /api/sessions/:sessionId/finalizations/:finalizationId/artifacts/report から API レスポンスとして取得します。

詳細: エンドポイント一覧

無認証公開

セッション ID や capability トークンなしで誰でも取得できる公開状態です。 本書では「公開可能」や「外部クライアント向け API」と区別して扱います。 現行のセッションスコープ API や bundle.zip 取得経路の多くは capability 保護されており、無認証公開ではありません。

詳細: バンドル構造

zkGate

STARK 検証の結果に基づいて Counted-as-Recorded チェックの評価を制御するゲートです。 STARK 未解決（not_run / running）の間、zkGate 対象チェックは not_run または pending になります。 STARK が failed の場合、zkGate 対象チェックも failed になり得ます。

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

証拠種別

検証チェックに使用するデータの出所を示す分類です。 local（投票時に確定したユーザー固有データ）、public（掲示板や capability 保護 API から取得する、秘密データを含まない検証用データ）、zk（zkVM ジャーナルに含まれるデータ）、demo（dev-mode receipt を許可した場合に、zk 証拠の表示用結果として使うデモ証拠）の 4 種別があります。 demo 証拠は production STARK proof としての Verified にはなりません。

詳細: チェック一覧

重要度（Criticality）

検証チェックの必須性を示す分類です。 required（失敗、未実行、未解決なら Verified をブロック）と optional（補助的で、単独では Verified をブロックしない）の 2 段階です。 recorded_sth_third_party のように、設定状況に応じて optional から blocking な required 相当に昇格するチェックもあります。

詳細: ゲーティングロジック、チェック一覧

掲示板と透明性

掲示板（Public Bulletin Board）

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

詳細: CT Merkle ツリー

RFC 6962

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

詳細: CT Merkle ツリー

STH（Signed Tree Head）

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

詳細: STH ダイジェスト

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

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

詳細: STH ダイジェスト

ルート履歴（Root History）

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

詳細: CT Merkle ツリー

改ざんシナリオ

改ざんシナリオ（Tamper Scenario）

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

詳細: 改ざんシナリオ

投票除外（Vote Exclusion）

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

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

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

excludedSlots

zkVM ジャーナルに含まれる、除外されたスロットの総数です。 0 でなければなりません。 0 より大きい場合は投票の未提示または未計上が発生しており、いかなる場合も「Verified」を表示してはなりません。 excludedSlots が現行の authoritative な公開除外数です。 excludedCount は古い入力を安全側に倒すための互換フィールドとしてだけ扱います。 現行レスポンスでは excludedCount を新規に返しません。

詳細: 4 段階検証モデル、ゲーティングロジック

インフラストラクチャ

ECS Fargate

AWS のサーバーレスコンテナ実行環境です。 本システムでは target の STARK 証明生成 task を実行するために使用します。 アイドル時のコストは 0 です。

詳細: 非同期プローバー

Step Functions

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

詳細: 非同期プローバー

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

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

詳細: 非同期プローバー

同期証明モード（Sync Proving）

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

Prover semaphore

DynamoDB の単一 lock item で、証明生成（RunProver）への同時進入数を制限する仕組みです。 通常の解放は Step Functions が行い、semaphore-janitor Lambda が terminal execution event と定期 sweep で残った owner を補償的に解放します。

詳細: 非同期プローバー

Quiesced phase

DynamoDB recovery の 4 phase（primary_active、primary_quiesced、replacement_quiesced、replacement_active）のうち、新規 session admission と prover / verification queue の consumption を止める切替中 phase です。 切替中の新規書き込みや非同期処理を fail-closed に抑止します。

詳細: Terraform

Develop operator gate

develop target で静的 frontend と API への viewer access を制限する、CloudFront signed-cookie gate です。 署名用の秘密鍵は KMS 内で管理し、導出した公開鍵だけを CloudFront trusted key group に登録します。 環境全体への入口を制限するもので、session-scoped な capability token の代わりにはなりません。

詳細: AWS runtime 境界

Saved-plan lane

plan stage が作成した exact saved plan だけを apply する deployment lane です。 normal と rollback を分け、rollback は Terraform plan が空でも approval を必須とします。

詳細: Terraform

Release authority

どの toolchain / prover image と application artifact をデプロイに使えるかを決める、受理済みの記録群です。 承認済み prover release record、それを選択する accepted pointer、そこから生成された app deployment record、および必要な承認・scan・signing evidence で構成されます。 target は現行 AWS 構成、legacy は退役対象の旧構成を指し、legacy 側のリソースは target runtime の authority に含めません。

詳細: イメージ署名、Terraform

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

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

詳細: イメージ署名

証明バンドル（Proof Bundle）

zkVM の実行結果を検証可能な形で保存、配布するためのアーティファクト群を指す 上位概念 です。 公開可能アーティファクト（public-input.json など）、protected report artifact（verification.json）、非公開アーティファクト（input.json、included-bitmap.json、seen-bitmap.json など）を含み得ます。 public /「公開可能」は秘密情報を含まず検証に利用可能であるという機密性の分類であり、無認証公開を意味しません。

公開許可リストで取り出した部分集合が 配布対象アーカイブ であり、それを ZIP 化したファイル名が bundle.zip です。 3 者の関係は次のとおりです。

証明バンドル ⊃ 配布対象アーカイブ ⊃ bundle.zip（ファイル）

「証明バンドル」は、AWS / S3 上の隣接オブジェクトや非公開アーティファクトも含めて議論したい箇所で使います。 単に公開可能な ZIP を指す場合は bundle.zip または「配布対象アーカイブ」を使います。

詳細: バンドル構造

隣接オブジェクト（Sibling Object）

S3 上で bundle.zip と同じ prefix（sessions/{sessionId}/{finalizationId}/）に配置される非 bundle ファイルです。 included-bitmap.json、seen-bitmap.json、verification.json などを指します。 bundle.zip には含まれませんが、コールバック復元や capability 保護された検証レポート配信で利用されます。

詳細: バンドル構造

セッションと API

セッション（Session）

一連の投票フロー（セッション作成、投票、集計、検証）を管理する単位です。 一意の sessionId（UUID v4）で識別されます。 クライアント側のローカルセッション TTL は投票 / 集計中が 30 分、検証中が 24 時間です。 サーバー側の保存 TTL は store 実装と runtime config に依存します。

詳細: セッションライフサイクル

選挙（Election）

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

集計確定（Finalization）

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

X-Session-ID

過去の contract で使われていたセッションスコーピング用の HTTP ヘッダーです。 現行 contract には含まれません。 現行のセッション特定は、path の sessionId と X-Session-Capability ヘッダーで行います。

詳細: エンドポイント一覧

X-Session-Capability

POST /api/sessions のレスポンスで返る署名付きセッショントークンを運ぶ HTTP ヘッダーです。 このヘッダーが運ぶ値を capability トークンと呼びます。 session-scoped / capability 保護 API で必須です（POST /api/sessions は新規セッション作成のため対象外）。 retired / debug route の扱いはエンドポイント一覧の Retired route と internal surfaceを参照してください。

詳細: エンドポイント一覧

capability 保護 API

セッション capability（X-Session-Capability ヘッダーが運ぶトークン）の提示を要求する API です。 外部クライアント向けに文書化されていても、無認証公開 API ではありません。

詳細: エンドポイント一覧

Turnstile

Cloudflare が提供する CAPTCHA サービスです。 POST /api/sessions、POST /api/sessions/:sessionId/votes、POST /api/sessions/:sessionId/finalizations が body の turnstileToken で Bot による不正アクセスを防止します。 token を要求するかどうかは実行環境の設定に依存します。 bypass の可否は runtime profile が一体として選び、production の bypass は認めません。session 作成の develop 例外も operator-gated runtime に限定されます。

詳細: エンドポイント一覧、AWS runtime 境界

定数