ステーブルコイン決済ゲートウェイのアーキテクチャ

Q: ゲートウェイは独立したサービスでなければなりませんか、それともメインアプリケーションに組み込まれているのでしょうか。

独立したゲートウェイサービスは、生産のために強く好まれる。 チェーン監視と署名の論理を主なアプリケーションから隔離し、独立して展開し、スケールすることができ、明確なセキュリティの境界があります。 ゲートウェイは支払いイベントを公開し、メインアプリケーションはそれらを消費します。

Q: RPC ノードがダウンしたらどうなるの?

モニタリング層は、余分な RPC プロバイダーで実行する必要があります。 すべてが失敗した場合、ゲートウェイは劣化状態に入ります - 新しい支払い確認が遅れていますが、失われません。 接続が復元されたとき、最後の確認されたブロックから再生して、見逃した転送イベントをキャッチします。 モニタリングと確認エンジン間のイベント列は、短い中断中にイベントが落とされないことを保証します。

Q: このアーキテクチャはどのようにして高容量にスケールするのですか?

チェーン監視ワーカーの水平スケーリング (チェーンまたはチェーン シャードごとに 1 つのワーカー)。イベントキューはバースト量を吸収します。確認エンジンは、台帳への書き込みが冪等である限り、水平方向にスケーリングします。アクティブなアドレスに対する適切なデータベースインデックスを使用したアドレス導出と検索スケール。通常、ボトルネックは RPC のレート制限です。大規模な専用の RPC エンドポイントを計画します。

アーキテクチャの概要:

ステーブルコイン決済ゲートウェイには 5 つのコア層があります: (1) 支払いごとに入金アドレスを作成および管理する支払い意図層、(2) 着信送金をブロックチェーンで監視するチェーン監視層、(3) 受領書を検証してイベントをトリガーする確認エンジン、(4) すべての支払い状態を記録する台帳、および (5) オフランプおよび財務管理を処理する決済層。

このガイドは、生産ステーブルコインゲートウェイの背後にあるシステム設計に焦点を当てています - 何の部品が存在するかだけでなく、それらがどのように接続するか、どこで故障が起こるか、そして規模の信頼性のためにどのような設計決定が重要です。

支払い意図層

支払い意図は、支払者が支払いを開始したときに作成されます。それは、予想される金額、ステーブルコインおよびチェーン、割り当てられた預金アドレス、到着時間、および下流の注文または請求書の参照を格納します。

入金アドレスの導出

デポジットアドレスは、BIP-44 を使用して HD ウォレットから取得されます。マスターシードはシークレットマネージャー (AWS Secrets Manager、Vault) に保存されます。各支払い意図には、一意の導出パスインデックスが割り当てられます。ゲートウェイは、派生インデックス、期待額、ステーブルコイン、チェーン、有効期限、支払いステータスを保存します。

EVM チェーンでは、すべての EVM 互換性のあるチェーンで同じ由来のアドレスが動作します。単一の HD ウォレットは Base、Ethereum、Polygon、および Arbitrum をそれぞれ別々のアドレスインデックスでサービスすることができます。

アドレスの有効期限と再利用

預金アドレスは、支払い目的で再利用してはならない。支払いが完了または成功した後、アドレスはモニタリング層で無効になります。遅れた支払いが到着したアドレスに到着した場合、ゲートウェイは手動でレビューするためにそれを比較されていないとして記録します。

チェーン監視層

チェーンモニタリング層は、ERC-20(または同等の)転送イベントのブロックチェーンをアクティブな預金アドレスに監視します。設計は、イベントの高量(忙しいチェーンで)、リアルタイムの検出、チェーン再編、複数のチェーン間のモニタリングを同時に処理する必要があります。

EVM チェーン監視

Subscribe to ERC-20 Transfer events from the stablecoin contract address using WebSocket RPC (Alchemy, QuickNode). Filter by the to address matching any active deposit address. Use a bloom filter or database index on active addresses for O(1) lookup.

Fallback: poll for recent Transfer events every N seconds using eth_getLogs. WebSocket subscriptions are preferred but can drop connections — the polling fallback ensures no missed events.

トロン TRC-20 モニタリング

TronGrid APIは、アドレスのトランザクション履歴を提供します。 TronGrid REST API を使用する各アクティブな預金アドレスの TRC-20 transfer 履歴を調査します。 WebSocket サブスクリプションは Tron では信頼性が低い - 投票は標準的なアプローチです。

Solana SPL トークンの監視

Solana uses Associated Token Accounts (ATAs) — each wallet address has a corresponding ATA for each SPL token. Monitor the USDC ATA corresponding to each deposit address using WebSocket account subscriptions or polling getSignaturesForAddress.

確認エンジン

確認エンジンは検出された転送を検証し、支払いイベントを発行します。主要な責任:

ブロックの深さのチェック: 確認されたイベントを発行する前に、取引が必要な確認深度に達するまで待つ。

金額の検証: 予想された金額に比べてみました。未払い(手動レビューまたは製品の許容性に基づく拒否)および過剰支払い(クレジットの全額、旗の過剰)を処理します。

チェーン再編成の処理: 以前検出された取引がチェーン再編で削除された場合、pay_detected イベントを戻し、待機状態を再入力します。チェーンの再処理リスクに適した短い確認深さを使用します。

べき等性: 確認されたすべてのトランザクションハッシュが保存されます。同じ確認イベントの再生はノーオプです。

台帳の設計

支払い帳簿は、すべてのステーブルコイン支払い活動の権威的な記録です。添付のみ(更新なし、挿入のみ)およびイベントソースでなければなりません - すべての状態移行(作成、検出、確認、有効期限、スワッピング)は、レジェンドエントリです。

