BIP-327 MuSig2の4つの応用：インスクリプション、ビットコインの再ステーキング、BitVM共同署名、デジタル資産の保管

原文タイトル：《BIP-327 MuSig2 in Four Applications: Inscription, Bitcoin Restaking, BitVM Co-sign, and Digital Asset Custody》

著者：Qin Wang (CSIRO), Cynic (Chakra), mutourend (Bitlayer), lynndell (Bitlayer)

はじめに

既存のビットコイン取引は CheckMultiSig を使用して n-of-n マルチシグネチャを検証しており、ビットコインブロックチェーン上に取引における署名者の数に比例した署名と公開鍵を公開する必要があります。この方法は、取引参加者の総数を明らかにするだけでなく、署名者の数が増えるにつれて取引手数料も増加します。この問題を解決するために、2018年に研究者たちは Schnorr マルチシグプロトコルである MuSig を提案しました。しかし、このプロトコルは署名者間で3ラウンドの通信を必要とし、ユーザー体験が相対的に悪いため、広く注目されず、適用されることはありませんでした。

2020年には MuSig2 が登場し、インタラクティブな署名が大きな進展を遂げました：3ラウンドの通信を2ラウンドに減らし、ユーザーにより良い体験を提供しました。さらに、MuSig2 は一群のユーザーが単一の署名と公開鍵を共同生成して取引を検証できるようにし、プライバシーを向上させ、取引手数料を大幅に削減しました。3年以上の継続的な改善を経て、Schnorr マルチシグ（MuSig2）はすでにウォレットやデバイスに実装されています。

MuSig2 に関連する提案は以下の通りです：

· 2022年のビットコイン BIP-327: MuSig2 for BIP340-compatible Multi-Signatures

· 最近 https://github.com/achow101/bips/commits/musig2/、現在は Bitcoin BIP ライブラリに統合されています。

Bitlayer と Chakra 研究グループは、銘文、ビットコインの再質押、BitVM、デジタル資産の保管の繁栄に伴い、BIP-327 MuSig2 が非常に応用の可能性を持つことを発見しました。理論的には無限の数の署名者が取引に参加でき、オンチェーンスペースを節約し、手数料を削減し、安全性、プライバシー、操作性を向上させることができます。

銘文：銘文はカスタマイズされた内容をビットコインのサトシに刻むことです。ブロックチェーン上に改ざん不可能で検証可能な情報記録を直接作成できるため、この概念は広く注目されています。銘文は単純なテキストから複雑なデータ構造まであり、デジタル資産の真実性と出所を認証するための信頼できる方法を提供します。ブロックチェーン銘文の永続性と安全性は、デジタルアイデンティティの検証、所有権の証明、重要情報のタイムスタンプなどのアプリケーションにおいて高い応用価値を持っています。銘文に関して、MuSig2 は署名と検証の速度を向上させ、鋳造プロセスで必要な取引手数料を削減し、オフチェーンインデクサーに必要な安全性を提供することで、全体的な銘文エコシステムの信頼性を高めます。

ビットコイン再質押：ビットコイン保有者がその質押資産を再配分し、さまざまなブロックチェーンプロトコルや分散型金融（DeFi）アプリケーションをサポートするメカニズムです。このプロセスにより、ビットコインはブロックチェーンエコシステム内で多様な役割を果たし、その実用性と収益潜在能力を強化します。再質押に参加することで、ユーザーは他のネットワークの安全性と機能に貢献しながら、自身のビットコイン保有量を維持できます。この革新的なアプローチは、ビットコインの流動性と安全性を活用し、より統合された効率的なブロックチェーン経済を推進します。ビットコインは流動性質押を実現するために必要な契約能力が不足しており、UTXO アーキテクチャも質押トークンの任意額引き出し機能にうまく対応できません。したがって、ビットコインの流動性質押を実現するために MuSig2 が必要です。

