ビットコインの DeFi の起源を探る: アプリケーションのスケーリングがなぜ複雑なのか?

ビットコイン上でトークン、NFT、DeFi を開発するプロセスは、実際には見た目よりも複雑です。たとえば、Ethereum 仮想マシン (EVM) やその他のスマートコントラクトプラットフォームでは、スマートコントラクトはチューリング完全です。つまり、カスタムコントラクトをデプロイするだけで、新しい機能やオプションを追加できます。しかし、ビットコインでは、開発者はハードフォークを起こさずに革新を起こすように注意する必要があり、既存のプロトコル機能の制限内でのみ動作することができます。先ほども述べたように、ビットコインが特に重要かつ価値あるものとなっている主な要因の 1 つは、メインチェーンが時間の経過とともにほとんど変更されていないという「独創性」へのこだわりです。

それでも、ビットコインは広く採用された最初のブロックチェーンであり、その後、より柔軟なブロックチェーンに実装された多くのテクノロジーは、実はビットコインにその起源を持つものでした。実際、NFT は「カラーコイン」の形でビットコインに初めて登場しました。ステートチャネルの概念は、今日の L1-L2 アーキテクチャと設計が非常に似ています。アトミックスワップは現代のクロスチェーンブリッジの基礎を築きました。これらの動向については、前回の記事「ビットコインから始まる：DeFiの真の起源」で部分的に紹介しました。しかし、Botanix や他のビットコインチェーンのインフラストラクチャとしてのビットコインの比類のない価値を真に理解するには、これらの初期のイノベーションが今日のエコシステムへの道をどのように切り開いたのかをより深く理解する必要があります。ビットコイン自体は比較的シンプルですが、実は Web3 空間で最も複雑で魅力的なエコシステムの 1 つであり、最も豊かな歴史を持っています。

ビットコインの機能理論を探る: ビットコインは複雑なエコシステムをサポートするのに十分な力を持っているか?

2009 年にビットコインが発売されたとき、単純な支払いを可能にするだけでなく、マルチ署名やタイムロックなどのより複雑な操作も最初からサポートするスクリプト言語が組み込まれていました。サトシ・ナカモトは、nLockTime とシーケンス番号を使用した未確認トランザクションは、高頻度取引のために二者間で複数回更新され、最終状態のみがチェーンに書き込まれるとさえ説明しました。

Bitcoin Script は非常に興味深いメカニズムです。一方では、チューリング不完全であるため、機能が制限されます。その一方で、シンプルで安全なままです。したがって、ビットコイン上で複雑な機能を構築する場合、開発者はスクリプトによって提供されるフレームワーク内でそれを設計する必要があります。さまざまなアクションをプログラムするために使用される多数のコマンド (オペコード) が含まれており、最終的にはトランザクションデータに書き込まれます。

Bitcoin Script は、コインの使用条件を定義するために Bitcoin で使用されるスクリプト言語です。スクリプトは、ケーキを焼くための一連の手順であるレシピと考えることができます。オペコードは、この言語の構成要素です。プログラマーがスクリプトを記述する際に使用する「かき混ぜる」「加熱する」などの基本的な命令です。スクリプトの機能をより明確に理解するために、最も一般的なスクリプトの種類を簡単に見てみましょう。

P2PK (公開鍵への支払い) — これは元々の BTC 転送方法で、後に P2PKH に置き換えられました。これは複数の Opcode で構成されます (例: OP_DATA_65 OP_CHECKSIG OP_DATA_33 OP_CHECKSIG)。
P2PKH (公開鍵ハッシュへの支払い) - スクリプトの形式は次のとおりです: OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG。このスクリプトは、トランザクションサイズを最適化するために 32 バイトの公開キーハッシュを使用するため、64 バイトの P2PK よりもスペース効率が高く、すぐに主流になりました。取引サイズが小さいほど、手数料は低くなります。これは、ビットコインの使用量と手数料が増加するにつれて特に重要になります。
任意のデータの保存 - これらのスクリプトは通常、非常に少量の Satoshi をロックし、主に ASCII テキスト、リンク、またはスクリプトを保存するために使用されます。例: OP_0 OP_DATA_20 # 20 バイトのカスタムデータ。 OP_RETURN を使用してデータを保存する標準化された方法もあります。たとえば、Bitcoin Colored Coins プロトコル (NFT の前身) は、OP_RETURN を介してトークンメタデータを埋め込みます。

