香港のステーブルコイン発行者向けスマートコントラクト実施ガイド

第1部 インフラとコンプライアンス戦略

1. ベースとなる分散型台帳の選択

実施ガイド

• 成熟したパブリックチェーンを優先選択：イーサリアムやアービトラムなどの成熟した高い安全性を持つパブリックブロックチェーンを優先して選ぶことをお勧めします。このようなネットワークは、長年の実績に裏打ちされた弾力性、膨大な検証ノードネットワーク、および継続的な公衆監視によって、自然な優位性を持っています。その高額な攻撃コストは、51%攻撃への抵抗力と取引の最終性を保証するという規制当局の懸念に直接応えることができます。

• 代替案の厳格な評価：もしコンソーシアムチェーンまたは他の種類の分散型台帳の採用を検討する場合、主流のパブリックチェーンと同等、またはそれ以上の安全基準を証明するために、厳密かつ定量的な比較分析を実施する必要があります。

• リスク評価文書：評価報告は、一般的な攻撃に対する耐性、コンセンサスアルゴリズムの種類、およびコードの欠陥、脆弱性、エクスプロイト、その他の脅威に関連するリスクを包括的にカバーし、これらのリスクがステーブルコインの発行、償還、及び日常運営にどのように潜在的な影響を与えるかを詳細に分析する必要があります。この文書は、規制当局に対して技術選定の慎重性を証明するための重要な文書です。

! 技術ガイダンス:香港ステーブルコイン発行者向けスマートコントラクト実装ガイド

2. コアトークン標準と規制機能の拡張

実施ガイド

• 基本標準：ERC-20を基本標準として採用し、トークンの同質性とより広範なエコシステムでの相互運用性を確保します。

• 機能拡張：規制要件を満たすために、以下の機能モジュールを統合する必要があります：

  • 一時停止可能：全ての通貨活動のグローバルな一時停止と復元機能を実装するために使用され、重大なセキュリティ事件に対処するための核心的なツールです。

  • Mintable：ライセンスを持つ発行者が制御されたプロセスを通じて新しい通貨を鋳造し、通貨の発行量が十分な法定通貨の準備資産に厳密に対応することを保証するために使用されます。

  • バーナブル：トークンを焼却する機能を提供します。具体的な実装では、この機能は任意のユーザーが自由に焼却できるのではなく、厳格な権限管理の対象となります。

  • フリーズ可能：特定のアカウントの通貨移転機能を一時停止するために使用(、疑わしい取引が関与する場合)。

  • ホワイトリスト：追加のセキュリティ対策を実施するために、デューデリジェンスと承認されたアドレスのみがコア操作(に参加できるようにします。新しく発行された通貨)を受け取ることができます。

  • ブラックリスト：違法活動(（マネーロンダリング、詐欺)）に関与するアドレスに対して取引禁止令を実施し、トークンの送受信を禁止します。ブラックリストの管理はAML/CFTシステムと連携し、疑わしい取引をリアルタイムで監視する必要があります。

  • AccessControl：これは、細分化された役割ベースの権限管理システムを実現するための基礎です。すべての管理機能は、このモジュールを通じて権限制御を行う必要があり、職務分離の要件を満たします。

3. 主要なコンプライアンスモデル：ブラックリストとホワイトリストの選択

実施ガイド

• ブラックリストモード(デフォルト推奨プラン)：

  • 利点：より高い実用性を持ち、広範な分散型金融(DeFi)エコシステムとシームレスに相互運用でき、ユーザーにとってより低い使用のハードルとよりスムーズな体験を提供します。

  • 欠点：コンプライアンスは強力でリアルタイムなオフチェーン監視分析能力に高度に依存し、不正なアドレスを迅速に発見して封じ込める必要があります。

  • 実現方式：スマートコントラクトの転送関数において、ロジックチェックを追加し、取引の送信者(from)および受信者(to)のアドレスがいずれもブラックリストに記録されていないことを確認する。

• ホワイトリストモード

  • 利点：最高レベルのAML/CFT管理を提供し、事前の予防を実現し、事後の救済ではありません。

  • 欠点：大きくステーブルコインの通貨の汎用性と採用率を制限し、ホワイトリストの管理に大きな運営コストをもたらし、広く受け入れられる取引媒体になることが難しくなる可能性があります。

  • 実現方法：スマートコントラクトの送金関数に、ロジックチェックを追加し、取引の送信者(from)と受信者(to)のアドレスが両方ともホワイトリストに存在する必要があります。操作の便利さを増すために、専用のWebユーザーバックエンドシステムの開発をお勧めします。

第二部分 スマートコントラクト実現