BitVM：ビットコインネットワーク上でスマートコントラクト機能を実現するフレームワークです。複雑なスマートコントラクトをネイティブにサポートするイーサリアム仮想マシン（EVM）とは異なり、BitVM はビットコインのスクリプト機能を拡張し、より複雑なプログラム可能な取引を可能にします。この発展は、ビットコインの分散型アプリケーション（dApps）や複雑な金融アプリケーションに新たな道を開き、その単純なスクリプト言語の制限を打破します。BitVM の導入は、ビットコインの実用性の重要な進化を示し、ビットコインと他のより柔軟なスマートコントラクトプラットフォームの間に橋を架けます。ソフトフォークを必要とせず、BitVM は事前署名を必要とし、1-of-n 信頼仮定とパーミッションレスチャレンジ機能を実現します。信頼仮定をできるだけ小さくするためには、n 値をできるだけ大きくする必要があります。しかし、既存の CheckMultiSig スクリプトは大規模なマルチシグを検証するために非常に高い取引手数料を必要とし、実行不可能です。MuSig2 は n 値をできるだけ大きくし、n の値がビットコインブロックやスタックサイズの制限に制約されず、実際に調整可能なコサイナーの数の制限に依存し、手数料を低く抑えます。

デジタル資産の保管：ブロックチェーンを使用してデジタル資産（暗号通貨、NFT（非代替性トークン）、およびその他のトークン化された資産）を安全に保存および管理します。これには、秘密鍵の保護、アクセス制御の確保、ネットワーク脅威からの防護が含まれます。閾値署名はデジタル資産の安全管理において重要な役割を果たし、分散型の方法で暗号鍵の管理を実現します。この技術は秘密鍵を複数の部分に分割し、異なる参加者に配布します。取引に署名したりデジタル資産にアクセスしたりするには、事前に定められた閾値数の部分を組み合わせる必要があり、単一の当事者が資産を一方的に制御したり悪用したりできないことを保証します。これにより、鍵の漏洩、内部脅威、単一障害点のリスクが軽減され、安全性が向上します。さらに、閾値署名はデジタル資産管理により堅牢で柔軟なガバナンスモデルを提供し、分散型組織や複数のシステムで安全な協力と意思決定を可能にします。閾値署名と MuSig2 を組み合わせることで、銘文、ビットコインの質押、BitVM コサイン、デジタル資産の保管などのアプリケーションニーズを同時に満たし、一魚四食を実現します。

MuSig2 の原理と実装規範

MuSig2 の原理

MuSig2 実装規範

最近、ビットコインコアの貢献者 Andy Chow がいくつかの BIP 提案を提出しました：

· BIP-328: Derivation Scheme for MuSig2 Aggregate Keys【アプリケーション層】：BIP 327 MuSig2 集約公開鍵に基づいて、BIP 32 拡張公開鍵を構築し、これらの BIP 32 拡張公開鍵を使用して鍵を派生させることを説明します。

· BIP-373: MuSig2 PSBT Fields【アプリケーション層】：BIP174 部分的に署名されたビットコイン取引（PSBT）内の乱数、公開鍵、および部分署名にフィールドを追加しました。

· BIP-390: musig() Descriptor Key Expression【アプリケーション層】：MuSig2 ウォレットが制御する取引出力の方法を提供します。

これは MuSig2 が採用され、ウォレットに統合されるための必要なステップです。これらの BIP と規範は、MuSig2 ウォレットを統合するために必要なすべての内容です。さらに、多くのウォレット開発者や協力的な保管ソリューション（Getting Taproot ready for multisigを参照）も、長い間 MuSig2 プロトコルの標準化を要求してきました。現在、正式な BIP が整ったことで、コミュニティは自らレビューし、フィードバックを提供し、認識を高めることができます。

MuSig2 一魚四食

銘文

