原作者: Faust、Geek web3 BTCEden.org Lianchuang (X: @faustliu1997)

元のソース:オタクウェブ3

RGB++ および関連資産の発行の人気に伴い、RGB および RGB++ プロトコルの原理に関する議論は、徐々に多くの人々にとって関心のあるトピックになってきました。しかし、RGB++ を理解するには、まず RGB プロトコルを理解する必要があることは誰もが認識しています。

オリジナルの RGB プロトコルは技術構造の点でやや曖昧であり、参考資料も散在しています。体系的でわかりやすい参考資料はこれまでのところあまりありません。geek web3 では以前に RGB と RGB++ に関する体系的な解釈記事を 2 つ掲載していますが、 （公式アカウントの歴史をご覧ください）しかし、コミュニティメンバーからのフィードバックによると、前述の記事は長すぎて、頭が疲れすぎます。

より多くの人が RGB および RGB++ プロトコルをより早く理解できるようにするために、この記事の著者は香港でのイベント中に RGB および RGB++ の短い現地語の解釈を急いで完成させました。読者は RGB と RGB++ をより良く、より直観的に理解できるようになります。

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

RGB プロトコルは特別な P2P アセット プロトコルであり、ビットコイン チェーンから離れたコンピューティング システムです。いくつかの点で支払いチャネルに似ています。ユーザーは自分でクライアントを実行し、自分の送金動作を検証する必要があります (自分で検証する)。単なるアセットの受信者であっても、転送ステートメントが有効になる前に、まずアセット送信者の転送ステートメントにエラーがないことを確認する必要があります。明らかに、これは従来のアセットの送受信形式とはまったく異なり、私たちはこれを「インタラクティブ転送」と呼んでいます。

なぜそうなるのでしょうか?その理由は、プライバシーを確​​保するために、RGB プロトコルは、ビットコインやイーサリアムなどの従来のブロックチェーンの「コンセンサス プロトコル」を採用していないためです（データがコンセンサス プロトコルを通過すると、ネットワーク内のほぼすべてのノードによって監視されます） 、プライバシーは保証されません。）。多数のノードが関与する合意プロセスを行わずに、アセットの変更が安全であることを確認するにはどうすればよいでしょうか?ここでは「クライアント検証」（自分で検証する）と呼ばれる考え方が使用されており、クライアントを自分で実行し、自分に関連する資産の変更を個人的に検証する必要があります。

アリスのことを知っているボブという名前の RGB ユーザーがいて、アリスが 100 個の TEST トークンをボブに転送したいとします。アリスが「アリスからボブへ」の転送情報を生成した後、最初に転送情報と関連する資産データをボブに送信し、後続のプロセスに入る前にボブに個人的にチェックさせて、それが正しいことを確認してもらいます。有効な RGB 転送。したがって、RGB プロトコルを使用すると、従来のコンセンサス アルゴリズムに代わって、ユーザーがデータの有効性を個人的に検証できるようになります。

しかし、コンセンサスはなく、異なる RGB クライアントによって受信および保存されたデータには一貫性がありません。誰もが自分の資産データをローカルに保存するだけで、他の人の資産ステータスは知りません。これにより、プライバシーが保護されると同時に「データ アイランド」が形成されます。誰かが 100 万の TEST トークンを持っていると主張し、100,000 をあなたに送金したいと主張したら、どうやって彼を信じることができますか?

RGB ネットワークでは、誰かがあなたに送金したい場合、まず資産の証拠を提示し、最初の発行から複数​​回の譲渡に至るまで資産の歴史的情報源を追跡し、トークンがあなたに送金されることを確認する必要があります。正体不明の紙幣を受け取ったときは、偽造紙幣を避けるために、その紙幣の歴史的起源や指定された発行者が発行した紙幣であるかどうかを相手に説明してもらいます。

（画像出典：Coinex）

上記のプロセスはビットコイン チェーンから外れて発生し、これらのプロセスだけでは RGB がビットコイン ネットワークと直接接続することはできません。この点、RGBプロトコルでは「シングルユースシール」と呼ばれる考え方を採用し、RGBアセットをビットコインチェーン上のUTXOにバインドしており、ビットコインUTXOが二重に消費されない限り、バインドされたRGBアセットが2倍になることはありません。ビットコイン ネットワークを使用して RGB アセットの「再編成」を防ぐことができるということです。もちろん、これにはビットコインチェーン上でコミットメントを発行し、OP_Return オペコードを使用する必要があります。