イベント	トリガー	Downstream アクション
クレジット.Created	支払い意図作成	支払者への返金アドレス
発見・発見	トランスファー見たオンチェーン, pending	Notify payer; show pending status (支払い者に通知する)
支払い確認	Required Confirmations 取得	オーダー/サブスクリプションを有効にする:Trigger Webhook
支払い終了	期限切れ、支払いなし	リリース・デポジット・アドレス; notify payer
未払い未払い	予想より少ない金額	Flag for review; product-specific handling(レビューのための旗)
トップページ > スワップ	資金が財務省ウォレットに流入	Update sweep record; reduce address balance. アドレスバランスを減らす

スイープおよび財務管理

実稼働環境では、トレジャリーウォレットはマルチ署名 (Safe/Gnosis Safe など) である必要があります。重要なトレジャリーオペレーションには複数の署名者が必要です。

ガス資金調達: 各デポジットアドレスにはネイティブ・トークン(ETH, TRX、等)が必要で、スウェイプ・トランザクション・ガス料金をカバーします。ゲートウェイは、スワイプする前に預金アドレスを上回るガス資金提供者サービスを維持しています。

スイープトリガー: バランスの値段、スケジュール、または手動で引き起こされます。バッテリースワイプは、ガス全体のコストを削減します。

スイープ確認: Sweep 取引は確認まで監視されます。成功すると、Sweep Ledger イベントが記録されます。

オフランプ統合アーキテクチャ

オフランプは、財務ウォレットに保持されているステーブルコインを法定通貨に変換します。統合パターン:

オフランププロバイダーアカウント: Off-ramp プロバイダー(Bridge、Coinbase Prime、その他)はステーブルコインターゲットアドレスを提供します。このアドレスに USDC を送信すると、設定された銀行口座に Fiat 決済が発生します。

転送命令: ゲートウェイは、トレジャリーウォレットからオフランプアドレスへの転送を構築し、署名します。これには、トレジャリーウォレットの署名キーへのアクセスが必要です。通常はマルチ署名の承認が必要です。

決済確認: Off-ramp プロバイダーは、webhooks を送信するか、APIs を提供して、フィアット決済を確認します。ゲートウェイは、オフランプの転送に対してフィアット決済のイベントを記録します。

生産上の考慮事項

生産の信頼性に関して重要な建築決定:

冗長 RPC ノード接続を実行します (Alchemy プライマリ + QuickNode フォールバック) — 単一の RPC 障害が支払い漏れを引き起こすことはありません
チェーンモニタリングと確認エンジン間のイベント列(Kafka、SQS、またはRedis Streams) - 摂取を処理から切り離し、再生を可能にする
レジジャー書類の周りのデータベーストランザクション - 確認イベントとダウンストリームアクションは、両方ともコミットするか、両方ともリボールする必要があります。
失敗したWebhook配信のためのデッド・メール・クエイ - RETRY with exponential backoff, alert on repeated failures
監視および警告:チェーンモニタリングの遅延、比較されていない支払い、スワープの失敗、オフランプ決済の遅延
署名キー管理をゲートウェイアプリケーションロジックから分離 - 財務業務にはマルチ署名の承認が必要です

よくある質問

ゲートウェイは独立したサービスでなければなりませんか、それともメインアプリケーションに組み込まれているのでしょうか。

独立したゲートウェイサービスは、生産のために強く好まれる。チェーン監視と署名の論理を主なアプリケーションから隔離し、独立して展開し、スケールすることができ、明確なセキュリティの境界があります。ゲートウェイは支払いイベントを公開し、メインアプリケーションはそれらを消費します。

間違った金額または間違ったステーブルコインを送信するユーザーをどのように処理しますか?

間違ったステーブルコイン転送(例えば、 DAI 代わりに USDC) に預金アドレスは、不一致として記録され、手動のレビューのために列に並ぶ。未払いは標識付けられています - 製品は、部分的な支払いを受け入れるか、拒否するか、または支払者にアップするように促すかを定義します。過剰支払いは、過剰返還されたオンチェーンで完全に請求できます。

RPC ノードがダウンしたらどうなるの?

モニタリング層は、余分な RPC プロバイダーで実行する必要があります。すべてが失敗した場合、ゲートウェイは劣化状態に入ります - 新しい支払い確認が遅れていますが、失われません。接続が復元されたとき、最後の確認されたブロックから再生して、見逃した転送イベントをキャッチします。モニタリングと確認エンジン間のイベント列は、短い中断中にイベントが落とされないことを保証します。

このアーキテクチャはどのようにして高容量にスケールするのですか?

チェーン監視ワーカーの水平スケーリング (チェーンまたはチェーンシャードごとに 1 つのワーカー)。イベントキューはバースト量を吸収します。確認エンジンは、台帳への書き込みが冪等である限り、水平方向にスケーリングします。アクティブなアドレスに対する適切なデータベースインデックスを使用したアドレス導出と検索スケール。通常、ボトルネックは RPC のレート制限です。大規模な専用の RPC エンドポイントを計画します。

アーキテクチャの概要

5 つの層: 支払い意図 (アドレス管理)、チェーン監視、確認エンジン、台帳、決済 (スイープ + オフランプ)。

HD ウォレットバリエーションは、アドレスごとにプライベートキーを保存することなく、ユニークで決定的な預金アドレスを提供します。

モニタリングと確認エンジンの間のイベント列は、信頼性と再生性にとって重要です。

Ledger は、Append-only と Event-Source でなければなりません - すべての状態の移行は、更新ではなく、レコードです。

財務省のマルチ署名とオフランプの統合は運用上重要なコンポーネントであり、適切な署名制御を使用して設計されています。