改ざんシナリオ

STARK Ballot Simulator は、E2E 検証可能投票の教育的デモとして 6 つの改ざんシナリオ（S0〜S5）を提供します。各シナリオは投票システムに対する特定の攻撃を模擬し、検証パイプラインがどのチェックで異常を検出するかを実演します。

本章の前提（実 API 基準）

本章は、src/server/api / src/lib/finalize / src/lib/verification の実 API 実装を基準に説明します。

NEXT_PUBLIC_USE_MOCK_API=true で mock API を使う場合は fixture ベースの応答になるため、チェック結果やステップ表示が本章と異なることがあります
特にローカル開発既定値（.env.local.example）では mock API が有効化されるため、実 API での再現時は mock API を無効化して確認します

教育モードの目的

改ざんシナリオは、暗号的検証が実際に機能することを確認するために設計されています。

正常ケース（S0）を基準として、検証パイプラインが通過する状態を確認する
攻撃シナリオ（S1〜S5）を適用して、どの不変条件が破れると検証が失敗するかを確認する

攻撃の 2 類型

flowchart TD
  A["攻撃類型"]
  I["入力改ざん (tamperMode=input)<br/>S1 / S3 / S5"]
  C["主張改ざん (tamperMode=claim)<br/>S2 / S4"]

  A --> I
  A --> C

この図は「改ざんがどこに入るか」の分類のみを示します。どのチェックで失敗するかの詳細は検出メカニズムを参照してください。

入力改ざん（S1/S3/S5）: 典型的には counted_missing_indices_zero（excludedCount > 0）で検出。S5 の再集計分岐では counted_tally_consistent が併発する場合があります
主張改ざん（S2/S4）: 典型的には counted_tally_consistent（claimed と verified の不一致）で検出

実装上、/api/verify の counted_* は STARK 状態でゲートされるため、verificationStatus=not_run では not_run、verificationStatus=running では pending が返り得ます。

シナリオ適用単位

現行実装では 1 回の finalize で選べるシナリオは 1 つです。

UI: /aggregate は single-select（S0〜S5 のラジオボタン）
API: POST /api/finalize は scenarioId を 1 つ受け取る
finalize 実行モードは FINALIZE_ASYNC_MODE で切り替わる（false: 同期, true: 非同期）
.env.local.example の既定値は FINALIZE_ASYNC_MODE=false（同期）
AWS 運用では通常 FINALIZE_ASYNC_MODE=true（非同期）を使う

この部に含まれる章

シナリオ一覧 — S0〜S5 の定義、データフロー、実装上の扱い
検出メカニズム — シナリオ別に失敗するチェックと最終判定