検証パイプライン

STARK Ballot Simulator の検証パイプラインは、投票の完全性を 4 段階で検証するシステムです。各段階は独立した暗号的保証を提供し、いずれかの段階が失敗した場合でも、どの段階で何が問題かを特定可能にします。

設計原則

本システムの検証パイプラインは、以下の 3 つの原則に基づいて設計されています。

原則 1: 必要な検証が未実行なら Verified を表示しない

検証チェックが not_run（未実行）または running（実行中）の状態にある場合、システムは「Verified」を表示しません。証拠の不在を成功として扱わないという姿勢です。

原則 2: 失敗した検証は即座にブロックする

excludedCount > 0（除外された投票が存在する）、整合性証明の失敗、第三者 STH 合意の不成立など、いずれかの必須チェックが失敗すれば、「Verified」表示は即座にブロックされます。

原則 3: チェック評価はサーバー中心、最終集約はクライアント

20 個の検証チェック（verificationChecks）は主にサーバー側（GET /api/verify）で評価されます。一方、最終的な Verified/Warning/Failed のサマリー集約はクライアント側（deriveVerificationSummary）で実行されます。STARK レシート検証はサーバー側の専用サービスで実行されます。validateVotingIntegrity は補助判定として実装されていますが、journal が取得できる場合にのみ実行されます（通常の /verify フローでは journal は省略）。

検証パイプラインの全体構造

1. 段階の依存関係

flowchart TD
  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"]
  UI["結果表示"]

  S1 --> S2
  S2 --> S3
  S3 --> S4
  S4 --> UI

2. 実行責務（どこで評価・検証されるか）

flowchart TD
  subgraph SERVER["サーバー側"]
    VFY["GET /api/verify<br/>Stage 1-3 を評価"]
    RUN["POST /api/verification/run<br/>Stage 4 を検証"]
  end

  subgraph CLIENT["クライアント（UI）"]
    UI["結果表示と最終サマリー集約<br/>（必要時に補助判定）"]
  end

  VFY --> UI
  RUN --> UI

検証の実行フロー

検証導線では、/result で STARK 検証を起動し、/verify で結果をポーリング表示します。

sequenceDiagram
  participant U as ブラウザ
  participant R as /result
  participant V as /verify
  participant A as API サーバー
  participant VS as 検証サービス

  U->>R: 「検証へ進む」をクリック
  R->>A: POST /api/verification/run（必要時）
  A->>VS: レシート + Image ID
  VS->>VS: Receipt::verify(imageId)
  VS-->>A: 検証レポート保存
  R-->>V: /verify へ遷移

  loop STARK 完了までポーリング
    V->>A: GET /api/verify
    A-->>V: 検証ペイロード<br/>(ステップ, チェック, 証明材料)
  end

  Note over V: クライアントは表示とシーケンス制御を実行

4 段階の概要

段階	名称	証明する内容	検証の実行場所
Stage 1	Cast-as-Intended	投票者の意図通りにコミットメントが生成された	サーバー（`GET /api/verify`）
Stage 2	Recorded-as-Cast	コミットメントが追記専用掲示板に正しく記録された	サーバー（`GET /api/verify`）
Stage 3	Counted-as-Recorded	記録された全投票が正しく集計に含まれた	サーバー（`GET /api/verify`）
Stage 4	STARK Verification	zkVM の実行が正しく行われたことの暗号学的証明	サーバー（`POST /api/verification/run`）

クライアントは verificationSteps / verificationChecks の表示と、verificationChecks からの最終サマリー集約を担当します。validateVotingIntegrity は journal が利用可能な場合にのみ実行できる補助判定です。

各段階の詳細は 4 段階検証モデルを参照してください。

検証チェック数

パイプライン全体で 20 個の検証チェックが定義されており、各チェックには一意の ID が割り当てられています。

段階	チェック数
Cast-as-Intended	4
Recorded-as-Cast	6
Counted-as-Recorded	8
STARK Verification	2
合計	20

チェックの詳細はチェック一覧を参照してください。

この部に含まれる章

4 段階検証モデル — 検証の全体設計と各段階の保証
チェック一覧 — 全検証チェック ID とその判定ロジック
バンドル構造 — 証明バンドルの公開・非公開アーティファクト
ゲーティングロジック — 「Verified」表示の条件と不変条件

Keyboard shortcuts

STARK Ballot Simulator Public Docs