上記の請求書は以下のフォーマットに従っています:

2./ボブはインボイス情報をチェックし、新しいRGBトランザクションを生成して、アリスが意図したようにRGB資産をアリスに移転する。しかし、ここで特に注意しなければならないのは、ボブはTEST資産の部分的な所有権を持っていることを証明しなければならないということです。これが必要な理由は、RGBプロトコルのデフォルトが「資産の状態をグローバルに可視化する記録なし」であり、Etherの場合のように、全員の資産を記録して処理するためにパブリックなエスクロー契約を使用しないからです。

RGBプロトコルの下では、異なるクライアントが、現在の残高や過去の出所など、自分に関連する資産データのみを記録し、クライアントごとにほとんど一貫性がありません。このため、各人が他人の資産状況を確認することは不可能であり、P2P取引では資産の証明を示すことが重要である。

わかりやすく例えるなら、自分と相手側は紙幣で取引しているが、相手側の紙幣が自分で印刷した偽札かどうかはわからないので、その紙幣がどこから入手したものなのか、何人がその手を通したものなのかをはっきり言ってもらうことで、相手側が偽札で自分を騙しているかどうかを判断できる。

お互いがお互いを認識している。大胆な取引ができること請け合いです。RGBの各取引は当事者間で認識されればよく、完全なP2P（OTCに似ている）です。

明らかに、このモデルはプライバシーを保護することができます。なぜなら、全員の資産状況、取引記録は、外部からは簡単に知ることができないからです。紙幣は銀行送金よりも匿名化しやすい、というような理屈だ。しかし明らかに、これはユーザーエクスペリエンスに不便をもたらす可能性もある。

先ほどのアリスとボブのケースでは、ボブはアリスの請求書を受け取り、その意図を知らされた後、ローカルクライアントの履歴データからTEST資産に関連する送金履歴を選択し、新しく生成されたボブ->アリスの送金とともにアリスに渡さなければなりません。アリスの転送は、新しく生成されたボブ->.アリスの転送とともに、アリスに渡され、対応する資産の所有権ソースの背後にある新しいRGB取引/所有権変更が有効でエラーがないことを確認します。

一般的に言って、クライアントのローカルに保存されたデータは、Strongと呼ばれます。ローカルに保存されたデータはStash「コレクション」と呼ばれ、RGBアセットの過去のデータが含まれています。StashはRGBアセット契約のログ記録と考えることができます。

これは、RGB資産契約のログ記録と考えることができます。3.アリスがボブからデータを受け取り、新しく宣言されたBob->Aliceトランザクションを受け取ると、アリスはその有効性を検証し、もしそれが通れば、アリスは「確認署名」を生成する。「

4. ボブはアリスの確認署名を受け取り、ボブ->アリスのトランザクションに対応するコミットメントをファイルに入れる。アリスのコミットメントはトランザクションをBTCネットワークにブロードキャストし、最終的にBTCチェーンに書き込まれ、最終となる。

("コミットメント")。Bob->Aliceの転送が、UTXO Bの所有者が30個のTESTトークンを持つことを宣言している場合、Aliceは30個のTESTトークンを持つことになります。TESTトークンを持つことを宣言した場合、アリスは自分がUTXO Bの所有者であることを証明する限り、それらのTESTトークンを使うことができます。

5.将来、アリスがTESTトークンを他の誰かに譲渡したい場合、これらのTESTの履歴ソースを提示する際、他の当事者はCOMMITMENTコミットメントの値をビットコインチェーン上のコミットメントの値と照らし合わせ、アリスから提供されたデータとチェーンから提供されたデータが一致するかどうかを検証することができます。アリスによって提供されたデータがチェーン上のコミットメント値に対応できるかどうか。これによって偽造データを防ぐことができます。

これによって偽造データを防ぐことができます。RGBプロトコルの利点は、複雑なスマートコントラクトの計算をオフチェーンでサポートできることです。それは本質的にBTCチェーンから計算ステップを移動させ、チェーン上のみでコミットメントを記録し、プライバシーを保護しながらオフチェーンでビットコインUTXOとRGB資産の所有権の関連付けを宣言し、ビットコインの助けを借りてRGB資産の所有権の変更を燃やし、可能にします。

