第三者検証ガイド
この章は、検証ページでダウンロードした bundle.zip と対応する公開 repository snapshot を使い、第三者がローカルに行える最小監査手順をまとめます。
/verify 画面の最終判定を完全に再現する手順ではなく、下表の不変条件を確認する手順です。
公開 snapshot に関する注意 すべての Step には、検証対象リリースと対応する公開 repository snapshot が必要です。 加えて、ZIP の admission と展開を行う Step 3 以降には、ダウンロード済み ZIP が必要です。
bundle.zip 単体では揃わないもの（検証材料として ZIP に入らないもの）：
GET /api/sessions/:sessionId/finalizations/:finalizationId/verificationが返す claimed tally （presentation.tally）、verification.checks、verification.steps- 投票者端末に残る投票意図、乱数、投票レシート
/verifyの Recorded-as-Cast 判定に使う session-scoped な自票 receipt / root-at-cast proof state と、サーバー側の整合性評価結果- 自票 inclusion 用のビットマップ証明
- 有効化されている場合の第三者 STH ソース照合
public-input.json には zkVM 入力として提示された各投票の index、commitment、Merkle path が含まれます。
この範囲は PoC の設計意図に沿っています。
配布対象アーカイブ の構成も参照してください。
この部の章
- ZIP ローカル検証（Ubuntu）：
bundle.zipを取得した第三者が Ubuntu 上で実行できる最小監査手順
想定読者と前提
- 想定読者：配布された
bundle.zipを独立にローカル監査したい第三者 - 前提：Ubuntu 系 Linux と
jq、unzipなどの基本 CLI、対応する公開リポジトリ snapshot へのアクセス。 詳細は はじめに を参照してください。
この部で扱わないもの
/verifyUI 最終判定の完全再現と、投票者端末のローカル証跡を使った Cast-as-Intended 検証（必要な材料は上の「bundle.zip単体では揃わないもの」を参照）- AWS インフラのデプロイと運用手順
関連する章
この章は bundle.zip のローカル監査に絞ります。
範囲外の作業は次のページを参照してください。
- チェック一覧：チェック ID と判定ロジック
- API エンドポイント一覧：手動検証に使う API 契約
- 検出メカニズム：改ざんシナリオごとの失敗パターン
- 非同期プローバー：非同期 finalize の処理と障害調査導線
- バンドル構造：配布対象アーカイブの公開可能なアーティファクトと非公開アーティファクト
- 用語集：「検証」と「監査」の使い分けほか
最低限確認する不変条件
| 項目 | 合格条件 |
|---|---|
| STARK レシート | verifier-service verify が status: "success" |
| receipt と journal の結合 | receipt 内の journal bytes を現行 contract で decode した全 proof-bound field が journal.json と一致 |
| 投票の除外有無 | excludedSlots == 0 かつ missingSlots == 0 かつ invalidPresentedSlots == 0 |
| 期待投票数整合 | totalExpected == treeSize |
| 処理投票数 | totalVotes > 0 |
| 集計合計整合 | journal.json の verifiedTally の合計が validVotes と一致 |
| 公開入力の基本整合性 | public-input.json が現行 contract に沿い、入力数、root、重複検査が成立 |
| 公開監査アーティファクト | election-manifest.json と close-statement.json の自己整合と相互整合が成立 |
| 入力整合性 | inputCommitment の再計算値が journal.json と一致 |