原題: BIP-327 MuSig2 の 4 つのアプリケーション: 碑文、ビットコイン再ステーキング、BitVM 共同署名、およびデジタル資産保管

元のリンク: https://blog.bitlayer.org/BIP-327_MuSig2_in_Four_Applications/

著者: Qin Wang (CSIRO)、Cynic (Chakra)、mutourend (Bitlayer)、lynndell (Bitlayer)

この記事では、最も人気のある 4 つの分野 (登録、再ステーキング、BitVM 共同署名、カストディ) における BIP-327 MuSig2 マルチ署名プロトコルのアプリケーションを紹介します。

1 はじめに

既存のビットコイン トランザクションは CheckMultiSig を使用して n-of-n マルチシグを検証するため、トランザクションの署名者の数に比例してビットコイン ブロックチェーン上に署名と公開キーを公開する必要があります。この方法では、取引参加者の総数が明らかになるだけでなく、署名者の数に応じて取引手数料が増加することも明らかになります。この問題を解決するために、2018 年に研究者らは Schnorr マルチ署名プロトコル Musig を提案しました。ただし、このプロトコルは署名者間で 3 ラウンドの通信を必要とし、ユーザー エクスペリエンスが比較的劣るため、このプロトコルは広く注目され、応用されることはありません。

2020 年、MuSig2 のリリースにより、インタラクティブ署名は大幅な進歩を遂げ、3 ラウンドのコミュニケーションが 2 ラウンドに減り、ユーザーにより良いエクスペリエンスがもたらされました。さらに、MuSig2 を使用すると、ユーザーのグループがトランザクションを検証するための単一の署名と公開キーを共同で生成できるため、プライバシーが向上し、トランザクション手数料が大幅に削減されます。 3 年以上の継続的な改善を経て、Schnorr マルチ署名 (MuSig2) がウォレットとデバイスに実装されました。

MuSig2 関連の提案は次のとおりです。

● 2022 年のビットコイン BIP-327: BIP340 互換のマルチ署名用 MuSig2

● 最近https://github.com/achow101/bips/commits/musig2/ 、ビットコイン BIP ライブラリに統合されました。

Bitlayer と Chakra の研究チームは、碑文、ビットコイン プレッジ、BitVM、デジタル資産保管の普及により、理論上は無制限の数の署名者がトランザクションに参加できるため、BIP-327 MuSig2 には大きな応用可能性があり、コストを節約できることを発見しました。 -チェーンスペースと手数料の削減、セキュリティ、プライバシー、操作性の向上など。

インスクリプション:インスクリプションは、カスタマイズされたコンテンツをビットコインに書き込み、インスクリプションを行うサトシです。この概念は、不変かつ検証可能な情報記録をブロックチェーン上に直接作成できるため、広く注目を集めています。碑文は単純なテキストから複雑なデータ構造まで多岐にわたり、デジタル資産の信頼性と出所を認証するための信頼できる方法を提供します。ブロックチェーン記述の永続性とセキュリティにより、デジタル ID 検証、所有権の証明、重要な情報のタイムスタンプなどのアプリケーションで非常に価値があります。碑文の場合、MuSig2 は署名と検証の速度を向上させ、キャスティング プロセスに必要な取引手数料を削減し、オフチェーン インデクサーに必要なセキュリティを提供することで、碑文エコシステム全体の信頼性を向上させることができます。

ビットコインステーキング：ビットコイン保有者が、さまざまなブロックチェーンプロトコルや分散型金融（DeFi）アプリケーションをサポートするために、約束した資産を再割り当てするためのメカニズム。このプロセスにより、ビットコインはブロックチェーンエコシステム内で複数の役割を果たすことができ、その有用性と収益の可能性が高まります。ヘビーステーキングに参加することで、ユーザーはビットコインの保有を維持しながら、他のネットワークのセキュリティと機能に貢献できます。この革新的なアプローチは、ビットコインの流動性とセキュリティを活用して、より統合された効率的なブロックチェーン経済を推進します。それは、ビットコインには流動性ステーキングを実現するために必要な契約機能が欠けており、UTXO 構造は、どのような額面の担保トークンの引き出し機能とも十分に互換性がないためです。したがって、ビットコインの流動性ステーキングを実装するには MuSig2 が必要です。