すべての取引宣言は当事者によって検証され、承認される必要があるため、セキュリティモデルは、当事者が合理的である限り、RGB資産は安全であるとする合理的人間仮定（Rational Man Assumption）に基づいています。ビットコインが安全である限り、RGB資産の所有権は「本質的に安全」である。

しかし、RGBプロトコルの欠陥も明らかだ（サイロと断片化されたストレージの問題は先に述べた）。第一に、他人に送金するため、あるいは最初に同意と確認を得るために、両当事者は基本的に同時にオンラインでなければならない。

そして第二に、データを記録するグローバルに可視化された方法が欠けているため、。RGBの契約書は奇妙なフォーマットで公表されており、契約書の利用者は、電子メールかQRコードをスキャンすることで、契約書に含まれるインターフェース機能を事前に発行者から知らされる。(現在の公式見解は、契約コードをウェブサイトのトップページやTwitterのトップに掲載するのは構わないというものです。)

RGBプロトコルの契約状態をもう少し探ってみましょう。RGBプロトコル内では、コントラクトの初期状態（ジェネシス）は、RBG-20コントラクト内のトークンの名前、コントラクト内のトークンの総量など、コントラクトが作成されたときに作成者によって設定されます。その後、契約の状態はRGB取引の連続的な進行とともに変化するが、この契約状態の進化は非線形であり、有向無サイクルグラフDAGを構成する。

（図中のオーナー1の視野は青と緑の部分、オーナー2の視野は青と黄色の部分）

例えば、ボブがアリスに送金する場合、契約の初期化からボブがトークンを受け取るまでの送金記録の一部だけが表示され、これは比較的狭いデータ経路である。アリスはこの経路の分岐に含まれる取引情報しか知ることができず、他の人の送金情報を知ることは難しい。これはRGB利用者のプライバシーを保護する一方で、欠点もあります：利用者がRGB契約のグローバルな状態、例えば各人が何個のRGB資産を持っているかを知ることは困難です。これは多くの問題を引き起こす可能性があります。

例えば、Bob -> Aliceの譲渡が最終段階に達し、約束の値がBTCチェーンに書き込まれ、不可逆的になったとき、Bobはデータの一部をローカルに削除することができます。--もしBobが自分のTESTトークンをすべて手放した場合、彼は単にローカルに保存されているTESTトークンに関連するデータを削除し、ストレージの圧力を減らすことができます。

トークンの受取人であるAliceは、トランザクションに関わるすべてのデータをローカルで追跡しなければなりません。(ボブがローカルのTESTトークンのデータを削除し、アリスのクライアントノードが事故で完全に破損した場合、この時点でアリスの資産は永久に凍結されるのでしょうか？アリスのTESTアセットデータは、事前にバックアップされていない限り、他に保存する場所がないからです)。

これは本質的にDAとデータストレージの問題に帰着します。つまり、RGBプロトコルにデータを追加することで、信頼できる、グローバルに可視化された方法で伝搬することができず、最終的に異なるクライアントを「データサイロ」にしてしまいます。「データサイロ」になってしまう。以前はイーサネットのエコシステムで優位に立っていましたが、後に非推奨となったPlasmaソリューションも、DA問題を解決できないため、最終的には死産となりました。

さらに、RGBプロトコルは、トランザクションの両者の間で多くの通信を必要とし、通信ステップの多くは、詳細が未熟なまま記述されている中央集中型の施設に依存しており、関係者は、通信は電子メールで行うことができるとさえ言っています。

RGB プロトコルは、使いやすさを求めるロングテールのユーザーにはあまりやさしく設計されていないことは比較的明らかです。のユーザーにとっては、これらの負担はまだ重く、大量導入の重大な障壁となりうる。現在に至るまででさえ、驚異的なRGB資産は出現していないというのが大方の見方です。

下の図では、RGB資産移転のフローチャートを示しており、これに基づいて読者は送金プロセス全体を深く理解することができます。

