ビットコイン上でのアセット発行：既存プロジェクトおよびそれぞれのソリューションガイド
TechFlow厳選深潮セレクト
ビットコイン上でのアセット発行：既存プロジェクトおよびそれぞれのソリューションガイド
イーサリアムがもし崩壊したら？DeFiは誰が受け止めるのか？
Web3業界の深掘り報道に専念し潮流を洞察本文の執筆者：Yunwen Liu 1、秘猿研究院
ご存知の通り、この問題に触れるとビットコインのピュアリストは「ビットコインは静かにデジタルゴールドでいればいいではないか？なぜトークンが必要なのか？なぜUSDTが必要なのか？」と考えるかもしれません。しかし、資産の安全性を真剣に考えるならば、「イーサリアムがもし崩壊したらどうなるのか？」「DeFiは誰が引き継ぐのか？」という疑問も避けられません。また、トークン方式はビットコインプロトコルと互換性があり、元の機能を損なうものではありません。興味がなければトークン用クライアントをダウンロードしなければよく、大きな影響も受けません。
ビットコイン上でのトークン発行：なぜ不可能ではないのか？
現実世界の資産取引をブロックチェーン上に移すために、ビットコイン上でトークンを発行するというアイデアは、2010年頃からビットコインコミュニティ内で登場していました。当初の議論では、不動産や株式、法定通貨などの現実資産をすべてビットコイン上で非中央集権的に取引できるようにしようという構想でした。しかし法的要因により、不動産や株式のような資産の移転は簡単ではありません。仮に自分の家のデジタル資産トークンを他人に送っても、政府がそれを認めず、現実の登記簿を自動で変更することはなく、税金の支払いなども必要になる可能性があります。また規制下では、自由にチェーン上で取引することもできません。
そのため、より魅力的な方法として、法定通貨に価格を連動させるステーブルコイン（安定通貨）の発行があります。ステーブルコインはNFTとは異なり、依然として同質的（fungible）なトークンですが、従来のビットコインとは区別されます。トークンとして存在する場合、その価値は対応する現実資産の価格によって決まり、もはや元の暗号資産の価格には依存しません（暗号資産の価格が資産価格を大きく上回った場合、資産を捨て去ることも理論上可能）。そのため、ビットコイン上のトークンは通常サトシ（Satoshi）単位で表されます。
暗号資産を基盤とするトークンを実現するには、主に以下の2つの課題を解決する必要があります：
-
ビットコイン上で現実世界の資産をどのように表現するか；
-
ビットコインの非常に限られたスクリプト言語の中で、複雑な取引ルールや契約をどのように設定するか。
以下ではこれらの点に焦点を当て、現在存在する主要なビットコイン資産発行スキームを概観し、データ可用性、資産キャリア、表現力、拡張性などの観点から比較します。
ビットコイン初のトークン：カラードコイン
ビットコイン上で最初にトークンプロトコルを設計した人物は不明で、おそらくビットコインフォーラムやコミュニティ内の議論から生まれたアイデアです。「カラードコイン」（Colored Coin）プロジェクトは2012年にYoni Assiaが立ち上げ、当時Vitalik Buterin、Lior Hakim、Meni Rosenfeld、Rotem Levらとともに『カラードコイン白書』（Colored Coins whitepaper）を執筆しました。プロジェクトは2013年から運用開始しました。
カラードコインの仕組みは、1サトシを特別な硬貨としてマークし、資産に関する情報をこのサトシに書き込むことで「染色」を行います。1サトシを異なる「色」やタグで識別できますが、同じ色のコイン間では依然として差別化されません。例えば、米ドルとして染色された一連のサトシは、依然として同質的です。初期のプロトコルではnSequenceフィールドを利用し、最初のinput UTXOのnSequenceにマークを追加していました。しかしnSequenceは最大4バイトしか保存できないため、後のトークン設計ではほとんどがOP_RETURNフィールドに切り替わり、より多くのメタデータを保存できるようになりました。
カラードコインが今でも話題にされるのは、ビットコイン上で最初のトークンプロジェクトだったという歴史的意義によるものです。しかしプロジェクト自体の発展は芳しくなく、大規模な採用も得られず、次第に忘れ去られていきました。当時の問題は、ビットコインの機能がまだこの先進的なアイデアを支えるには不十分であり、実際に実装して効率的かつ安定的に動作させることは極めて困難だったことです。これが、Vitalikが後にビットコインの反対側へと向かい、スマートコントラクトにこだわるようになった理由の一つかもしれません。
カラードコインはサトシの形態で存在するため、その検証はUTXOの有効性を検証するのと同じく、チェーン全体をダウンロードする必要があります。この問題は後述するクライアントサイド検証（client-side validation）によって解決されます。
OP_RETURNを使用したトークン発行：Counterparty & Omni Layer
カラードコインとは異なり、CounterpartyとOmni Layer（USDTの背後にあるプロトコル）は、サトシに直接色をつけるのではなく、値がゼロのUTXOをトランザクション内に設け、そのUTXOのOP_RETURNフィールドにメタデータを保存します。OP_RETURNは80バイトまで保存でき、OP_RETURN付きのUTXOは使用できません。実際のトークンは、OP_RETURNに記録されたi番目のoutputとして存在します。このoutputの値は通常0.00000546 BTC（システムが許可する最小送信額）であり、トークンの価値はBTCと連動しないため、これ以上の量を送る必要はありません。
これらのプロジェクトの検証はすべてオンチェーンで行われ、メタデータもオンチェーンに保存されます。
Omni Layerは長らくイーサリアムチェーン上で活動していましたが、最近になってビットコインエコシステムに戻り、BTC-USDTの発行を準備しています。Counterpartyは一部のビットコインをステーキングしており、独自のトークンXCPを持っています。Twitterを見ると、最近はNFTに注力しているようです。
OP_RETURNについてさらに詳しく知りたい方は、以下を参照してください：
サイドチェーンでビットコインをアンカー：Rootstock & Liquid Network
RootstockとLiquid Networkは、2017年頃に登場したサイドチェーン方式のプロジェクトで、相互ペグ（Two-way peg）によりビットコインをサイドチェーンに移動させ、EVM互換のサイドチェーン上でDeFiやdAppsを利用できます。WBTCに似たトークン（RSKはRBTC、LiquidはL-BTC）を提供しており、主にBTCを使ってイーサリアムエコシステム上で開発したいユーザーを対象としています。
Rootstock上でトークンを発行する方法は、イーサリアム上で行うのとほぼ同じです。むしろ、Rootstockというサイドチェーンは、マイニングがビットコインチェーンと共通であることを除けば、他のすべての機能がイーサリアムエコシステムに適応するために設計されています。例えば、スマートコントラクトコードもSolidityで記述されます。したがって、ここでのトークンはRBTCを基盤として発行されており、BTCとは直接関係ありません。
本稿の焦点はパブリックチェーンにあるため、Liquid Networkはコンソーシアムチェーンであるため、ここでは深入りしません。
RSKについてさらに詳しく知りたい方は、以下を参照してください：
前述のプロジェクトの中には消滅したもの（例：カラードコイン）や、ビットコインの名を借りてイーサリアムエコシステムを販売しているものもあります。これは、イーサリアムが資本を受け入れたことで、DeFiやdAppsが絶対的な市場優位を占めているため、それに追随しないDeFiプロジェクトが優位を得ることが難しいからです。イーサリアム上のトークンはERC-20などの標準に従い、スマートコントラクトによって発行・取引されます。ビットコインエコシステムもここ2年ほどでようやくコントラクト機能のロックを解除し始め、BitVMやBRC-20といったトークン標準も登場しています。
ビットコイン上でスマートコントラクトを実現：RGB
2016年に登場したRGB（Really Good for Bitcoin）は、当初はカラードコインの競合として設計されました。しかし同様の課題に直面し、ビットコイン上でスマートコントラクトを可能にする方向へと舵を切ります。スマートコントラクトの実行に重点を置いていますが、その仮想機械AluVMの制限により、2024年時点で完全なコントラクト機能はまだ限定的です。
RGBのアプローチは、可能な限りデータやスマートコントラクトコードをオフチェーンに置き、Merkle rootを通じて取引検証やトークン発行のコミットメント（保証）を提供するというものです。ビットコインチェーンはこのコミットメントの検証と最終性の確認のみを行い、二重支出がないことを証明します。
特筆すべきは、RGBがクライアントサイド検証とワンタイムシール（single-use seal）技術を同時に利用している点です。これにより、UTXOにマークを付けてトークンを表現する必要がなくなります。これら2つの概念は、Peter Toddが2013年に提唱したもので、Giacomo ZuccoとMaxim Orlovskyがこれを基にRGBプロトコルを設計しました。
クライアントサイド検証（Client-side validation）により、取引に使用されるデータやコードはすべてオフチェーンに保存され、公開ブロードキャストされることはありません。一部のデータは取引当事者のみで秘密裏に交換され、他の関係ない人々には一切知られません。オフチェーン状態はビットコインによって維持され、ブロックチェーンはタイムスタンプとして機能し、状態の前後関係を証明します。
一方、ワンタイムシール（single-use seal）は、デジタル版の使い捨て封印です。各UTXOは一度しか使用できない性質を利用して、オフチェーンの状態情報をあるUTXOに書き込みます。このUTXOが使用された瞬間、状態が更新されたことがわかり、新しい状態情報は新たに生成されたUTXOに記録されます。このオフチェーン状態情報は、USDTトークンの所有権であったり、特定のコントラクト内にどれだけのトークンがあるかといった情報になります。
例えば、AliceがBobに1つのUSDTを送りたい場合、このUSDTはビットコインチェーン上に存在するわけではなく、オフチェーンで管理されていますが、Aliceが制御するUTXOに関連付けられています。その情報は、そのUTXOを生成したトランザクション内の、値がゼロのUTXOのOP_RETURNフィールドに保存されます。これにより、そのUSDTはAliceのみが使用でき、Bobはチェーン上の取引履歴を追跡することで、過去にそのUSDTがどのUTXOに保存されていたか、それらのUTXOが有効かどうか、取引が合法かどうかを確認できます。したがって、AliceがそのUSDTのコミットメント情報をBobが制御するUTXOに移転する取引を発生させると、Bobは自身がそのUSDTを取得したことを確信できます。
RGBはライトニングネットワーク上でも動作可能です。状態がオフチェーンであるため、コミットメントをチェーン上またはライトニングネットワーク上に配置するだけで済みます。Taprootアップグレード後、RGBはコミットメントをTaprootトランザクションに埋め込むことができ、より柔軟にビットコインチェーン上にコミットメントを組み込むことが可能になりました。
RGBについてさらに詳しく知りたい方は、以下を参照してください：
スマートコントラクト非対応、トークンのみ対応：Taproot Assets
Taproot Assetsは、Lightning Network Daemon (LND)チームが開発したプロジェクトです。その原理はRGBに似ていますが、複雑なスマートコントラクトには対応せず、トークンのみをサポートしています（Taproot 語解説を参照）。
クライアントサイド検証、RGB、Taprootについてさらに詳しく知りたい方は、以下を参照してください：
すべてのサトシをユニークにする：Ordinals & Inscriptions
Casey Rodarmorは2023年初頭にOrdinalプロトコルを発表しました。このプロジェクトの発端は、「サトシに番号を振って、それぞれを一意の順序で識別できるようにするにはどうすればよいか」というアイデアにあります。この考え方はカラードコインと同時期のものでしたが、昨年再び注目されるようになりました。SegWitやTaprootの導入により、実現が容易になったのです。Ordinalにより、すべてのサトシが互いに異なり、NFTをビットコインチェーン上に直接発行できるようになりました。
InscriptionsはまさにそのようなNFTプロジェクトです。NFTのデータは、従来のプロジェクトが使用していたOP_RETURNフィールドではなく、トランザクションのwitnessデータに保存されます。これにより、最大4MBまでのメタデータを保存できます。イーサリアムのNFTとは異なり、Inscriptionはメタデータや画像を含めて完全にオンチェーンで保存されます。
Ordinalsについてさらに詳しく知りたい方は、以下を参照してください：
任意のUTXOチェーン間で双方向バインディング：RGB++ 同型バインディング
RGB++は当初、BTCとCKB（Nervos Networkの基盤）間の同型バインディングプロトコル（isomorphic binding protocol）として登場しましたが、現在ではその適用範囲は広く、CKBとBTCに限定されず、理論的には任意の2つのUTXOチェーン間でこのプロトコルを使用できます。
RGB++は、RGBのクライアントサイド検証とワンタイムシールの考え方をさらに発展させています。前述のように、RGBプロトコルの最大の問題は、データがユーザー自身がローカルに保存する必要がある点です。ユーザーがデータを紛失した場合、バックアップもなく、復旧も不可能です。また、ユーザーは自身のトークンに関連するデータのみを保存するため、他のデータを検証することが困難です。同型バインディング層のアプローチは、トークンをビットコインUTXOのOP_RETURNフィールドにバインドするだけでなく、対応するビットコイン取引情報をCKBチェーン上の取引にもバインドする（CKBのCellのLock Scriptに特殊なIB-lock-scriptを使用して実現）というものです。CKBチェーン上の取引が合法かどうかを判断する際、Lock ScriptはCKB上のBTCライトクライアントのデータを使い、対応するUTXOが使用されたか、またそれが使用された後、新しく生成されたUTXOが現在のトークン取引情報（署名を含まない部分情報）と正しくバインドされているかを検証します。
RGB++の注目すべき特徴：
-
双方向バインディングによりデータ可用性問題を解決：
-
CKB CellがUTXOのOP_RETURNフィールドにコミットメント
-
UTXO情報がCKB取引のoutput Cellにバインド
-
-
ライトニングネットワークおよびFiber Network（CKBベースのライトニングネットワーク）との互換性
-
マルチアセット対応
-
任意のUTXOチェーンとのバインディングが可能
RGB++についてさらに詳しく知りたい方は、以下を参照してください：
各プロジェクトの強みと限界をより明確に理解するため、上記のプロジェクトを以下の表にまとめ、比較します。特に注目すべき指標は次の通りです：
-
データ可用性（Data availability）：同型チェーン（isomorphic-chain）とサイドチェーンはほぼ同等で、オフチェーンのデータ可用性は他の方式より劣ります。強さの順は：オンチェーン ≥ 同型チェーン ≥ サイドチェーン > オフチェーン；
-
資産キャリア（Asset carrier）：BTCと直接関連するトークン方式は、非直接関連の方式より優れています；
-
同質性（Fungibility）：プロジェクトのネイティブトークンが相互に交換可能かどうかを指します。プロジェクトがNFT発行をサポートしないということではなく、それは追加プロトコルで実現可能です；
-
表現力（Expressiveness）：複雑なスマートコントラクトを処理できる能力を指します。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