BitVM:ビットコイン ネットワーク上にスマート コントラクト機能を実装するためのフレームワーク。複雑なスマート コントラクトをネイティブにサポートするイーサリアム仮想マシン (EVM) とは異なり、BitVM はビットコインのスクリプト機能を拡張して、より複雑なプログラム可能なトランザクションを可能にするように設計されています。この開発により、ビットコインの分散型アプリケーション (dApps) と複雑な金融アプリケーションに新たな道が開かれ、その単純なスクリプト言語の限界が打ち破られます。 BitVM の導入は、ビットコインと他のより柔軟なスマート コントラクト プラットフォームとの間に架け橋を構築する、ビットコインのユーティリティにおける重要な進化を示しています。 BitVM ではソフト フォークを必要とせずに事前署名が必要で、1/n の信頼仮定と許可のないチャレンジ機能が有効になります。信頼の仮定をできるだけ小さくするには、n の値をできるだけ大きくする必要があります。しかし、大規模なマルチ署名を検証する既存の CheckMultiSig スクリプトでは、非常に高額なトランザクション手数料が必要となるため、実行不可能です。 MuSig2 は n の値を可能な限り大きくできるため、n の値はビットコインのブロックとスタック サイズの制限によって制限されず、調整できる実際の連署者の数に依存し、コストが低くなります。

デジタル資産の保管:ブロックチェーンを使用して、暗号通貨、NFT (代替不可能なトークン)、その他のトークン化された資産などのデジタル資産を安全に保管および管理します。これには、秘密キーの保護、アクセス制御の確保、サイバー脅威に対する保護の提供が含まれます。しきい値署名は、デジタル資産のセキュリティ管理において重要な役割を果たし、暗号化キーを分散して管理します。この手法では、秘密キーを複数の共有に分割し、異なる参加者に配布します。取引に署名したり、デジタル資産にアクセスするには、事前に設定されたしきい値の株式を組み合わせて、単一の当事者が一方的に資産を制御したり悪用したりできないようにする必要があります。これにより、鍵の侵害、内部関係者の脅威、単一障害点のリスクが軽減され、セキュリティが強化されます。さらに、しきい値署名はデジタル資産管理のためのより堅牢で柔軟なガバナンス モデルを提供し、分散型組織や複数パーティ システムでの安全なコラボレーションと意思決定を可能にします。しきい値署名と MuSig2 を組み合わせることで、碑文、ビットコイン誓約、BitVM 共同署名、デジタル資産保管などのアプリケーションのニーズを同時に満たし、1 つの魚から 4 つのメリットを実現できます。

2. MuSig2の原理と実装仕様

2.1 MuSig2 の原理

2.2 MuSig2実装仕様

最近、Bitcoin Core の貢献者 Andy Chow はいくつかの BIP 提案を提案しました。

● BIP-328: MuSig2 集約キーの導出スキーム[アプリケーション層]: BIP 327 MuSig2 集約公開キーに基づいて BIP 32 拡張公開キーを構築し、これらの BIP 32 拡張公開キーをキー導出に使用する方法について説明します。

● BIP-373: MuSig2 PSBT フィールド[アプリケーション層]: BIP174 部分署名ビットコイン トランザクション (PSBT) に乱数、公開キー、部分署名用のフィールドを追加しました。

● BIP-390: musig() 記述子キー式[アプリケーション層]: MuSig2 ウォレットによって制御されるトランザクション出力のメソッドを提供します。

これは、MuSig2 の導入とウォレットの統合に必要なステップです。 MuSig2 ウォレットを統合するために必要なのは、これらの BIP と仕様だけです。さらに、多くのウォレット開発者と共同ホスティング ソリューション ( 「Taproot をマルチシグに対応させる」を参照) は長い間、MuSig2 プロトコルの標準化を要求してきました。現在、正式な BIP が整備されているため、コミュニティはそれを自らレビューし、フィードバックを提供し、意識を高めることができます。

3. MuSig2 は 4 匹の魚を食べます。

3.1 碑文