要するに、RGBプロトコルは、RGBの所有権の変更を可能にします。プロトコルは、ビットコインUTXOの助けを借りてRGB資産の所有権変更を可能にし、BTCチェーン上にコミットメント値（Commitment）を投稿することで、オフチェーンデータがクライアントによって私的に改ざんされないようにします。実際、いわゆるRGBの「ワンタイム封印」とは、チェーン下のRGB取引の宣言を通じて、ビットコインUTXOとRGB資産の所有権を関連付けることであり、ビットコインの強力なセキュリティによってRGB資産の安全性を保証するものである。しかし、DAとデータストレージの問題により、オリジナルのRGBプロトコルの可用性とUXは比較的悪く、データ損失により資産は簡単に凍結（利用不可）される。

RGB++：CKBに基づく拡張RGBプロトコル

上記のセクションでは、RGBプロトコルの利点と欠点をまとめました。RBG システムの長所と短所をまとめました。クライアント側のデータのサイロ化と、契約状態のグローバルな可視性を持つことができないことが、RGB プロトコルの使いやすさに影響する最も重要な要因です。

実際、RGBプロトコルの長所と短所は非常に明白で、プライバシーとセキュリティのレベルが高い人は、独自のクライアントを実行し、データをバックアップする傾向がありますが、ロングテールのユーザーは明らかにそのための忍耐力がないでしょう（たとえば、ほとんどのライトニング・ネットワークのユーザーのほとんどは、自分でクライアントを実行するのではなく、サードパーティのノードに頼るだろう）。

このような理由から、Nervos氏はサイファーのRGB++ソリューションを共同設立し、RGBのアセットステータス、コントラクトの発行、トランザクションの検証をCKBパブリックチェーンに委譲しようとしています。CKBはサードパーティのデータ・ホスティングおよびコンピューティング・プラットフォームとして機能し、、ユーザーが独自のRGBクライアントを実行する必要性を排除する。

CKB自体が拡張されたUTXOモデル（Cell）であるため、RGB資産のオフチェーン情報をCellに書き込み、CellとビットコインUTXOの間に1対1のマッピング関係を確立することができます。そして、使いやすさの問題を解決する方法として、オリジナルのRGBスキームを強化補完する検証スキームを提供します。

。この段落は少し複雑に読めるかもしれません。

記事の前半で述べたように、RGBプロトコルは基本的に、オンチェーンでの約束とオフチェーンでの宣言を発行することで、ビットコインUTXOとRGB資産の所有権を関連付けます。しかし、RGB資産契約のデータは断片化され、グローバルに可視化されることなく、異なるクライアントにローカルに保存されます。

RGB++は、ビットコインのUTXOと対応するRGB資産との間のマッピング関係を、CKBのUTXOの拡張版であるCellを通じて、CKBチェーン上に直接表示します。表示され、CKBパブリックチェーンがユーザーのP2Pクライアントに置き換わって、各RGB転送の有効性を検証します。

RGBデータのこのようなグローバルに可視化された記録があれば、RGBプロトコルで実装が困難な多くのシナリオが実装しやすくなります。

（RGB++トランザクションの流れ、書き込み。(RGB++トランザクションフロー、RGBアセット情報をCellに書き込み、CellとビットコインUTXOを関連付け、最後にCKB上で発生したRGB++トランザクションを、RGB++アセットに関連付けられたビットコインUTXOとともにプロミスに含め、そのプロミス値をビットコインチェーンに書き込む)

最初にEVMを思い浮かべる人もいるかもしれません。RGBの状態と検証にEVMを使用できるのでしょうか？RGB資産は本質的にビットコインUTXOに寄生し、ビットコインUTXOと1対1のマッピング関係にあるためです。ビットコインUTXOとEVMコントラクトデータの間にマッピング関係を確立したい場合、技術的な実装はスムーズではなく、直接UTXOパブリックチェーンを選択した方が良いでしょう。

