ペイメントライフサイクル
Deposit・Transfer・Withdrawal の全体フロー
INTMAX のロールアップ（Rollup）アーキテクチャは、状態遷移に対して完全に分散化されたクライアント主体のアプローチを採用しています。Deposit・Transfer・Withdrawal のすべての操作は、暗号コミットメント（Commitment）とゼロ知識証明を介して行われ、オンチェーンの計算や状態への依存を最小限に抑えています。
Deposit：L1 → L2 エントリー
Deposit は、オンチェーンデータに金額と受取人の身元が平文で含まれる唯一の操作です。これは L2（Layer 2）上でユーザー残高を初期化するために必要です。
仕組み
ユーザーはロールアップコントラクトの
deposit()メソッドを以下のパラメータで呼び出します：トークン量（
ETHまたは ERC-20）ターゲット L2 アドレス（BLS 公開鍵（Public Key））
コントラクトはこのアクションを Deposit ブロックとして内部ログに追記します
このエントリーが、後続のすべての L2 残高計算の起点となります
ポイント：グローバルな状態マッピングは更新されません。コントラクトはイベントをログに記録するのみで、残高追跡は完全にクライアント層にオフロードされます。
Transfer：L2 → L2 プライベート送金
Transfer は L2 上のユーザー間で価値を移動する主要な手段です。プロトコルは厳密な責務分離を強制します：アグリゲーターは調整を行い、計算と検証はユーザーのみが実行します。
Phase 1：Merkle コミットメント
ハッシュ送信 — 各ユーザーがトランザクションバッチのソルト付きハッシュを計算し、そのハッシュのみを選択したアグリゲーターに送信
Merkle Tree 構築 — アグリゲーターが受信したすべてのハッシュで Merkle Tree を構築し、各ユーザーに Merkle Inclusion Proof を送信
署名（Signature） — 各ユーザーが BLS 鍵で Merkle root に署名し、バッチの包含を承認
集約 — アグリゲーターがすべての署名を収集し、BLS 集約署名（Aggregate Signature）を計算
Phase 2：コントラクトとのインタラクション
アグリゲーターは以下を含む Transfer ブロックを INTMAX コントラクトに送信します：
Merkle root（トランザクションハッシュバッチへのコミットメント）
BLS 集約署名
署名者の公開鍵リスト
コントラクトは集約署名を検証し、ブロックをロールアップの履歴に追記します。
Phase 3：ピアツーピア（P2P）のプルーフ伝播
各送信者が以下を送信：
Merkle Inclusion Proof
元のトランザクションバッチ
残高証明（Balance Proof）（過去の受領データと ZK proof から構築）
各受取人が ZK proof を検証し、自身のクライアントサイド状態を更新
注目すべき点として、コントラクトは誰が誰に何を送ったかも金額も把握しません。このデータはオンチェーンに一切公開されません。
Withdrawal：L2 → L1 エグジット
Withdrawal は、ユーザーが L2 の残高を Ethereum 上で実体化する際に実行されます。
仕組み
ユーザーが以下を証明する ZK proof を計算：
特定の履歴ルート
rにおいて自身の公開鍵が少なくとも
vの価値を受け取ったこと
以下を提出：
履歴ルート
r主張する金額
v有効な受領の ZK proof
コントラクトが以下を実行：
rが状態履歴内の有効なブロックルートであることを検証プルーフを検証
過去の Withdrawal を差し引き
残りの請求可能残高を L1（Layer 1）アドレスに送金
ロールアップコントラクトは、部分的な知識の前提下でも二重支出（Double-spending）を防止するために、累積 Withdrawal マップを管理します。
データフローのまとめ
Deposit
ユーザー → コントラクト
（受取人 L2 鍵、金額）
✅
Transfer
ユーザー ↔ アグリゲーター
トランザクションハッシュのみ
❌（完全にプライベート）
Transfer
アグリゲーター → コントラクト
Merkle root + 署名
✅
Transfer
送信者 → 受取人
ZK proof + Merkle path
❌（オフチェーンのみ）
Withdrawal
ユーザー → コントラクト
残高の ZK proof
✅（検証可能なプルーフ）
最終更新