碑文の最も典型的な用途は、ビットコイン上の NFT トークンとみなせる BRC20 を構築することです。その中心となる設計は、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 埋め込みには、BRC20 トークンをデプロイするための主要なパラメーターが含まれています。プロトコルは「brc-20」、操作タイプは「deployment」、トークンシンボルは「ordi」、最大供給量は 2,100 万、鋳造制限は 1,000 に設定されています。ここで、このプロセスをサポートする主要な BIP には、Schnorr Signature (BIP340)、Taproot (BIP314)、Tapscript (BIP342)、および SegWit (BIP141) が含まれます。

3 番目のステップである BRC20 トークンの識別には、インデクサーによって管理されるオフチェーン状態が含まれます。これらのインデクサーは、履歴トランザクションに基づいて BRC20 トークンのステータスを解析して解釈します。オンチェーン データを解析し、トークンのステータスをチェックし、残高を更新して情報が最新であることを確認します。さらに、ライト クライアントはこの情報を統合して、ユーザーが BRC20 トークンをシームレスに識別して管理できるようにします。

図 1. BRC20 トークンの主な手順

ここで、デプロイメントおよびミント操作には 1 つのトランザクションのみが必要ですが、BRC20 トークンの転送 (つまり、転送操作) には 2 つのトランザクションが必要です。最初のトランザクションでは、基本的に必要なオンチェーン書き込みが送信者に対して実行されます。これはミント操作と非常によく似ています。 2 番目のトランザクションでは、別のトランザクションが送信者から受信者への転送を完了します。次に、オフチェーン インデクサーが状態を更新します。条件が満たされる場合、インデクサーは送信者の残高から対応する金額を差し引き、受信者の残高に入金します。

Schnorr 署名がビットコインの Taproot アップグレードに使用され、ビットコイン取引のプライバシーと効率が向上していることがわかります。 Schnorr マルチ署名 (MuSig2) のアップグレード バージョンは、Taproot のアップグレードされた部分に非常に直感的かつ自然に統合でき、碑文や BRC20 などの作成プロセスと自然に接続できます。新たにアップグレードされた刻印により、既存のベースに基づいて署名と検証の速度が向上し、鋳造プロセスに必要な取引手数料がさらに削減されます。

別のアプリケーションはオフチェーン インデクサー部分から来ます。現在のインデクサーは本質的にオフチェーン検証ツールであり、さまざまなサービス プロバイダーが独自のインデクサー更新サービスを提供しています。ここで生じるリスクは、多くのサイドチェーンやロールアップサービスプロバイダーと同様に、比較的集中管理されているサービスプロバイダーを信頼できないことから生じます。これらのインデクサーはユーザーの自然資金を保管していませんが、見積もりが間違っていたり、見積もりが遅れたりすると、ユーザーのトランザクションが失敗する原因になります。 MuSig2 はマルチサインのアイデアを提供します。比較的分散化された多数の検証器を導入して、チェックポイント メカニズムと同様に、同じインデクサーを共同で維持し、毎回特定のノードで署名を共同で検証して署名することができます。ユーザーは少なくとも、インデックスがオンチェーンの書き込みとトランザクション フローを正直かつ確実に送信する前のインデクサーを信頼できます。このようにして、MuSig2 はオフチェーン インデクサーに必要なセキュリティを提供し、全体的な碑文エコロジーの信頼性を向上させます。

3.2 ビットコインの誓約

ネイティブの誓約メカニズムを備えたイーサリアムなどの PoS チェーンとは異なり、ビットコインは PoW コンセンサスメカニズムによって維持されるブロックチェーンであり、誓約機能を実装するには追加のメカニズムが必要です。現在、最もよく知られているのは、Babylon によって提案されたビットコイン ステーキング ソリューションです。

Babylon プレッジ メカニズムでは、ユーザーは Babylon によって定義された BTC プレッジ スクリプトを通じてプレッジを完了します。これはプレッジ トランザクションと呼ばれ、プレッジ出力を生成します。ステーキング出力は Taproot 出力で、内部キーは NUMS ポイントに設定すると無効になります。また、ステーキング機能を実装するために使用できるスクリプト パスが 3 つあります。彼らです：

● タイムロックパス: 誓約のロックアップ機能を実現します。

● 誓約解除パス: 誓約を早期に終了する機能を実現します。

● 罰パス: 悪事を行った場合のシステムの罰機能を実現します。