銘文の最も典型的な応用は BRC20 の構築であり、これはビットコイン上の NFT トークンと見なすことができます。その核心設計は、Ordinals プロトコルを通じてデータを各サトシに刻み、簡単な操作を実現することです。全体的に、ここには3つのステップがあります。

第一ステップ、各サトシの唯一性を追跡します。サトシはビットコインの最小かつ分割不可能な単位であり、ビットコインの総量は2100万で、利用可能なサトシの上限は2.1千兆です。ビットコイン内の各サトシは独特の存在であり、唯一性を持っています。これがビットコイン上で NFT を構築するための基盤となる論理です。ここで各サトシには順方向のシーケンス番号が付与され（Ordinals プロトコルを通じて）、先入れ先出しの方法で管理され、正確な追跡と秩序ある処理が保証されます。図では、各サトシが完全な順序シーケンスの一部であることが示されており、例としてサトシ #1、#11、#31 が表示されています。

第二ステップ、JSON フォーマットと Taproot スクリプトを使用してメッセージをサトシに埋め込みます。これらのメッセージは SegWit フィールドに保存され、プロセスは効率的かつ安全です。スクリプトは JSON をサトシに埋め込み、OP フィールド内に配置します。OPIF が条件判断を開始し、埋め込まれた内容は OPFALSE フィールドの後に配置され、この条件により後続の内容が実行されず、単に保存されることが保証されます。したがって、埋め込まれた JSON はこのサトシに完全に保存されました。図1に示される JSON 埋め込み内容には、BRC20 トークンを展開するための重要なパラメータが含まれています。プロトコルは「brc-20」で、操作タイプは「展開」、トークンシンボルは「ordi」、最大供給量は2100万、鋳造限度は1000に設定されています。このプロセスをサポートする重要な BIP には、Schnorr Signature (BIP340)、Taproot (BIP314)、Tapscript (BIP342)、および SegWit (BIP141) が含まれます。

第三ステップ、BRC20 トークンの識別はインデクサーによって管理されるオフチェーン状態に関連しています。これらのインデクサーは、過去の取引に基づいて BRC20 トークンの状態を解析し、解釈します。彼らはオンチェーンデータを解析し、トークンの状態を確認し、残高を更新して、情報が最新であることを保証します。さらに、軽量クライアントはこれらの情報を統合し、ユーザーが自分の BRC20 トークンをシームレスに識別し、管理できるようにします。

画像1. BRC20 トークンの重要なステップ

ここで、展開と鋳造操作は1回の取引で済みますが、BRC20 トークンの移転（すなわち transfer 操作）には2回の取引が必要です。最初の取引では、送信者に基本的な要求のオンチェーン刻印が行われ、これは鋳造操作と非常に似ています。2回目の取引では、別の取引が送信者から受信者への移転を完了します。その後、オフチェーンインデクサーが状態を更新します。条件が満たされると、インデクサーは送信者の残高から相応の金額を差し引き、受信者の残高に記録します。

私たちは、Schnorr 署名がビットコインの Taproot アップグレードに使用され、ビットコイン取引のプライバシーと効率を向上させたことを観察できます。アップグレードされた Schnorr マルチシグ（MuSig2）は、Taproot アップグレードの一部に非常に直感的かつ自然に統合され、銘文や BRC20 のような作成プロセスに自然に接続されます。新しくアップグレードされた銘文は、既存の基盤の上に署名と検証の速度を向上させ、鋳造プロセスで必要な取引手数料をさらに削減します。

