この記事の著者：ユンウェン・リウ 1、秘猿研究院
私は知っています、この問題について話すと、ビットコインの純粋主義者は「ビットコインは静かにデジタルゴールドを作るだけでいいのではないか？なぜトークンが必要なのか？なぜUSDTが必要なのか？」と感じるかもしれません。しかし、資産の安全性を特に重視するのであれば、Ethereumがもし崩壊したらどうなるのか？DeFiは誰が支えるのか？さらに、トークンソリューションはビットコインプロトコルと互換性があり、元の機能を損なうことはありません。もし気に入らなければ、トークンクライアントをダウンロードしなくても大きな影響はありません。
ビットコイン上でトークンを発行する：なぜできないのか？
ビットコイン上でトークンを発行し、現実世界の資産取引をチェーン上に移転するというアイデアは、2010年頃にビットコインコミュニティに登場しました。コミュニティの最初の議論は、現実世界の資産（たとえば、不動産、株式、法定通貨など）をビットコイン上で分散型取引することを想定していました。しかし、法的要因により、不動産や株式のような資産を移動することは容易ではありません。たとえ自分の家のデジタル資産トークンを別の人に支払ったとしても、政府はそれを認めないかもしれませんし、現実世界の不動産証明書を自動的に変更する必要があるかもしれませんし、様々な税金を支払わなければならないかもしれません。また、規制の下では自由にチェーン上で取引することもできません。
したがって、より魅力的な方法は、法定通貨にペッグされたトークン、つまりステーブルコインを発行することです。ステーブルコインはNFTとは異なり、依然として均質化（fungible）トークンであり、元のビットコインとは区別されています。トークンとして登場すると、その価値は表す現実世界の資産の価格によって決まり、元のデジタル通貨の価格はもはや関係ありません（もしデジタル通貨の価格が資産価格を大幅に超えた場合、その資産を放棄することも可能です）。これが、通常ビットコイン上のトークンがサトシ（Satoshi）単位で表される理由です。
デジタル通貨を資産のトークンとして扱うには、2つの主要な問題を解決する必要があります：
ビットコインを使って現実世界の資産を表現する方法；
ビットコインの非常に制限されたスクリプト言語で複雑な取引ルールと契約を設定する方法。
以下の内容は、上記の2点に焦点を当て、現在存在するいくつかの主要なビットコイン資産発行ソリューションを概説し、データの可用性、資産キャリア、表現力、拡張性などのいくつかの側面から比較しました。
ビットコイン上の最初のトークン：着色コイン
ビットコイン上で最初にトークンプロトコルを設計した人物は特定できませんが、そのアイデアはビットコインフォーラムやコミュニティの議論から生まれた可能性があります。着色コイン（Colored Coin）プロジェクトは、ヨニ・アシアが2012年に開始しました。当時、彼はビタリック・ブテリン、リオール・ハキム、メニ・ローゼンフェルド、ローテム・レフと共に（着色コイン白書）（Colored Coins whitepaper）を執筆し、プロジェクトは2013年に運営を開始しました。
着色コインの動作原理は、サトシを特別なコインとしてマークし、その資産に関連する情報をこのサトシに書き込むことです。このプロセスを「着色」と呼びます。サトシを異なる色に着色し、異なるタグを付けることができますが、同じ色のコイン間では依然として区別はできません。たとえば、一群のドルに着色されたサトシは、依然として均質です。比較的早期のプロトコルではnSequenceフィールドが使用され、トランザクションの最初の入力UTXOのnSequenceにタグを追加しました。しかし、nSequenceのストレージ上限は4バイトしかないため、その後のトークン設計は基本的にOP_RETURNフィールドに変更され、より多くのメタデータを保存できるようになりました。
着色コインは現在、ビットコイン上の最初のトークンプロジェクトであるために言及されています。プロジェクトの発展は実際には理想的ではなく、大規模な応用も得られなかったため、プロジェクト自体は徐々に忘れ去られました。着色コインが当時直面していた問題は、ビットコインの機能がこの前衛的なアイデアをサポートできなかったことです。このアイデアを実現し、効率的かつ安定して運用することは非常に難しいのです。これが、ビタリックが着色コインプロジェクトの後にビットコインの反対側に進み、スマートコントラクトにそれほど執着した理由かもしれません。
着色コインはサトシの形で存在するため、その検証はUTXOの有効性を検証するのと同じで、全体のチェーンをダウンロードする必要があります。この問題は後でクライアントサイド検証（client-side validation）によって解決されます。
OP_RETURNを使用してトークンを発行する：Counterparty & Omni Layer
着色コインとは異なり、CounterpartyとOmni Layer（USDTの背後にあるプロトコル）は、サトシ上で直接着色するのではなく、トランザクション内で数値が0のUTXOを設定し、このUTXOのOP_RETURNにメタデータを保存します。OP_RETURNは80バイトを保存でき、OP_RETURNのUTXOは消費できないことを示しています。本当のトークンはOP_RETURNに記録されたi番目の出力です。この出力の数値は通常0.00000546 BTCであり、システムが送信を許可する最小値です。また、トークンの価値はBTCにリンクされていないため、0.00000546 BTCより多くの通貨を発行する必要はありません。
これらのプロジェクトの検証はすべてオンチェーンで行われ、メタデータはオンチェーンに保存されます。
Omni Layerは長い間Ethereumチェーンのプレイヤーでしたが、最近になってビットコインエコシステムに戻り、BTC-USDTの発行を準備しています。Counterpartyは一部のビットコインを担保にしており、独自のトークンXCPを持っています。Twitterによると、最近はNFTを作成しているようです。
OP_RETURNについてさらに学ぶには、参照してください：
ビットコインOP RETURNメタデータの分析
手動でOP_RETURNを構築してUSDTを送信する1
サイドチェーンでビットコインをアンカーする：Rootstock & Liquid Network
RootstockとLiquid Networkの2つのプロジェクトは、約2017年に登場し、いずれもサイドチェーンソリューションです。ビットコインをサイドチェーンに交換するための双方向ペグを使用し、EVM互換のサイドチェーン上でさまざまなDeFiやdAppsを使用します。彼らはWBTCのようなトークン（RSKにはRBTC、LiquidにはL-BTC）があり、主にBTCをEthereumエコシステムで構築したい人々を対象としています。
Rootstock上でトークンを発行する方法は、Ethereum上で発行する方法と同じであり、またはRootstockこのサイドチェーンはマイニングをビットコインチェーンと一緒に行う以外の機能はすべてEthereumエコシステムに適応するために設計されています。たとえば、スマートコントラクトコードもSolidityで書かれています。したがって、ここでのトークンはRBTCを基に発行されており、BTCとは直接の関係がありません。
この記事は主にパブリックチェーンに焦点を当てており、Liquid Networkはアライアンスチェーンであるため、ここでは深く議論しません。
RSKについてさらに学ぶには、参照してください
RSK：状態を持つスマートコントラクトを備えたビットコインサイドチェーン（RSKペーパー）
RSKマネー
FAQs
前述のプロジェクトの中には消えてしまったものもあり（たとえば着色コイン）、ビットコインの名の下にEthereumのエコシステムを売り込んでいるものもあります。これは主にEthereumが資本を受け入れた後、DeFiとdAppsが絶対的な市場優位性を占めたため、DeFiプロジェクトがそれと競争するのが難しくなったためです。Ethereum上のトークンは契約を通じて発行および取引され、ERC-20などの標準に従います。ビットコインエコシステムも最近2年で契約機能を解放し始め、BitVMなどが登場し、BRC-20などのトークン標準も登場しました。
ビットコイン上でスマートコントラクトを実現する：RGB
2016年に誕生したRGB（Really Good for Bitcoin）は、最初は着色コインの競争相手として設計されました。しかし、同様の課題に直面し、ビットコイン上でスマートコントラクトを有効にする方向にシフトしました。主にスマートコントラクトの実行に焦点を当てているものの、彼らの仮想マシンAluVMの制限により、2024年までに完全な契約機能は依然として限られています。
RGBの考え方は、オフチェーンでアクセスできるデータとスマートコントラクトのコードをビットコインの外部に置き、Merkle rootを介して取引の検証とトークンの発行の約束（commitment）を提供し、ビットコインチェーンは取引の約束の検証と最終性を行い、二重支払いが発生していないことを証明することです。
RGBの特筆すべき点は、クライアントサイド検証と一度限りのシールの技術を同時に使用していることで、これによりUTXO上にトークンを表す印を付けることはありません。これらの2つの概念は、2013年にピーター・トッドによって最初に提案され、ジャコモ・ズッコとマキシム・オルロフスキーがこの基盤の上にRGBプロトコルを設計しました。
クライアントサイド検証（Client-side validation）は、取引に使用されるデータとコードをオフチェーンに保存し、公開放送されないようにします。一部のデータは取引の両当事者の間でのみ私的に交換されることがあり、取引に関連しない他の人々は何も知らないかもしれません。オフチェーンの状態はビットコインによって維持され、ブロックチェーンはタイムスタンプの役割を果たし、状態の先後関係を証明できます。
一度限りのシール（single-use seal）は、クライアントサイド検証で最も一般的に見られる形態で、デジタル版の一度限りの密封条です。これは、各UTXOが一度だけ消費できる性質を利用して、オフチェーン状態の情報を1つのUTXOに書き込みます。したがって、ある時点でこのUTXOが消費されると、状態が更新されたことがわかり、その後の更新状態情報が新しく生成されたUTXOに書き込まれます。このオフチェーン状態情報は、USDTトークンの所有権であったり、特定の契約にどれだけのトークンが存在するかであったりします。
たとえば、アリスがボブにUSDTを送信したい場合、このUSDTはビットコインチェーン上には存在せず、その情報はオフチェーンで管理されていますが、アリスが制御するUTXOと関連があります。その情報は、このUTXOを生成したトランザクションの数値がゼロのUTXOのOP_RETURNフィールドに保存されています。こうして、アリスだけがこのUSDTを使うことができ、ボブはオンチェーンの取引を通じて、このUSDTが過去の取引でどのUTXOに保存されていたか、これらのUTXOが有効かどうか、取引が合法かどうかを追跡できます。このように、アリスが取引を開始し、このUSDTの約束情報をボブが制御するUTXOに移転すると、ボブはこのUSDTを確実に取得します。
RGBはLightning Network上でも動作可能です。なぜなら、その状態はオフチェーンにあり、約束をオンチェーンまたはLightning Network上に置くだけで済むからです。Taprootのアップグレード後、RGBは約束をTaprootトランザクションに埋め込むことができ、これによりRGBはより柔軟にビットコインチェーンに約束を埋め込むことができます。
RGBについてさらに学ぶには、参照してください：
RGB Blueprint 1
トークンをサポートし、スマートコントラクトをサポートしない：Taprootアセット
TaprootアセットはLightning Network Daemon (LND)チームが開発したプロジェクトです。原理はRGBに似ていますが、複雑なスマートコントラクトはサポートせず、トークンのみをサポートしています（Taprootのエントリの説明を参照）。
クライアントサイド検証、RGB、Taprootについてさらに学ぶには、参照してください
クライアントサイド検証
オフチェーントランザクション：ビットコイン資産プロトコルの進化
Counterparty vs RGB vs TARO
すべてのサトシをユニークにする：Ordinals & Inscriptions
ケイシー・ロダーマーは2023年初頭にOrdinalプロトコルを発表しました。このプロジェクトは、サトシに番号を付け、各サトシにユニークなシリアル番号を付けて並べ替える方法から生まれました。このアイデアは着色コインと同時期に提案されましたが、昨年再提起されました。また、SegWitとTaproot機能の追加により、その実装はそれほど難しくなくなりました。Ordinalはすべてのサトシを互いに異なるものとし、これによりNFTがビットコインチェーン上で直接発行できるようになります。
Inscriptionsは、そのようなNFTプロジェクトの1つです。NFTのデータは取引のwitnessデータに保存され、以前のプロジェクトが使用していたOP_RETURNフィールドではなく、4MB以内のメタデータを保存できます。Ethereum上のNFTとは異なり、Inscriptionsはオンチェーンストレージで、メタデータと画像が含まれています。
Ordinalsについてさらに学ぶには、参照してください：
Ordinals: Ethereumとビットコインのマキシマリストの共通の基盤？
ビットコインのOrdinalsとInscriptionsに関する究極のガイド
任意のUTXOチェーンを双方向でバインドする：RGB++同型バインディング
RGB++は最初にBTCとCKB（Nervos Networkの基盤）間の同型バインディングプロトコル（isomorphic binding protocol）として登場しましたが、現在ではその適用範囲は広がり、CKBとBTCの間に限られず、理論的には任意の2つのUTXOチェーンをこのプロトコルでバインドできます。
RGB++は、RGBのクライアントサイド検証と一度限りのシールのアイデアを一歩進めました。前述のように、RGBプロトコルの最大の問題は、データがユーザー自身によってローカルに保存されていることです。ユーザーが不注意でデータを失った場合、バックアップはなく、復元することもできません。また、ユーザーは自身のトークンに関連するデータだけを保存するため、他のデータの検証は難しくなります。同型バインディング層のソリューションは、トークンをビットコインUTXOのOP_RETURNフィールドにバインドするだけでなく、関連するビットコイン取引情報をCKBチェーンの取引にバインドすることです（CKBセルのロックスクリプト内で、特別なIBロックスクリプトを使用して実現）。CKBチェーン上の取引が合法かどうかを判断する際、ロックスクリプトはCKB上のBTCライトクライアントのデータを使用して、対応するUTXOが消費されたかどうか、消費された後に新たに生成されたUTXOが現在のトークン取引情報にバインドされているか（署名を含まない部分情報として）を調べます。
RGB++の注目すべき特徴：
双方向バインディングでデータの可用性の問題を解決する：
CKBセルの約束がUTXOのOP_RETURNフィールドにバインドされる
UTXO情報がCKB取引の出力セルにバインドされる
Lightning NetworkおよびCKBに基づくFiber Networkと互換性がある
複数の資産をサポート
任意のUTXOチェーンとバインドできる
RGB++についてさらに学ぶには、参照してください：
RGB++プロトコルライトペーパー
RGB、RGB++、クライアントサイド検証に関する究極のガイド
各プロジェクトの利点と限界をより明確に理解するために、上記のプロジェクトを以下の表にまとめて比較しました。特に注目すべき指標は：
データの可用性（Data availability）：同型チェーン（isomorphic-chain）とサイドチェーンはほぼ同じですが、オフチェーンのデータの可用性は他のソリューションよりも劣ります。この項目の強さから弱さへの順序は：オンチェーン ≥ 同型チェーン ≥ サイドチェーン > オフチェーン；
資産キャリア（Asset carrier）：BTCに直接関連するトークンソリューションは、非直接関連のソリューションよりも優れています；
均質性（Fungibility）：ここではプロジェクトのネイティブトークンが相互に交換可能かどうかを指し、プロジェクトがNFTの発行をサポートしていないわけではなく、後者は追加のプロトコルを通じて実現可能です；
表現力（Expressiveness）：複雑なスマートコントラクトを処理する能力を指します。