1. 精密なアクセス制御システムを設計する

実施ガイド

明確な役割を定義し、これらの役割を異なる複数署名ウォレットが管理する実体またはスタッフに割り当てる必要があります。これにより、責任の分離が実現され、単一障害点や共謀による操作のリスクが最小限に抑えられます。各役割は特定の機能に限定され、すべての操作は複数署名による承認が必要であり、同じ従業員が複数の高リスク役割を同時に持たないようにします。すべての操作はログに記録され、年次の第三者監査を受け、権限の割り当ては管理者または取締役会によって監視されます。

• MINTER_ROLE：ステーブルコインの発行(mint)操作を処理する責任があり、有効な発行リクエストを受け取った後にトークンユニットを作成し、発行が準備資産プールの対応する増加と一致することを確認します。

• BURNER_ROLE：ステーブルコインの焼却(burn)操作を処理する責任があり、有効な償還リクエストを受け取った後にトークン単位を焼却します。

• PAUSER_ROLE：(の操作を一時的に停止する責任があり、例えば異常なイベント)（セキュリティの脅威(など）が検出された場合に、送金、発行、または償還を一時停止します。

• RESUME_ROLE：)resume(の操作を復元する責任があります。たとえば、停止イベントの解決後に送金、発行、または償還を再有効にします。

• FREEZER_ROLE：特定のウォレットまたは通貨の)freeze(および)remove freeze(操作を凍結および解除する責任があります。たとえば、)のような疑わしい活動(（マネーロンダリングリスク)など）が検出された場合、資産を一時的に凍結します。

• WHITELISTER_ROLE：ホワイトリスト(whitelist)の管理を担当し、許可されたウォレットアドレスの追加または削除を含み、例えば発行をホワイトリストアドレスのみに制限する。

• BLACKLISTER_ROLE：ブラックリスト(blacklist)を管理し、ブラックリスト(remove blacklist)から削除する責任があります。たとえば、疑わしいウォレットをブラックリストに登録して送金を防ぐことができます。

• UPGRADER_ROLE：アップグレード可能なモデルを採用する場合、(upgrade)スマートコントラクトのアップグレードを担当します。例えば、契約コードを更新して脆弱性を修正したり、機能を追加したりします。

2. 発行(通貨)メカニズム

実施ガイド

前置チェック：関数はコインの発行前に、ターゲットアドレスtoがブラックリストに載っているか、凍結された状態にあるかを確認する必要があります。

操作フロー：

• オフチェーンデューデリジェンス：顧客はすべての必須のオフチェーン顧客身元確認(KYC)および顧客デューデリジェンス(CDD)プロセスを完了する必要があります。さらに、AML/CFT規制により、ビジネス関係を確立するか、特定の閾値(（例えば、8,000香港ドル)）を超える偶発的な取引を行う顧客に対して、CDDを実行する必要があります。
• 資金の受領:クライアントは、発行者が指定した銀行口座に同額の不換紙幣資金を送金します。
• 内部検証：発行者の内部システムが資金の受領を確認し、対応して準備資産の会計記録を更新します。
• チェーン上で実行：運営チームがマルチシグ取引を作成し署名し、スマートコントラクトのトークン発行関数を呼び出し、新たに発行されたステーブルコインを顧客が事前に登録し検証されたウォレットアドレスに送信します。

3. リデンプション(廃棄)メカニズム

実施ガイド

償還準備：ユーザーはまず、償還するトークンを発行者が管理する指定アドレスに移動する必要があります。

操作フロー：

• オフチェーンリクエスト：ユーザーは発行者のプラットフォームを通じてオフチェーンの償還リクエストを提出します。リクエストを処理する前に、発行者は顧客に対して適切な顧客デューデリジェンス(CDD)を実施しなければなりません。
• システム検証：発行者のシステム検証リクエストの有効性を確認し、ユーザーがチェーン上で対応する通貨転送操作を完了しているかどうかをチェックします。
• 法定通貨の支払い：発行者は等価の法定通貨をユーザーが事前に登録し検証された銀行口座に送金します。
• チェーン上の焼却：法定通貨の送金が成功したことを確認後、BURNER_ROLEを持つマルチシグウォレットが焼却関数を呼び出し、指定されたアドレスから対応する数量のトークンを焼却します。

4. 緊急制御の実装:一時停止とフリーズ

実施ガイド

機能停止：PAUSER_ROLEを持つマルチシグウォレットのみが呼び出すことができ、契約機能の全体的な停止に使用されます。トリガー条件には、ネットワーク攻撃や準備資産の不一致(などの異常イベント)が検出された場合が含まれ、取締役会または上級管理職の承認が必要です。機能の再開は独立したRESUME_ROLEによって処理され、職務分離を実現します。