別の応用はオフチェーンインデクサー部分から来ています。現行のインデクサーは本質的にチェーン外の検証者であり、異なるサービスプロバイダーがそれぞれのインデクサー更新サービスを提供しています。ここで生じるリスクは信頼性の欠如に起因し、多くのサイドチェーンや Rollup サービスプロバイダーと同様に、ユーザーは相対的に管理が中央集権的なサービスプロバイダーを信頼できません。これらのインデクサーがユーザーの天然資金を保存していなくても、誤った見積もりや遅延した見積もりはユーザーの取引失敗を引き起こす可能性があります。MuSig2 はマルチシグの考え方を提供します。相対的に分散された多数の検証者が同じインデクサーを共同で維持し、特定のノードで共同検証を行い、チェックポイントメカニズムのように署名します。ユーザーは少なくとも、チェックポイント前のインデクサーが誠実かつ信頼できる方法でオンチェーン銘文と取引フローを提出したことを信頼できます。こうして、MuSig2 はオフチェーンインデクサーに必要な安全性を提供し、全体的な銘文エコシステムの信頼性を高めます。

ビットコイン質押

イーサリアムなどの PoS チェーンにはネイティブな質押メカニズムがあるのに対し、ビットコインは PoW コンセンサスメカニズムによって維持されるブロックチェーンであり、追加のメカニズムを通じて質押機能を実現する必要があります。現在、最も広く知られているのは Babylon が提案したビットコイン質押スキームです。

Babylon 質押メカニズムでは、ユーザーは Babylon が定義した BTC 質押スクリプトを通じて質押を完了し、質押取引を生成します。質押出力は Taproot 出力であり、内部鍵は NUMS 点を無効にするように設定され、質押機能を実現するための3つの利用可能なスクリプトパスがあります。それぞれは：

· タイムロックパス：質押のロック機能を実現します；

· アンロックパス：質押を早期に終了する機能を実現します；

· 罰則パス：悪行時のシステムの罰機能を実現します。

ビットコイン質押メカニズムはビットコイン保有者に比較的安全な利息生成スキームを提供し、ビットコイン資産の有用性を向上させます。しかし、この質押はある程度ビットコインの流動性を損ないます。しかし、イーサリアムの質押メカニズムの多年にわたる探求はビットコイン質押の道を開き、流動性質押を使用してこの問題を解決できます。

流動性質押は新しい役割、すなわち資産の保管者を導入します。ユーザーは流動性質押プロジェクトの保管アドレスに資産を預け、対応する割合の流動性質押トークン（Liquid Staking Token, LST）を取得します。流動性質押プロジェクトは収集した資産をネイティブに質押し、LST の保有者は自動的に質押収益を共有します。さらに、LST の保有者は二次市場で LST を直接取引したり、LST を燃焼してネイティブな質押資産と交換したりできます。

イーサリアム上の流動性質押はスマートコントラクトを通じて実現できます。しかし、ビットコインは流動性質押を実現するために必要な契約能力が不足しており、UTXO アーキテクチャも LST の任意額引き出し機能にうまく対応できません。現在、OP_CAT などの契約オペコードが未実装であり、ビットコイン取引出力の将来の使用方法に対する制限を効果的に実施できません。したがって、ビットコインの流動性質押を実現するために MuSig2 が必要です。

図2に示すように、Chakra の流動性質押では、ユーザーは最初にビットコインを MuSig2 に対応したマルチシグアドレスに転送します。このイベントはインデクサーによってキャッチされ、オンチェーン契約が呼び出され、ユーザーのために ckrBTC が鋳造されます。マルチシグアドレス内のビットコインは Babylon に質押されます。ユーザーは ckrBTC を保有しながら、Babylon の質押収益を継続的に得ることができます。ユーザーが質押を終了したい場合、ckrBTC を燃焼し、インデクサーが燃焼イベントを検出すると、アンロック操作が行われ、ビットコインがユーザーに返還されます。さらに、ユーザーは二次市場で直接取引し、ckrBTC をビットコインに交換することもできます。

図2. Chakra 流動性質押プロセス

自己保管質押と比較して、MuSig2 に対応した流動性質押は、複数の参加者がデジタル資産保管の安全性を維持し、同時に質押ビットコインの流動性を解放し、LST が BTCFi でより大きな役割を果たすことを可能にし、ユーザーにより多くの利益を提供します。

