RGB++の人気が高まるにつれて、RGBおよびRGB++プロトコルの原則に関する議論がより多くの人々の関心を引くようになってきました。しかし、RGB++を理解するためには、まずRGBプロトコルを理解する必要があります。元のRGBプロトコルはある程度技術的な構造を持ち、散在する参考資料がありますが、これまでにあまり体系的で理解しやすいリファレンス資料はありませんでした。Geek Web3は以前、RGBとRGB++の2つのシステマティックな解釈を公開していましたが、コミュニティからのフィードバックによると、それらの記事は長くて複雑すぎるとのことです。この記事の著者は、より多くのコミュニティ愛好家がより良く、直感的にRGBおよびRGB++を理解できるようにするために、香港のイベント中にRGBおよびRGB++の簡単な素人向け解説を急いで完成させました。数分で読むことができ、RGBおよびRGB++をよりよく理解することを目指しています。

RGB Protocol:ユーザーはデータを個人的に確認する必要があります

RGBプロトコルは、ビットコインチェーンの計算システムの下で運用されるP2Pアセットプロトコルの特別なタイプです。ある面では、支払いチャネルに似ています：ユーザーは自分自身のクライアントを実行し、自分自身に関連する転送アクションを確認する必要があります（「自己確認」）。資産の受取人であっても、転送が有効になる前に送信者からの転送声明が正しいことを最初に確認する必要があります。このアプローチは、「インタラクティブ転送」として知られ、従来の資産転送および受信方法とは著しく異なります。なぜこれが必要なのでしょうか？その理由は、プライバシーを保護するために、RGBプロトコルがビットコインやイーサリアムなどの従来のブロックチェーンに見られる「コンセンサスプロトコル」を使用しないからです（データがコンセンサスプロトコルに入ると、ほとんどのネットワークノードによって観察され、プライバシーを保護することが難しくなります）。多数のノードを巻き込む合意プロセスがない状況で、どのように資産変更を安全に保証できるのでしょうか？これが「クライアント確認」（「自己確認」）の考えが登場する場面です。クライアントを実行し、自分に関連する資産変更を個人的に確認する必要があります。

たとえば、Alice を知っている Bob という名前の RGB ユーザーについて考えてみましょう。Alice は 100 TEST トークンを Bob に譲渡したいと考えています。「Alice to Bob」転送情報を生成した後、Alice は転送情報と関連する資産データを Bob に送信し、Bob が個人的に確認できるようにします。ボブがすべてが正しいことを確認した場合にのみ、転送は有効なRGB転送になります。そのため、RGBプロトコルでは、従来のコンセンサスアルゴリズムに取って代わり、ユーザーがデータの有効性を自分で検証する必要があります。ただし、コンセンサスがないと、異なるRGBクライアントによって受信および保存されるデータに一貫性がありません。誰もが自分に関連する資産データのみをローカルに保存し、他の人の資産ステータスを知りません。これにより、プライバシーは保護されますが、「データアイランド」も作成されます。誰かが100万のTESTトークンを持っていると主張し、100,000をあなたに送金したいと言った場合、どのように彼らを信頼しますか?RGBネットワークでは、誰かがあなたに資産を譲渡したい場合、まず資産の証明を提供し、最初の発行から複数回の送金までの資産の履歴を追跡し、あなたに送金したいトークンが正当であることを確認する必要があります。原因不明の紙幣を受け取ったときに、偽造紙幣を避けるために、指定された発行者によって発行されたかどうか、その紙幣の履歴を送信者に説明してもらうようなものです。

（画像出典：Coinex）

上記のプロセスはビットコインチェーンの下で発生し、これらの手順だけではRGBとビットコインネットワークとの直接的な接続を確立しません。このために、RGBプロトコルでは「一度だけ使用する封印」という概念を採用しており、これによりRGBアセットがビットコインチェーン上のUTXO（未使用取引出力）に結び付けられます。ビットコインUTXOが二重支払いされていない限り、結び付けられたRGBアセットは二重支払いの対象とはならず、したがってRGBアセットの「再編成」を防ぐためにビットコインネットワークを利用します。もちろん、これにはビットコインチェーン上でのCommitmentsの公開とOP_Returnオペコードの使用が必要です。

RGBプロトコルのワークフローを概説しましょう：

1. RGBアセットはBitcoin UTXOにバインドされており、Bobは特定のBitcoin UTXOを所有しています。AliceはBobに100トークンを送金したいと考えています。アセットを受け取る前に、BobはAliceに対して、これらのRGBアセットをバインドするためにどのBitcoin UTXOを使用すべきかを通知します。

（画像ソース：Geekweb3/GeekWeb3）

