原題: BIP-327 MuSig 2 in 4 つのアプリケーション: 碑文、ビットコイン再ステーキング、BitVM 共同署名、およびデジタル資産保管
原作者: Qin Wang (CSIRO)、Cynic (Chakra)、mutourend (Bitlayer)、lynndell (Bitlayer)
この記事では、最も一般的な 4 つの分野 (登録、再ステーキング、BitVM 共同署名、保管) における BIP-327 MuSig 2 マルチ署名プロトコルのアプリケーションを紹介します。
1 はじめに
既存のビットコイン トランザクションは CheckMultiSig を使用して n-of-n マルチシグを検証するため、トランザクションの署名者の数に比例してビットコイン ブロックチェーン上に署名と公開キーを公開する必要があります。この方法では、取引参加者の総数が明らかになるだけでなく、署名者の数に応じて取引手数料が増加することも明らかになります。この問題を解決するために、2018 年に研究者らは Schnorr マルチ署名プロトコル Musig を提案しました。ただし、このプロトコルは署名者間で 3 ラウンドの通信を必要とし、ユーザー エクスペリエンスが比較的劣るため、このプロトコルは広く注目され、応用されることはありません。
2020 年、MuSig 2 の発売により、インタラクティブ署名は大幅に進歩し、3 ラウンドのコミュニケーションが 2 ラウンドに減り、ユーザーにより良いエクスペリエンスがもたらされました。さらに、MuSig 2 を使用すると、ユーザーのグループが単一の署名と公開キーを共同で生成してトランザクションを検証できるため、プライバシーが向上し、トランザクション手数料が大幅に削減されます。 3 年以上の継続的な改善を経て、Schnorr マルチ署名 (MuSig 2) がウォレットとデバイスに実装されました。
MuSig 2 関連の提案は次のとおりです。
最近https://github.com/achow101/bips/commits/musig2/ 、現在はビットコイン BIP ライブラリに統合されています。
Bitlayer と Chakra 研究グループは、碑文、ビットコイン誓約、BitVM、デジタル資産保管の隆盛により、BIP-327 MuSig 2 には、理論的には無制限の数の署名者がトランザクションに参加することをサポートし、費用を節約できるという大きな応用可能性があることを発見しました。チェーンスペースや手数料の削減、セキュリティ、プライバシー、操作性の向上など。
インスクリプション:インスクリプションは、カスタマイズされたコンテンツをビットコインに書き込み、インスクリプションを行うサトシです。この概念は、不変かつ検証可能な情報記録をブロックチェーン上に直接作成できるため、広く注目を集めています。碑文は単純なテキストから複雑なデータ構造まで多岐にわたり、デジタル資産の信頼性と出所を認証するための信頼できる方法を提供します。ブロックチェーン記述の永続性とセキュリティにより、デジタル ID 検証、所有権の証明、重要な情報のタイムスタンプなどのアプリケーションで非常に価値があります。碑文の場合、MuSig 2 は署名と検証率を高め、鋳造プロセスに必要な取引手数料を削減し、オフチェーン インデクサーに必要なセキュリティを提供することで、碑文エコシステム全体の信頼性を向上させることができます。
ビットコインステーキング：ビットコイン保有者が、さまざまなブロックチェーンプロトコルや分散型金融（DeFi）アプリケーションをサポートするために、約束した資産を再割り当てするためのメカニズム。このプロセスにより、ビットコインはブロックチェーンエコシステム内で複数の役割を果たすことができ、その有用性と収益の可能性が高まります。ヘビーステーキングに参加することで、ユーザーはビットコインの保有を維持しながら、他のネットワークのセキュリティと機能に貢献できます。この革新的なアプローチは、ビットコインの流動性とセキュリティを活用して、より統合された効率的なブロックチェーン経済を推進します。ビットコインには流動性ステーキングの実装に必要な契約機能が欠けており、UTXO アーキテクチャは、どのような額面の担保トークンの引き出し機能とも十分に互換性がないためです。したがって、ビットコインの流動性ステーキングを実装するには MuSig 2 が必要です。
BitVM:ビットコイン ネットワーク上にスマート コントラクト機能を実装するためのフレームワーク。複雑なスマート コントラクトをネイティブにサポートするイーサリアム仮想マシン (EVM) とは異なり、BitVM はビットコインのスクリプト機能を拡張して、より複雑なプログラム可能なトランザクションを可能にするように設計されています。この開発により、ビットコインの分散型アプリケーション (dApps) と複雑な金融アプリケーションに新たな道が開かれ、その単純なスクリプト言語の限界が打ち破られます。 BitVM の導入は、ビットコインと他のより柔軟なスマート コントラクト プラットフォームとの間に架け橋を構築する、ビットコインのユーティリティにおける重要な進化を示しています。 BitVM ではソフト フォークを必要とせずに事前署名が必要で、1/n の信頼仮定と許可のないチャレンジ機能が有効になります。信頼の仮定をできるだけ小さくするには、n の値をできるだけ大きくする必要があります。しかし、大規模なマルチ署名を検証する既存の CheckMultiSig スクリプトでは、非常に高額なトランザクション手数料が必要となるため、実行不可能です。 MuSig 2 は n の値を可能な限り大きくできるため、n の値はビットコインのブロックとスタック サイズによって制限されず、調整できる実際の連署者の数に依存し、コストが低くなります。
デジタル資産の保管: ブロックチェーンを使用して、暗号通貨、NFT (代替不可能なトークン)、その他のトークン化された資産などのデジタル資産を安全に保管および管理します。これには、秘密キーの保護、アクセス制御の確保、サイバー脅威に対する保護の提供が含まれます。しきい値署名は、デジタル資産のセキュリティ管理において重要な役割を果たし、暗号化キーを分散して管理します。この手法では、秘密キーを複数の共有に分割し、異なる参加者に配布します。取引に署名したり、デジタル資産にアクセスするには、事前に設定されたしきい値の株式を組み合わせて、単一の当事者が一方的に資産を制御したり悪用したりできないようにする必要があります。これにより、鍵の侵害、内部関係者の脅威、単一障害点のリスクが軽減され、セキュリティが強化されます。さらに、しきい値署名はデジタル資産管理のためのより堅牢で柔軟なガバナンス モデルを提供し、分散型組織や複数パーティ システムでの安全なコラボレーションと意思決定を可能にします。しきい値署名と MuSig 2 を組み合わせることで、碑文、ビットコイン誓約、BitVM 共同署名、デジタル資産保管などのアプリケーションのニーズを同時に満たし、1 つの魚から 4 つのメリットを実現できます。
2. MuSig 2の原則と実装仕様
2.1 MuSig 2 原則
2.2 MuSig 2の実装仕様
最近、Bitcoin Core の貢献者Andy Chow がいくつかの BIP 提案を提出しました。
BIP-328: MuSig 2 集約キーの導出スキーム[アプリケーション層]: BIP 327 MuSig 2 集約公開キーに基づいて BIP 32 拡張公開キーを構築し、これらの BIP 32 拡張公開キーをキー導出に使用する方法について説明します。
BIP-373: MuSig 2 PSBT フィールド[アプリケーション層]: BIP 174 部分署名ビットコイン トランザクション (PSBT) に乱数、公開キー、部分署名用のフィールドを追加しました。
BIP-390: musig() 記述子キー式[アプリケーション層]: MuSig 2 ウォレットによって制御されるトランザクション出力のメソッドを提供します。
これは、MuSig 2 の導入とウォレットの統合に必要なステップです。 MuSig 2 ウォレットを統合するために必要なのは、これらの BIP と仕様だけです。さらに、多くのウォレット開発者と共同ホスティング ソリューション ( 「Taproot をマルチシグに対応させる」を参照) は長い間、MuSig 2 プロトコルの標準化を要求してきました。現在、正式な BIP が整備されているため、コミュニティはそれを自らレビューし、フィードバックを提供し、意識を高めることができます。
3. MuSig 2 1 匹の魚で 4 つのものを食べる
3.1 碑文
碑文の最も典型的な用途は、ビットコイン上の NFT トークンと見なすことができる BRC 20 を構築することです。その中心となる設計は、Ordinals プロトコルを通じて各 SATOSHI にデータを書き込み、単純な操作を実装することです。全体として、ここには 3 つのステップがあります。
最初のステップは、各サトシの独自性を追跡することです。サトシはビットコインの分割不可能な最小単位であり、ビットコインの総数は 2,100 万であるため、利用可能なサトシの上限は 2.1 京です。ビットコインの各サトシはユニークな存在であり、ユニークです。これがビットコイン上でNFTを確立する基本的なロジックです。ここで、各サトシには順方向シーケンス番号が (Ordinals プロトコル経由で) 割り当てられ、先入れ先出しベースで管理され、正確な追跡と秩序ある処理が保証されます。 図に示すように、各サトシは完全な連続シーケンスの一部であることがわかります (この例ではサトシ #1、#11、および #31 として示されています)。
2 番目のステップでは、JSON 形式と Taproot スクリプトを使用してメッセージをコンテナに埋め込みます。これらのメッセージは SegWit フィールドに保存されるため、プロセスが効率的かつ安全になります。スクリプトは OP フィールド内に JSON を埋め込みます。 OP_IF は条件判定を開始し、埋め込まれたコンテンツは OP_FALSE フィールドの後に配置されます。この条件により、後続のコンテンツは実行されずに保存されるだけになります。したがって、新しく埋め込まれた JSON は完全にこの SATOSHI に保存されます。図 1 に示す JSON 埋め込みには、BRC 20 トークンをデプロイするための主要なパラメーターが含まれています。プロトコルは「brc-20」、操作タイプは「deployment」、トークンシンボルは「ordi」、最大供給量は 2,100 万、鋳造制限は 1,000 に設定されています。ここで、このプロセスをサポートする主要な BIP には、Schnorr Signature (BIP 340)、Taproot (BIP 314)、Tapscript (BIP 342)、および SegWit (BIP 141) が含まれます。
3 番目のステップである BRC 20 トークンの識別には、インデクサーによって管理されるオフチェーン状態が含まれます。これらのインデクサーは、履歴トランザクションに基づいて BRC 20 トークンのステータスを解析して解釈します。オンチェーン データを解析し、トークンのステータスをチェックし、残高を更新して情報が最新であることを確認します。さらに、ライト クライアントはこの情報を統合して、ユーザーが BRC 20 トークンをシームレスに識別して管理できるようにします。
図 1. BRC 20 トークンの主な手順
ここで、展開および鋳造操作には 1 つのトランザクションのみが必要ですが、BRC 20 トークンの転送 (つまり、転送操作) には 2 つのトランザクションが必要です。最初のトランザクションでは、基本的に必要なオンチェーン書き込みが送信者に対して実行されます。これはミント操作と非常によく似ています。 2 番目のトランザクションでは、別のトランザクションが送信者から受信者への転送を完了します。次に、オフチェーン インデクサーが状態を更新します。条件が満たされる場合、インデクサーは送信者の残高から対応する金額を差し引き、受信者の残高に入金します。
Schnorr 署名がビットコインの Taproot アップグレードに使用され、ビットコイン取引のプライバシーと効率が向上していることがわかります。 Schnorr マルチ署名 (MuSig 2) のアップグレード バージョンは、Taproot のアップグレードされた部分に非常に直感的かつ自然に統合でき、碑文や同様の BRC 20 の作成プロセスに自然に接続できます。新たにアップグレードされた刻印により、既存のベースに基づいて署名と検証の速度が向上し、鋳造プロセスに必要な取引手数料がさらに削減されます。
別のアプリケーションはオフチェーン インデクサー部分から来ます。現在のインデクサーは本質的にオフチェーン検証ツールであり、さまざまなサービス プロバイダーが独自のインデクサー更新サービスを提供しています。ここで生じるリスクは、多くのサイドチェーンやロールアップサービスプロバイダーと同様に、比較的集中管理されているサービスプロバイダーを信頼できないことから生じます。これらのインデクサーはユーザーの自然資金を保管していませんが、見積もりが間違っていたり、見積もりが遅れたりすると、ユーザーのトランザクションが失敗する原因になります。 MuSig 2 は、マルチサインのアイデアを提供します。比較的分散化された多数の検証者を導入して、同じインデクサーを共同で維持し、チェックポイント メカニズムと同様に、毎回共同で特定のノードで署名を検証して署名することができます。ユーザーは少なくとも、インデックスがオンチェーンの書き込みとトランザクション フローを正直かつ確実に送信する前のインデクサーを信頼できます。このようにして、MuSig 2 はオフチェーン インデクサーに必要なセキュリティを提供し、それによって碑文エコシステム全体の信頼性が向上します。
3.2 ビットコインの誓約
ネイティブの誓約メカニズムを備えたイーサリアムなどの PoS チェーンとは異なり、ビットコインは PoW コンセンサスメカニズムによって維持されるブロックチェーンであり、誓約機能を実装するには追加のメカニズムが必要です。現在、最もよく知られているのは、Babylon によって提案されたビットコイン ステーキング ソリューションです。
Babylon ステーキング メカニズムでは、ユーザーは Babylon によって定義された BTC プレッジ スクリプトを通じてプレッジを完了します。これはプレッジ トランザクションと呼ばれ、プレッジ出力を生成します。ステーキング出力は Taproot 出力で、内部キーは NUMS ポイントに設定すると無効になります。また、ステーキング機能を実装するために使用できるスクリプト パスが 3 つあります。彼らです：
タイムロックパス：誓約のロックアップ機能を実現します。
誓約解除パス: 誓約を早期に終了する機能を実現します。
パニッシュメントパス：悪事を行ったときのシステムのパニッシュメント機能を実現します。
ビットコイン プレッジ メカニズムは、ビットコイン保有者により安全な利息獲得ソリューションを提供し、ビットコイン資産の有用性を高めます。ただし、このステーキングはビットコインの流動性をある程度損ないます。しかし、イーサリアムのステーキングメカニズムの長年の研究により、ビットコインステーキングへの道が開かれ、流動性ステーキングを使用してこの問題を解決できます。
流動性ステーキングでは、資産の保管者という新しい役割が導入されます。ユーザーは流動性ステーキング プロジェクトの保管アドレスに資産を預け、対応する割合のリキッド ステーキング トークン (LST) を取得します。流動性ステーキング プロジェクトは収集された資産をネイティブに担保し、LST 保有者はステーキング収入を自動的に共有します。さらに、LST 保有者は流通市場で LST を直接取引したり、ネイティブの質入れ資産と引き換えに LST を燃やすことができます。
イーサリアムの流動性ステーキングは、スマートコントラクトを通じて実装できます。ただし、ビットコインには流動性ステーキングの実装に必要な契約機能が欠けており、UTXO アーキテクチャはあらゆる額面の LST の出金機能と互換性がありません。現在、OP_CAT などのコントラクト オペコードはオンラインではないため、ビットコイン トランザクションの出力が将来どのように使用されるかについて制限を効果的に強制する方法はありません。したがって、ビットコインの流動性ステーキングを可能にするには MuSig 2 が必要です。
図 2 に示すように、Chakra 流動性ステーキングでは、ユーザーはまず MuSig 2 を利用したマルチシグネチャ アドレスにビットコインを転送します。このイベントはインデクサーによってキャプチャされ、オンチェーン コントラクトが呼び出されて、ユーザーのために crrBTC を作成します。マルチ署名アドレス内のビットコインはバビロンに預けられます。 crrBTCを保有している間、ユーザーはバビロンのステーキングから引き続きリターンを受け取ることができます。ユーザーがプレッジを終了したい場合は、crrBTC を破棄できます。インデクサーが破棄イベントを検出すると、プレッジ解除操作が実行され、ビットコインがユーザーに返されます。さらに、ユーザーは流通市場で直接取引して crrBTC をビットコインに交換することもできます。
図 2. Chakra 流動性ステーキング プロセス
セルフカストディステーキングと比較して、MuSig 2 によってサポートされる流動性ステーキングでは、デジタル資産カストディの安全性を維持するために複数の当事者が導入され、同時に担保されたビットコインの流動性が解放されるため、LST は BTCFi においてより大きな役割を果たすことができます。ユーザーにさらなるメリットを提供します。
3.3 BitVM 余符号
Robin Linus は、Lamport のワンタイム署名を使用してステートフル ビットコイン スクリプトを実装する、「BitVM: Compute Anything on Bitcoin」ホワイト ペーパーを 2023 年 10 月にリリースしました。このシステムは、新しいオペコードなどのソフトフォークを導入することなく、オプティミスティックチャレンジメカニズムを通じてチューリング完全なビットコインコントラクトを実装できます。このシステムは、OP_BOOLAND および OP_NOT オペコードで構築された NAND ゲート バイナリ回路のみを使用し、ビットコインでの任意の計算を検証するという課題を示していますが、プログラムによってコンパイルされた回路は非常に大規模であるため、実際のアプリケーションにはほとんど実用的ではありません。その後、 BitVM 1 はRISC-V 命令を使用してプログラムを表現し、ビットコイン システムのすべてのオペコードを最大限に活用して効率を向上させます。
BitVM 2 は、 2 つの方法で BitVM 1 を拡張します。 (1) BitVM 1 のチャレンジャーは初期設定に参加したアライアンス メンバーですが、BitVM 2 のチャレンジャーは任意の参加者です。したがって、BitVM 1 では同盟メンバーが悪を行う危険性がありますが、BitVM 2 ではチャレンジャーは Permissionless であり、同盟メンバーは悪を共謀することができません。 (2) BitVM 1 は複数回のチャレンジが必要でサイクルが長いのに対し、BitVM 2 は ZK Proof のシンプルさと Taptree のスクリプト表現能力を活かし、チャレンジサイクルは 2 ラウンドのみで、プレ回数も少ない。ペグインに必要な署名済みトランザクションは約100トランザクションから約10トランザクションです。具体的には、BitVM 1 は、複数回の対話後にプログラム内で誤って実行された RISC-V 命令を見つけるために二分法を使用する必要があります。一方、BitVM 2 はプログラム自体を検証するのではなく、プログラムが正しく実行されることを検証する ZK 証明を検証します。 BitVM 2 ZK 検証アルゴリズムは複数のサブ機能に分割され、各サブ機能は Tapleaf に対応します。異議が申し立てられた場合、オペレーターは各サブ機能の値を明らかにする必要があります。矛盾がある場合、誰でもそれを罰するために反証トランザクションを開始できます。
図 3 に示すように、BitVM 2 は多数の n-of-n 事前署名を必要とします。ユーザーは、ペグイン トランザクションを開始する前に、どのオペレーターが支払いを前払いしてくれるのかわからないため、BitVM Alliance は、Take 1、Take 2、Assert、Disprove、Burn の n-of-n トランザクションに事前署名する必要があります。各子孫トランザクションの事前署名が完了したことをユーザーが確認した後でのみ、資金はペグイン トランザクションを通じて n-of-n マルチ署名制御アドレスに実際に入金されます。ユーザーがお金を引き出したい場合は、ペグアウト取引を開始することができ、オペレーターの 1 人が支払いを前払いし、引き出しを完了することができます。
オペレーターは、アドバンスビットコインの払い戻しを受ける前に 2 BTC を誓約する必要があります。誰も異議を唱えない場合、オペレーターは Take 1 トランザクションを通じて正常に払い戻されます。オペレーターが何か悪いことをした場合、1 BTC をクラウドファンディングすれば誰でもチャレンジを開始できます。チャレンジに直面して、オペレーターが応答しない場合、書き込みトランザクションが実行されます。つまり、1.9 BTC が破棄され、オペレーターが応答した場合、残りの 0.1 BTC が書き込みトランザクションの受信アドレスに与えられます。実行されました。
ケース 1: 特定のサブ関数の値が矛盾している場合、誰でも反証トランザクションを開始できます。つまり、1 BTC が破棄され、反証トランザクションの受信アドレスに 1 BTC が与えられます。
シナリオ 2: サブ関数の値が一貫して明らかになった場合、オペレーターは 2 週間後に Take 2 トランザクションを通じて正常に払い戻される可能性があります。
図 3. BitVM 2 プロセス
BitVM 2 システムでは、BitVM Alliance は n-of-n トランザクション (Take 1、Take 2、Assert、Disprove、Burn) に事前署名する必要があります。 BitVM の信頼仮定は 1-of-n であり、n の値が大きいほど信頼仮定は低くなります。しかし、このような大規模なマルチ署名には非常に高額な手数料が必要となるため、ビットコインではほとんど実現不可能です。 MuSig 2 は、多数のマルチ署名を 1 つの署名に集約して、手数料を最小限に抑えることができ、理論的には、調整できる実際の連帯署名者の数に応じて、n 値 1000 またはそれ以上など、無限の n 値をサポートします。 。
BitVM を導入する場合、BitVM Alliance が n-of-n 個のマルチ署名で共謀して消費するのを防ぐため、ペグインの設定後、n 人の共同署名者のうち少なくとも 1 人の共同署名者が秘密鍵を削除する必要があります。 。これにより、BitVM ブリッジ内の資金は、オペレーターによって誠実に送金された後にのみ、償還トランザクションを使用して使用できるようになります。したがって、BitVM ブリッジのセキュリティが向上します。
3.4 デジタル資産の保管
集約署名を使用すると、複数の署名を 1 つの署名に結合できるため、検証プロセスが簡素化され、効率が向上します。図 4 に示すように、アリスは完全な秘密鍵 KeyA を使用して署名 SigA を生成し、ボブは完全な秘密鍵 KeyB を使用して完全な署名 SigB を生成します。次に、SigA が SigB と集約されて、集約署名 AggSig が生成されます。このアプローチでは、各参加者の独立性と責任が確保されるだけでなく、許可された操作を実行するには両当事者の参加が必要となるため、システム全体のセキュリティも強化されます。この連携を通じて、アリスとボブは、より安全で効率的なデジタル資産管理を実現し、単一障害点や悪意のある操作を防止しながら、トランザクションの複雑さと検証コストを簡素化することができます。
一方、Alice は、分散デバイスを使用してしきい値署名を使用してデジタル署名を生成および管理しますが、単一のデバイスでは完全な署名機能を備えることはできません。具体的には、閾値署名方式は秘密鍵をいくつかの部分に分割し、各デバイスは 1 つの秘密鍵を保管します。有効な署名は、特定の数のデバイス (つまり、しきい値に達した) が連携する場合にのみ生成できます。このメカニズムにより、秘密鍵の一部が漏洩したとしても攻撃者は有効な署名を生成できないため、デジタル資産のセキュリティが大幅に向上します。さらに、しきい値シグネチャにより、単一障害点を防止し、システムの堅牢性と継続性を確保できます。したがって、しきい値署名は、デジタル資産の分散管理のための効率的で安全なソリューションを提供します。
図 4. 集約された署名、しきい値署名
アリスとボブの両方がしきい値署名を使用してそれぞれのデジタル資産を管理し、前述の碑文、ビットコイン誓約、BitVM 共同署名、その他のアプリケーションなどのトランザクションに複数署名するために集約署名 (MuSig 2) を使用する必要がある場合。この場合、複数の魚を達成するには、集約シグネチャとしきい値シグネチャを組み合わせる必要があります。
図 5. 集約署名としきい値署名の組み合わせ
図 5 に示すように、アリスとボブがデジタル資産の保管にしきい値署名を使用すると、完全な秘密鍵 KeyA と KeyB は表示されませんが、対応する秘密鍵のフラグメント (ShareA 1、ShareA 2、ShareA 3) のみがそれぞれ表示されます。 (シェアB 1、シェアB 2、シェアB 3)。このとき、秘密鍵シャード (ShareA 1、ShareA 2、ShareA 3) および (ShareB 1、ShareB 2、ShareB 3) に基づいてしきい値署名が実行され、それぞれ署名 SigA と署名 SigB が生成されます。次に、署名 SigA が署名 SigB と集約されて、集約署名 AggSig が生成されます。プロセス全体を通じて、完全な秘密キー KeyA と KeyB は表示されません。したがって、しきい値署名と集約署名の組み合わせは、複数のアプリケーション要件を同時に満たすために実現されます。
参考文献
2023. MuSig 2 での偽キーによる偽造
2023. BitVM ホワイトペーパー