BitVM コサイン

Robin Linus は 2023 年 10 月に BitVM: Compute Anything on Bitcoin のホワイトペーパーを発表し、Lamport のワンタイム署名を使用して状態を持つビットコインスクリプトを実現しました。このシステムは、新しいオペコードを導入することなく、楽観的なチャレンジメカニズムを通じてチューリング完全なビットコイン契約を実現します。このシステムは OPBOOLAND と OPNOT オペコードを使用して構築された NAND ゲートのバイナリ回路を使用し、ビットコイン上で任意の計算を検証するチャレンジメカニズムを示していますが、プログラムがコンパイルする回路の規模は非常に大きく、実際の応用にはほとんど適用できません。その後、BitVM1 は RISC-V 命令を使用してプログラムを表現し、ビットコインシステム内のすべてのオペコードを最大限に活用して効率を向上させました。

BitVM2 は BitVM1 に対して2つの側面で拡張を行いました。（1）BitVM1 ではチャレンジャーは初期設定に参加したアライアンスメンバーですが、BitVM2 ではチャレンジャーは任意の参加者です。したがって、BitVM1 ではアライアンスメンバーが共謀して悪行を行うリスクがありますが、BitVM2 のチャレンジャーはパーミッションレスであり、アライアンスメンバーは共謀して悪行を行うことができません。（2）BitVM1 では複数回のチャレンジが必要で、周期が長いのに対し、BitVM2 は ZK プルーフの簡潔さと Taptree のスクリプト表現能力を最大限に活用し、チャレンジ周期をわずか2回に短縮し、ペグイン時に必要な事前署名の取引数を約100件から約10件に削減しました。具体的には、BitVM1 では二分法を使用して多くのラウンドのインタラクションを経て、プログラム内の誤った実行の RISC-V 命令を見つける必要がありますが、BitVM2 ではプログラム自体を検証するのではなく、プログラムが正しく実行されたことを検証する ZK プルーフを検証します。BitVM2 は ZK 検証アルゴリズムを複数のサブ関数に分割し、各サブ関数は1つの Tapleaf に対応します。チャレンジを受けた場合、オペレーターは各サブ関数の値を明らかにする必要があり、一致しない場合は誰でも Disprove 取引を発起して罰を与えることができます。

図3に示すように、BitVM2 では大量の n-of-n 事前署名が必要です。ユーザーはどのオペレーターがその費用を立て替えるかを知らないため、ペグイン取引を開始する前に、BitVM アライアンスは Take1、Take2、Assert、Disprove、Burn の5つの取引に対して n-of-n 事前署名を行う必要があります。ユーザーは各子取引の事前署名が完了したことを確認してから、資金を実際に n-of-n マルチシグ制御アドレスにペグイン取引を通じて預け入れます。ユーザーが出金したい場合、ペグアウト取引を開始し、その際に1人のオペレーターが立て替えれば出金が完了します。

オペレーターは2 BTC を質押する必要があり、立て替えたビットコインを返済できます。誰もチャレンジしなければ、オペレーターは Take1 取引を通じて成功裏に返済できます。オペレーターが悪行を行った場合、誰でも1 BTC をクラウドファンディングした後にチャレンジを発起できます。チャレンジに直面した場合、オペレーターが応答しない場合は Burn 取引を実行し、1.9 BTC を破棄し、残りの0.1 BTC を Burn 取引内の受取アドレスに送ります。オペレーターが応答する場合は Assert 取引を実行します。

· 状況1：あるサブ関数の値の開示が一致しない場合、誰でも Disprove 取引を発起でき、1 BTC を破棄し、1 BTC を Disprove 取引内の受取アドレスに送ります。

· 状況2：サブ関数の値の開示が一致する場合、2週間後にオペレーターは Take2 取引を通じて成功裏に返済できます。

図3. BitVM 2 プロセス

