マルチシグ・ウォレットの取引モデルと署名ルール

主なポイント

• マルチシグ・ウォレットは、単一障害点を排除し、機関投資家向けに設計された、構造化された複数承認者による管理モデルを採用しています。

• トランザクション・モデルと署名ルールは、権限、ガバナンス、およびリスク管理が実際にどのように実施されるかを規定するものである。

• マルチシグのアーキテクチャは、運用上のニーズに応じて、処理速度、耐障害性、柔軟性のバランスを調整します。

• 組織のワークフローにおいて、ポリシー適用レイヤーは暗号署名と同様に重要です。

• 適切に設計されたマルチシグ・フレームワークは、監査可能性、リスク管理、および長期的な運用継続性を支えます。

マルチシグは、単なる理論上の概念ではなく、機関向けのインフラである

マルチシグウォレット マルチシグウォレットは、単一鍵ウォレットからの単純なセキュリティ強化策として紹介されることがよくあります。しかし、機関投資家にとっては、その捉え方は不十分です。マルチシグウォレットは単なる暗号技術的な構成ではなく、現実世界の制約下において、資産がどのように移動するか、誰が権限を持つか、そしてリスクがどのように管理されるかを決定する運用モデルなのです。

金融機関は、セキュリティ、管理、リスク管理、および業務の継続性を重視しています。マルチシグの設計選択は、これら4つの要素すべてに直接影響を及ぼします。これらの要素がどのように相互に関連しているかを理解することは、強靭なカストディおよび財務業務を設計する金融機関にとって不可欠です。

マルチシグウォレットとは？ 概要

マルチシグウォレットとは、取引を承認するために複数の暗号署名が必要なデジタル資産ウォレットのことです。資金の管理を単一の秘密鍵に委ねるのではなく、複数の独立した鍵が使用され、あらかじめ定められた閾値に基づいて、その操作を承認するために必要な鍵の数が決まります。

最も一般的な構造は「M-of-N」モデルです。これは、すべての鍵が必要となる「N-of-N」から、特定の閾値まで多岐にわたります。例えば「2-of-3」ウォレットでは、3つの異なる鍵が存在し、取引を有効にするにはそのうち2つで署名する必要があります。この構造により、特定の個人、デバイス、またはシステムへの依存度が低減されます。また、チームや組織間で管理権限を共有することも可能になります。

構造的に、マルチシグウォレットは、権限の配分という点でシングルキーウォレットとは異なります。シングルキーウォレットでは、アクセス権とリスクの両方が一元化されています。一方、マルチシグウォレットでは、これらを意図的に分離しています。この分離により、二重承認、職務分掌、災害復旧計画といった内部統制が可能になります。

機関にとって、マルチシグは基盤となるインフラです。これは、ガバナンス、ポリシー、暗号技術が連携して機能する枠組みを構築します。この基盤があるからこそ、より高度な取引モデルや承認ワークフローをその上に構築することが可能になるのです。

マルチシグは実際にはどのように機能するのでしょうか？

実際には、マルチシグウォレットは、あらかじめ定義されたトランザクションのライフサイクルに沿って動作します。まず、通常は権限を持つオペレーターやシステムによってトランザクションが提案されます。その提案は、その後、必要な数の署名者によって審査・承認されます。閾値に達すると、トランザクションはネットワークに送信され、チェーン上で確定されます。

マルチシグの実装は、ブロックチェーンやアーキテクチャによって異なります。ビットコインでは、マルチシグはプロトコルレベルでスクリプト条件を通じてネイティブに実装されており、これはしばしば ビットコインネイティブのマルチシグ. イーサリアムやその他のスマートコントラクトプラットフォームでは、マルチシグのロジックは通常、署名者セットと閾値を管理するスマートコントラクトを通じて実装されます。一部の機関向けシステムでは、署名が行われる前に承認プロセスを調整するオフチェーンのポリシーエンジンを追加しています。

鍵を誰が管理しているかは、鍵の数がいくつあるかと同じくらい重要です。鍵は、社内の各チーム、外部の保管業者、あるいは地理的に分散した環境などに分散して管理される場合があります。多くの場合、役割が明確に区分されており、取引の提案と、その承認や実行とは別々のプロセスとなっています。