NCC グループの調査では、156 種類の異なるスクリプトパターンをまとめ、これらのスクリプト構造の詳細な分析を実施しました。

では、スクリプトを使用してビットコイン上で DeFi のようなメカニズムを構築することはできるでしょうか?次のステップの探索を続けましょう。

融資の仕組み：

前述したように、オペコードを組み合わせて一連の小さな命令チェーンを構築し、より複雑な動作を実現できます。たとえば、開発者はオペコードを組み合わせることで、ローン契約機能を備えた複雑なスクリプトを構築できます。これは、タイムロックとマルチ署名の組み合わせによって実現できます。

OP_CHECKSEQUENCEVERIFY (CSV): 相対的なタイムロックの場合 (例: 特定のトランザクションの後に資金を X ブロックロックする)。
OP_CHECKLOCKTIMEVERIFY (CLTV): 絶対時間ロックの場合 (例: ローンの有効期限は特定のブロックの高さまたはタイムスタンプで切れます)。
OP_CHECKMULTISIG (または OP_ADD を使用した複数の OP_CHECKSIG): 複数の当事者による署名が必要です。
条件付きロジックオペコード OP_IF / OP_ELSE: 異なる支出パスを定義します (例: 返済とデフォルト)。

これらのツールにより、「タイムアウト付きの二国間エスクロー契約」が可能になります。たとえば、アリスが BTC を担保として提供し、ボブがオフラインでステーブルコインを貸し出すとします。彼らは契約を通じて以下のルールを設定したいと考えています: アリスが期限までにローンを返済できなかった場合、ボブは彼女の BTC を受け取ります。彼女が期限通りにローンを返済すれば、BTC はロック解除され、アリスに返却されます。これを行うには、2/2 のマルチ署名出力を使用できます (資金を使用するには、アリスとボブの両方が署名する必要があります)。次に、スクリプトロジックを設定できます。特定のブロックの高さに達した後もローンの返済が行われない場合、ボブだけが資金を単独で使用できます。

しかし、ここでまだ大きな困難が残っています。ビットコイン自体は、自動的に利息を計算したり、担保比率を監視したり、清算を強制したりすることができません。利息の支払いは、オフチェーンまたは事前に署名されたトランザクションを介して行う必要があります（これは実際にはかなり複雑です）。ローン期間中に BTC の価格が下落した場合、Bitcoin スクリプト自体はこれを認識できず、自動的に清算をトリガーすることはできません。この機能を実現するには、オラクルまたはオフチェーンプロトコルを使用する必要があります。オラクルが存在しない場合は、契約は最終的な有効期限に基づいてのみ決定を下すことができます。

したがって、ビットコインレイヤー上で信頼のない BTC 担保付きステーブルコイン貸付を直接実装することは非常に困難です。現在の慣行は通常、信頼できる第三者に依存するか、他のチェーン上のアトミックスワップメカニズムを通じて間接的に実装されます。

AMM の機能:

前述のように、貸付とステーキングのメカニズムは理論的には Bitcoin Script を通じて実装できますが、実際には効率が低くなります。しかし、ビットコイン上に自動マーケットメーカー（AMM）のようなより複雑なメカニズムを構築できるかどうかはまだ検討の余地があります。 Bitcoin Script には、OP_ADD、OP_SUB、OP_MUL などの数学オペコード (ただし、これらの一部は無効になっています) と、OP_LESSTHAN などの比較オペコードが含まれています。理論的には、これらの関数を使用して価格計算ロジックを実装できます。