凍結機能：FREEZER_ROLEを持つマルチシグウォレットによって呼び出され、特定のアドレスに対する送金制限に使用されます。トリガー条件には疑わしい活動(、AMLアラートや裁判所命令)が含まれ、オフチェーンでの検証後に実行される必要があります。凍結解除は同じ役割で処理されますが、追加の監査検証が必要であり、乱用を防ぐために関連する公告が発表されます。

5. アドレスフィルタリングとブラックリストメカニズム

実施ガイド

• 関数の実装：ブラックリストの追加および削除機能を実装する関数であり、BLACKLISTER_ROLEを持つマルチシグウォレットのみが呼び出すことができます。
• 転送制限：ブラックリストに追加されたアドレスによるトークンの移動/受信は禁止されています。
• 操作フロー：分析ツールがアラームを発し、内部コンプライアンス審査を引き起こし、コンプライアンスチームが審査確認後、BLACKLISTER_ROLEのマルチシグウォレットがブラックリスト追加取引を開始します。

6. スマートコントラクトの可アップグレード性

実施ガイド

• プロキシモデル：EVMタイプのスマートコントラクトに対しては、成熟したERC-1967プロキシモデルを使用してアップグレード可能性を実現できます。
• 権限管理：アップグレード関数は、UPGRADER_ROLEを持つマルチシグウォレットのみが呼び出すことができなければなりません。
• 変更管理プロセス：規制要件に基づき、アップグレードを提案する前に厳格な変更管理プロセスを完了する必要があり、これには新しいロジック契約に対する包括的で独立した第三者のセキュリティ監査が含まれます。

7. 分析と報告に使用されるオンチェーンイベントログ

実施ガイド

ERC-20標準の要求である送金(Transfer)、承認(Approval)イベントに加えて、契約はすべての管理行為と状態変化のためにカスタムイベントを定義し発行しなければならない。

• トークンの鋳造/バーン(Minted/Burned)イベント
• 先物の一時停止/再開(Paused/Resume)イベント
• ブラックリストに追加/削除(ブラックリスト追加/ブラックリスト削除)イベント
• ホワイトリストからの(WhitelistAdded/WhitelistRemoved)イベントの追加/削除
• (AddressFrozen/AddressUnfrozen)イベントのフリーズ/フリーズ解除に対応
• 特権ロールの変更(RoleGranted/RoleRevoked)イベント
• コントラクトアップグレード(アップグレード)イベント

第三部分 運営の安全性とライフサイクル管理

1. セキュリティキー管理アーキテクチャ

実施ガイド

• キー生成：詳細な文書記録がある「キーセレモニー」(key ceremony)を、物理的に安全で外部ネットワークから完全に隔離されたギャップ環境で実施する必要があります。
• キー管理：すべての管理ロールはマルチシグウォレットによって制御されなければなりません。これらのマルチシグウォレットの署名者が使用する秘密鍵は、HSMまたはその他の安全なハードウェアウォレットに保存する必要があります。最も重要な役割に対する秘密鍵は、オフラインシステムに保存し、オンライン環境と物理的に隔離する必要があります。
• キーの使用：マルチシグネチャポリシーを強制する必要があります。「重要なプライベートキー」を含む取引の署名には、関連する人々が直接現場で操作する必要がある場合があります。
• バックアップと復元：キーシェアまたはニーモニックフレーズのバックアップは、香港国内(または規制当局に承認された場所)の複数の安全で地理的に分散した場所に保存し、改ざん防止のパッケージを使用する必要があります。

2. 完全なデプロイメントプロセスとランタイムモニタリング

実施ガイド

正式な展開の前に、「展開前チェックリスト」を策定し、厳格に実施する必要があります。

• 全面的なテスト：ユニットテストカバレッジ95%以上、コアコードカバレッジ100%を確保し、ユニットテストのカバレッジレポートを出力することを確認します。
• 独立監査：少なくとも1社、できれば2社の信頼できる監査会社による独立したセキュリティ監査報告書を完成させること。
• コード凍結：監査完了後、コードを凍結し、リリースまで変更を行わない。
• 回帰テスト：正式にデプロイする前に、単体テストを実行し、回帰テストを行います。
• コンプライアンス承認：内部コンプライアンスチームから正式な承認を取得し、契約のロジックがすべての関連する規制要件を満たしていることを確認します。
• デプロイ演習：詳細なデプロイスクリプトを準備し、メインネット環境と完全に一致するテストネットで実施すること