どのモデルにも一長一短があります。オンチェーンのマルチシグは透明性と簡潔さを提供します。スマートコントラクトベースのマルチシグは柔軟性とプログラム可能性をもたらします。オフチェーンのポリシーレイヤーは制御性と監査可能性を高めますが、システムの複雑さを増すことになります。機関は、リスク許容度、運用規模、およびリスク管理上の義務に基づいてモデルを選択します。

署名ルール：権限と管理の定義

署名ルールは、誰が、どのような条件下で、どのような組み合わせで取引を承認できるかを定義します。「3人中2人」や「5人中3人」といった閾値は、ガバナンスおよびリスク管理方針を具体化したものです。

一般的に、閾値を低く設定すると処理速度は向上するが、耐障害性は低下する。一方、閾値を高く設定すると耐障害性と監視機能は向上するが、処理速度が低下する可能性がある。機関は、業務効率とセキュリティおよび事業継続性のバランスをとらなければならない。

署名ルールには、意思決定権限も規定されています。ある組織では、業務部門とコンプライアンス部門からそれぞれ1名ずつの署名を義務付ける場合があります。また、別の組織では、セキュリティチームや外部の受託者を関与させる場合もあります。こうしたルールは職務分掌を徹底させ、一方的な行動によるリスクを低減します。

重要なのは、署名ルールは組織のニーズに合わせて進化させるべきだということです。チームの拡大、管轄区域の変更、あるいは規制要件の拡大に伴い、閾値や署名者の範囲は柔軟に対応できるものでなければなりません。署名の設定を「生き生きとしたポリシー」ではなく「固定された設定」として扱うことは、組織が犯しがちな過ちです。

一般的なマルチシグ取引モデル

いくつか マルチシグ取引モデル 施設などで広く利用されている。

「3本中2本」のカストディモデルは、最も一般的な形態の一つです。通常、鍵の1本は顧客が、もう1本はカストディアンが、そして残りの1本はバックアップまたはエスクロー機関が保管します。このモデルは、顧客による管理と、制度的な安全策および復旧手段とのバランスをとっており、多くの場合、規制対象の コールドウォレット.

「5分の3」のガバナンスモデルは、内部の財務部門やプロトコルの運用においてよく採用されます。鍵は、運用、セキュリティ、コンプライアンス、および経営陣のステークホルダーの間で分散される場合があります。この構造により、複数部門による承認プロセスが可能となり、特定の機能への依存度を低減できます。

しきい値ベースのスマートコントラクトモデルは、プログラム可能なブロックチェーン上で一般的です。これらは、動的な署名者セット、役割ベースの権限、およびオンチェーンロジックとの統合を可能にします。これらは強力ですが、慎重な設計と継続的な監視が必要です。

どのモデルにも、速度、耐障害性、ポリシーの柔軟性、および回復力の間でトレードオフが存在します。また、機関はトランザクション・モデルを選択する際、署名者の利用不能や鍵の漏洩といった災害復旧シナリオについても考慮する必要があります。

ポリシーの適用とトランザクションのワークフロー

暗号署名だけでは、組織のガバナンスには不十分です。ポリシーの適用レイヤーが、署名をいつ、どのように使用できるかを定義します。

ポリシーエンジンは、トランザクションの意図とキーの使用の間に位置します。これらは、利用限度額、承認の遅延、ロールベースのアクセス制御、宛先許可リストなどのルールを適用します。これらの機能は、多くの場合、プログラムを通じて提供されます。 Wallet-as-a-Service ポリシー適用をトランザクションのワークフローに直接組み込んだソリューション。

トランザクションは署名閾値を満たしていても、ポリシーに違反している場合はブロックされることがあります。鍵による署名とポリシーによる承認のこの区別は極めて重要です。署名はプロトコルレベルでトランザクションを承認するものです。一方、ポリシーは、そもそも署名が適用されることを許可するかどうかを規定するものです。

組織にとって、オフチェーンでのポリシー適用は、チームや管轄区域をまたいだ一貫性を確保します。また、内部統制や規制上の要件への準拠を証明する監査証跡も作成されます。ポリシー層がなければ、マルチシグウォレットは運用上のボトルネックやガバナンス上の死角となるリスクがあります。

マルチシグにおける制限事項とエッジケース

マルチシグはセキュリティを向上させる一方で、運用上の課題も生じます。鍵の紛失や漏洩により、利用可能な署名者が必要な閾値を下回ってしまう可能性があります。また、出張、人事異動、または不測の事態により署名者が不在となった場合、調整がうまくいかなくなる恐れがあります。

