HTX Venture：ビットコインのプログラマビリティという視点からBTCFIのラビットホールを探る
TechFlow厳選深潮セレクト
HTX Venture：ビットコインのプログラマビリティという視点からBTCFIのラビットホールを探る
Babylonステーキングプロトコルなどの新規アプリケーションの登場や、Fractal BitcoinなどのUTXOネイティブなネイティブスケーリング方式の導入により、BTCFI市場の潜在的可能性が次第に明らかになりつつある。
Web3業界の深掘り報道に専念し潮流を洞察
要約
本稿はビットコインのプログラミング可能性とその進化経路から出発し、分散型金融（BTCFI）分野におけるビットコインの潜在能力と課題を体系的に検討している。アーキテクチャ上、ビットコインはUTXOモデルを採用しており、独自のスクリプト言語とオペコードを通じて「検証」を中心とするコントラクト体系を形成している。イーサリアムのスマートコントラクトと比較すると、ビットコインのコントラクトは「ステートレス」「非計算可能」という特徴があり、機能面では制限がある一方で、より高い安全性と分散性を持つ。
Taprootアップグレードの実施により、ビットコインのコントラクト能力は著しく強化された。特にMASTおよびSchnorr署名の導入によって、より複雑なコントラクトロジックが可能になり、プライバシー性と取引効率も大幅に向上した。これらの技術革新は、BTCFIのさらなる発展の道を切り拓き、ビットコインが従来の分散化の優位性を維持しつつ、より多様な金融応用シナリオを探求することを可能にしている。
この基盤の上に、本稿はビットコインのプログラミングがどのように多様なBTCFIアプリケーションを支えるかを深く分析している。マルチシグネチャ、タイムロック、ハッシュロックなどのメカニズムの解説、DLC、PSBT、MuSig2などのツールの応用について述べることで、信頼不要の条件下で分散型決済や複雑な金融契約を実現する可能性を示している。このようなビットコインネットワーク原生の分散型金融システムは、WBTC時代のクロスチェーンブリッジ方式が抱える中央集権的リスクを克服し、ビットコイン保有者にさらに堅固な信頼基盤を提供する。
最後に、本稿はBTCFIの発展は単なる技術的進歩ではなく、エコシステム構造の深い変革であると強調している。Babylonステーキングプロトコルのような新規アプリケーションや、Fractal BitcoinのようなUTXOベースのネイティブスケーリング方式の登場により、BTCFIの市場ポテンシャルが徐々に明らかになりつつある。今後、ビットコイン価格の上昇とともに、BTCFIは主流ユーザーの参加をさらに引き寄せ、「ビットコイン中心」の新たな金融エコシステムを形成していくだろう。そしてこのエコシステムの形成は、「デジタルゴールド」という物語を超えて、ビットコインを世界経済において不可欠な分散型金融インフラへと進化させる。
序論
2022年12月にOrdinalsプロトコルが登場して以降、BRC-20、Atomicals、Pipe、Runesなど数十種類の資産発行プロトコルや数百のビットコインLayer 2ネットワークが相次いで出現し、コミュニティ内でもビットコイン分散型金融（BTCFI）の実現可能性について活発な議論が行われている。
前回の暗号資産サイクルでは、DeFiに参加したいビットコイン保有者を惹きつけるために、WBTCが登場した。WBTCは中央集権的な託管機関がビットコインを預かり、それをイーサリアム上のDeFiプロトコルで利用できるようにするもので、WBTCのターゲットユーザーは、クロスチェーンブリッジのリスクを受け入れてでもビットコインDeFiに参加したい人々であった。EVMエコシステムへのビットコイン接続を代表する存在として、WBTCはBTCFIの一つの経路を実現した。今回登場したEVM系のビットコインLayer 2ネットワークとそのエコシステム内のDeFiプロジェクトも、このモデルを踏襲している。このモデルは、WBTCがイーサリアムエコシステム内で90億ドル以上の時価総額を達成したものの、ビットコイン全体の時価総額に対しては1%未満であり、その限界性が明らかになっている。
対照的に、もしビットコイン保有者がクロスチェーンでの発行を経ずに直接BTCFIに参加でき、資金の完全な分散型管理が保証されるならば、より多くのビットコインユーザーを惹きつけ、より広大な市場を創出できるだろう。そのためには、UTXO構造下でのビットコインプログラミングが必要となる。イーサリアムDeFiに入る鍵がSolidityの習得であるように、BTCFI市場に入るためにはビットコインプログラミングの習得が必須なのである。
イーサリアムコントラクトとは異なり、ビットコインコントラクトは計算能力を持たず、むしろ一連の署名によってつながれた検証プログラムに近い。当初は応用範囲が限られていたが、ビットコインネットワークの継続的なアップグレードとOGコミュニティの革新により、ビットコインプログラミングの可能性はますます顕在化しており、多くの研究成果が既に実用化間近のBTCFI製品に転換されている。
本稿では、ビットコインのプログラマビリティという視点からBTCFIの発展経路を深く探り、その歴史的・論理的脈絡を整理することで、読者が現在のBTCFIの実際の適用シーンを理解し、それらがビットコイン保有者およびビットコインエコシステム全体にどのような影響を与えるかを明らかにする。
ビットコインコントラクトの基礎
中本聡の思考：UTXO、スクリプト言語、オペコード
2010年、satoshi（中本聡）はBitcoin Talkフォーラムに以下のように投稿した：
-
ビットコインの核心設計はバージョン0.1リリース後に固定されると考えており、可能な限り多くの取引タイプをサポートしたいが、これらはそれぞれ特別なサポートコードとデータフィールドを必要とし、特殊ケースごとに個別対応が必要となり、結局無数の例外が生まれてしまう。
-
この問題を解決する方法が「スクリプト」である。取引の入力・出力側は、ノードネットワークが検証可能な命題（スクリプト言語）として取引をコンパイルできる。ノードはこの命題（スクリプト言語）を検証し、送信者の条件が満たされているか評価する。
-
「スクリプト」というのはただの「命題（predicate）」にすぎない。つまり、真または偽のいずれかになる方程式のことだ。「Predicate」という言葉は長くて珍しいので、私はこれを「スクリプト」と呼ぶことにした。
-
受信者はスクリプトに対してテンプレートマッチングを行う。現在、受信者は2つのテンプレートしか受け入れない：直接支払いとビットコインアドレス。将来のバージョンでは、より多くの取引タイプのテンプレートを追加でき、そのバージョン以降を実行するノードはそれらを受け取れるようになる。ネットワーク内のすべてのノードは、新しい取引を検証・処理し、ブロックに取り込むことができるが、それらの読み方を知らない場合もある。
-
この設計により、私がかつて設計したさまざまな取引タイプ――信託取引、担保契約、第三者仲裁、マルチシグネチャなどが可能になる。ビットコインが人気を得れば、これらは将来的に探求すべき領域になるが、最初期から設計されていなければならない。そうしないと、将来実現できなくなるからだ。
中本聡が14年前に行ったこの設計が、ビットコインプログラミングの基礎を築いた。ビットコインネットワークには「アカウント」という概念はなく、「出力（output）」のみが存在する。正式名称は「取引出力（TXO）」であり、これはビットコイン資金の一単位を表し、ビットコインシステムの状態の基本単位である。
出力を使用するとは、その出力を取引の入力として指定し、当該取引に資金を提供することを意味する。これがまさに「UTXO（未使用取引出力）モデル」に基づくビットコインシステムである理由である。なぜなら、取引で使えるのは「UTXO（未使用取引出力）」だけだからだ。まるで金属塊が溶鉱炉に入り、再び新しい金属塊（新しいUTXO）となって出てくるようなもので、元の金属塊「取引出力（TXO）」は消滅する。
各資金には自身のロックスクリプト（スクリプト公開鍵とも呼ばれる）と額面があり、ビットコインの合意則によれば、スクリプト公開鍵は検証プログラムとして機能する。つまり、公開鍵に特定の操作を実行する命令——オペコードOP-Codes——を組み合わせたものであり、これを解除するには、特定のデータ群すなわちアンロックスクリプト（スクリプト署名、scriptSig）を提供しなければならない。アンロックスクリプトとロックスクリプト、およびOP-Codesを含む完全なスクリプトが有効であれば、対応する出力は「アンロック」され、使用可能になる。
したがって、ビットコインのスクリプトプログラミングとは、資金自体をプログラミングし、特定の金額が特定の入力データに対して反応するようにすることである。スクリプト公開鍵、オペコードOP-Codes、およびユーザー間の相互作用プロセスを設計することで、ビットコインコントラクトの重要な状態遷移に暗号学的な保証を与え、コントラクトの正常履行を確保できる。
ここに、ビットコインの標準的なP2PKH（公開鍵ハッシュへの支払い）スクリプトの簡単な図を示す
仮に小明に1 BTCを支払う場合、自分のウォレット内で利用可能なUTXOを使用して、1億サトシ相当のUTXOを作成し、そのUTXOのロックスクリプトに小明の公開鍵（および署名チェック用オペレータ）を配置する。これにより、小明の秘密鍵による署名のみがこの資金をアンロックできる。
まとめると、Script（スクリプト言語）は非常に基礎的なプログラミング言語であり、二種類のオブジェクトから構成される：データ（公開鍵・署名など）＋データを操作するシンプルな関数（オペコード）。オペコード一覧はこちら参照。
ビットコインプログラミングの武器庫
前述の通り、中本聡は当初からビットコインネットワークがサポートすべき取引タイプとして信託取引、担保契約、第三者仲裁、マルチシグネチャなどを挙げていた。これらを実現する手段は何か？また、それらはどのようにBTCFIに活用されるのか？
マルチシグネチャ（MULTISIG）
- ロックスクリプト形式は M <PUB-1> <PUB-2> ... <PUB-N> N OP_CHECKMULTISIG であり、n個の公開鍵を記録し、そのうちm個の署名を提供することでUTXOをアンロックできる。
- 例：Alice、Bob、Chloeの3人のうち2人が署名すれば資金を使用できる。スクリプトコードは：2 <Alice> <Bob> <Chloe> 3 OP_CHECKMULTISIG。OP_CHECKMULTISIGは、署名が提供された公開鍵と一致するか検証するオペコードである。
- 主な用途：
- 個人・企業の資金管理：2-of-3マルチシグウォレットを設定すれば、2人いれば資金を使える。また、ウォレットメーカーが悪意を持っても、m人の合謀が必要になるため、安全性が高まる。
- 取引仲裁：
- AliceとBobがordinals NFTの購入取引をするが、一手交金一手交貨ができない。そこで、資金をマルチシグ出力にロックし、BobがNFTを受け取った時点でAliceに支払いを行う。代金不払いを防ぐため、第三者を仲裁者として2-of-3マルチシグ出力に組み込む。取引に紛争が生じた場合、第三者が公正を保つ。第三者がAliceの出荷を確認すれば、Aliceと共謀して資金を移動できる。
- 第三者が公開鍵を公開していれば（例えば予言機）、取引当事者は2-of-3マルチシグスクリプトにその公開鍵を使用できる。オンチェーン出力にはスクリプトのハッシュ値のみ記録されるため、仲裁者が知らぬ間に組み込める。ただし、この方式では予言機が契約結果を決定できるリスクがある。後述の慎重日誌契約（DLC）はこの点を改善し、ビットコイン貸付などへの真正な応用が可能になる。
タイムロック
タイムロックは取引の有効性や出力の使用可能時期を制御するもので、リーステーキング、ステーキング、担保貸付といったBTCFIシナリオで頻繁に使用される。開発者は相対タイムロック（nSequence）か絶対タイムロック（nLocktime）を選択する：
- 絶対タイムロック（nLocktime）：特定の時刻以降のみ取引が有効となり、ブロックに取り込まれる。スクリプトレベルではOP_CLTVオペコードを使用。「ブロック高さ400,000以降にのみ使用可能」など。
- 相対タイムロック（nSequence）：入力が生成された取引（先行取引）がブロック確認されてから一定期間後、取引が有効となり、UTXOをアンロックできる。スクリプトレベルではOP_CSVを使用。「ブロック確認後3ブロック経過後にのみ使用可能」など。
ハッシュロック（ハッシュ原像検証）
他にも、ハッシュロック（ハッシュ原像検証）と組み合わせたハッシュタイムロック契約（HTLC）もあり、ビットコインステーキングやリステーキングでよく使われる：
- ハッシュロックのロックスクリプト形式：OP_HASH160 <hash> OP_EQUAL 。アンロックスクリプト内のデータがロックスクリプト内のハッシュ値の原像かどうかを検証。
- ハッシュタイムロック契約（HTLC）：受取人が一定時間内にハッシュ値の原像を提示できない場合、資金は送金者に返還される。
フロー制御（並列アンロック条件）
OP_IFオペコードを使うことで、ロックスクリプト内に複数のアンロックパスを設け、いずれかの条件が満たされればUTXOをアンロックできる。前述のHTLCも、このフロー制御オペコードを利用している。
Taprootアップグレード後、MAST（Merkle化抽象構文木）機能により、異なるアンロックパスを異なるMerkleツリーの葉に配置できるようになり、BabylonのBTCステーキング取引でもMASTが使用され、取引効率とプライバシー性が向上している。詳細は後述。
SIGHASH付き情報署名
ビットコイン取引の署名時にはSIGHASHタグを使用でき、これにより署名の有効性に追加の指定が可能になり、取引の一部を変更しても署名が無効にならないようにできる。これは署名人が署名の用途や委任を明示する手段となる。例：
- SIGHASH_SINGLE | ANYONECANPAY：入力と同インデックス番号の出力のみを署名。他の入力・出力は変更可能で、署名は無効にならない。Andyが1 BTCの入力と100某Runesトークンの出力を署名すれば、誰でも1 BTCと100某Runesトークンの交換取引を完成させ、オンチェーン化できる。
他にも、Taprootアップグレード後のSchnorr署名は慎重日誌契約（DLC）に使用される。
ビットコインプログラマビリティの制限
ビットコインプログラミングの基本パターンは、UTXOのロックスクリプトが検証条件を示し、アンロックスクリプトがデータを提供し、ロックスクリプト内のオペコードがデータの検証手順（署名検証、ハッシュ原像検証など）を定義するというもの。資金が使用可能になるのは検証手順を通過したときであり、主な制限は以下の通り：
- 利用可能な検証手順は限られている：ゼロ知識証明や他の検証手順を実装するにはフォークが必要。Unisatが提案するBTCFI拡張案Fractalは、ビットコインと100%互換だが、OP_CATやZKネイティブ検証用OPCodeなど「議論を呼ぶ」オペコードを実装するために、流動性と安全性の面でビットコインメインネットと部分的に分離している。
- ビットコインスクリプトには計算能力がない：任意のパスで資金をアンロックできれば、その資金は全額使用可能。資金の使用方法はアンロック後には制限できない。これはBTCFI貸付プロジェクトにおいて変動金利が難しく、固定金利しか使えないことを意味する。この問題を解決するため、コミュニティでは「制限条項」（covenants）の導入を議論しており、これにより取引のさらなる使用を制限し、BTCFIの応用範囲を広げられる。Taproot Wizardが提唱するBIP-420やOP_CAT、OP_CTV、APO、OP_VAULTなどもこれに関連する。
- UTXOのアンロック条件は完全に独立している：あるUTXOが、別のUTXOの存在やそのロック条件に基づいて自身のアンロック可否を判断できない。これはBTCFIの担保貸付やステーキングでよく問題となる。後述する部分署名ビットコイン取引（PSBT）がこの問題の解決策となる。
ビットコインコントラクトの調整と進化
計算に基づくイーサリアムコントラクトと比べ、ビットコインコントラクトは検証に基づくものであり、このステートレスな特性はBTCFI製品開発に多くの困難をもたらす。しかし、過去十数年の発展の中で、暗号アルゴリズムや署名の巧妙な応用により、プライバシー性、効率性、分散性が大幅に向上し、製品化可能なBTCFIの実現が可能になった。
慎重日誌契約（DLC）：BTCFIにおける分散型決済問題の解決
貸付、オプション、先物プロトコルが予言機価格に基づきユーザーのポジションを決済する必要がある場合、ユーザー資産の操作権を保持せざるを得ず、ユーザーはプロトコルが悪意を持たないと信じるコストを負うことになる。
この問題を解決するために導入されたのが慎重日誌契約（DLC）であり、これは「アダプタ署名（adaptor signature）」という暗号技術を用いることで、ビットコインスクリプトに外部イベントに依存する金融契約をプログラミングし、十分なプライバシー性を保証できる。
これは2017年にMITのデジタル通貨イニシアチブ（Digital Currency Initiative）のTadge Dryja （研究科学者）とGert-Jaap Glasbergen（ソフトウェア開発者）によって提案され、2018年3月19日に公開デモが行われた。
アダプタ署名は、ある署名が特定の秘密鍵を加えたときにのみ有効な署名になるようにする。Taprootアップグレードで導入されたSchnorr署名が、アダプタ署名の一種である。
簡単に言えば、Schnorr署名の標準形は(R, s)であり、(R, s')が与えられたとき、x（秘密値）を知ればs = s' + xとし、(R, s)を得ることができる。
ここで簡単な例で応用方法を説明する：
- AliceとBobがスポーツ試合の相反する結果に賭け（引き分けなし）、それぞれ1 $BTCを賭ける。予想が当たった方が2 $BTCを獲得する。二人は賭け金をマルチシグウォレットにロックし、マルチシグ署名で資金を解放する。
- 予言機を選ぶ。これは試合結果を公表する（通常、情報源は取引所や公式サイトなどオフチェーンにある）。
- 予言機は賭けに関する詳細を知る必要もなく、誰がDLCに参加しているかも知る必要はない。仕事は結果の提供に限定され、イベント発生後、結果を確定したことを示す暗号的証明（コミットメント）を発表する。
- マルチシグウォレットにロックされた資金を引き出すには、勝者Aliceが予言機が提供する秘密値を使って有効な秘密鍵を作成し、ウォレット資金の支出取引に署名する。
- この取引はビットコインブロックチェーンに追加され決済される。このとき、署名は普通の署名と区別がつかず、DLCであることも分からない。これは一般的なマルチシグパターン――コントラクト内容が完全に公開され、予言機が意思決定に参加する――とは全く異なる。
貸付プロトコルの決済メカニズム
仮にAliceが$ORDIを担保資産として、0.15 $BTCを借り入れる。予言機による$ORDI価格が225,000 sats/ordiを下回った場合、このポジションは決済待ち状態となる。DLCにより、決済人は許可なく決済を行えるが、価格が決済価格に達していないときはユーザーの担保資産を操作できない。上記のシナリオでは、Aliceは貸付プロトコルと$ORDI価格に関して賭けをしていることになる：
- 価格が225,000 sats/ordiを下回った場合、プロトコルはAliceの全担保品を得て、対応するBTC債務を負う。
- 価格が225,000 sats/ordi以上の場合、何も起こらず、資産の帰属関係は変わらない。
そこで、価格が225,000 sats/ordiを下回った場合、予言機がnonce R_cを使って結果の署名s_c_1を発表することが必要になる：
- Aliceとプロトコルは、結果に対してコミット取引を作成し、(R, s)ではなく適応署名(R, s')を作る。つまり、双方が相手に渡す署名はそのままではコントラクトをアンロックできない。秘密値を明らかにしなければならない。この秘密値こそがs_c_1.Gの原像、すなわち予言機の署名である。予言機の署名nonce値はすでに確定しているため、s_c_1.Gは構築可能。
- 価格が225,000 sats/ordiを下回った場合、予言機が署名(R_c, s_c_1)を発表。プロトコルは相手の適応署名を補完し、自身の署名を加えて有効な取引とし、ネットワークにブロードキャスト、決済をトリガーする。
- 逆に、価格が225,000 sats/ordiを下回らない場合、予言機はs_c_1を発表せず、コミット取引は有効な取引にならない。
本質的に、DLCはユーザーとプロトコルが参加者としてビットコインブロックチェーン上で合意を結ぶことを可能にする。双方は資金をマルチシグアドレスにロックすることでDLCスクリプトを構築する。これらの資金は、予言機が指定時間に指定情報を発表したときにのみ使用可能となり、特定のルールに従って再分配される。
こうして、貸付プロトコルはDLCを活用し、ユーザーが何のエンティティも信頼する必要のない、外部価格予言機による決済メカニズムを実現できる。
後述する貸付プロトコルLiquidiumやShell Financeは、この技術を用いて許可不要の分散型決済を実現している。
予言機の役割
DLCにおける予言機は、定期的な価格フィードサービスを提供し、DLCメカニズムにおける秘密値（secret）の生成と公開に第三者として関与する。
現在、標準化されたDLC予言機製品はまだ存在せず、主に貸付プロトコルがDLCモジュールを開発し、Chainlinkなどの標準化予言機がオフチェーンデータフィードを担当している。しかし、DLCベースの貸付プロトコルのリリースと発展に伴い、多くの既存予言機プロジェクトがDLC予言機の開発に取り組んでいる。
部分署名ビットコイン取引（PSBT）：BTCFIプロトコルにおけるマルチパーティ取引での資金の非託管化
PSBTはビットコイン標準BIP-174に由来する。この標準により、複数の当事者が同一取引に並列に署名し、その後PSBTを統合して完全署名取引を形成できる。当事者とは、プロトコルとユーザー、買い手と売り手、ステーキング者とステーキングプロトコルなどを指す。したがって、複数の資金交換を伴うBTCFIアプリケーションはすべてPSBTを活用でき、既存のBTCFIプロジェクトのほとんどがこの技術を使用している。
Alice、Bob、Charlieの3人が2/3マルチシグに資金を保管しており、これを均等に3分割して引き出したい。このためには、3人全員が同じ取引に署名してUTXOを消費しなければならない。彼らが互いに信頼しない場合、どのようにすれば資金の安全を保てるだろうか？
- まず、Aliceが作成者としてPSBT取引を開始。マルチシグUTXOを入力とし、出力は3人のウォレットアドレス。PSBTは、この取引以外の取引では誰の署名も使用できないため、Aliceは署名後、Bobに送信できる。
- 同様に、BobがPSBTを確認し、問題なければ署名。その後Charlieに送り、Charlieも署名して取引を公開する。
したがって、「部分署名（Partially signed）」とは、各個人が自分
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@Ventures_HTX
