ソリューション
鍵のセキュリティと照合を軸に構築するデジタルアセットインフラ
私たちは、デジタルアセットを保管し移転するシステムを設計・構築します。鍵管理、ウォレットサービス、入出金パイプライン、取引コンポーネント、そしてオンチェーンの実態と内部の記録を結びつけるモニタリングが対象です。
課題の全体像
デジタルアセットのプラットフォームには、金融システムとしての正確性の要求に加えて、従来の金融にはない制約があります。パブリックブロックチェーン上のトランザクションは原則として取り消せず、秘密鍵を制御することが資金を制御することを意味します。誤った出金や悪意ある出金を、相手方の銀行が組み戻してくれることはありません。そのためエンジニアリングは鍵のカストディとトランザクションの承認から出発し、それ以外のすべては、これらを守るように配置します。
もう1つの本質的な問題は、ブロックチェーンがプラットフォームの制御下にない外部システムであることです。ノードは同期が遅れたり、互いに食い違ったりします。ブロックは再編成され、確定したように見えたトランザクションが消えることがあります。手数料は急激に変動し、送信したトランザクションが何時間も未確定のまま残ることもあります。ネットワークごとに、アカウントモデル、ファイナリティの挙動、トークンの規約が異なります。プラットフォームは、これらすべてを吸収しながら、ユーザーと経理部門に対して一貫した内部の全体像を提示しなければなりません。
このページはエンジニアリングのみを説明するものです。Staroneは投資助言を行わず、いかなるアセットの価値や見通しについても言及せず、ライセンスの保有や規制当局の承認についても一切主張しません。プラットフォームは、運営事業者が必要とする統制を支えるように設計します。運営事業者にどの規制の枠組みが適用されるかは、運営事業者とその法律顧問が判断する事項です。
なぜ難しいのか
エンジニアリング上の課題
秘密鍵の漏えい
アプリケーションのメモリや設定ストアに置かれた鍵は、そのホストに侵入した者なら誰でも抜き取ることができ、損失は即時かつ恒久的です。広い署名権限を持つ単一鍵のホットウォレットは、大規模な流出の典型的な根本原因です。鍵の情報はハードウェア内に隔離するか複数の当事者に分割し、署名はポリシーによって統制しなければなりません。
チェーンの再編成とファイナリティ
入金をブロックに現れた時点で反映すると、ユーザーが取引や出金を行った後で、再編成によってその入金が取り除かれるリスクにプラットフォームをさらすことになります。ファイナリティはネットワークによって異なり、確率的なものもあれば、明示的なファイナリティのチェックポイントを持つものもあります。確認ポリシーはチェーンごとに設定し、入金はそのしきい値に達するまで内部的に取り消せる状態にしておく必要があります。
滞留する出金、重複する出金
ブロードキャストしたトランザクションは、破棄されたり、手数料不足になったり、置き換えられたりすることがあります。不用意に再送信すれば資金を二重に送ってしまい、アカウントベースのチェーンでnonceの管理を誤れば、同じアドレスからの後続トランザクションがすべて止まります。出金パイプラインには、明示的なnonce管理、手数料引き上げのルール、そして1件のリクエストが1件のオンチェーン送金に対応するという保証が必要です。
オンチェーンと内部台帳の乖離
内部台帳は各顧客が何を保有しているかを示し、チェーンはプラットフォームのアドレスが何を保持しているかを示します。入金の検知漏れ、未記録の手数料、スイープの失敗によって、両者は乖離します。継続的な照合がなければ、不足が生じていても、誰かが気づくまで数週間そのままになりえます。
ノードとプロバイダーの信頼性
単一のノードや単一のRPCプロバイダーは、単一障害点であると同時に、誤っているかもしれない唯一の情報源でもあります。同期の遅れたノードは古い残高を返し、不具合のあるノードは正規のチェーンに存在しないトランザクションを報告することがあります。重要な読み取りには、複数の独立したソースと、不一致を検知する手段が必要です。
高負荷下でのマッチングエンジンの正確性
取引所は、注文を厳密かつ再現可能な順序で適用しなければなりません。並行処理のバグは、誤った価格での約定やマイナスになる残高を生みます。クラッシュ後のリカバリーでは、まったく同じオーダーブックを復元できなければなりません。決定性を犠牲にしてスループットを得ることはできません。
構築の進め方
アーキテクチャ
プラットフォームは、鍵のカストディと署名を他のすべてのサービスから分離し、顧客の保有を示す記録として内部の複式簿記の台帳を持ち、各ブロックチェーンを冗長化したノードを通じて観測する外部システムとして扱います。
- 01
鍵管理・署名サービス
秘密鍵は、HSM（ハードウェアセキュリティモジュール）内で生成・保持するか、MPC（マルチパーティ計算）によって分割します。これにより、単一のマシンや人物が完全な鍵を保持することはありません。署名サービスは、構造化され検証済みのリクエストのみを受け付け、最小限の内部呼び出し元からしか到達できません。オペレーターによるアクセスには複数の承認者が必要で、その内容は記録されます。
- 02
ウォレットの階層とポリシーエンジン
資金はホット、ウォーム、コールドの各階層に分け、当面の出金に必要な額だけをオンラインに置きます。ポリシーエンジンは、すべての署名リクエストを、金額の上限、一定期間内の回数・金額の上限（ベロシティ制限）、送金先の許可リスト、タイムロック、必要な承認数といったルールに照らして評価します。ポリシーはバージョン管理された設定であり、ポリシーの変更にはそれ自体の承認プロセスを経る必要があります。
- 03
入金検知パイプライン
チェーンインデクサーが、対応する各ネットワークを複数のノードを通じて追跡し、プラットフォームのアドレス宛ての送金を抽出して、確認数を追跡します。入金は、チェーンごとの確認ポリシーに従って保留中と確認済みの状態を遷移し、そのポリシーを満たした時点で初めて内部台帳に反映されます。再編成が起きた場合、インデクサーは分岐点までロールバックして再処理します。
- 04
出金パイプライン
出金リクエストはリスクチェックを通過した後、台帳上で引当され、キューに入ります。トランザクションビルダーが、nonceの割り当てまたはインプットの選択、手数料の見積もりを行い、ネットワークが対応していれば送金をバッチ化します。署名とブロードキャストの後、パイプラインはトランザクションをファイナリティまで追跡し、滞留した場合は置き換えルールを適用し、結果に応じて台帳上の引当を確定または解放します。
- 05
内部台帳と取引所コア
顧客残高は、オンチェーンのアドレスから独立した、追記専用の複式簿記の台帳で管理します。そのため、内部振替と約定はブロックチェーンに触れることなく決済されます。取引機能が対象範囲に含まれる場合は、シングルスレッドで決定論的に動作するマッチングエンジンが、順序付けされた注文ストリームをメモリ上で処理します。すべての入力はジャーナルに記録するため、リプレイによってオーダーブックを再構築できます。マーケットデータと決済結果はイベントとして発行します。
- 06
オンチェーンモニタリングとトランザクションリスク
モニタリングサービスは、プラットフォームのアドレス、コントラクトのイベント、未確定のトランザクションを監視し、想定外の動きがあればリアルタイムでアラートを上げます。入出金は、ブロックチェーン分析プロバイダーを通じて、制裁対象アドレスや高リスクアドレスとの関わりをスクリーニングし、判断のつかない結果はレビューに回します。異常を検知した場合は、自動統制によって特定のアセットまたはプラットフォーム全体の出金を一時停止できます。
- 07
トレジャリーと照合
スケジュールされたジョブが、アセットごとに台帳上の負債と全階層のオンチェーン保有高を比較し、差異があれば報告します。トレジャリー管理ツールは、入金アドレスからのスイープ、承認に基づく階層間のリバランス、そしてガス不足で出金が止まらないようにするための手数料用アセットの管理を扱います。トレジャリーによる資金移動はすべて台帳に記帳し、照合の対象に含めます。
アプリケーション・API
- クライアントアプリ
- APIゲートウェイ
- パートナーAPI
- 運用コンソール
ウォレット・トランザクション
- アドレス管理
- トランザクション構築
- ナンス・手数料制御
- ポリシーエンジン
鍵管理
鍵は署名境界の外に出ない
- HSM
- MPC署名
- 承認クォーラム
- 鍵ローテーション
ノード / RPC層
- フルノード
- RPCプロバイダー
- フェイルオーバー経路制御
- メモリプールアクセス
インデックス・分析
チェーンデータはファイナリティに達するまで暫定扱い
- ブロック取り込み
- イベントデコード
- リオーグ（再編成）処理
- クエリAPI
監視・コンプライアンス
- トランザクション監視
- アドレススクリーニング
- 監査証跡
- アラート
プロジェクトの成果物
- カストディのアーキテクチャと鍵セレモニーの手順
- ポリシーエンジンと承認ワークフローを備えた署名サービス
- 合意したネットワーク向けの入金・出金パイプライン
- 内部台帳と、対象範囲に含まれる場合のマッチングエンジン
- オンチェーンモニタリング、スクリーニング連携、アラート
- 照合とトレジャリー業務のツール
- 脅威モデルと、出金停止手順を含むインシデントランブック
着手する前に
早い段階で決めておくべきこと
- カストディはHSMか、MPCか、マルチシグか
- HSMは広く理解されており、強固な物理的統制のもとでの集中型の署名に適しています。MPCは単一の完全な鍵をなくし、オンチェーン側の変更なしに複数のチェーンで機能しますが、プロトコルと運用はより複雑になります。オンチェーンのマルチシグは透明性が高く監査も容易ですが、チェーン固有であり、外部の観測者から見えます。多くの設計では、階層ごとにこれらを組み合わせます。
- ノードを自前で運用するか、プロバイダーを使うか
- ノードプロバイダーは運用負荷を取り除いてくれるため、初期段階ではほとんどのネットワークで妥当な選択です。取り扱う金額や処理量が最も大きいネットワーク、あるいはトレースやアーカイブデータが必要なネットワークについては、自前のノードを運用します。重要な読み取りには、少なくとも2つの独立したソースを使い、その結果を比較します。
- カストディを自社構築するか、カストディアンと連携するか
- 実績のあるカストディプロバイダーと連携すれば、デリバリー期間が短くなり、運用リスクの一部を移転できます。その代わり、手数料が発生し、先方のロードマップと対応アセットに依存することになります。自社構築は、規模が大きくなったときにポリシーとコストを自ら制御できる一方、確立に時間のかかるセキュリティエンジニアリングと運用の成熟度が求められます。この判断は、運営事業者の所在する法域における規制上の期待に沿って決まることが多くあります。
- 入金反映までに何回の確認を待つか
- ネットワークごとに、そのファイナリティモデルとリスクにさらされる金額から設定します。決定論的なファイナリティを持つチェーンでは、ファイナライズされた時点で反映できます。確率的なチェーンでは、対象金額に対して再編成が経済的に成り立たなくなる深さが必要です。高額な入金ほど長く待つのは合理的です。このポリシーは、ネットワークが不安定な際にすぐ引き締められるよう、設定値として持つべきです。
FAQ
よくあるご質問
Staroneはカストディサービスの提供や取引所の運営を行っていますか。
いいえ。Staroneは技術を設計・構築する立場です。カストディと取引所の業務は、お客様が、自らに適用されるライセンスと承認のもとで行います。当社は、当社自身についても、当社が設計するシステムについても、規制上の地位に関する主張を一切行いません。
どのブロックチェーンに対応できますか。
アーキテクチャは、アドレス生成、トランザクションの構築、手数料の見積もり、確認数の追跡を担うチェーンアダプターの背後に、各ネットワークを隔離します。アカウントベースのチェーンとUTXOベースのチェーンは、どちらもこのモデルに収まります。ネットワークが1つ増えるごとに連携、テスト、運用の作業が加わるため、対象とするネットワークは案件ごとに合意します。
内部不正の脅威からシステムをどのように守りますか。
いかなる個人も単独では資金を動かせないようにします。署名には複数の当事者によるポリシー上の承認が必要です。鍵シェアやHSMの認証情報は役割ごとに分離し、管理操作は改ざんできない形でログに記録し、ポリシーの変更にはそれ自体の定足数（クォーラム）を必要とします。モニタリングは、承認グループの外にいる人にアラートが届くように設計します。
スマートコントラクトの開発と監査は行いますか。
設計上必要な場合は、実績のあるライブラリ、プロパティベーステスト、静的解析を用いてスマートコントラクトを開発・テストします。価値を保持するコントラクトについては、デプロイ前に独立した外部監査を受けることを推奨します。監査はリスクを低減しますが、なくすものではありません。