1. アリスは、「アリスからボブへ」のRGB資産の転送のための取引データとこれらの資産の履歴を構築し、ボブに検証のためにそれを提供します。
2. ボブがローカルでデータが正しいことを確認した後、取引が進行できることをアリスに通知するために領収書を送信します。
3. Aliceは、「Alice to Bob」RGB転送データをMerkle Treeに構築し、Merkle RootをBitcoinチェーンにコミットメントとして公開します。コミットメントは単に転送データのハッシュとして理解することができます。
4. 将来誰かが「アリスからボブへ」の転送が実際に行われたことを確認したい場合、2つのことを行う必要があります。まず、Bitcoinチェーン上の「アリスからボブへ」の完全な転送情報を取得し、その後、対応するコミットメント（転送データのハッシュ）がBitcoinチェーン上に存在するかどうかを検証する必要があります。

BitcoinはRGBネットワークの履歴ログとして機能しますが、そのログは取引データのハッシュ/マークルルートのみを記録し、取引データ自体は記録しません。クライアント側検証と一度きりの封印の採用により、RGBプロトコルは非常に高いセキュリティを提供します。RGBネットワークはP2Pで構成された動的ユーザークライアントから成り、コンセンサスフリーの方法であり、限られたノードに取引要求を送信する必要がなく、いつでも取引相手を変更できます。そのため、RGBネットワークは強力な検閲耐性を示します。この組織構造により、Ethereumのような大規模な公開チェーンに比べて、検閲に対してより耐性を持っています。

（画像の出典：BTCEden.org）

確かに、RGBプロトコルによってもたらされる高いセキュリティ、検閲耐性、プライバシー保護には莫大なコストが伴います。ユーザーはデータを検証するためにクライアントを実行する必要があります。誰かが数千回の送金を含む長い取引履歴で資産を送金した場合、それらをすべて検証する必要があり、かなりの負担になる可能性があります。

さらに、すべての取引には当事者間で複数のコミュニケーションが必要です。 受取人は送信者の資産のソースを検証し、送信者の転送リクエストを承認するために受領書を送信する必要があります。 このプロセスには当事者間で少なくとも3つのメッセージ交換が関与します。 この「インタラクティブトランスファー」は、ほとんどの人々が慣れ親しんでいる「非インタラクティブトランスファー」とは大きく異なります。 お金を送金する必要があると想像してみてください、そして送金データを検査するためにあなたに送信し、送金プロセスを完了する前にあなたの受領メッセージを待っている状況を。

さらに、前述のように、RGBネットワークには合意がなく、各クライアントが孤立して動作しているため、伝統的なパブリックチェーンから複雑なスマートコントラクトシナリオをRGBネットワークに移行することが難しいです。これは、イーサリアムやSolanaのDeFiプロトコルがグローバルに可視で透明な台帳に依存しているためです。RGBプロトコルを最適化し、ユーザーエクスペリエンスを向上させ、これらの課題に対処する方法は、RGBプロトコルにとって避けられない問題となります。

RGB++は楽観的なカストディアンアプローチを導入し、クライアントサイドの検証を置き換えます。

RGB++というプロトコルは、RGBプロトコルをCKB、Cardano、FuelなどのUTXOサポートされた公開チェーンと組み合わせることで新しいアプローチを導入しています。このセットアップでは、後者がRGBアセットの検証およびデータ保存レイヤーとして機能し、ユーザーが元々行っていたデータ検証タスクをCKBなどの第三者プラットフォーム/チェーンに移行させます。これにより、クライアント側の検証を「第三者分散型プラットフォーム検証」で置き換える効果があります。CKB、Cardano、Fuelなどのプラットフォーム/チェーンを信頼していれば問題ありません。信頼できない場合は、いつでも従来のRGBモードに切り替えることができます。

RGB++と元のRGBプロトコルは理論的に互換性があります。片方か他方かというケースではなく、共存することができます。

上記の効果を実現するには、「ホモモーフィック バインディング」と呼ばれる概念を活用する必要があります。CKBやCardanoなどのパブリックチェーンは、ビットコインチェーンのUTXOよりもプログラム可能性が高い拡張UTXOモデルを持っています。「ホモモーフィック バインディング」とは、CKBやCardano、Fuelなどのチェーン上の拡張UTXOをRGBアセットデータの「コンテナー」として使用するアイデアです。 RGBアセットのパラメータはこれらのコンテナーに書き込まれ、ブロックチェーン上で直接表示されます。 RGBアセット取引が発生するたびに、対応するアセットコンテナーも同様の特性を示すことができ、実体と影の関係に似た特性が現れます。これが「ホモモーフィック バインディング」の本質です。

