4 段階検証モデル

この章では、E2E 検証可能投票の各段階（Cast-as-Intended / Recorded-as-Cast / Counted-as-Recorded / STARK Verification）で成立する保証を説明します。

段階間の依存関係

概念モデルでは 4 段階を順に評価します。 ただし、実行場所は段階ごとに異なります。 Stage 1 はクライアントで実行し、Stage 2 から Stage 4 はサーバー中心で実行します。 実行責務の詳細は 設計と実行フロー を参照してください。

flowchart LR
  subgraph "証拠の生成"
    V["投票時<br/>投票レシート発行"]
    F["集計時<br/>zkVM 実行"]
  end

  subgraph "4 段階検証"
    S1["Stage 1<br/>Cast-as-Intended"]
    S2["Stage 2<br/>Recorded-as-Cast"]
    S3["Stage 3<br/>Counted-as-Recorded"]
    S4["Stage 4<br/>STARK Verification"]
  end

  V --> S1
  V --> S2
  F --> S3
  F --> S4

  S1 ~~~ S2
  S2 ~~~ S3
  S3 ~~~ S4

Stage 1: Cast-as-Intended

目的

投票者が意図した選択肢のコミットメントが、サーバーから返却された投票レシートと一致することを確認します。 この確認により、サーバーが投票者の選択を差し替える攻撃を検出します。

検証する内容

/verify 画面のクライアントコードがローカルに保持された 3 つの値（選挙 ID、選択肢、乱数）からコミットメントを再計算し、投票レシートのコミットメント値と照合します。 再計算の規則（ドメインタグ、正準フォーマット）は コミットメントスキーム を参照してください。

flowchart LR
  subgraph "投票時に確定したデータ"
    EID[選挙 ID]
    CH[選択肢]
    RND[乱数]
  end

  subgraph "再計算"
    HASH["SHA-256<br/>(ドメインタグ || 選挙ID || 選択肢 || 乱数)"]
  end

  subgraph "照合"
    CMP{"一致?"}
    REC[投票レシートの<br/>コミットメント]
  end

  EID --> HASH
  CH --> HASH
  RND --> HASH
  HASH --> CMP
  REC --> CMP

必要な証拠

選挙 ID、選択肢、乱数はクライアントセッション（localStorage.starkBallotSession）に保持されます。 投票レシートは capability で保護された GET /api/sessions/:sessionId/finalizations/:finalizationId/verification 応答の data.voterEvidence が availability: "available" のときに、その voteReceipt から取得します。

cast-time 証跡を再構成できない場合、data.voterEvidence は availability: "unavailable" と reason を返し、投票レシートは得られません（取得と fail-closed 挙動の正本は 設計と実行フロー）。

失敗モード

限界

この段階は投票者の手元データに依存します。 そのため、localStorage 消去後や別端末からは検証できません。

Stage 2: Recorded-as-Cast

目的

投票者のコミットメントが、追記専用の掲示板（CT Merkle ツリー）に正しく記録されていることを確認します。 さらに、掲示板が追記専用性を維持していることを検証します。 つまり、過去のエントリが削除や改変を受けていないことを確認します。 掲示板のツリー構造とハッシュ規則は CT Merkle ツリー を参照してください。

検証する内容

この段階には 3 系統の検証があります。

flowchart TB
  subgraph "2a: 包含証明"
    IP["包含証明の検証<br/>自分のコミットメントが<br/>ツリーに存在するか"]
  end

  subgraph "2b: 整合性証明"
    CP["整合性証明の検証<br/>投票時のルートから<br/>最終ルートへの追記専用性"]
  end

  subgraph "2c: 第三者 STH 検証"
    STH["STH 合意の検証<br/>独立したソース間で<br/>ツリー状態が一致するか"]
  end

  IP --> RESULT{"Recorded 系の証拠を総合評価"}
  CP --> RESULT
  STH --> RESULT

2a: 包含証明（Inclusion Proof）

RFC 6962 の PATH 関数に基づく CT スタイルの Merkle 包含証明を検証し、投票者のコミットメントが掲示板のツリーに含まれていることを確認します。 検証者はリーフハッシュと Merkle パスからルートハッシュを再計算し、期待されるルートと照合します。

2b: 整合性証明（Consistency Proof）

