RGBとRGB++プロトコルの設計に関する数分間のクラッシュコース: 用語解説

著者：Faust、geekweb3 & BTCEden.orgの共同制作者

RGB++のリリースと関連資産の加熱に伴い、RGBとRGB++プロトコルの原理に関する議論が徐々に注目されるようになりました。より注目されるようになりました。しかし、RGB++を理解するためには、まずRGBプロトコルを理解する必要があることに誰もが気づいています。

元のRGBプロトコルは技術的な構造が少し不明瞭で、参考文献も散在しているため、体系的で理解しやすい参考文献は多くありません。 Geekweb3は、RGBとRGB++の体系的な解説を2つ公開しています（ブログ記事を参照）。Geekweb3は以前、RGBとRGB++に関する2つの体系的な記事を公開しました(私たちの公開番号の履歴を見ることができます)が、コミュニティメンバーのフィードバックによると、以前の記事は長すぎて脳が焼けるようです。

より多くの人にRGBとRGB++プロトコルをより速く理解してもらうため、この記事の著者は香港のイベント中に、RGBとRGB++の短い方言による説明を即興で作成しました。RGBとRGB++を理解する。

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

RGBプロトコルは特殊な種類のP2Pアセットプロトコルであり、ビットコインチェーンの下にある計算システムです。ユーザーは、自分に関連する送金を検証するために、自分でクライアントを実行しなければならない（Verify by yourself）。単なる資産の受取人であっても、その送金明細を検証する前に、資産の送り手の送金明細が間違っていないことを確認しなければなりません。これは、私たちが「双方向送金」と呼んでいる、資産を送受信する従来の形式とは明らかに異なるものです。

なぜこれが重要なのでしょうか？その理由は、RGBプロトコルは、プライバシーを保護するために、ビットコインやイーサなどの従来のブロックチェーンで使用されている「コンセンサス・プロトコル」を使用していないからです（いったんデータがコンセンサス・プロトコルを通過すると、ネットワーク内のほぼすべてのノードによって観察されることになり、プライバシーを保護するには良い方法ではありません）。多数のノードが参加するコンセンサス・プロセスがなければ、資産の変更が安全であることを保証することはできない。ここでは、あなた自身がクライアントを実行し、あなたに関連するアセット変更を個人的に検証する、「あなた自身による検証」と呼ばれるアイデアを使用します。

アリスを知っているボブというRGBユーザーがいて、アリスが100TESTトークンをボブに送金したいとします。アリスは "Alice to Bob "送金メッセージを生成した後、送金情報と関係するアセットデータをボブに送らなければなりません。つまり、RGB プロトコルは、従来のコンセンサス アルゴリズムに代わって、ユーザーが個人的にデータの有効性を確認できるようにしているのです。

しかし、コンセンサスがなければ、異なるRGBクライアントによって受信され保存されたデータは一貫性がなく、誰もが自分に関係する資産データのみをローカルに保存し、他の人の資産の状態については知りません。「データ・サイロ」を構成します。もし誰かが100万TESTトークンを持っていて、10万をあなたに送金したいと主張したら、あなたはどうやってその人を信用できるでしょうか？

RGBネットワークでは、誰かがあなたにお金を送金したい場合、あなたはまず彼に資産の証明を示すように求めなければなりません。出所不明の紙幣を受け取った後、偽造を回避する方法として、相手にその紙幣の歴史的な出所と、指定された発行者が作成したものかどうかを尋ねる。

（画像ソース：Coinex）

上記のプロセスはビットコインチェーンの下で行われ、それだけではRGBをビットコインネットワークに直接関連付けることはできません。これに対して、RGB プロトコルは、ビットコインチェーン上の UTXO に RGB 資産をバインドするために「シングルユースシール」と呼ばれるアイデアを使用しています。これにより、ビットコインネットワークを通じたRGB資産の「再組織化」が防止されます。もちろん、これはOP_Returnオペコードでビットコインチェーンに投稿されるコミットメントを必要とします。

RGBプロトコルのワークフローの簡単な概要は以下の通りです:

1.RGBアセットはビットコインUTXOに結び付けられます。

(Image credit: Geekweb3/ GeekWeb3)

2. アリスは、RGBの資産譲渡データの「アリスからボブへ」の合計を構築します。"の合計を構築します。

