技術選定

主要コンポーネントの技術選定理由を、背景・採用理由・トレードオフに絞って要約します。

1. STARK 証明: RISC Zero zkVM

背景

集計処理の正しさを暗号学的に示すため、ゼロ知識証明システムが必要でした。PoC では Trusted setup 不要の透明性を重視しています。

採用理由

• Trusted setup 不要で、投票システムの監査説明と整合する。
• RISC-V 上で通常の Rust コードを使えるため、実装と監査の往復がしやすい。
• Image ID による実行バイナリ照合と組み合わせやすい。

トレードオフ

• 64 票で約 370 秒の証明生成時間が必要。
• 証明サイズは小さくないため、クライアント配布よりサーバー検証向き。

詳細: zkVM 設計、Image ID

2. 追記専用掲示板: RFC 6962 CT Merkle

背景

Recorded-as-Cast には、包含証明だけでなく「後から削除・改変されていない」ことの証明が必要です。

採用理由

• RFC 6962 の整合性証明で追記専用性を示せる。
• 包含証明と整合性証明の両方を同一モデルで扱える。
• STH ダイジェストと組み合わせてスプリットビュー攻撃の検出力を上げられる。

トレードオフ

• ドメイン分離（0x00/0x01）を含む実装厳密性が要求される。
• 自前実装ゆえに、検証テストを厚く維持する必要がある。

詳細: CT Merkle ツリー、STH ダイジェスト

3. デュアルランタイム: Next.js + Hono（共通ハンドラー）

背景

開発時は Next.js の統合体験、運用時は API Gateway + Lambda の軽量 API 実行が必要です。どちらか片方に寄せるより、同一ハンドラーを複数アダプタで使う構成を採用しています。

採用理由

• ハンドラー実装は 1 本化し、ランタイム差分はアダプタに限定。
• NEXT_PUBLIC_API_BASE_URL 未設定時は相対 /api を使い、同一フロント実装で両経路に対応。

トレードオフ

• Next/Hono の両アダプタを継続保守する必要がある。
• ランタイム差異の回帰をテストで継続検出する必要がある。

詳細: API リファレンス、トポロジー

4. インフラ分割: Amplify Gen2 + Terraform

背景

Web/API/Data と、重量級の証明パイプラインでは必要な運用粒度が異なります。

採用理由

• Amplify Gen2: フロント/ API / AppSync の開発速度を優先。
• Terraform: ECS / Step Functions / SQS / ECR など、証明基盤の低レイヤ制御を優先。
• 境界を分けることで、アプリ改修と証明基盤改修の干渉を下げる。

トレードオフ

• IaC が 2 系統になるため、運用知識の分散コストがある。
• デプロイ手順は単一ツールより長くなる。

詳細: AWS アーキテクチャ、Terraform

5. 証明実行環境: ECS Fargate（ARM64）

背景

STARK 証明生成は CPU/メモリ負荷が高く、通常の HTTP リクエスト処理と分離が必要です。PoC 設計時点では GPU 版 Lambda を前提にできず、SQS → Step Functions → ECS の非同期経路を標準としています。

採用理由

• 16 vCPU / 32 GB の実行要求を満たせる。
• Step Functions と組み合わせて、署名検証や失敗ハンドリングを実装しやすい。
• ARM64 でビルドと実行を揃え、コスト効率を優先。

トレードオフ

• タスク起動待ち（コールドスタート）がある。
• コンテナビルド/署名/配布の運用が前提になる。

詳細: 非同期プローバー、イメージ署名

6. ビルド戦略: Base Image と App Image の分離

背景

RISC Zero ツールチェーンを毎回アプリイメージに同梱ビルドすると、CI 時間とコストが大きくなります。

採用理由

• ベースを分離することで、日々のアプリビルドを短縮。
• ARM64 でビルドと実行を統一し、x86_64 エミュレーションを避ける。
• 実行基盤（Fargate ARM64）と同一アーキでの再現性を保ちやすい。

詳細: イメージ署名、非同期プローバー