また、イーサ上の「資産」は多くの場合ピアツーピアの公共財であり、1つのコントラクトが無数の人々の資産データを記録し、コントラクトコントローラーが絶対的な権力を持っています。このような資産の扱い方は、ビットコインのUTXOやRGBプロトコルと深刻に対立するもので、資産を完全に私有化し、各個人が自分の資産を完全にコントロールできるように設計されています（紙幣とWeChat Payの違いを思い浮かべてください）。また、イーサリアムやEVMチェーンに常に存在する問題、つまり資産契約の所有者による悪用、資金に損害を与える契約のバグ、資産契約のデータ破損を考慮する必要はありません。問題は、資産契約の所有者が権力を乱用すること、契約がバグること、資金が損傷すること、資産契約のデータを移行するのが面倒なことです。

(Geekweb3の過去記事「テックサークルの有名人が馬をガラガラポン：高性能なパブリックチェーンは新しいことを起こすのが難しい、スマートコントラクトは力の分散が必要」より)

というわけで、ビットコインのUTXOとオフチェーンのRGBのマッピング関係をよりスムーズに表現したいのならアセットをよりスムーズに表現したい場合、最良の選択肢はやはり UTXO チェーンを通じてです。そしてCKBは拡張UTXO - Cellをサポートし、CKB VMの命令セットはRISC-Vに基づいており、EVMよりもビットコインの公開鍵-秘密鍵検証アルゴリズムを含むさまざまな暗号アルゴリズムとの互換性が高いため、RGB++が提案する技術的ソリューションの実装により適しています。

RGB++の技術的実装

RGB++はCKBの拡張UTXOを使用します。--セルを使用します。

RGB++はCKBの拡張UTXO --Cellを使用します。left;">容量は、このセルが持つオン・チェーン・スペースの量を表し、データはセル内に含まれ、読み取りや変更が可能なデータ・セットを指す。

TypeはこのCellがバインドされているプログラムコードで、データ・データを変更できる条件を制限します。例えば、100個のTESTトークンのデータが自分のCellにあるのに、110個のTESTを他の人に譲渡すると宣言した場合、これはTypeで指定された制限条件を満たさないため、拒否されます。

一方、LockはBitcoin UTXOのロック解除スクリプトに似た、Cellの所有権検証ロジックを表します。

UTXOのアップグレード版としてCellを理解することができ、TypeとCapacityの2つのフィールドが追加され、データはデータ型をカスタマイズすることができます。達成するためにスクリプトのロックを解除します。

。一方、RGB++のアイデアは、RGB資産の所有関係をCKBチェーン上のCellsで表現することです。もともとRGBクライアントにローカルに保存されていたアセットデータをCKBチェーンに移動してCellの形式で表現することで、CKBがRGBアセットのパブリックデータベースとして機能します。RGBアセットを表すCellはビットコインチェーン上のUTXOと1対1のマッピング関係を持ち、このマッピング関係はCellのLockフィールドに直接表示されます。

たとえば、RGB アセットがビットコイン UTXO A に関連付けられていると仮定すると、対応するマップされたバージョンのセルは、ビットコイン UTXO A と一致するように独自の所有権検証条件を設定できます（つまり、ロックスクリプトをビットコイン UTXO A のロック解除条件に設定します）。スクリプトを Bitcoin UTXO A のロック解除条件に設定する)。あなたがUTXO Aのコントローラーであれば、CKB上のマッピングされたCellを直接操作することができますが、もちろんCKBはあなたがUTXO Aのオーナーであることを確認します。

CKBチェーンは、ビットコインブロックヘッダーを同期するビットコインライトノードを実装します。RGBアセットに対応するCell上で動作するRGBトランザクションを宣言する場合、ビットコインUTXO Aのコントローラーであることを証明する必要があります。証明するステップは2段階です：

1.CKBチェーンに実装されているビットコインライトノードに証明するノードがビットコインチェーン上にUTXO Aが存在することを証明し、Merkle Proofの提示を要求する;

2.自身がUTXO Aの所有者であることを証明するデジタル署名を提示する。

RGB++ シナリオでは、ユーザーがフロントエンドでRGB資産の譲渡を宣言すると、CKBチェーン上のトランザクションがトリガーされ、RGB資産のデータを記録するCellが書き換えられ、所有権が変更されます。 元々は、Bitcoin UTXO 1のコントローラーがCellを所有していた可能性があり、所有者の変更後、Bitcoin UTXO 2のコントローラーがCellの新しい所有者になります。これはすべてCKBチェーン上で確認できます。