理論上、開発者は固定価格または事前に定義された一連の許容可能な価格ポイントを使用してスクリプトを作成できますが、各トランザクションの後に価格を動的に調整することはできません。その理由は、ビットコインは UTXO モデルを使用しており、各トランザクションで新しい UTXO とスクリプトが生成されるため、考えられるすべての状態を事前に計算するか、各トランザクションの後にコントラクトを再展開する必要があるためです。

AMM 実装におけるもう 1 つの重要な要素は、資産を交換できることです。理論上、ビットコインは流動性プールではなく注文帳の形式で構築できるアトミックスワップをサポートしています。 AMM のような動作は、一連の HTLC (ハッシュタイムロックコントラクト) を構築したり、異なる価格ポイントで注文を発行して静的な自動マーケットメイクシステム (利回り曲線に類似) を形成したりすることによってもシミュレートできます。しかし、そのようなシステムを維持するのは非常に面倒です。各トランザクションの後にスクリプトを手動で更新し、UTXO を再発行する必要があり、オンチェーンコストが非常に高くなります。

したがって、AMM は理論的には構築できますが、実際にはもっと大きな問題があります。ビットコインメインネットにはネイティブ資産である BTC が 1 つしかないのです。 Omni プロトコルなどのプロトコルはトークンメカニズムを提供しますが、これらの資産はトランザクションのメタデータ内に存在するため、スクリプトによって識別および処理することはできません。したがって、Bitcoin Script では、真の資産間交換や流動性プールの維持は実現できません。さらに、ビットコインの UTXO モデルでは、複数の当事者からの資金を同時に保持し、部分的な残高を更新する単一の契約はサポートされていません。状態の変更ごとに、新しいトランザクションと複数の署名が必要になります。

拡張スクリプト機能:

上記の点は、ビットコインが機能性を向上させるために定期的に大規模なアップデートを受ける理由を説明しています。重要なアップデートの 1 つは Taproot です。これはソフトフォークで導入されましたが、スクリプトの設計方法を大幅に変更しました。

TaprootのOP_SUCCESSメカニズム：

Taproot アップグレード (BIP 342) の導入により、以前は無効化または予約されていた多くのオペコードが Tapscript (つまり SegWit v1 スクリプト) で OP_SUCCESS オペコードに変換されました。 OP_SUCCESS は、オペコードが実行されるとすぐにスクリプトが正常に終了することを意味します。この設計により、ソフトフォークを介して新しいオペコードを追加することがより簡単かつ安全になります。具体的には、Tapscript では、オペコードの値が特定の範囲 (例: 0x50、0x62、0x7E ～ 0x81、0x83 ～ 0x86、0x89 ～ 0x8a、0x8d ～ 0x8e、0x95 ～ 0x99、0xbb ～ 0xfe) 内にある場合、OP_SUCCESSx と見なされます。これらのオペコードに遭遇すると、スクリプトは無条件に成功したと判断し、他のロジックを無視します。

このメカニズムは、古い OP_NOP (オペレーションコードなし) アップグレード方式に代わるもので、より高いセキュリティと柔軟性をもたらします。将来のソフトフォークでは、特定の OP_SUCCESS オペコードの動作が再定義される可能性があり、古いバージョンのノードではそれを「スクリプトの成功」と見なすため、バージョンの不一致によって発生する無効なトランザクションを回避できます。要約すると、「使用可能」としてリストされていないすべてのオペコードは、使用するために予約されているか、常に OP_SUCCESS を返すように Taproot で変換されています。

もう 1 つの重要な点は、オペコードが BIP (Bitcoin Improvement Proposal) プロセスを通じて提案される可能性があり、すでにいくつかの強力な提案が検討中であったり、拒否されたりしていることです。これらの提案のいくつかは、採用されればビットコインの機能を大幅に拡張し、より複雑な操作を実行できるようになります。