RGB プロトコルのワークフローの概要は次のとおりです。

1. RGB アセットはビットコイン UTXO にバインドされており、ボブは特定のビットコイン UTXO を所有しています。アリスは 100 個のトークンをボブに転送したいと考えています。資産を受け取る前に、ボブはボブのどのビットコイン UTXO をこれらの RGB アセットのバインドに使用する必要があるかをアリスに事前に伝えます。

（画像出典：Geek web3/Geek Web3）

• アリスは、これらのアセットの履歴ソースとともに「アリスからボブ」RGB アセット転送データを構築し、検証のためにボブに渡します。

• ボブはデータが正常であることをローカルで確認した後、トランザクションが完了できることを伝える領収書をアリスに送信します。

• アリスは「アリスからボブ」のRGB転送データをマークルツリーに構築し、マークルルートをコミットメントとしてビットコインチェーンに公開しますが、コミットメントは単純に転送データのハッシュとして理解できます。

• 誰かが将来、上記の「アリスからボブ」への転送が実際に起こったことを確認したい場合は、次の 2 つのことを行う必要があります。1 つは、ビットコイン チェーンの下で「アリスからボブ」への完全な転送情報を取得し、次に、次のことを確認することです。ビットコインチェーン上に対応するトランザクションがある コミットメント（転送データのハッシュ）、それだけです。

ここでのビットコインは RGB ネットワークの履歴ログとして機能しますが、トランザクション データ自体ではなく、トランザクション データのハッシュ/マークル ルートのみがログに記録されます。クライアント検証とワンタイム シーリングの使用により、RGB プロトコルは非常に高いセキュリティを備えています。RGB ネットワークは P2P の非コンセンサス形式の動的ユーザー クライアントで構成されているため、いつでも取引相手を変更できます。トランザクション リクエストは限られた数のノードに送信されるため、RGB ネットワークは検閲に非常に耐性があり、この組織形態はイーサリアムなどの大規模なパブリック チェーンよりも検閲に耐性があります。

(画像出典: BTCEden.org)

もちろん、非常に高いセキュリティ、検閲耐性、プライバシー保護のコストも明らかです: ユーザーは自分でクライアントを実行してデータを検証する必要があります。長い歴史があるので、プレッシャーの下でもすべてを検証する必要があります。

さらに、各トランザクションでは両当事者間で複数回の通信が必要となるため、受信側はまず送信者の資産の出所を確認し、送信者の送金リクエストを承認するために領収書を送信する必要があります。このプロセス中に、少なくとも 3 つのメッセージが 2 つの当事者間で受け渡される必要があります。この種の「インタラクティブな送金」は、ほとんどの人が慣れ親しんでいる「非インタラクティブな送金」とは大きく矛盾しています。誰かがあなたに送金したい場合、確認して取得するために取引データを送信する必要があることを想像できますか?メッセージを受信した後でのみ転送プロセスを完了できますか?

さらに、RGB ネットワークにはコンセンサスがなく、各クライアントはアイランドであると述べましたが、イーサリアムやソラナの Defi プロトコルはすべて A に依存しているため、従来のパブリック チェーン上の複雑なスマート コントラクト シナリオを RGB ネットワークに移行するのは困難ですグローバルに表示され、データが透明な台帳。 RGB プロトコルを最適化し、ユーザー エクスペリエンスを向上させ、上記の問題を解決するにはどうすればよいでしょうか?これは、RGB プロトコルにとって避けられない問題となっています。

RGB++: クライアント検証が楽観的ホスティングになる

RGB++と呼ばれるプロトコルは新しいアイデアを提唱しており、RGBプロトコルとCKB、Cardano、FuelなどのUTXOをサポートするパブリックチェーンを組み合わせており、後者はRGBアセットの検証層およびデータストレージ層として機能し、本来実行されたデータを変換しますユーザーによる検証作業はCKBなどのサードパーティプラットフォーム/パブリックチェーンに引き継がれます。これは、クライアント認証を「検証用のサードパーティ分散プラットフォーム」に置き換えることに相当します。CKB、Cardanoなどのパブリックチェーンを信頼している限り、 、燃料などを信頼できない場合は、従来の RGB モードに戻すこともできます。

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

