全体像

STARK Ballot Simulator は、投票の完全性を段階的に検証するための PoC です。 AWS runtime は個人プロジェクトとして運用できるよう、WAF を採用せず、artifact lifecycle やオンデマンド実行を前提にコストを抑える設計です。

flowchart LR
  A[Cast-as-Intended] --> B[Recorded-as-Cast]
  B --> C[Counted-as-Recorded]
  C --> D[STARK Verification]

投票から検証までの流れ

sequenceDiagram
  participant V as 投票者
  participant S as サーバー
  participant B as 掲示板
  participant Z as zkVM
  participant VS as 検証サービス

  V->>S: 投票意図（選択肢・乱数）+ コミットメント
  S->>B: 掲示板に追記
  S-->>V: 投票レシート
  Note over S: ボット投票を自動追加
  V->>S: POST /api/sessions/:sessionId/finalizations で finalization を要求
  S->>Z: 同期または SQS / Step Functions / ECS 経由で証明生成
  Z-->>S: STARK レシート + ジャーナル
  S-->>V: /result で tally と finalization output を表示
  V->>S: POST /api/sessions/:sessionId/finalizations/:finalizationId/verification
  alt local profile
    S->>VS: local bundle の verifier-service を同期実行
  else target AWS profile
    S->>VS: durable SQS queue 経由で verification worker を実行
  end
  VS-->>S: receipt を検証し protected report artifact を保存
  V->>S: /verify が同じ finalization-scoped verification GET をポーリング
  S-->>V: 段階別チェックと overall verdict を表示

図から読み取れない要点は次の 3 点です。

• finalization と STARK receipt verification は別の lifecycle です。finalization は集計結果、zkVM ジャーナル、STARK レシート、配布用バンドルを作る段階であり、STARK receipt verification が常に同時に完了するわけではありません。
• 実行形態は profile で分かれます。ローカル構成は finalization と verifier-service を同期実行できますが、AWS target runtime は finalization を SQS、Step Functions、ECS Fargate で非同期実行し、STARK receipt verification は durable SQS queue 経由の verification worker が担います。非同期のあいだ、ブラウザは GET /api/sessions/:sessionId/finalizations/current と finalization-scoped verification GET をポーリングします。
• verification POST 応答の verificationStatus と、available な verification GET resource の verifierResult.status は STARK receipt verification の状態であり、どちらも overall verdict ではありません。ブラウザはローカルの Cast-as-Intended 証拠を server checks に重ね、共有 presentation policy が 4 段階の必須チェックと hard-failure 条件を評価して、最終的な「Verified / 失敗 / 制限付き」などの表示を導きます。

検証で扱う要素

各段階の目的、必要な証拠、失敗モードは 4 段階検証モデル を参照してください。

バンドル用語の階層

検証で扱うアーティファクト群は、証明バンドル ⊃ 配布対象アーカイブ ⊃ bundle.zip（ファイル） の 3 層で呼び分けます。 定義は 用語集 > 証明バンドル、詳細は バンドル構造 を参照してください。 verification.json は bundle.zip のメンバーではなく、capability 保護された report artifact として扱います。

PoC として受け入れている制約

次の制約は、検証可能投票の E2E フローを明瞭に示すための意図的な PoC スコープです。実装漏れでも、本番選挙システムとしての安全性・性能の主張でも ありません。正確な定数や mode 条件は各技術章を単一の参照先とします。

プロジェクト規模

コードベースの規模は、テストを含め約 33 万行です。内訳は次のとおりです（2026 年 8 月時点）。

各章への案内