PoC の意図的な制約

本章では、公開版 PoC で意図的に受け入れている制約を 3 点に絞って説明します。

「バグではなく設計上の割り切り」であることを明確化し、本番移行時にどこを解消すべきかを共有します。

制約の全体像

項目	内容
制約の内容	`BOT_COUNT=63`、`MERKLE_TREE_DEPTH=6`（2^6 = 64 リーフ）で固定
受け入れた理由	単一ユーザーでも掲示板・Merkle・zkVM・検証 UI までの E2E フローを再現できる最小構成
影響範囲	入力サイズ、証明時間、ツリー深度、検証表示
本番移行方針	動的な投票数/ツリー深度への対応、証明分割または再帰証明の導入

PoC の主目的は「検証可能投票の成立条件を end-to-end で示すこと」であり、まずは 64 票固定でパイプライン全体の再現性を優先しています。

項目	内容
制約の内容	ビットマップ Merkle で 32 バイト（256 ビット）チャンクを返すため、対象ビット以外の隣接ビットも同時に見える
受け入れた理由	PoC では 63 票がボットであり、隣接ビットの情報価値が相対的に低い
漏洩する情報	近傍インデックスが集計に含まれたか否か
本番移行方針	チャンク縮小（より深い木）または 1 ビット単位に近い証明方式へ移行

本来はチャンクを小さくし、木を深くすることで漏洩を抑制できます。PoC では zkVM 実行時間とのトレードオフを優先し、現在のチャンク設計を採用しています。

項目	内容
制約の内容	STARK 証明生成を CPU 前提で実行（ECS Fargate 16 vCPU / 32 GB）
受け入れた理由	PoC 設計時点では GPU 版 Lambda を前提にできず、かつ Lambda のメモリ/実行時間制約が厳しかったため、非同期キュー + Fargate が現実的だった
影響範囲	`POST /api/finalize` は非同期実行を前提、証明完了まで数分待機が発生
本番移行方針	GPU 対応プローバー/実行基盤の成熟に合わせて、GPU ワーカーへの移行を再設計

この PoC では「GPU 実行を前提にした Lambda 経路を置かない」ことを先に固定し、運用容易性と再現性を優先しています。結果として、証明実行は SQS → Step Functions → ECS Fargate の非同期経路が中心になります。

上記の制約を受け入れていても、以下は常に維持します。

不変条件	根拠
`excludedCount > 0` で Verified を表示しない	投票除外は最重要の不正シグナル
整合性証明失敗で Verified を表示しない	追記専用性が崩れるため
必須チェック未実行（`not_run`/`running`）で Verified を表示しない	証拠不在を成功扱いしないため