投票時点のツリー状態（ルートとサイズ）から、最終的なツリー状態への遷移が追記のみで行われたことを検証します。 RFC 6962 の SUBPROOF アルゴリズムに基づく整合性証明により、サーバーが過去のエントリを密かに削除したり順序を変更したりするスプリットビュー攻撃を検出します。

2c: 第三者 STH 検証（オプション）

複数の独立した STH（Signed Tree Head）ソースに問い合わせ、合意が成立しているかを確認します。 この確認により、サーバーが検証者ごとに異なるツリー状態を提示するスプリットビュー攻撃を検出します。 照合対象となるダイジェストの構成は STH ダイジェスト を、照合条件の詳細は チェック一覧 を参照してください。

必要な証拠

Recorded の検証リソースは GET /api/sessions/:sessionId/finalizations/:finalizationId/verification の data です。

cast-time 証跡（voteReceipt と、oldSize を与える userVote.proof.treeSize）を再構成できない場合、Recorded の必須チェックは not_run となり、全体判定は fail-closed で missing_evidence 側へ倒れます。 取得と admission の分離は 設計原則 4 を、check 単位の判定は チェック一覧 を参照してください。

失敗モード

Stage 3: Counted-as-Recorded

目的

掲示板に記録された全投票が、zkVM の集計処理に正しく含まれたことを確認します。 投票の除外、欠落、重複がないことも確認します。 さらに、公開された claimed tally（表示用集計値）が zkVM の verifiedTally と一致することを検証し、集計結果の完全性と整合性を保証します。

検証する内容

この段階では 10 個の required チェックが全て success であることを要求します。 導出ルールと journal 省略時のガード補正は ゲーティングロジック を参照してください。

1 つでも success でないチェックが残る場合、Counted は成功にならず、Verified をブロックします。

必要な証拠

公開入力サマリーはサーバー内部表現であり、レスポンスにそのまま含まれません。 inputCommitment が束縛するのは public-input.json の部分集合です。 通常応答で proof-bound な値は data.proofAuthority、claimed tally は data.presentation.tally に分離され、旧 flat field への fallback はありません。 各チェックの判定ロジックは チェック一覧 を参照してください。

重要な判定: 除外数（excludedSlots）

excludedSlots > 0 はハード失敗であり、全体の検証成功を阻止します。 除外数の解決順序と legacy aliases の扱いは チェック一覧の counted_missing_indices_zero を、全体判定への影響は ゲーティングロジック を参照してください。

失敗モード

Stage 4: STARK Verification

目的

zkVM の実行が正しく行われたことを STARK 証明（レシート）の暗号学的検証により確認します。 レシートの検証に成功すれば、ジャーナルの内容（集計結果、除外情報、入力コミットメント等）がゲストプログラムの正しい実行の結果であることが保証されます。

検証する内容

flowchart LR
  subgraph "入力"
    RCP[レシート<br/>Seal + Journal]
    EID[期待 Image ID]
  end

  subgraph "Rust 検証サービス"
    VF["Receipt::verify(image_id)"]
  end

  subgraph "結果"
    OK["success<br/>暗号学的に検証済み"]
    NG["failed<br/>証明が無効"]
    DM["dev_mode<br/>フェイクレシート"]
  end

  RCP --> VF
  EID --> VF
  VF --> OK
  VF --> NG
  VF --> DM

検証の 2 段階

STARK Verification では 2 つのチェックを実行します。

Image ID 照合: verifier-confirmed な receipt_image_id が期待 Image ID と一致し、ホスト主張値（imageId）や comparison-only の journal.imageId とも矛盾しないことを確認します。 Image ID はゲストプログラムから導出される暗号的識別子であり、プログラムの改変やホスト主張値の食い違いを検出します。 解決順の詳細は チェック一覧 を参照してください。

レシート検証: RISC Zero の Receipt::verify(image_id) を呼び出し、Seal（STARK 証明）がジャーナルと Image ID に対して暗号学的に正当であることを検証します。 この検証は計算量が多いため、サーバー側の Rust 検証サービスで実行されます。

必要な証拠

開発モードの検出

RISC0_DEV_MODE=1 で生成された dev-mode receipt はフェイクレシートであり、本物の STARK 証明ではありません。 dev_mode ステータスの検出、正規化、Demo Only（demo_only）表示のルールは ゲーティングロジック を参照してください。 profile ごとの帰結は次節の失敗モード表にまとめています。

失敗モードと非 production evidence

UI ステップの対応チェック、集約ルール、最終判定の決定方法は ゲーティングロジック を参照してください。