出典：bytewon CKB
こうなると、ビットコイン純粋主義者はこう思うかもしれない：ビットコインは黙ってデジタルゴールドでいいのではないか？なぜトークンが必要なのか？なぜUSDTでなければならないのか？ しかし、資産の安全性を特に心配するのであれば、イーサリアムがダウンしたらどうするのか、DeFiは誰がそれをキャッチするのか、と考えなければならない。 また、トークンソリューションはビットコインのプロトコルと互換性があり、本来の機能を破壊しないので、それが嫌ならトークンクライアントをダウンロードしなければいいだけで、大きな影響はない。
ビットコインでトークンを発行する：なぜしないのか？
現実世界の資産取引をチェーンに転送するために使用される、ビットコイン上でトークンを発行するというアイデアは、2010年頃にビットコインコミュニティで浮上しました。コミュニティにおける初期の議論では、不動産、株式、不換紙幣などの現実世界の資産をビットコインに移行し、分散型取引を行うことが想定されていた。しかし、法的な要因もあり、不動産や株式のような資産を移動させるのはそう簡単ではない。自分の家のデジタル資産トークンを別の人に支払ったとしても、政府がそれを認めなかったり、現実世界の不動産証書に自動的に置き換わったり、さまざまな税金を支払わなければならないこともある。それに、規制のもとではチェーン上で取引することもできない。
したがって、より魅力的なアプローチは、ステーブルコインとして知られる不換紙幣と結びついたトークンを発行することである。ステーブルコインは、NFTとは異なり、まだカンジブル・トークンだが、オリジナルのビットコインとは区別される。トークンとして登場した場合、その価値はそのトークンが表す現実世界の資産の価格によって決定され、もはや元のデジタル通貨での価格はない（デジタル通貨の価格が資産の価格と比較して上昇しすぎた場合、資産を捨てるのは悪い考えではない）。これが、通常ビットコインのトークンがサトシ（Satoshi）建てである理由だ。
デジタル通貨を資産として使用するトークンには、解決すべき2つの主な問題があります：
- ビットコインで現実世界の資産を表現する方法。
ビットコインの非常に限られたスクリプト言語で、複雑な取引ルールや契約を設定する方法。
この2点に注目し、以下のコンテンツでは、現在利用可能ないくつかの主要なビットコイン資産発行ソリューションの概要を提供し、データの可用性、資産キャリア、表現力、スケーラビリティなどの観点から比較します。
ビットコイン上の最初のトークン：カラーコイン
ビットコイン上のトークンプロトコルを最初に考案した人物は不明で、そのアイデアはビットコインのフォーラムやコミュニティでの議論から生まれたのかもしれません。Coloured Coinプロジェクトは2012年にYoni Assia氏によって開始され、Vitalik Buterin氏、Lior Hakim氏、Meni Rosenfeld氏、Rotem Lev氏とともにColoured Coinsホワイトペーパー[1]を執筆し、2013年に発表された。このプロジェクトは2013年に開始された。
カラーコインは、サトシを特別なコインとしてマークし、そのサトシに資産に関する情報を書き込むことで機能します。サトシを異なる色に染め、異なるタグを付けることができますが、同じ色のコインは互いに区別がつきません。以前のプロトコルでは、最初の入力UTXO nSequenceのトランザクションで、nSequenceフィールドを使用してタグを追加していた。しかし、nSequenceのストレージの限界は4バイトしかないため、後のトークン設計では基本的に、より多くのデータを格納できるOP_RETURNフィールドに切り替えられている。
Colourcoinは、ビットコインの最初のトークンプロジェクトだったため、今でも語り継がれている。プロジェクト自体は、実際にはうまくいかず、大量採用もされなかったため、次第に忘却の彼方へと落ちていった。当時ステインコインが直面していた問題は、ビットコインの機能がまだこのかなり先進的なアイデアをサポートできておらず、アイデアを軌道に乗せ、効率的かつ安定的に運営することが難しかったことだ。ステインコイン・プロジェクトの後、ヴィタリックがビットコインの反対側に行き、スマート・コントラクトに夢中になったのはそのためだろう。
ステインコインはサトシとして存在するため、その検証はUTXOの検証と同じで、チェーン全体をダウンロードする必要がある。この問題は、後にクライアントサイドの検証で解決されます。
OP_RETURNでトークンを送信する：Counterparty & Omni Layer
Dyed Coinとは異なり、Counterparty[2]およびOmni Layer[3](USDTの背後にあるプロトコル)はSatoshiを直接染色するのではなく、トランザクションのUTXOに0という値を設定し、そのUTXOのOP_RETURNにメタデータを格納します。 OP_RETURNは最大80バイトまで保持でき、OP_RETURNでタグ付けされたUTXOは使用できないため、実際のトークンはOP_RETURNに記録されたiの値となります。実際のトークンはOP_RETURNに記録されたi番目の出力で、通常は0.00000546 BTC、つまりシステムが送信を許可している最低値であり、トークンの値はBTCと結びついていないため、0.00000546 BTC以上を送信する必要はありません。
これらのプロジェクトの検証は、メタデータが保存されているオンチェーンで必要です。
オムニレイヤーは長い間イーサリアムチェーンのプレイヤーでしたが、最近になってBTC-USDTのリリース準備のためにビットコインエコシステムに戻ってきました。
OP_RETURNについては、
サイドチェーンでビットコインをアンカリングする：Rootstock &; Liquid Network
Rootstock[7]とLiquid Network[8]。2017年頃に登場したRootstock[7]とLiquid Network[8]は、双方向ペグを使用してビットコインをサイドチェーンにスワップし、EVM互換のサイドチェーン上で様々なDeFiやdAppsを使用するサイドチェーンソリューションです。トークン（RSKはRBTC、LiquidはL-BTC）があり、これは主にBTCを使ってイーサリアムのエコシステムを構築したい人々を対象としている。
Rootstockでトークンを発行することは、イーサでトークンを発行することと同じである。あるいは、Rootstockは、マイニングをビットコインチェーンで行う以外はイーサのエコシステムに適応したサイドチェーンであり、スマートコントラクトコードなどの残りの機能はSolidityで書かれていると言える。スマートコントラクトのコードもSolidityで書かれている。つまり、ここでのトークンはRBTCの上で発行され、BTCとは直接リンクしていない。
この記事は主にパブリックチェーンに焦点を当てており、Liquid Networkはアライアンスチェーンであるため、ここでは深く議論しません。
RSKについては、
先に述べたこれらのプロジェクトのうち、いくつかは消滅し（例えばDye Coin）、いくつかはビットコインを装ってイーサのエコシステムを販売しました。これは主に、イーサがビットコインのエコシステムを受け入れているためである。これは主に、イーサが資本を受け入れた後、DeFiとdAppsが市場を支配するため、それを相手にしないDeFiプロジェクトが優位に立つことが難しくなるためである。イーサ上のトークンは、ERC-20のような標準に従った契約を通じて発行され、取引される。ビットコインのエコシステムもまた、トークン標準のBRC-20が登場したBitVMなど、ここ2年でコントラクトの機能を解放し始めている。
ビットコインにスマートコントラクトを実装する：RGB
2016年に誕生したRGB（Really Good for Bitcoin）[13]は当初、ダイコインと競合するように設計されました。競合する。しかし、同様の課題に直面し、ビットコイン上でスマートコントラクトを可能にすることに目を向けた。その主な焦点は、ヘアスタイルトークンよりもスマートコントラクトを実行することであるが、完全なコントラクト機能は、仮想マシンであるAluVMの制限により、2024年時点では制限されたままである。
RGBの考え方は、オフチェーンで取得できるデータとスマートコントラクトコードをビットコインの外で実行し、Merkleルートがトランザクションの検証とトークン発行の約束（コミットメント）を提供し、ビットコインチェーンはトランザクションのコミットメントの検証と確定のみを行い、二重消費がないことを証明することだ。二重消費がないことを証明している。
RGBは、トークンを表すためにUTXOをマークしないように、クライアントサイドの検証とワンタイムシーラーのテクニックの両方を使用していることで注目されています。これら2つのコンセプトは、2013年にPeter Todd氏によって初めて紹介され[14]、Giacomo Zucco氏とMaxim Orlovsky氏はこれらに基づいてRGBプロトコルを設計しました。
クライアントサイドのバリデーションにより、トランザクションで使用されるデータとコードはオフチェーンに保持され、公にブロードキャストされない。オフチェーンの状態はビットコインの助けを借りて維持され、ブロックチェーンは状態の順序を証明するタイムスタンプとして機能している。
そして、シングルユースシール（クライアント側の認証で最もよく見られるもの）は、シングルユースシールのデジタル版である。シールである。これは、各UTXOが一度しか使用できないという事実を利用し、UTXOにチェーンダウンした状態に関する情報を書き込む。そのため、ある時点でUTXOが使用されると、状態が更新されたことがわかり、更新された状態情報が新しく生成されたUTXOに書き込まれる。このオフチェーンステータス情報は、USDTトークンの所有権であったり、コントラクトにトークンがいくつあるかであったりします。
アリスがボブにUSDTを送金したいとすると、このUSDTはビットコインチェーン上には存在せず、その情報はオフチェーンで管理されますが、アリスが管理するUTXOにリンクされています。その情報はUTXOのOP_RETURNフィールドに格納され、UTXOを生成したトランザクションの値はゼロである。したがって、アリスだけがUSDTを使うことができ、ボブはUSDTがどのUTXOに保持されているか、それが有効かどうか、取引が正当かどうかを取引の連鎖を通して追跡することができる。
RGBはライトニング・ネットワーク上でも機能することができます。またはライトニング・ネットワーク上にコミットメントを置くだけでよいからだ。Taprootのアップグレード後、RGBはTaprootトランザクションに約束を埋め込むことができ、これによりRGBはより柔軟な方法でビットコインチェーンに約束を埋め込むことができます。
RGBの詳細については、以下をご覧ください：RGBブループリント[15]
トークンはあるがスマートコントラクトはない：Taprootアセット
トークンはあるがスマートコントラクトはない：Taprootアセットタップルート・アセットは、 Lightning Network Daemon (LND)[16]のチームによって開発されたプロジェクトです。原理的にはRGBと似ていますが、複雑なスマートコントラクトはサポートしておらず、トークンのみをサポートしています（Taprootエントリーの説明[17]はこちら）。
クライアントサイド検証、RGB、Taprootの詳細については、以下をご覧ください：
クライアント側の検証 [18]
オフチェーン取引。ビットコインアセットプロトコルの進化[19]
カウンターパーティ vs RGB vs TARO[20]
すべてのサトシを異なるものにする：Ordinals & Inscriptions
ケイシー・ローダーモアは2023年初めにOrdinal Protocol[21]をリリースした。このプロジェクトはもともと、各サトシが一意のシリアル番号を持ち、それによってソートされるように、サトシにナンバリングする方法というアイデアから生まれたものです。このアイデアはステインコインと同じ時期のもので、昨年再導入されたばかりである。そして、SegWitとTaproot機能が追加されたおかげで、Ordinalがすべてのサトシを互いに異なるものにするため、NFTをビットコインチェーン上で直接発行できるようになり、実装の難易度はかなり下がりました。
Inscriptions[22]はそのようなNFTプロジェクトの1つです。 NFTデータは、以前のプロジェクトで使用されていたOP_RETURNフィールドではなく、トランザクションの証人データに保存され、最大4MBのサイズのメタデータが可能です。Ether上のNFTとは異なり、Inscriptionはメタデータや画像を含めてオンチェーンで保存されます。
Ordinalsについての詳細は以下をご覧ください：
オーディナル：イーサリアムとビットコインの最大主義者の共通点[23]
究極のGuide to Bitcoin Ordinals and Inscriptions[24]
いずれかのUTXOチェーンへの双方向バインディング: RGB++同型バインディング
RGB++同型バインディング?left;">RGB++[25]はもともと、BTCとCKBの間の同型バインディングプロトコル（Nervosネットワーク[26]の基礎）として登場しましたが、現在では、CKBとBTCの間だけでなく、理論的には任意の2つのUTXOチェーンの間など、適用範囲が広くなっています。2つのUTXOチェーンがこのプロトコルによって理論的に結合されている限り、CKBとBTCに限定されることはありません。
RGB++は、RGBのClient-Side ValidationとSingle-Use-Sealsのアイデアをさらに一歩進めたものです。先に述べたように、RGBプロトコルの最大の問題は、データがユーザーによってローカルに保存されることです。ユーザーが誤ってデータを紛失した場合、バックアップはなく、データを取り戻す方法もない。さらに、ユーザーは自分のトークンに関連するデータのみを保存するため、他のデータを検証することが難しくなる。同型バインディングレイヤーの解決策は、トークンをビットコイン UTXO の OP_RETURN フィールドにバインドするだけでなく、対応するビットコイン取引情報を CKB チェーン上の取引にバインドすることである（CKB セル [27]のロックスクリプトに特別な IB-lock-script を使用することで実現）。CKBチェーン上のトランザクションが正当かどうかを判断する際、ロックスクリプトはCKB上のBTCライトクライアントのデータを使用して、対応するUTXOが使用されたかどうか、および使用された後に新たに生成されたUTXOが現在のトークン取引の情報に（署名を含まない情報の一部として）バインドされているかどうかを確認します。
注目のRGB++機能：
Multi-asset support
RGB++は任意のUTXOチェーンにバインドできます
任意のUTXOチェーンにバインドできます
RGB++は任意のUTXOチェーンにバインドできます。align: left;">RGB++プロトコルライトペーパー[28]
RGB、RGB++、およびクライアント側検証の究極ガイド[29] 。検証[29]
各プロジェクトの長所と限界をより明確に把握するために、上記の項目を以下の表にまとめて比較しました。
データの可用性。同型チェーンはサイドチェーンに匹敵するが、チェーンのデータ可用性は他の方式より弱い。この項目の強いものから弱いものへのランキングは以下の通りです：オンチェーン≧同型チェーン≧サイドチェーン > オフチェーン;
アセットキャリア：BTCに直接関連するトークンスキームは、そうでないものよりも優れています;
BTCに直接関連するトークンスキームは、そうでないものよりも優れています;
記事中で言及されているリンクの一部:[1]https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1&tab=t.0#heading=h.pr8n14cpqri5
[2] https.www.counterparty.io/
[3] https://www.omnilayer.org/
[4] https://x.com/counterpartyxcp
[5] https://arxiv.org/pdf/1702.01024
[6]。https://juejin.cn/post/6844903769327534088
[7] https://rootstock.io/
[8] https://liquid.net/
[9] https://www.wbtc.network/
[10] https://liquid.net/ left;">[10] https://eprint.iacr.org/2022/684.pdf
[11] https://wiki.moneyonchain.com/getting-started/what-do-i-need-to-know-first
[12] https://dev.rootstock.io/resources/faqs/
[13] https://rgb.tech/
[14] https://petertodd.org/2013/disentangling-crypto-coin-mining
[15] https://rgb-org.github.io/
[16] https://docs.lightning.engineering/
[17] https://bitcoinops.org/en/topics/client-side-validation/ ；
[18] https://bitcoinops.org/en/topics/client-side-validation/
[19] https://mirror.xyz/0x5CCF44ACd0D19a97ad5aF0da492AC0388469DfE9/h7XChxETK-cBfGdc0sTq_cCuWeo13-sp1j-g0ZYoYdc
[20] https://mandelduck.medium.com/counterparty-vs-rgb-vs-taro-8cd707d544f7
[21] https://docs.ordinals.com/
[22] https://ordinals.com/inscriptions
[23] https://blog.kraken.com/crypto-education/ordinals-a-common-ground-for-ethereum-and-bitcoin-maximalists
[24] https://www.nervos.org/knowledge-base/guide_to_inscriptions
[25]https://www.rgbppfans.com/
[26] https://www.nervos.org/
[27] https://docs.nervos.org/docs/tech-explanation/cell
[28] https://github.com/utxostack/RGBPlus-design/blob/main/docs/light-paper-ja.md
[29 ] https://www.nervos.org/knowledge-base/
[29] _rgb_guide_to_rgbpp_and_client_side_validation
Anais
Weatherly
Catherine
Kikyo
Alex