ビットコイン プレッジ メカニズムは、ビットコイン保有者により安全な利息獲得ソリューションを提供し、ビットコイン資産の有用性を高めます。ただし、このステーキングはビットコインの流動性をある程度損ないます。しかし、長年にわたるイーサリアムステーキングメカニズムの探求により、ビットコインステーキングへの道が開かれ、流動性ステーキングを使用してこの問題を解決できます。

流動性ステーキングでは、資産の保管者という新しい役割が導入されます。ユーザーは流動性ステーキング プロジェクトの保管アドレスに資産を預け、対応する割合のリキッド ステーキング トークン (LST) を取得します。流動性ステーキング プロジェクトは収集された資産をネイティブに担保し、LST 保有者はステーキング収入を自動的に共有します。さらに、LST 保有者は流通市場で LST を直接取引したり、ネイティブの質入れ資産と引き換えに LST を燃やすことができます。

イーサリアムの流動性ステーキングは、スマートコントラクトを通じて実装できます。ただし、ビットコインには流動性ステーキングの実装に必要な契約機能が欠けており、UTXO アーキテクチャはあらゆる額面の LST の出金機能と互換性がありません。現在、OP_CAT などのコントラクト オペコードはオンラインではないため、ビットコイン トランザクションの出力が将来どのように使用されるかについて制限を効果的に強制する方法はありません。したがって、ビットコイン流動性ステーキングを実装するには MuSig2 が必要です。

図 2 に示すように、Chakra 流動性ステーキングでは、ユーザーはまず MuSig2 を利用したマルチシグネチャ アドレスにビットコインを転送します。イベントはインデクサーによってキャプチャされ、オンチェーン コントラクトが呼び出されて、ユーザーのために ccrBTC を作成します。マルチ署名アドレス内のビットコインはバビロンに預けられます。 crrBTCを保有している間、ユーザーはバビロンステーキングからのリターンを引き続き受け取ることもできます。ユーザーがプレッジを終了したい場合は、crrBTC を破棄できます。インデクサーが破棄イベントを検出すると、プレッジ解除操作が実行され、ビットコインがユーザーに返されます。さらに、ユーザーは流通市場で直接取引して crrBTC をビットコインに交換することもできます。

図 2. Chakra 流動性ステーキング プロセス

セルフカストディステーキングと比較して、MuSig2 がサポートする流動性ステーキングでは、デジタル資産カストディの安全性を維持するために複数の当事者が導入され、同時に担保されたビットコインの流動性が解放されるため、LST は BTCFi においてより大きな役割を果たすことができ、ユーザーに大きな役割を提供します。さらに多くのメリットがあります。

3.3 BitVM 余符号

Robin Linus は、Lamport ワンタイム署名を使用してステートフル ビットコイン スクリプトを実装する、 「BitVM: Compute Anything on Bitcoin」ホワイト ペーパーを 2023 年 10 月にリリースしました。このシステムは、新しいオペコードなどのソフトフォークを導入することなく、オプティミスティックチャレンジメカニズムを通じてチューリング完全なビットコインコントラクトを実装できます。このシステムは、OP_BOOLAND および OP_NOT オペレーション コードで構築された NAND ゲート バイナリ回路のみを使用し、ビットコイン上の任意の計算を検証するチャレンジ メカニズムを実証します。しかし、プログラムでコンパイルされた回路は大規模であり、実用的ではありません。その後、 BitVM1 はRISC-V 命令を使用してプログラムを表現し、ビットコイン システムのすべてのオペコードを最大限に活用して効率を向上させます。

BitVM2 は、 2 つの側面で BitVM1 を拡張します。 (1) BitVM1 のチャレンジャーは初期設定に参加したアライアンス メンバーですが、BitVM2 のチャレンジャーは任意の参加者です。したがって、BitVM1 の同盟メンバーは悪を行うために共謀する危険にさらされていますが、BitVM2 の挑戦者には許可がなく、同盟メンバーが悪を行うために共謀することはできません。 (2) BitVM1 は複数ラウンドのチャレンジを必要とし、サイクルが長いのに対し、BitVM2 は ZK Proof のシンプルさと Taptree のスクリプト表現能力を最大限に活用し、チャレンジサイクルは 2 ラウンドのみで、事前署名されたトランザクションの数も少なくなります。ペグインに必要なトランザクションが約 100 トランザクションから約 10 トランザクションに減少します。具体的には、BitVM1 は二分法を使用して、複数ラウンドの対話後にプログラム内で誤って実行された RISC-V 命令を見つける必要があります。一方、BitVM2 は、それがプログラム自体ではなく、プログラムが正しく実行されることを検証する ZK 証明であることを検証します。 BitVM2 は検証アルゴリズムを複数のサブ関数に分割し、各サブ関数が Tapleaf に対応します。異議が申し立てられた場合、オペレーターは各サブ機能の値を明らかにする必要があります。矛盾がある場合は、誰でもそれを罰するために反証トランザクションを開始できます。