OP_CAT (連結演算子): Bitcoin スクリプトでデータを結合および処理する機能を強化するために使用され、表現力が大幅に向上します。 OP_CAT は元々、初期のビットコインに存在していました（2010 年に無効化されました）。その機能は、スタックから 2 つのバイト文字列を取得し、それらを接続してから、スタックにプッシュし戻すことです。このシンプルでありながら強力な操作は、メッセージを動的に構築したり、スクリプト内の Merkle ツリーハッシュやその他の複雑なロジックを計算したりするために使用できます。この提案では、連結された結果を 520 バイト (スタック要素の最大制限) 以下に制限することを提案しています。
OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY (略して OP_CSFS): このオペコードは、Oracle ベースのスクリプト検証を有効にします。たとえば、スクリプトは、外部条件 (価格やイベントの結果など) に関する署名されたメッセージが特定のオラクルから送信されたものであることを確認できます。シンプルな実行ロジックにもかかわらず、OP_CSFS はビットコインにまったく新しい機能をもたらすことができます。たとえば、オラクルが「BTC は時刻 X に 20,000 ドルを下回る」というメッセージに署名し、貸付スクリプトが OP_CSFS を通じてこの署名を検証し、貸し手が担保を清算できるようにします。このプロセスでは、第三者が秘密鍵を保持する必要はありません。また、借り手がローンを返済した後、オラクルまたは貸し手は「返済受領」に署名することができ、スクリプト検証後に担保が返却されます。 OP_CSFS がなければ、外部条件に基づくこのような自動契約は実装不可能になるか、共同署名者としてのオラクルを通じてのみ完了できるようになり、信頼リスクが高まります。
OP_CHECKTEMPLATEVERIFY (略して OP_CTV): このオペコードを使用すると、ユーザーはビットコインの将来の使用方法を事前に定義できます。たとえば、特定のアドレスセットにのみ転送したり、特定の手数料条件が満たされた場合にのみ使用したりできます。 OP_CTV は、特定の定義済みルールが確実に適用されるようにする「契約」メカニズムに基づいて、バッチトランザクション、チャネルファクトリ、その他の高度なユースケースを構築するために使用できます。

しかし、なぜこれらのオペコードはまだ承認されていないのでしょうか?

主な理由は、ビットコイン開発者コミュニティがビットコインの本来の形式を維持することに非常に慎重であることにあると考えられます。

一方で、新しい機能を導入することで、ビットコインの使いやすさと拡張性は確かに向上します。しかし一方で、ビットコイン自体は「遅く」なるように設計されたネットワークであり、この「遅さ」は、ある意味ではビットコインの「本来の」特徴ともみなされています。たとえば、清算メカニズムに OP_CSFS を適用する場合、速度が重要な要素となります。市場が暴落し、BTC の価格が急落すると、次のようなパラドックスが生じる可能性があります。

まず、ブロックチェーンの負荷が急上昇し、ネットワーク速度がさらに低下しました。

第二に、ビットコインネットワークにおける取引処理速度は大幅に遅れ、価格は現在の市場水準をはるかに超えていますが、中央集権型取引所と分散型取引所（CEXとDEX）はすでに迅速に対応しています。

オンチェーン決済取引が完了する前に価格が回復する可能性が非常に高いです。

そのため、ビットコイン自体は動作が遅く、高負荷時には取引手数料が非常に高くなるため、メインネット上で DeFi 関連のメカニズムをネイティブに実装する試みは基本的に意味がありません。

このため、開発者は徐々に、ビットコインの上に拡張レイヤーを構築すべきだというより合理的な結論に達しました。これは実際には、Rollup のアイデアの前身である「プロトペイメントチャネル」の概念です。オフチェーンで複数のマイクロトランザクションをサポートすることで、最終的にオンチェーンの決済トランザクションに圧縮されます。