マルチシグの実装によっては、アップグレードが困難な場合があります。署名者セットや閾値を変更するには、複雑な移行作業や、リスクを伴うオンチェーン取引が必要になることがあります。誤ってロックアウトされる事態を避けるため、ガバナンスの変更は慎重に計画する必要があります。

鍵の失効、緊急アクセス、組織再編といった例外的なケースについては、あらかじめ対応策を講じておく必要があります。こうしたシナリオを想定していない組織は、危機的状況下で脆弱性が露呈することがよくあります。

こうした理由から、一部の機関では、以下のような代替的または補完的なアプローチを検討している。 マルチパーティ計算...といった特定のユースケースにおいて。代替手段が存在することは、マルチシグ自体の欠陥ではなく、エコシステムの成熟度を反映している。

マルチシグとリスク管理

マルチシグのアーキテクチャは、内部統制や受託者責任に関する規制上の要件と密接に整合しています。複数の承認者を設けることで、職務分掌が図られ、不正な資産移動のリスクを低減します。

監査可能性も重要な利点の一つです。マルチシグ取引では、誰が、何を、いつ承認したかという明確な記録が残されます。このデータをポリシーログと組み合わせることで、内部監査や外部監査の根拠となります。

多くのリスク管理フレームワークでは、複数承認者によるプロセスが求められています。SOC 2 や 暗号資産セキュリティ基準 アクセス制御、承認ワークフロー、および監視を重視する。マルチシグは、これらの要件を満たすための技術的基盤を提供する。

規制対象企業にとって、マルチシグは規制上の義務を、実行可能な運用ルールへと転換するのに役立ちます。

BitGoが、ポリシー主導型の安全なマルチシグアーキテクチャを実現する方法

BitGoは、実運用における複雑な要件に対応するよう設計された、機関投資家向けのマルチシグインフラを提供しています。同社は、規制対象の事業体、適格なカストディサービス、および設定可能なポリシー管理を通じて、マルチシグ機能をサポートしています。

BitGoのアーキテクチャは、鍵管理とポリシーの適用を分離しており、単一障害点を生じさせることなく、きめ細かな承認ワークフローを実現します。安全な鍵の保管、役割ベースの権限管理、および透明性の高い監査証跡により、業務効率とコンプライアンス要件の両方を満たします。

BitGoは、マルチシグを単なる機能として扱うのではなく、より広範なカストディおよび取引フレームワークの一部として位置付けています。このアプローチにより、機関投資家は、要件の変化に応じて拡張・適応し、強靭性を維持できるガバナンスモデルを構築することが可能になります。

なぜBitGoなのか

金融機関には、業務の透明性を損なうことなく、セキュリティ、ガバナンス、および規制上の要件を整合させるインフラが求められます。BitGoは、金融機関の実際の業務体制を反映したマルチシグ取引モデルや署名ルールを実装するためのツールを提供します。

規制対象となるデジタル資産のワークフローを10年以上にわたり支援してきた実績を持つBitGoは、カストディおよび取引のライフサイクル全体において、ポリシーに基づく管理、監査可能性、および耐障害性を実現します。

よくある質問

マルチシグ暗号資産ウォレットとは何ですか？

マルチシグ暗号ウォレットは、取引を承認するために複数の暗号署名が必要です。単一の秘密鍵に依存するのではなく、複数の鍵に管理権限を分散させます。

M-of-Nなどの一般的なマルチシグ取引モデルは、どのように機能するのでしょうか？

M-of-Nモデルは、全鍵のうち何個の署名が必要かを定義する。2-of-3ウォレットでは、3つの承認鍵のうち任意の2つが取引を承認しなければならない。

組織は、効果的なマルチシグ署名ルールやポリシーをどのように策定すればよいでしょうか？

組織は、閾値をガバナンス体制と整合させ、職務分掌を徹底し、ポリシー層を活用して署名の適用方法を管理すべきである。

マルチシグウォレットとMPCウォレットの間には、どのようなトレードオフがありますか？

マルチシグは個別の鍵と閾値に依存するのに対し、MPCは鍵素材を参加者間で分散させます。それぞれのアプローチは、柔軟性、復旧性、および運用上の複雑さにおいて異なる影響を及ぼします。

マルチシグはガバナンスと運用管理をどのように支援するのでしょうか？

マルチシグは、複数承認者のプロセスを徹底し、監査証跡を作成し、単一障害点を低減することで、内部ガバナンスと規制遵守の両方を支援します。