ここに注意してください。BTCチェーン上のコミットメントに関連するワークフローは依然としてBTCメインネット上で行われます。つまり、RGB++は依然として、CKB上で行われたRGB資産の取引記録に関連するビットコインチェーン上のコミットメントを公開しなければなりません。このステップは、従来のRGBプロトコルと変わりません。

ただし、異なるのは、従来のRGBプロトコルでクライアント自身がオフチェーンで処理するすべてのタスクが、CKBによって処理されることです。コントラクトの発行はサードパーティのチャネルを経由する必要があるなどです。このような面倒な荷物はすべて、ユーザーが自分でクライアントを実行しなくてもCKBが処理できます。

これにより、RGBクライアントのサイロ化されたデータの問題が解決され、また、コントラクトの状態がグローバルに可視化されないという欠陥も解決されます。同時に、RGBコントラクトはCKBチェーン上に直接展開することができ、RGBセルが参照するためにグローバルに可視化されるため、RGBプロトコルのコントラクトがリリースされる際の一連の奇妙な操作を避けることができます。

簡単に言うと、CKBは Cell スクリプトを使用して、RGB コントラクトを CKB チェーン上に展開する方法を提供します。strong>CKBはCellスクリプトのプログラム可能性を利用して、まずRGB転送の開始者がRGBアセットに関連するビットコインであるUTXOを本当に所有しているかどうかを判断し、これが検証された場合、RGBアセットデータを記録するCellを転送によって他の誰かに転送できるようにします。

一言で言えば、CKBはRGB資産の公開データホスティングプラットフォームとして機能し、データストレージとグローバルに可視化されたコントラクトの公開、所有権の検証と計算を提供します。もっと簡潔に言えば、CKBはRGBのクライアントに取って代わり、その過程で他の問題を解決する。

もちろん、RGB++はグローバルに可視化されたデータ公開を可能にするため、プライバシーはRGBプロトコルに比べて必然的に低下しますが、使いやすさが大幅に向上するという利点があります。