3. ボブはこのデータがOKであることをローカルで確認し、アリスに「このトランザクションは実行できます」と確認通知を送ります。

4. Aliceは「Alice to Bob」のRGB転送データからMerkle Treeを構築し、Merkle RootをビットコインチェーンにCommitとして投稿します。

5. 将来、誰かが「AliceからBob」への転送が実際に起こったことを確認したい場合、Merkle Treeを使って、転送に使われたMerkle Rootと同じでないことを確認できます。将来誰かが「AliceからBobへの」転送が実際に起こったことを確認したい場合、彼らは2つのことをする必要があります：ビットコインチェーンの下で完全な「AliceからBobへの」転送を取得し、対応するコミットメント（転送データのハッシュ）があるかどうかを確認するためにビットコインチェーンをチェックする、それだけです。

ビットコインはRGBネットワークの履歴ログとして機能しますが、ログは取引データのハッシュ/マッシュのみを記録します。取引データそのものではなく、取引データのハッシュ/メルクルルートを記録します。クライアント側の認証とワンタイムシールのため、RGB プロトコルは非常に安全です。 RGB ネットワークは P2P のコンセンサスのない動的なユーザークライアントで構成されているため、有限数のノードに取引リクエストを送信することなく、いつでも取引相手を変更することができます。は極めて検閲に強く、この組織形態はEtherのような大規模なパブリックチェーンよりもはるかに検閲に強い。

(Image source：BTCEden.org )

もちろん、極めて高いセキュリティと検閲耐性、プライバシー保護には、明らかな代償が伴います：ユーザーは、反対側が何万回も手を変え品を変え何かを送信する場合、データを検証するために独自のクライアントを実行する必要があります、

さらに、各取引は、送金者の送金要求を承認する領収書を送信する前に、受信者が送金者の資産の出所を確認するという、両者間の複数回の通信を必要とする。このプロセスでは、両者間で少なくとも3回のメッセージが発生する。このような「双方向の送金」は、多くの人が慣れ親しんでいる「非対話的な送金」とは一致しない。 誰かがあなたに送金し、あなたに取引データを送って確認させ、送金プロセスを完了する前にあなたの確認メッセージを受け取ることを想像できますか？送金のプロセスを完了する前に、あなたの確認メッセージを受け取ることができますか？

さらに、これまで述べてきたように、RGBネットワークにはコンセンサスがなく、各クライアントは島であるため、イーサリアムやソラナ上のDefiプロトコルがグローバルに可視化され、データが透過的な台帳に依存しているように、従来のパブリックチェーンからRGBネットワークへの複雑なスマートコントラクトシナリオの移行には適していません。台帳のユーザーエクスペリエンスを向上させ、上記の問題を解決するために、RGBプロトコルをどのように最適化するか？これは、RGBプロトコルが回避できない問題になります。

RGB++: Client Authentication Becomes Optimistic Hosting

RGB++と呼ばれるプロトコルは、CKBを使ったRGBプロトコルについての新しい考え方を提示しています、Cardano、Fuel、およびその他のUTXOをサポートするパブリックチェーンは、後者がRGBアセットの検証およびデータ保管レイヤーとして機能し、本来ユーザーが行うデータ検証作業をCKBのようなサードパーティのプラットフォーム/パブリックチェーンに引き継ぎます。これは、CKBを信頼する限り、クライアント検証を「検証を行うサードパーティの分散型プラットフォーム」に置き換えることに相当します。これは、CKB、Cardano、Fuelなどのパブリックチェーンを信頼している限り、クライアント側の検証を「検証を行うサードパーティの分散型プラットフォーム」に置き換えることと等価であり、信頼できない場合は、従来のRGBモードに切り替えることができる。

RGB++とオリジナルのRGBプロトコルは、理論的には互いに互換性があり、私がいなければ彼がいないというわけではありません。

上記のような効果を得るには、"CKBやCardanoのようなパブリックチェーンは、BTCチェーンのUTXOよりもプログラム可能な独自の拡張UTXOを持っています。同型バインディング」のアイデアは、CKB、Cardano、Fuelチェーン上の拡張UTXOをRGBアセットデータの「コンテナ」として使用し、RGBアセットのパラメータをこれらのコンテナに書き込み、ブロックチェーン上に直接表示することです。RGB資産取引が発生するたびに、対応する資産コンテナは、実体と影の関係のように、同様の特性を示すことができます。