図 3 に示すように、BitVM2 は多数の n-of-n 事前署名を必要とします。ユーザーは、どのオペレーターが自分の代わりに支払いを前払いしてくれるのかわからないため、ペグイントランザクションを開始する前に、BitVM Alliance は Take1、Take2、Assert、Disprove、Burn の n-of-n トランザクションに事前署名する必要があります。各子孫トランザクションの事前署名が完了したことをユーザーが確認した後でのみ、資金はペグイン トランザクションを通じて n-of-n マルチ署名制御アドレスに実際に入金されます。ユーザーがお金を引き出したい場合、ペグアウト取引を開始することができ、オペレーターの 1 人が支払いを前払いし、引き出しを完了することができます。

オペレーターは、アドバンスト ビットコインを返済する前に 2 BTC を誓約する必要があります。誰も異議を申し立てない場合、オペレーターは Take1 トランザクションを通じて正常に払い戻すことができます。オペレーターが悪事を行った場合、クラウドファンディングで 1 BTC を調達すれば、誰でもチャレンジを開始できます。チャレンジに直面して、オペレーターが応答しない場合、書き込みトランザクションが実行されます。つまり、1.9 BTC が破棄され、オペレーターが応答した場合、残りの 0.1 BTC が書き込みトランザクションの受信アドレスに与えられます。実行されました。

● ケース 1: 特定のサブ関数値が矛盾して公開された場合、誰でも反証トランザクションを開始できます。つまり、1 BTC が破棄され、反証トランザクションの受信アドレスに 1 BTC が与えられます。

● ケース 2: サブ関数の値が一貫して明らかになった場合、オペレーターは 2 週間後に Take2 トランザクションを通じて正常に払い戻される可能性があります。

図 3. BitVM 2 プロセス

BitVM2 システムでは、BitVM Alliance が n-of-n トランザクション (Take1、Take2、Assert、Disprove、Burn) に事前署名する必要があります。 BitVM の信頼仮定は 1-of-n であり、n の値が大きいほど信頼の仮定は低くなります。しかし、このような大規模なマルチ署名には非常に高額な手数料が必要となるため、ビットコインではほとんど実現不可能です。 MuSig2 は、多数のマルチ署名を 1 つの署名に集約して、手数料を最小限に抑えることができ、理論的には、調整できる実際の連署者の数に応じて、n 値 1,000 以上など、無限の 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. 集約された署名、しきい値署名

図 4. 集約された署名、しきい値署名

アリスとボブの両方がしきい値署名を使用してそれぞれのデジタル資産を管理し、集合署名 (MuSig2) を使用してトランザクション (前述の碑文、ビットコイン誓約、BitVM 共同署名、その他のアプリケーションなど) に複数署名する必要がある場合。この場合、複数の魚を達成するには、集約シグネチャとしきい値シグネチャを組み合わせる必要があります。

図 5. 集約署名としきい値署名の結合

図 5 に示すように、アリスとボブがデジタル資産の保管にしきい値署名を使用すると、完全な秘密鍵 KeyA も KeyB も表示されず、対応する秘密鍵のフラグメント (ShareA1、ShareA2、ShareA3) および (ShareB1、シェアB2、シェアB3）。このとき、秘密鍵シャード (ShareA1、ShareA2、ShareA3) および (ShareB1、ShareB2、ShareB3) に基づいてしきい値署名が実行され、それぞれ署名 SigA と署名 SigB が生成されます。次に、署名 SigA と署名 SigB が集約されて、集約署名 AggSig が生成されます。プロセス全体を通じて、完全な秘密キー KeyA と KeyB は表示されません。したがって、しきい値署名と集約署名の組み合わせは、複数のアプリケーション要件を同時に満たすために実現されます。

参考文献