上記の効果を実現するには、「同型バインディング」と呼ばれる考え方を使用する必要があります。 CKB や Cardano などのパブリック チェーンには独自の拡張 UTXO があり、BTC チェーンの UTXO よりもプログラム可能です。 「同型バインディング」とは、CKB、Cardano、および Fuel チェーン上の拡張 UTXO を RGB アセット データの「コンテナ」として使用し、RGB アセットのパラメータをこれらのコンテナに書き込み、ブロックチェーン上に直接表示することです。 RGB アセット トランザクションが発生するたびに、エンティティとシャドウの関係と同様に、対応するアセット コンテナも同様の特性を示すことができます。これが「同型バインディング」の本質です。

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

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

アリスが 30 個のトークンをボブに送信したい場合、最初にコミットメントを生成できます。対応するステートメントは、UTXO A に関連付けられた RGB トークンのうち 30 個をボブに転送し、70 個を彼女が制御する他の UTXO に転送します。

その後、アリスはビットコイン チェーン上で UTXO A を消費し、上記のステートメントを公開してから、CKB チェーン上でトランザクションを開始して、100 個の RGB トークンを保持する UTXO コンテナを消費し、2 つの新しいコンテナを生成します。1 つは 30 個のトークンを保持し、もう 1 つは (ボブに) 70 個のトークンを保持します (アリスによって制御されます)。このプロセスでは、アリスの資産の有効性と取引明細の有効性を検証するタスクは、ボブの介入なしに、コンセンサスを通じて CKB や Cardano などのネットワーク ノードによって完了します。現時点では、CKB と Cardano は、ビットコインチェーンの下で検証層と DA 層として機能します。

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

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

ここで、RGB++ では重要な信頼性の前提が導入されていることを強調しておく必要があります。ユーザーは、CKB/Cardano チェーン、またはコンセンサス プロトコルに依存する多数のノードで構成されるネットワーク プラットフォームが信頼でき、エラーが発生しないと楽観的でなければなりません。 CKB を信頼しない場合は、元の RGB プロトコルの対話型通信および検証プロセスに従い、クライアントを自分で実行することもできます。

RGB++プロトコルの下では、ユーザーは直接ビットコインアカウントを使用して、クロスチェーンなしでCKB/CardanoなどのUTXOチェーン上で独自のRGBアセットコンテナを操作でき、上記のパブリックチェーンでUTXOの特性を利用してロック解除条件を設定するだけで済みます。 Cellコンテナの特定のビットコインアドレス/ビットコインUTXOに紐付けるように設定するだけです。 RGB アセットトランザクションの両当事者が CKB のセキュリティを信頼している場合、ビットコイン チェーン上でコミットメントを頻繁に発行する必要さえありません。多くの RGB 転送が完了した後、ビットコイン チェーンにコミットメントを送信できます。これは「」と呼ばれます。トランザクションフォールディング」機能により、利用コストを削減できます。

ただし、同型バインディングで使用される「コンテナ」には、UTXO モデルをサポートするパブリック チェーン、または状態ストレージに同様の特性を持つインフラストラクチャが必要であることに注意してください。EVM チェーンは適切ではなく、多くの落とし穴に遭遇します。 (このトピックは個別に書くことができ、多くの内容が含まれます。興味のある読者は Geek Web3 の以前の記事を参照してください。「RGB++ と同形バインディング: CKB、Cardano、および Fuel がビットコイン エコシステムをどのように強化するか」；

まとめると、同型バインディングの実装に適したパブリック チェーン/機能拡張層は、次の特性を持つ必要があります。

• UTXO モデルまたは同様の状態ストレージ スキームを使用します。

• UTXO はかなりのプログラマビリティを備えており、開発者はロック解除スクリプトを作成できます。

• 資産ステータスを保存できる UTXO 関連の状態空間があります。

• ビットコイン関連のブリッジまたはライトノードがあります。