(画像ソース：RGB++ LightPaper)

たとえば、Aliceが100のRGBトークンとビットコインチェーンのUTXO（UTXO Aと呼びましょう）を所有しており、また、CKBチェーン上に「RGBトークン残高: 100」とマークされたUTXOと、UTXO Aに関連付けられたアンロック条件を持っている場合:

Alice が Bob に 30 トークンを送信したい場合、まず、関連するステートメントを使用してコミットメントを生成できます：UTXO A に関連付けられた 30 RGB トークンを Bob に転送し、さらに 70 トークンを自分で制御する別の UTXO に転送します。

次に、アリスはUTXO Aをビットコインチェーン上で消費し、上記のステートメントを公開した後、CKBチェーン上でトランザクションを開始します。このトランザクションは、100 RGBトークンを保持するUTXOコンテナーを消費し、30トークンを保持する1つの新しいコンテナー（ボブ用）と70トークンを保持する別の新しいコンテナー（アリスが制御）を作成します。この過程で、アリスの資産とトランザクションステートメントの妥当性を検証する作業は、CKBやCardanoなどのネットワーク上のノード間の合意によって完了します。この時点で、CKBとCardanoは、それぞれビットコインチェーンの下において検証レイヤーおよびDA（データ可用性）レイヤーとして機能します。

（画像ソース：RGB++ LightPaper）

すべての個人のRGBアセットデータは、CKBまたはCardanoチェーンに保存されており、DeFiシナリオの実装を容易にするグローバルに検証可能な特性を提供しています。 もちろん、上記のアプローチはプライバシーを犠牲にしています。 それは基本的に、プライバシーと製品の使いやすさの間のトレードオフを含んでいます。 もし最高のセキュリティとプライバシーを重視するのであれば、従来のRGBモードに切り替えることができます。 これらのトレードオフを気にしないのであれば、個人のニーズに完全に依存して、RGB++モードを自信を持って採用することができます。 （実際、CKBやCardanoのようなパブリックチェーンの強力な機能を活用することで、プライバシートランザクションはZKの使用を通じて実現できます。）

RGB++は、重要な信頼の前提を導入していることを強調することが重要です：ユーザーは、CKB/Cardanoチェーンまたは大量のノードからなるネットワークプラットフォームが信頼性がありエラーがないと楽観的に信じる必要があります。 CKBを信頼していない場合は、クライアントを自分で実行して元のRGBプロトコルでの対話型コミュニケーションおよび検証プロセスに従うことができます。

RGB++プロトコルに従うと、ユーザーはクロスチェーン取引を必要とせずに、Bitcoinアカウントを直接使用して、CKB/Cardano UTXOチェーン上のRGBアセットコンテナを操作できます。彼らは単に、前述の公開チェーンのUTXOの特性を活用し、Cellコンテナのアンロック条件を特定のBitcoinアドレス/UTXOに関連付ける必要があります。RGBアセット取引に関与する当事者がCKBのセキュリティを信頼している場合、Bitcoinチェーン上でコミットメントを頻繁に公開する必要さえありません。その代わりに、複数のRGB転送が発生した後に、Bitcoinチェーンにコミットメントを集約して送信することができます。これは「トランザクション折りたたみ」機能として知られており、取引コストを削減できます。

ホモモーフィック バインディングで使用される「コンテナ」は、UTXO モデルを使用する公開チェーンによってサポートされるか、その状態の保存インフラストラクチャーに類似した機能を持つ必要があります。EVM ベースのチェーンはこの目的にはあまり適しておらず、多くの課題に直面する可能性があります。（このトピックは多くのコンテンツを含むため、別の記事で取り上げられる可能性があります。興味のある読者は、Geek Web3 による以前の記事「"）に言及してください。RGB++と同型結合：CKB、Cardano、およびFuelがBitcoinエコシステムを強化する方法。“)

要約すると、ホモモーフィック バインディングを実装するのに適したパブリック チェーンまたは機能拡張レイヤーは、次の特性を持つべきです:

1. UTXOモデルまたは類似の状態保存スキームを利用します。
2. 十分なUTXOのプログラム可能性を提供し、開発者がアンロックスクリプトを書くことができるようにします。
3. 資産状態を保存できるUTXOに関連する状態空間を持っています。
4. ビットコイン関連のブリッジやライトノードが利用可能です。

免責事項：

1. この記事は[Geek Web3]から転載されました。すべての著作権は元の著者に帰属します[ファウスト]. If there are objections to this reprint, please contact the Gate Learnチームが promptly それを処理します。
2. 責任の免責事項：この記事で表現されている見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳はGate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。