リファレンスアーキテクチャ
参考例デジタルアセットインフラ
デジタルアセットプロダクトを支えるオフチェーンインフラです。ブロックチェーンノード、ウォレットサービス、安全な鍵管理、インデックス、トランザクションモニタリング、APIゲートウェイで構成します。
課題
ユーザーに代わって、または自社のトレジャリーとして、1つ以上のパブリックブロックチェーン上でデジタルアセットを保有、送付、受領する必要のある事業を想定します。この事業は、入金アドレスを生成し、着金を検知し、出金トランザクションに署名し、自社のアプリケーションを通じて正確な残高と履歴を提示しなければなりません。
ブロックチェーンは特殊な依存先です。トランザクションは取り消せず、ファイナリティに達するまで承認は確率的であり、ブロックは再編成されることがあり、手数料は変動し、漏えいした秘密鍵は事後にローテーションしても被害を防げません。チェーンそのものが提供しない安全性、監査可能性、運用上の統制は、チェーンを取り巻く基盤が担う必要があります。
設計が満たすべき要件
- 秘密鍵は、アプリケーションのメモリ、ログ、バックアップ、運用担当者の端末のいずれにおいても、平文で存在してはなりません。
- すべての出金トランザクションはポリシーチェックを通過し、高額の送付には複数人による承認が必要でなければなりません。
- 残高はファイナリティに達したチェーンデータから導出され、チェーンの再編成後には自動的に修正されなければなりません。
- 単一のノードまたはRPCプロバイダーを失っても、入金の検知や出金のブロードキャストが止まってはなりません。
- トランザクションはスクリーニングおよびモニタリングの対象とし、誰が依頼し、承認し、署名したのかを示す完全な監査証跡を残さなければなりません。
- 別のEVM互換チェーンへの対応は、書き直しではなく、設定とテストの作業で済まなければなりません。
設計
コンポーネント
アプリケーション・API
- クライアントアプリ
- APIゲートウェイ
- パートナーAPI
- 運用コンソール
ウォレット・トランザクション
- アドレス管理
- トランザクション構築
- ナンス・手数料制御
- ポリシーエンジン
鍵管理
鍵は署名境界の外に出ない
- HSM
- MPC署名
- 承認クォーラム
- 鍵ローテーション
ノード / RPC層
- フルノード
- RPCプロバイダー
- フェイルオーバー経路制御
- メモリプールアクセス
インデックス・分析
チェーンデータはファイナリティに達するまで暫定扱い
- ブロック取り込み
- イベントデコード
- リオーグ（再編成）処理
- クエリAPI
監視・コンプライアンス
- トランザクション監視
- アドレススクリーニング
- 監査証跡
- アラート
APIゲートウェイ
認証された単一のエントリーポイントが、社内アプリケーションとパートナー連携にサービスを提供します。価値の移動を伴うすべての操作に対して、レート制限、リクエスト署名、冪等性キーを強制します。出金エンドポイントは読み取りエンドポイントから分離されているため、より厳格な統制と独自のクォータを適用できます。
ウォレットサービス
ウォレットサービスは、階層的決定性（HD）鍵から入金アドレスを導出し、それらを口座に対応づけ、プラットフォームが管理するアドレスを追跡します。日常の出金を処理するホットウォレットと、準備資産を保有するウォームおよびコールドの階層を分離します。階層間のスイープとリバランスは、ポリシーによって統制される明示的な操作です。
トランザクションサービスとポリシーエンジン
このサービスは、トランザクションを構築し、ナンスを管理し、手数料を見積もり、トランザクションが滞留した場合の置き換えを処理します。署名に先立って、ポリシーエンジンが限度額、頻度ルール、送付先の許可リスト、承認要件を評価します。サービスは、各トランザクションの送信、ブロックへの取り込み、ファイナリティまでを明示的なステートマシンとして追跡します。
安全な鍵管理
署名は、ハードウェアセキュリティモジュール（HSM）の内部、またはマルチパーティ計算（MPC）によって行われます。MPCでは鍵シェアを別々の当事者が保持し、完全な鍵が組み立てられることはありません。署名境界は、有効なポリシー判定と必要な承認を伴うリクエストのみを受け付けます。鍵セレモニー、バックアップ、リカバリーは文書化された手順であり、演習を行います。
ブロックチェーンノードとRPC層
プラットフォームは、自社運用のフルノードと外部RPCプロバイダーからなるプールを通じて、チェーンからの読み取りとチェーンへのブロードキャストを行います。ルーティング層はノードの健全性とブロック高を確認し、自動的にフェイルオーバーし、重要な読み取りについては複数のソース間でレスポンスを比較します。複数の経路でブロードキャストすることで、トランザクションが気づかれないまま破棄される可能性を下げます。
インデクサー
インデクサーはブロックを取り込み、送付とコントラクトイベントをデコードし、ブロック番号とハッシュをキーとするリレーショナルストアに書き込みます。データは、ブロックが設定されたファイナリティ深度に達するまで暫定として扱われ、再編成は影響を受けたブロックをロールバックして再生することで処理します。アプリケーションは、残高と履歴をライブのRPC呼び出しからではなく、このストアから読み取ります。
トランザクションモニタリングとスクリーニング
入金と出金は、アドレスのリスクデータに照らしてスクリーニングされ、ストラクチャリングや異常な頻度といった行動ルールに照らして確認されます。アラートはレビュー用のケースを起票し、フラグの付いた出金は事後に調査するのではなく、署名前に保留されます。このコンポーネントは組織のコンプライアンス義務を支援するよう設計されたものであり、その義務に代わるものではありません。
オブザーバビリティと監査
ダッシュボードでは、ノードの遅延、インデクサーの遅延、保留中トランザクションの経過時間、手数料支出、ホットウォレット残高を、しきい値と対比して追跡します。すべてのリクエスト、ポリシー判定、承認、署名は、追記専用の監査ログに書き込まれます。定期ジョブが内部台帳とオンチェーン残高を照合し、差異があれば報告します。
トレードオフ
設計判断
| 判断 | 理由 |
|---|---|
| アプリケーションが鍵を保持するのではなく、MPCまたはHSMで署名 | 鍵をアプリケーションの設定に置く方法は単純で高速ですが、サーバーが1台でも侵害されれば全損につながります。ハードウェアまたはマルチパーティによる署名は、レイテンシ、コスト、運用上の手続きを増やしますが、鍵を盗まれうる単一の箇所をなくすための対価として妥当です。 |
| ホット残高を小さく抑えた階層型ウォレット構成 | すべての資金をホットウォレットに置けば出金は即時になりますが、リスクにさらされる額も最大になります。運転に必要な流動性だけをホットに置くことで、攻撃者やソフトウェアの不具合が到達できる範囲を限定できます。その代償として、リバランスの運用が必要になり、ホット階層の残高が不足した際には出金が遅れることがあります。 |
| 自社運用ノードと外部RPCプロバイダーの併用 | 1つのプロバイダーに頼る方法は安価ですが、レート制限、遅延、停止の起こりうる依存関係を生みます。一方、ノードの運用は現実に大きな運用負荷です。そのため、設計では両方を使います。自社ノードは独立性と検証のため、プロバイダーはバースト時のキャパシティと地理的な到達範囲のためです。 |
| チェーンへのオンデマンド照会ではなく、専用のインデクサー | ライブのRPCクエリでは、ある口座の全履歴といった問いに効率よく答えられず、ファイナリティに達していないデータをユーザーに見せてしまいます。インデクサーは構築し同期を保つべきシステムがもう1つ増えることを意味しますが、残高を高速で一貫性があり、再編成後も正確なものにするのはこの仕組みです。 |
| 設定したファイナリティ深度に達してから入金を反映 | 最初の承認で残高に反映すれば速く感じられますが、後に再編成で消える送付を反映してしまうリスクがあります。ファイナリティを待つと、利用可能になるまでにチェーンごとに異なる時間がかかるため、その間はユーザーに保留中の状態として伝えます。 |
意図する成果
- アプリケーションコードにも運用担当者にも露出しない秘密鍵
- ポリシーと承認の統制を迂回できない出金
- 再編成の後も含め、チェーンと整合し続ける残高
- 各トランザクションを誰が依頼し、承認し、署名したのかを示す完全な記録
この設計が達成を目指すものです。参考例であり、クライアント案件の実測結果ではありません。
代表的な技術
- Go
- TypeScript
- Node.js
- PostgreSQL
- Kafka
- Redis
- Ethereum / EVM
- HSM / MPC signing
- Kubernetes
- Terraform
- OpenTelemetry