BitVM2 システムでは、BitVM アライアンスが Take1、Take2、Assert、Disprove、Burn の5つの取引に対して n-of-n 事前署名を行う必要があります。BitVM の信頼仮定は1-of-nであり、n 値が大きくなるほど信頼仮定は低くなります。しかし、このような大規模なマルチシグは非常に高い手数料を必要とし、ビットコイン上ではほぼ実行不可能です。MuSig2 は大量のマルチシグを1つの署名に集約し、手数料を最低限に抑え、理論的には n 値を無限大にサポートし、具体的には実際に調整可能なコサイナーの数に依存します。n 値は1000やそれ以上になる可能性があります。

BitVM の展開時には、BitVM アライアンスが n-of-n マルチシグによる共謀支出を防ぐために、ペグイン設定が完了した後、n 人のコサイナーのうち少なくとも1人が秘密鍵を削除することが求められます。これにより、BitVM ブリッジ内の資金はオペレーターが誠実に立て替えた後、返済取引を使用してのみ支出できるようになります。したがって、BitVM ブリッジの安全性が向上します。

デジタル資産の保管

集約署名は複数の署名を組み合わせて1つの署名を生成し、検証プロセスを簡素化し、効率を向上させます。図4に示すように、アリスは完全な秘密鍵 KeyA を使用して署名 SigA を生成し、ボブは完全な秘密鍵 KeyB を使用して完全な署名 SigB を生成します。次に、SigA と SigB を集約して集約署名 AggSig を生成します。この方法は、各参加者の独立性と責任を確保するだけでなく、全体のシステムの安全性を強化します。なぜなら、いかなる権限操作も両者の参加が必要だからです。この協力を通じて、アリスとボブはより安全で効率的なデジタル資産管理を実現し、単一障害点や悪意のある操作を防ぎ、取引の複雑さと検証コストを簡素化します。

一方、アリスが閾値署名を使用して分散型デバイスでデジタル署名を生成および管理し、いかなる単一デバイスも完全な署名能力を持たない場合、具体的には、閾値署名スキームは秘密鍵をいくつかの部分に分割し、各デバイスが1つの部分を保存します。一定数のデバイス（すなわち閾値に達する）だけが協力することで、有効な署名を生成できます。このメカニズムはデジタル資産の安全性を大幅に向上させます。なぜなら、部分的な秘密鍵の断片が漏洩しても、攻撃者は有効な署名を生成できないからです。さらに、閾値署名は単一障害点を防ぎ、システムの堅牢性と持続性を確保します。したがって、閾値署名は分散型のデジタル資産管理に高効率で安全なソリューションを提供します。

図4. 集約署名、閾値署名

アリスとボブがそれぞれのデジタル資産を閾値署名で管理し、特定の取引に対して集約署名（MuSig2）を使用する必要がある場合、上記の銘文、ビットコイン質押、BitVM コサインなどのアプリケーションが含まれます。この場合、集約署名と閾値署名を組み合わせて、一魚多食を実現する必要があります。

図5. 集約署名と閾値署名の結合

図5に示すように、アリスとボブが閾値署名を使用してデジタル資産を保管する場合、完全な秘密鍵 KeyA と KeyB は現れず、対応する秘密鍵の断片のみが現れます。それぞれ (ShareA1, ShareA2, ShareA3) と (ShareB1, ShareB2, ShareB3) です。この時、秘密鍵の断片 (ShareA1, ShareA2, ShareA3) と (ShareB1, ShareB2, ShareB3) に基づいて閾値署名をそれぞれ実行し、署名 SigA と署名 SigB を生成します。次に、署名 SigA と署名 SigB を集約して集約署名 AggSig を生成します。この全プロセスにおいて、完全な秘密鍵 KeyA と KeyB は現れません。したがって、閾値署名と集約署名を結合し、複数のアプリケーションニーズを同時に満たすことができます。