RGBプロトコル：ユーザーはデータ検証を自分で行う必要があります

RGBプロトコルは、Bitcoinチェーンの下にある特別なP2Pアセットプロトコルおよびコンピューティングシステムです。いくつかの側面で支払いチャネルに似ています：ユーザーはクライアントを自分で実行し、自分自身の転送動作を検証する必要があります（自分で検証）。アセットの受信者であっても、転送声明に誤りがないことをまず確認する必要があります。その後、転送声明が有効になります。これは明らかに従来の資産の送受信形式とは全く異なります。これを「インタラクティブ転送」と呼んでいます。

なぜそうなるのでしょうか?その理由は、プライバシーを確保するために、RGBプロトコルはビットコインやイーサリアムなどの従来のブロックチェーンの「コンセンサスプロトコル」を採用していないためです。(データがコンセンサスプロトコルを通過すると、ネットワーク内のほぼすべてのノードによって監視され、プライバシーは保証されません)。多数のノードが関与するコンセンサスプロセスなしで資産の変更が安全であることを保証するにはどうすればよいでしょうか?ここでは「Client Verification」(自分で確認する)という考え方が使われています。クライアントを自分で実行し、自分に関連するアセットの変更を個人的に確認する必要があります。アリスを知っているボブという名前のRGBユーザーがいて、アリスが100個のTESTトークンをボブに転送したいとします。アリスは「アリスからボブへ」の転送情報を生成した後、まず転送情報と関連するアセットデータをボブに送信し、後続の処理に入る前にボブに個人的に確認してもらい、最終的に有効なRGB転送になります。このように、RGBプロトコルを使用すると、ユーザーはデータの有効性を個人的に検証でき、従来のコンセンサスアルゴリズムに取って代わることができます。しかし、コンセンサスがなければ、異なるRGBクライアントによって受信および保存されるデータに一貫性がありません。誰もが自分の資産データをローカルに保存するだけで、他の人の資産ステータスを知ることはできません。プライバシーを保護する一方で、これは「データアイランド」にもなります。誰かが100万のTESTトークンを持っていると主張し、100,000をあなたに送金したいと言ったら、どうしてそれを信じることができますか?RGBネットワークでは、誰かがあなたに送金したい場合、彼は最初に資産の証拠を提示し、最初の発行から複数の所有者の変更までの資産の履歴ソースをさかのぼり、あなたに送金されるトークンがクリーンであることを確認する必要があります。これは、出所不明の紙幣を受け取ったときに、偽造通貨を避けるために、その紙幣の歴史的出所と指定された発行者によって作られたかどうかを相手に説明を求めるようなものです。

（画像ソース：Coinex）

上記のプロセスはビットコインチェーンの下で発生し、これらのプロセスだけではRGBを直接ビットコインネットワークに関連付けることはできません。この点で、RGBプロトコルは、RGB資産をビットコインチェーンのUTXOにバインドするために「シングルユースシール」というアイデアを採用しています。ビットコインのUTXOが二重に消費されていない限り、バウンドされたRGB資産は二重に支出されません。このようにして、ビットコインネットワークを使用してRGB資産の「再編成」を防ぐことができます。もちろん、このコミットメントはビットコインチェーン上に公開され、OP_Returnオペコードが使用されます。

RGBプロトコルのワークフローの概要です。

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

（画像ソース：Geekweb3/GeekWeb3）

1. Aliceは、「Alice to Bob」RGBアセット転送データを構築し、これらのアセットの歴史的ソースとともにBobに渡して検証します。
2. ボブがローカルでデータが正常であることを確認した後、トランザクションが完了できることをアリスに伝えるために、受領書を送信します。
3. Aliceは、「Alice to Bob」のRGB転送データをMerkle Treeに構築し、Merkle RootをBitcoinチェーンにコミットメントとして公開します。コミットメントは単純に転送データのハッシュとして理解できます。
4. 将来、上記の「アリスからボブへ」の転送が実際に行われたことを確認したい場合、彼は2つのことを行う必要があります。まず、ビットコインチェーン上の「アリスからボブへ」の完全な転送情報を取得し、次に、ビットコインチェーン上の対応するトランザクションがあるかどうかを確認します。これにより、コミットメント（転送データのハッシュ）が得られます。