つまり、RGB++は、RGBプロトコルではできないシナリオを可能にする一方で、本質的にプライバシーと使いやすさを交換します。ユーザーが製品のシンプルさと機能性を重視するなら、RGB++ を好むでしょう。プライバシーと自分で確認できるセキュリティを求めるなら、従来の RGB プロトコルを好むでしょう。すべてはユーザー自身の選択に依存します (この考え方は、Vitalik が EtherChannel Layer2 についてコメントしたときに表明したものと似ています)。(この考え方は、VitalikがEthernet Layer2についてコメントしたとき、セキュリティを求めるならRollupを使うべきで、低コストを求めるならValidiumやOptimiumのような非Rollupソリューションを使うべきだというのと似ている）。もちろん、RGB++のホワイトペーパーによると、CKBチェーン上でプライバシートランザクション方式を実装し、ユーザーの身元と転送量を隠すことも可能です。

RGB++の追加機能

対話型ではない取引（非常に重要インタラクティブでない取引 (非常に重要)

元のRGBプロトコルの大きな問題の1つは、RGB転送が正常に実装される前に、受取人が、自身のUTXOの1つがRGBアセットにバインドされていることを示すメッセージ(前述の小切手)を最初に支払人に送信しなければならないことでした。を送信する必要があります。このため、共通のトランザクションを完了するために、受取人と支払人の間で複数のチャネルのインタラクティブな通信が必要になり、明らかにユーザーの理解の困難さと製品の複雑さが増します。その代わりに、RGB++はデータホスティングおよびコンピューティングプラットフォームとしてのCKBの性質を活用し、非同期で非対話的な方法で取引相手間の送金を完了できるようにしています。

AがBに送金する際に必要なのは、Bの住所を事前に知っていることと、その住所に送金が行われるという声明だけであり、受取人がオンラインで通信したりデータを提供したりする必要はない。その後、受取人は自分で資産を受け取ることができ、CKBチェーン上のスクリプト・コードによって、受取人が支払人によって指定された人物であることが検証される。明らかに、このモデルは多くの人が慣れ親しんでいるものに近く、airdropsや報酬分配といった、本来RGBプロトコルではサポートされていないモードも実行できるため、RGB資産の分配も容易になります。

また、RGBプロトコルの動作モードは、典型的な多対多の非対話型トランザクションプールであるUniswapのようなDefiシナリオの開発には当然不利であり、オリジナルのRGBプロトコルでは開発がほぼ不可能であるのに対し、RGB++は非対話型トランザクションを実現し、状態のグローバルな可視性を検証でき、Cellを借りて「条件を満たした者全員が状態を変更できる」ことを実現しさえすれば、オリジナルのRGBプロトコルの開発は不可能ではありません。条件を満たせば誰でも状態を変更できる「マスターレス契約」を実現するためにセルを借りさえすれば、多くのデフィのシナリオを実現することができる。

もちろん、誰もがその状態を変更できる所有者のいない契約は、複数の人が同時に契約の状態を変更したいという状態競合/読み書き競合が起こりやすく、カオスになりかねません。この問題を解決するために、RGB++は、異なるリクエストを並べ替える「シーケンサー」として、インテント・セルのオンチェーン実装を使用する予定です。

Transaction Folding (Aggregating Commitment Posting for Multiple Transactions)

Transaction Foldingは、CKBをオンチェーンのIntent Cellとして使用することとしてよりよく理解されます。このアイデアは、CKBを「オフチェーンの事前決済レイヤー」として使用することであり、そうすることで、複数のRGB転送が行われたときに、トランザクションのバッチが集約され、トランザクションのバッチのコミットメントが作成され、その後、一度にビットコインチェーンにポストされます。

具体的には以下のフローチャートで表されます：

BTCアセットは、チェーンを横断することなく、CKBオンチェーンアセットと直接やり取りします

RGB++は、アセットとアセットを直接やり取りすることができます。>RGB++は、Bitcoin UTXOとCKB Cell間のアソシエーションマッピングを実装した後、チェーンをまたいだ直接的なアセットレス相互運用性を可能にします。 RGB++のトランザクションステートメントを通じて、自分のビットコインUTXOを他人に譲渡することができ、相手は自分のCKB資産の所有権を自分に譲渡することができます。このモデルには多くの想像の余地があり、先に述べたトランザクションの折りたたみ（バルクトランザクション）と組み合わせることで、理論的にはBTC資産を必要とせずに、チェーン間でBTC - CKBオンチェーン資産の相互運用性を可能にすることができます。

概要

RGB++は、異なるRGBクライアントにローカルに保存されたアセットデータを取得し、CKBチェーン上のセルに直接表現します。ユーザーは、ビットコインアカウント/アセットを介して、CKBチェーン上の自分のRGB++アセットとやり取りすることができます。このアプローチはより簡潔であり、転送が2つの当事者間の事前の通信を必要とするRGBプロトコルの問題、グローバルに可視化された状態をサポートすることの難しさ、断片化されたデータストレージ、スマートコントラクトとDefiの不親切さを解決します。

RGB++は、BTC-CKB間の相互運用性を達成するためにアセットがクロスチェーンする必要がなく、RGBアセットとDefiシナリオの組み合わせを容易にし、RGBプロトコルの使いやすさの問題を大幅に解決します。しかし、高度なプライバシーを追求する RGB ニッチ プレーヤーにとって、RGB++ は本質的にプライバシーと使いやすさのトレードオフであり、すべてはユーザーのトレードオフに依存します。しかし、理論的には、プライバシーの問題は、たとえばZKを導入することによって、CKBチェーン上で解決することができます。

全体として、RGB++はビットコインチェーン下の決済/計算レイヤーとしてのCKBの可能性を示しており、この考え方は今後ますます多くのビットコインレイヤー2またはアセットプロトコルによって採用されるでしょう。ビットコインチェーンのサードパーティ決済レイヤー間の競争がまもなく始まることは予見できる。そして、POWとUTXOに注力し、長年の技術蓄積を持つCKBは、このモジュール型ブロックチェーン競争において、その技術的優位性を示すことができるかもしれない。