(Image courtesy of RGB++, LightPaper)

(Image courtesy of RGB++, LightPaper)LightPaper）

例えば、アリスが100個のRGBトークンとビットコインチェーン上のUTXO Aを所有しており、CKBチェーン上にもUTXOがあるとします。"RGBトークン残高: 100 "と表示され、ロック解除条件はUTXO Aに関連付けられています。

アリスが30トークンをボブに渡したい場合、コミットメントとしてそうすることができます。これは、UTXO Aに関連付けられたRGBトークンを受け取り、そのうち30トークンをボブに、70トークンを彼女がコントロールする他のUTXOに転送するステートメントに相当します。"text-align: left;">その後、アリスはビットコインチェーン上でUTXO Aを使い、上記のステートメントを公開し、CKBチェーン上でトランザクションを開始し、100 RGBトークンを運ぶUTXOコンテナを消費し、2つの新しいコンテナを生成する。このプロセスでは、アリスの資産の有効性と取引明細の有効性を検証する作業は、ボブが介入することなく、CKBやCardanoのようなネットワークノードがコンセンサスを歩きながら行う。この時点で、CKBとカルダノはビットコインチェーンの検証レイヤーとDAレイヤーとして機能する。

()Image credit: RGB++ LightPaper)

RGBの資産データはすべて、グローバルに検証可能なCKBまたはカルダノチェーン上に保存され、流動性プールや資産質権設定契約などのDefiシナリオを容易にします。もちろん、上記のアプローチはプライバシーも犠牲にします。これは本質的に、プライバシーと製品の使いやすさのトレードオフです。 究極のセキュリティとプライバシーを追求するのであれば、従来のRGBモデルに戻すことができます。これを気にしないのであれば、個人のニーズに完全に依存するRGB++モデルを採用すれば安心です。(実際、CKBやCardanoのようなパブリックチェーンの強力な機能の完全性により、ZKでプライバシー取引を実現することは可能です。)

ここで強調しておきたいのは、RGB++は重要な信頼の前提を導入しているということです。ユーザーは、CKB/Cardanoチェーン、つまりCKB/Cardanoチェーンがプライバシーを実現する最善の方法であると楽観的に考えなければなりません。カルダノ・チェーン、つまりコンセンサス・プロトコルに依存する多数のノードからなるネットワーク・プラットフォームは、信頼性が高くエラーがない。CKBを信頼できない場合は、オリジナルのRGBプロトコルの対話型通信と検証プロセスに従って、自分でクライアントを実行することもできます。

RGB++プロトコルの下では、ユーザーはCKB/CardanoなどのUTXOチェーン上で自分のRGBアセットコンテナを、チェーンをまたぐことなく自分のビットコインアカウントで直接操作することができます。コンテナのロック解除条件を特定のビットコインアドレス/ビットコインUTXOに関連付けるだけです。RGB資産取引の両当事者がCKBのセキュリティを信頼し、ビットコインチェーンに頻繁にコミットメントを行う必要さえない場合、RGBの転送が多数行われた後にビットコインチェーンに単一のコミットメントを送信することができます。これは「トランザクション・コラプシング」として知られている。

ただし、同型バインディングに使用されるコンテナはUTDをサポートする必要があることに注意してください。"、パブリックチェーンのUTXOモデルをサポートする必要がある、またはインフラストラクチャの同様の特性の状態ストレージでは、EVMチェーンは非常に適していない、落とし穴の多くに遭遇するでしょう。（このトピックは、別の記事にすることができ、より多くのコンテンツが含まれ、興味のある読者は、geekweb3以前の記事を参照することができます"RGB++と同型バインディング：CKB、Cardano、Fuelはどのようにビットコインエコシステムを強化するか";"

まとめると、パブリックチェーン/パブリックチェーンの実装に適しているのは

1. UTXOモデルまたは類似の状態保存スキームを使用すること。

2. かなりのUTXOプログラマビリティを持ち、開発者はロック解除スクリプトを書くことができます。

3. 資産の状態を保存できるUTXO関連の状態空間があります。li>

4. ビットコイン関連のブリッジまたはライトノードの存在;