BitcoinはここでRGBネットワークの歴史的なログとして機能しますが、取引データのハッシュ/メルクルルートのみがログに記録されます。取引データ自体ではなく。クライアントサイドの検証とワンタイムシールドにより、RGBプロトコルは非常に高いセキュリティを持っています。RGBネットワークはP2Pの動的ユーザークライアントで構成されており、コンセンサスが不要です。したがって、取引リクエストを限られたノードに送信せずにいつでもカウンターパーティを変更できます。そのため、RGBネットワークは極めて検閲に強く、この組織形態はEthereumなどの大規模な公開チェーンよりも検閲に対して耐性があります。

(画像ソース: BTCEden.org)

確かに、非常に高いセキュリティ、検閲耐性、およびプライバシー保護には明らかなコストがかかります：ユーザーはクライアントを実行してデータを自分自身で検証する必要があります。もしその他の当事者から何度も取引され、長い歴史を持つ資産を送金された場合、ユーザーはすべての検証をプレッシャーの中で行わなければなりません。

さらに、各取引には2つの当事者間で複数回の通信が必要です。受信側はまず送信者の資産のソースを確認し、その後送信者の送金リクエストを承認するために受領書を送らなければなりません。このプロセス中には、少なくとも2つの当事者間で3つのメッセージがやり取りされなければなりません。この種の「対話型転送」は、ほとんどの人々が慣れ親しんでいる「非対話型転送」とは深刻に一致していません。

あなたにお金を送金したいと思っている人がいると想像してみてください。しかし、彼らはあなたに検証のための取引データを送らなければならず、あなたの受領メッセージを受け取ってからのみ送金プロセスが完了できますか？

また、RGBネットワークにはコンセンサスがなく、各クライアントが孤立していると述べました。これは、従来のパブリックチェーン上の複雑なスマートコントラクトシナリオをRGBネットワークに移行するのに適していません。なぜなら、EthereumやSolana上のDefiプロトコルは、グローバルに可視でデータ透明な台帳に依存しているからです。RGBプロトコルを最適化し、ユーザーエクスペリエンスを向上させ、上記の問題を解決する方法は？これがRGBプロトコルにとって避けられない問題となっています。

RGB++: クライアントサイドの検証は楽観的な保管となります

RGB++というプロトコルは新しいアイデアを提案しています。これは、RGBプロトコルをサポートするCKB、Cardano、およびFuelなどのUTXOをサポートするパブリックチェーンと組み合わせています。後者はRGBアセットの検証レイヤーおよびデータストレージレイヤーとして機能し、元々ユーザーによって処理されたデータを検証作業に変換し、CKBなどのサードパーティプラットフォーム/パブリックチェーンに引き渡します。これは、クライアント検証を「第三者の分散型プラットフォームに置き換える」ということに相当し、CKB、Cardano、Fuelなどのパブリックチェーンを信頼すれば、信頼できます。信頼できなくても、従来のRGBモードに切り替えることができます。

RGB++とオリジナルのRGBプロトコルは理論的に互換性があります。

上記の効果を達成するには、「等質結合」というアイデアを使用する必要があります。CKBやCardanoなどのパブリックチェーンは、BTCチェーン上のUTXOよりもプログラマブル性の高い拡張UTXOを持っています。「等質結合」とは、CKB、Cardano、Fuelチェーン上の拡張UTXOをRGBアセットデータの「コンテナ」として使用し、これらのコンテナにRGBアセットのパラメータを書き込み、それらをブロックチェーン上で直接表示することです。RGBアセットの取引が発生するたびに、対応するアセットコンテナにも同様の特性が表示され、実体と影の関係のようなものです。これが「等質結合」の本質です。

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

例えば、Aliceが100のRGBトークンとビットコインチェーンのUTXO Aを所有しており、また、CKBチェーン上にもUTXOを持っている場合、このUTXOは「RGBトークン残高：100」とマークされ、アンロック条件はUTXO Aに関連しています。

