BLUEPRINT

第12章：技術アーキテクチャ

12.1 アーキテクチャ概要

┌─────────────────────────────────────────────┐
│  アプリケーション層（DApp、Fayインターフェース、│
│  ガバナンスUI）                               │
├─────────────────────────────────────────────┤
│  Layer 2：ZK Rollup（高頻度                   │
│  トランザクション処理）                        │
│  - 貢献記録、親密度更新、                      │
│    日常インタラクション                        │
├─────────────────────────────────────────────┤
│  Layer 1：Substrate専用チェーン               │
│  （決済とコンセンサス）                        │
│  - 状態ルートアンカリング、アイデンティティ管理、│
│    ガバナンス投票                              │
├─────────────────────────────────────────────┤
│  アイデンティティ層：DID + PKI + ZKP           │
└─────────────────────────────────────────────┘

12.2 技術選定の比較

議論中に複数のアプローチが評価されました：

アプローチ利点欠点結論
Ethereumメインネット成熟したエコシステム、高いセキュリティ高いガス代、低いTPS（15–30）人口規模の高頻度記録には不適
Ethereum L2手数料の削減Ethereumエコシステムに制約される代替案
DAG（IOTA/Nano）高スループット、手数料なしコンセンサスセキュリティが弱いセキュリティ不十分
Substrateカスタムチェーン完全にカスタマイズ可能、ガス代なし独自のエコシステム構築が必要推奨

ガス代の問題

ガス代はEthereumのようなパブリックチェーンにおけるトランザクションごとの計算コストです。全人口が日々大量の微小な貢献記録を生成する中で、それぞれをオンチェーンに記録するのは法外に高価になります。GMCには無料または極めて低コストの記録方法が必要です。

スループットの問題

Ethereumメインネットは約15–30 TPSを処理します。世界中の数十億ユーザーからの貢献記録に対して、このスループットは到底十分ではありません。

12.3 Substrate専用チェーン

なぜSubstrateなのか

  1. 完全にカスタマイズ可能なコンセンサス：貢献記録に特化したコンセンサスアルゴリズムを設計できます
  2. ガス代なし：手数料無料のトランザクションとして設計できます
  3. カスタマイズ可能なガバナンスモジュール：コミュニティコンセンサスに自然に適しています
  4. Polkadotとの相互運用性：リレーチェーンを通じて他のチェーンと相互運用できます
  5. モジュラー：必要に応じてRuntimeモジュールを組み合わせられます

根拠

GMCの独自の要件により、汎用パブリックチェーンは不適切です：

  • 全人口参加 = 極めて高いトランザクション量
  • 微小な貢献記録 = 高頻度、低価値のトランザクション
  • 手数料を課せない = 貢献の記録が経済的負担になってはならない
  • カスタム減衰計算と親密度アルゴリズムが必要

12.4 ZK Rollup

核心的コンセプト

オフチェーンで実行し、オンチェーンで検証します：

  • 日々の貢献記録はL2で高速に処理され、手数料なし・高スループットです
  • バッチ記録のゼロ知識証明が定期的にL1に提出されます
  • L1は圧縮された状態ルートのみを保存します

ZK Rollup vs. Optimistic Rollup

特徴ZK RollupOptimistic Rollup
検証方法ゼロ知識証明（数学的保証）不正証明（チャレンジ期間）
確認時間高速低速（通常7日）
セキュリティ数学的保証正直なバリデーターに依存
計算コスト高い低い

選択：ZK Rollup — 評判システムには高速な確認と数学的に保証されたセキュリティが必要です。

責任分担

  • L2処理：貢献記録の作成、リアルタイムMeriToken計算、親密度更新
  • L1アンカリング：状態ルート、アイデンティティ登録/変更、ガバナンス投票結果、罰則記録

12.5 データストレージ

オンチェーン（L1）：アイデンティティレジストリ、状態ルート、ガバナンス記録、罰則記録
Rollup（L2）：MeriToken残高とバッチ、親密度、貢献記録
オフチェーン（IPFSなど）：インタラクション詳細、貢献証拠、大容量ファイル

12.6 コンセンサスメカニズム

  • バリデーター参入：一定量のMeriTokenが必要です（評判担保）
  • 検証インセンティブ：検証作業自体が貢献であり、Meritを獲得できます
  • L1コンセンサス：GRANDPA/BABE（Substrateのデフォルト）
  • L2コンセンサス：軽量BFT

12.7 パフォーマンス推定

10億ユーザーが各自1日5件の記録を生成すると仮定：

  • 日次トランザクション量：50億件
  • TPS要件：約58,000
  • 必要なもの：複数の並列Rollupインスタンス（シャーディング）、効率的な証明生成、分散L2ノード

12.8 議論メモ

技術アーキテクチャにおける核心的決定：

  • 汎用パブリックチェーンではなく専用チェーン：GMCの要件は特殊すぎます
  • OptimisticではなくZK Rollup：高速な確認と数学的保証が必要です
  • 階層的ストレージ：セキュリティとスケーラビリティのバランスです
  • パフォーマンスが最大の課題です：全人口参加の規模は前例がありません

これは議論草案段階のアーキテクチャコンセプトです。実際の実装は技術の発展に基づいて調整される必要があります。