2011 年 4 月には、ビットコインの最初のコードブランチである Namecoin がリリースされ、ビットコイン技術を通じて分散型ドメイン名登録 (DNS「.bit」) が実現されました。

名前と値のペアをオンチェーンで保存する Namecoin の例は、ビットコインの設計が通貨取引だけでなく、おそらく別のブロックチェーン構造を持つ他の資産にも使用できることを初めて実証しました。これらのコンセプトは、その後の資産のトークン化、分散型取引、ビットコインのオフチェーン拡張イノベーションの基礎を築きました。

ステーブルコイン：ビットコインのエコシステムにおいてどれほど効果的でしょうか?

ステーブルコインは、DeFi に直接関係ないものも含め、あらゆる Web3 エコシステムの重要なコンポーネントになっています。ユーザーは、これらを使用することで、ボラティリティリスクをヘッジし、資産価格の変動を心配することなく資金を送金することができます。前述のように、ビットコインネットワークは常に機能のシンプルさと記録できるデータの量のバランスを取ろうとしています。興味深いことに、ビットコインで資産を発行する最も初期の試みは、ある意味で NFT に似ている「カラードコイン」の開発を通じて達成されました。

JRウィレット氏は2012年に早くもビットコインで新しい資産を発行するというアイデアを提案し、「カラードコイン」という概念を提唱しました。その後、彼はマスターコインプロトコル（後にオムニに改名）の作成に協力し、ビットコイン上の資産のトークン化（法定通貨にペッグされたトークンを含む）の基盤を築きました。

標準の Bitcoin Script スクリプトには直接的な「トークン」オペコードがないため、開発者は OP_RETURN の助けを借りてトークンメタデータをトランザクション出力に埋め込むことしかできません (OP_RETURN は出力を使用不可にし、データを付加します)。 OP_RETURN が標準化される前は、データをエンコードするための回避策として、マルチ署名スクリプトも使用されていました。

Bitcoin Script 自体はトークンルールを適用できません。ルールは、Bitcoin トランザクションの解析を担当するオフチェーンソフトウェアによって維持されます。

Colored Coins、Omni Layer（旧Mastercoin）、Counterparty、Open Assetsなどのプロトコルはすべて、「特定のサトシまたはUTXOを色分け」することでトークンを表します。たとえば、Open Assets プロトコルは、トークンの金額と資産 ID を示すメタデータを含む OP_RETURN 出力を使用します。

本質的に、ビットコインブロックチェーン自体は「トークン」の存在を認識せず、単にデータを処理します。トークンの有効性（供給量、所有権など）は、OP_RETURN データを解析した後、外部ウォレット自体によって追跡されます。

OP_RETURN にはデータサイズの制限があることに注意してください。 Bitcoin Core クライアントの標準ポリシーでは、各 OP_RETURN 出力には 80 バイト以下の任意のデータしか含めることができないものと規定されています。 80 バイトを超えるデータは「非標準トランザクション」とみなされ、デフォルトでは転送されません。理論上は、トランザクションに複数の OP_RETURN 出力を含めることができ、付随するデータの量を増やすことができます (それぞれ最大 80 バイト)。ただし、スパムトランザクションを防ぐため、Bitcoin の現在の標準リレー戦略では通常、各トランザクションに 1 つの OP_RETURN 出力のみを含めることができます。

ビットコイン取引にメタデータを埋め込むこの機能により、2012 年に Mastercoin プロトコルが作成され、後に Omni と改名されました。 Omni Layer は Tether の初期の運用で重要な役割を果たし、最初の一連の USDT 転送の基盤となる伝送プロトコルとなりました。

2010 年代半ばの一時期、ビットコイン (Omni) をベースとした USDT は市場で最も支配的なステーブルコインであり、Bitfinex などの取引所で広く使用されていました。 Omni トランザクションは、基本的には追加のメタデータが追加された標準的な Bitcoin トランザクションです。その後、Omni はいくつかの異なる実装カテゴリを開発し、独自の技術進化パスを形成しました。