Alice が Bob に 30 トークンを送りたい場合、まず Commitment を生成することができます。対応する文は次のとおりです: UTXO A に関連付けられた RGB トークンの 30 を Bob に送信し、残りの 70 を彼女がコントロールしている他の UTXO に送信します。

その後、アリスはUTXO Aをビットコインチェーンで消費し、上記の声明を公開し、その後、CKBチェーンでトランザクションを開始して、100 RGBトークンを搭載したUTXOコンテナを消費し、30トークンを保持する1つの新しいコンテナと70トークンを保持する1つの新しいコンテナを生成します（ボブに対して）、アリスが制御します。 このプロセスでは、アリスの資産の有効性とトランザクション声明の有効性を検証する作業は、ボブの介入なしに、CKBやCardanoなどのネットワークノードによってビットコインチェーンの下で合意に基づいて完了されます。 この時点で、CKBとCardanoは、ビットコインチェーンの下で検証レイヤーおよびDAレイヤーとして機能します。

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

誰ものRGBアセットデータは、グローバルに検証可能な特性を持ち、流動性プールや資産担保プロトコルの実装に有利なCKBまたはCardanoチェーンに保存されます。 もちろん、上記のアプローチはプライバシーを犠牲にしています。 その本質は、プライバシーと製品の使いやすさとの間でトレードオフを行うことです。 究極のセキュリティとプライバシーを追求する場合は、従来のRGBモードに切り替えることができます。 それに関心がない場合は、RGB++モードを安全に使用できます。 すべてはあなたの個人のニーズに依存します。（実際、CKBやCardanoなどのパブリックチェーンの機能的な完全性により、ZKを使用してプライベートトランザクションを実装することができます）

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

RGB++プロトコルにより、ユーザーは、Bitcoinアカウントを直接使用して、CKB/CardanoなどのUTXOチェーン上でRGBアセットコンテナを操作することができます。クロスチェーンなしで。上記のパブリックチェーンのUTXOの特性を利用し、Cellコンテナのアンロック条件を特定のBitcoinアドレス/Bitcoin UTXOに関連付けるように設定します。RGBアセット取引に関与する両当事者がCKBのセキュリティを信頼できる場合、Bitcoinチェーン上で頻繁にCommitmentsを発行する必要はありません。多くのRGB転送が行われた後、BitcoinチェーンにCommitmentを送信できます。これは「トランザクション折りたたみ」機能と呼ばれ、使用コストを削減できます。

ただし、isomorphicバインディングで使用される「コンテナ」には、UTXOモデルをサポートするパブリックチェーン、またはステートストレージに類似した特性を持つインフラが必要です。EVMチェーンは適しておらず、多くの落とし穴に直面することになります。（このトピックは別途で書かれ、多くの内容を含んでいます。興味のある読者は、Geek Web3の以前の記事を参照してください。）「RGB++と同型結合：CKB、Cardano、Fuelがビットコインエコシステムを強化する方法」；

要約すると、等価結合を実現するのに適した公開チェーン/機能拡張レイヤーは、次の特性を持つ必要があります:

1. UTXOモデルまたは類似の状態保存スキームを使用してください;
2. かなりのUTXOプログラム可能性があり、開錠スクリプトを書くことができる開発者向け
3. 資産状態を格納できるUTXO関連の状態空間があります;
4. Bitcoin関連のブリッジやライトノードがあります;

免責事項:

1. この記事は[から再生されましたギーク Web3],元のタイトルは「RGBとRGB++プロトコルの設計を数分で: 簡単な手順」となっています、著作権は元の著者[Faust]に帰属します、転載に異議がある場合はご連絡くださいGate Learn チーム, チームは関連手続きに従ってできるだけ早く対応します。

2. この記事で表明された意見および見解は、著者個人の見解を表しており、投資アドバイスを構成するものではありません。

3. 他の言語版の記事は、Gate Learnチームによって翻訳されています。参照なしGate.io, 翻訳記事の複製、配布、または盗用は禁止されています。