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 ビット）チャンク全体を返すため、対象ビット以外の counted 状態も同時に見える
受け入れた理由	64 票が 1 チャンクに収まり、63 票がボットのため情報価値が限定的
漏洩する情報	現行の 64 票構成では、全 64 票が集計に含まれたか否か

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

項目	内容
制約の内容	STARK 証明生成を CPU 前提で実行（ECS Fargate 16 vCPU / 32 GB）
受け入れた理由	GPU インスタンスは高価かつ起動に時間がかかるため、非同期キュー + Fargate が現実的だった
影響範囲	公開 AWS 構成では `FINALIZE_ASYNC_MODE=true` を前提に `POST /api/finalize` が非同期化され、証明完了まで数分待機が発生

コードベース自体は同期パスも保持しており、FINALIZE_ASYNC_MODE=false のローカル・テスト構成では同期レスポンスを返せます。