RGBからRGB++へ：CKBをビットコインのLayer2およびオンチェーン決済層として再考する
TechFlow厳選深潮セレクト
RGBからRGB++へ：CKBをビットコインのLayer2およびオンチェーン決済層として再考する
RGB++の本質は、利便性を得るためにプライバシーを犠牲にすることであり、同時にRGBプロトコルでは実現不可能なシナリオをもたらす。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Shew、Faust，Geek web3
アドバイザー：CyberOrange，Unipass
概要（やや長め）：RGBプロトコルは有望なBTC拡張プロトコルであり、本質的にはオフチェーン計算システムである。ライトニングネットワークと同様の思想を採用しており、「自身に関連する資産変動をユーザーが自ら検証・承認する（Verify by yourself）」という方式を取り、取引当事者が合意した結果やコミットメントをビットコインチェーン上に記録する。
-
RGBプロトコルは、カラードコインやMastercoinと一部似た発想を活用し、ビットコインのUTXOに「寄生的資産」を関連付けている。オフチェーン取引データのコミットメント（約束値）をビットコインチェーン上に保存するもので、Ordinalsプロトコルのように完全なDAデータをオンチェーンに掲載するわけではない。ビットコインチェーン上に記録されたコミットメント値に基づき、RGBクライアントは他のクライアントが提供するRGB履歴データが有効かどうかを検証できる。
-
また、ハッシュ/コミットメントだけでは背後にあるオリジナルデータを復元できないため、第三者はオンチェーンのコミットメントに対応するオフチェーンデータを直接観測できない。これによりプライバシーが保護され、インスクリプションに比べてスペースも節約できる。第三者の視点からは、RGBクライアントが実際に行っていることが分からない。
-
さらに、RGBはビットコインUTXOの一回限り使用の特性を利用して、「ワンタイムシール（一時封印）」というアイデアを通じて、RGB資産の所有権をビットコインUTXOに関連付ける。これにより、ビットコインの強固なセキュリティを借りて、RGB資産の「二重支出（ダブルスペンディング）」を防ぐことができる（ビットコインUTXOが二重支出されない限り、RGB資産も二重支出されない）。
-
しかし、RGBはビットコインチェーン外で動作するスマートコントラクトシステムであり、各クライアントがローカルに履歴データを保持する必要がある。異なるクライアント（ユーザー）は自分に関係するデータのみを保管し、他人の資産状況を見ることはできない。この「データ孤島」はプライバシーを守る一方で、大規模な普及を妨げる要因となり、OTC取引者によるP2Pネットワークに近い構造となる。
-
RGB++の考え方は、CKBチェーン上のCellを使ってRGB資産の所有権関係を表現することである。従来RGBクライアントのローカルに保存されていた資産データを、CKBチェーン上でCellとして表現し、ビットコインUTXOとの間で1対1のマッピング関係を構築する。これにより、CKBはRGB資産の公開データベースおよびオフチェーン前処理レイヤーとして機能し、独立したクライアントの代わりに、より信頼性の高いデータホスティングとRGBコントラクトの相互作用を実現する。これは、他のUTXO型L2にとっても「同種結合（homomorphic binding）」というトレンドである。
-
RGBプロトコル自体はインタラクティブな送金プロセスしかサポートしておらず、取引両者が頻繁に通信する必要がある。この方式はDeFiシーンには不向きであり、RGB資産の発行にも不利である。CKBが個別クライアントを代替することで、非インタラクティブなRGB取引が可能になり、DeFiの実装やエアドロップ機能などが容易になる。また、BTC資産をクロスチェーンなしでCKBチェーン上の資産と直接やり取りできるようになる。
-
RGB++の本質は、使いやすさを得るためにプライバシーを犠牲にすることであり、同時に従来のRGBプロトコルでは実現できなかったユースケースを提供する。製品の使いやすさと機能の完全性を重視するユーザーはRGB++を好むだろう。一方で、プライバシーと「Verify by yourself」の安全性を追求するユーザーは伝統的なRGBプロトコルを選ぶことになる。すべてはユーザー自身の選択次第である。（理論的には、ZKなどの技術でRGB++のプライバシー問題も解決可能である）
RGBプロトコルの原理とその利点・欠点
RGBプロトコル自体は比較的複雑な仕組みであり、具体的なRGB資産の送金例を通じて、その動作方法を説明する。
RGBプロトコルに準拠したトークン「TEST」があるとする。AliceはBobに100個のTESTトークンを送ってほしいと依頼している。つまり、Bob → Aliceのトークン送金を生成したい。
ここでまず、RGBプロトコルは「ワンタイムカプセル化（一時封入）」という考え方を採用している。表面上はBobがAliceに送金しているように見えるが、実際にはBobがビットコインチェーン上のUTXO Aを制御しており、そのUTXO Aが何らかの方法で特定のRGB資産と関連付けられているということだ。
もしBobが「UTXO Aに関連付けられた部分のRGB資産をAliceに譲渡する」と宣言する場合、以下のように宣言できる。「UTXO Aに関連付けられた30枚のTESTトークンを、UTXO Bに関連付けることにする」。AliceがUTXO Bの所有者であれば、彼女はその30枚のTESTトークンを所有することになる。
（図出典：Discoco Labs）
実際のビットコインチェーン上での所有権記録方法はすべてUTXOによって実現されており、「UTXO Bがxx数量のRGB資産を制御する資格がある」と宣言することは、すなわち「UTXO Bの所有者がxx数量のRGB資産を制御できる」ことを意味する。これは私たちが慣れ親しんでいるアカウントアドレスモデルとは一致しないが、ビットコインなどUTXO型パブリックチェーンの特徴である。
この点を理解した上で、RGBプロトコルの動作手順を確認すると、染色コインやMastercoinといったビットコインUTXO寄生資産との違いが見えてくる。
1. RGBプロトコルの仕組みに従い、Aliceはまず送金取引のためにインボイス（請求書）を発行し、自分の意図を明示する。インボイスには以下の情報が含まれる：
-
コントラクトID：AliceがどのRGB資産コントラクトと相互作用するかを宣言
-
インターフェース：Bobがコントラクトのすべての操作インターフェースを把握できるようにする
-
操作：AliceがBobに呼び出してほしいコントラクトのインターフェース名
-
ステータス：Bobが変更すべきコントラクトの状態。ここではBobがAliceに送るトークンの数量
-
Seal（シール）：ワンタイムシールに使うUTXO。単純に言えば、AliceがBobからのRGB資産権限を受け取るためのUTXO。
最終的に、Aliceは以下の形式のインボイス内容を得る：
上記のインボイスは以下のフォーマットに従う：
2. AliceはこのインボイスをBobに送る必要がある。Bobはインボイスの内容を確認し、Aliceの意図に従って新しいRGB取引を生成し、RGB資産をAliceに譲渡する。
ただし注意が必要なのは、Bobが実際にTEST資産の一部を所有していることを証明しなければならない点である。なぜなら、RGBプロトコルは「グローバルに可視な資産ステータス記録」を持たず、イーサリアムのように共通の管理コントラクトで全員の資産を記録・処理する仕組みではないからだ。
RGBプロトコル下では、各クライアントは自身に関係する資産データ（現在の残高、履歴的由来など）のみを記録しており、各クライアントの記録内容は基本的に異なる。そのため、誰も他人の資産状況を確認できず、P2P取引時には資産保有の証明を提示する必要がある。
比喩で言えば、相手と紙幣で取引しているが、相手の紙幣が偽札かどうか分からない。そこで、その紙幣がどこから来て、何人の手を経てきたかを説明させ、偽札ではないかを判断するのである。
双方が互いに認め合えば、安心して取引できる。各RGB取引は参加者間の合意だけで成立し、完全にP2P的である（OTCに類似）。
明らかに、この方式はプライバシーを保護する。個人の資産状況や取引履歴は外部に知られにくく、あなたと取引相手が何をしたかは第三者には分からない。まるで現金取引が銀行振込よりも匿名性が高いのと同じ理屈である。しかし、ユーザーエクスペリエンス（UX）には悪影響を与える。
前述のAliceとBobの事例では、BobがAliceのインボイスを受け取り、その意図を把握した後、自らのクライアントに保存されたTEST資産に関連する過去の送金履歴を選出し、新しく生成されたBob → Aliceの送金データとともにAliceに検証させる。これにより、新たなRGB取引／所有権変更の裏にある資産由来が正当であることを証明する。
一般に、クライアントがローカルに保存するデータは「Stash（隠し場所）」と呼ばれる。これはRGB資産の過去データを含み、RGB資産コントラクトのログ記録と考えることができる。
3. AliceがBobからデータと新しいBob → Aliceの取引を受け取ったら、その正当性を検証する。検証が通れば、Aliceは「確認署名」を生成し、Bobに返信する。
4. BobがAliceの確認署名を受け取った後、Bob → Aliceの取引に対応するコミットメント（Commitment）をBTCネットワーク内にブロードキャストし、最終的にBTCチェーン上に書き込まれ、「最終性（finality）」を持つ。
（コミットメントの構造図。実際にはMerkleルート）
もしBob → Aliceの送金において、UTXO Bの所有者が30枚のTESTトークンを所有すると宣言されているなら、AliceがUTXO Bの所有者であることを証明すれば、これらのTESTトークンを使用できる。
5. 将来、AliceがTESTトークンを他の人に送る場合、そのTESTの履歴由来を提示するとき、相手はビットコインチェーン上のコミットメント値を使って検証できる。Aliceが提示したデータがチェーン上のコミットメントと一致するかを確認することで、データの偽造を防ぐ。
RGBプロトコルの利点は、オフチェーンで複雑なスマートコントラクト計算をサポートできることにある。計算処理をBTCチェーン外に移し、オンチェーンにはコミットメントのみを記録する。これによりプライバシーを守りつつ、オフチェーンでビットコインUTXOとRGB資産所有権の関連を宣言し、ビットコインを使ってRGB資産の所有権変更を刻印・実現する。
すべての取引宣言は当事者の検証と承認を必要とするため、そのセキュリティモデルは「合理的人間の仮定」に基づいている。当事者が合理的であり、ビットコインが安全なら、RGB資産の所有権も「基本的に安全」である。
しかし、RGBプロトコルの欠点も明らかである（前述のデータ孤島と断片化ストレージ問題）。まず、他人に送金するには相手の同意と確認を事前に得る必要があり、基本的には双方がオンラインで同期する必要がある。
次に、グローバルに可視なデータ記録手段がないため、RGBのコントラクト発行さえ非常に奇妙な形態を取る。コントラクト利用者は事前にコントラクト発行者から、コントラクトに含まれるインターフェース機能を知る必要がある。具体的な方法としてはメールやQRコード読み取りなどがある。（公式の見解によると、コントラクトコードを公式サイトトップやTwitterのピン留めにするのも可能だろう）
続いて、RGBプロトコルのコントラクトステートについて考察する。RGBプロトコルでは、コントラクトの初期状態（Genesis）は作成時に作成者が設定する。例えばRBG-20コントラクトにおけるトークン名や総量などである。その後、コントラクトの状態は継続的なRGB取引とともに変化するが、この状態の進化は非線形的であり、有向非巡回グラフ（DAG）を形成する。
（図中、owner1の視野範囲は青と緑の部分、Owner2は青と黄色の部分）
例えばBobがAliceに送金する際、コントラクト初期化からBobがトークンを取得するまでの部分的な送金履歴のみを提示するため、データパスは狭くなる。Aliceもその分岐に含まれる取引情報しか知ることができず、他人の送金情報を知ることは難しい。これはRGBユーザーのプライバシーを守る一方で、悪い影響もある：ユーザーはRGBコントラクトのグローバルステート（誰がどれだけのRGB資産を持っているかなど）を把握しにくい。これが多くの問題を引き起こす。
例えば、Bob → Aliceの送金が最終段階に達し、そのコミットメントがBTCチェーンに書き込まれて不可逆になった後、Bobはローカルから部分データを削除できる。もしBobがすべてのTESTトークンを他人に渡した場合、ローカルのTEST関連データを削除してストレージ負荷を軽減できる。
一方、受取人であるAliceは、当該取引に関わるすべてのデータをローカルに記録しなければならない。（もしBobがTESTデータを削除し、Aliceのクライアントノードが事故で完全に破損したら、Aliceの資産は永久に凍結してしまうのではないか？ 他の場所にデータが保存されていない限り、事前にバックアップしていない限りはそうなる。）
これは本質的にDA（データ可用性）とデータストレージの問題に帰着する。つまり、RGBプロトコルの追加データは信頼性高く、グローバルに可視な方法で広がることが不可能であり、結果として各クライアントが「データ孤島」となる。かつてイーサリアムエコシステムで隆盛を極めたが後に放棄されたPlasma方式も、DA問題を解決できなかったために失敗した。
さらに、RGBプロトコルは取引両者の大量な通信を必要とし、多くの通信ステップは中央集権的な設備に依存している。この点に関する詳細な説明はまだ成熟しておらず、公式ですらメールによる通信が可能だと述べている。
明らかに、RGBプロトコルの設計は使いやすさを求めるロングテールユーザーには優しくない。多くの資産を持ち、プライバシーを重視する富裕層はデータバックアップやクライアントの維持を喜んで行うだろうが、ロングテールユーザーにとってはこれらの負担は重すぎて、大規模な普及を大きく阻害する。実際、現時点でも象徴的なRGB資産はほとんど存在しないとされている。
下図はRGB資産送金のフローチャートであり、読者はこれを通じて全体の流れをより深く理解できる。
要するに、RGBプロトコルはビットコインUTXOを活用してRGB資産の所有権変更を実現し、BTCチェーン上にコミットメントを発行することで、オフチェーンデータがクライアントによって勝手に改ざんされることを防止する。実際、RGBの「ワンタイムシール」とは、オフチェーンのRGB取引宣言を通じてビットコインUTXOとRGB資産所有権を関連付けることであり、ビットコインの強力なセキュリティを借りてRGB資産の安全を確保する。しかし、DAとデータストレージの問題により、オリジナルのRGBプロトコルの可用性とUXは劣り、データ紛失により資産が凍結（使用不能）になるリスクがある。
RGB++：CKBに基づく強化版RGBプロトコル
上記で、RBGシステムの長所と短所をまとめた。特にクライアントのデータ孤島、コントラクトステートのグローバル不可視性が、RGBプロトコルの使いやすさを妨げる主な要因である。
実際、RGBプロトコルの長所と短所はいずれも明白であり、プライバシーとセキュリティを重視する人々は自分でクライアントを運用し、データバックアップを行う傾向がある。しかし、ロングテールユーザーには明らかにその忍耐力はない（例えば、ほとんどのライトニングネットワークユーザーは自分でクライアントを運営せず、サードパーティのノードに依存している）。
この理由から、Nervos共同創業者CipherはRGB++というスキームを提案した。RGBの資産ステート、コントラクト発行、取引検証をCKBパブリックチェーンに委託する試みである。CKBはサードパーティのデータホスティングおよび計算プラットフォームとして機能し、ユーザーが自分でRGBクライアントを運営する必要をなくす。
CKB自体は拡張されたUTXOモデル（Cell）を採用しており、RGB資産のオフチェーン情報をCellに書き込むことができ、CellとビットコインUTXOの間に1対1のマッピング関係を構築することで、CKBに基づくRGB資産データのホスティングと検証スキームを実現し、使いやすさの問題を解決する。これはRGBオリジナルスキームの補強策である。
この説明は少し分かりづらいかもしれない。もう少し詳しく説明しよう。
前述した通り、RGBプロトコルの本質は、オンチェーンコミットメントとオフチェーン宣言を通じて、ビットコインUTXOとRGB資産所有権を関連付けることである。しかし、RGB資産コントラクトのデータは断片的に異なるクライアントのローカルに分散保存されており、グローバルに可視なビューは存在しない。
RGB++は、CKBの拡張版UTXOであるCellを使い、ビットコインUTXOと対応するRGB資産のマッピング関係を直接CKBチェーン上に表示する。さらに、CKBパブリックチェーンがユーザーのP2Pクライアントに代わって、各RGB送金の有効性を検証する。
このようなグローバルに可視なRGBデータ記録があれば、従来のRGBプロトコルでは実現困難だった多くのユースケースが現実的になる。
（RGB++の取引フロー：RGB資産情報をCellに書き込み、CellとビットコインUTXOを関連付け、最後にCKB上で発生したRGB++取引とRGB++資産に関連するビットコインUTXOをまとめてコミットメントに含め、そのコミットメント値をビットコインチェーンに書き込む）
おそらくすぐにEVMを思い浮かべる人もいるだろう。EVMでRGBのステートと検証を担うことはできるだろうか？答えは「非常に面倒」である。なぜなら、RGB資産は本質的にビットコインUTXOに寄生しており、ビットコインUTXOと1対1のマッピング関係を持っているからだ。ビットコインUTXOとEVMコントラクトデータの間にマッピング関係を構築するのは技術的にスムーズではなく、むしろUTXOパブリックチェーンを直接選ぶ方が良い。
さらに、イーサリアム上の「資産」はしばしばプール型の公共財であり、一つのコントラクトが無数の人の資産データを記録し、コントラクト管理者が絶対的な権限を持つ。この資産処理方式は、ビットコインUTXOおよびRGBプロトコルと深刻に衝突する。後者の設計思想は資産の完全な私有化であり、各自が完全に自分の資産を制御する（現金とWeChat Payの違いを想像せよ）。イーサリアムやEVMチェーンで常に発生する問題——資産コントラクトのオーナーの権力乱用、バグによる資金被害、資産コントラクトのデータ移行の煩雑さ——などを回避できる。
（出典：Geek web3 過去記事『テック界の有名人シャンマ：高性能パブリックチェーンは新しさを出しにくい、スマートコントラクトは権力分配を含む』）
したがって、ビットコインUTXOとオフチェーンRGB資産のマッピング関係をスムーズに表現したいなら、最良の選択はUTXOチェーンを使うことである。CKBは拡張型UTXO（Cell）をサポートしており、CKB VMの命令セットはRISC-Vに基づいており、EVMに比べて異なる暗号アルゴリズム（ビットコインの公開鍵・秘密鍵検証アルゴリズムを含む）との互換性が高く、RGB++が提唱する技術スキームの実現に有利である。
RGB++の技術的実装
RGB++はCKBの拡張型UTXOであるCellを利用する。一つのCellは以下のフィールドを含む：
CapacityはこのCellが持つオンチェーンスペースの大きさを表し、dataはCellに含まれるデータセットであり、読み取りや変更が可能である。
TypeはこのCellにバインドされたプログラムコードであり、dataの変更条件を制限する。例えば、Cellに100枚のTESTトークンのデータがあるが、110枚を他人に送ろうと宣言しても、Typeに規定された制限条件に違反するため拒否される。
LockはCellの所有権検証ロジックを表し、ビットコインUTXOのロックスクリプトに類似する。
Cellをアップグレード版のUTXOと考えることができる。TypeとCapacityという二つのフィールドが追加され、dataは任意のデータ型をカスタマイズ可能である。Cellの所有権変更方法はビットコインUTXOとほぼ同じで、ロックスクリプトによる解除によって実現される。
RGB++の考え方は、CKBチェーン上のCellを使ってRGB資産の所有権関係を表現することである。もともとRGBクライアントのローカルに保存されていた資産データを、CKBチェーン上でCellの形式で表現し、CKBをRGB資産の公開データベースとする。RGB資産を表すCellは、ビットコインチェーン上のUTXOと1対1のマッピング関係を持ち、この関係はCellのLockフィールドに直接示される。
例えば、あるRGB資産がビットコインUTXO Aに関連付けられている場合、対応するマッピングCellは、所有権検証条件をビットコインUTXO Aと同じに設定できる（つまり、LockスクリプトをビットコインUTXO Aのロック解除条件に設定する）。もし自分がUTXO Aの制御者であれば、直接CKB上のマッピングCellを操作できるが、当然CKBは自分が本当にUTXO Aの所有者かどうかを検証する。
CKBチェーン上にはビットコインのライトノードが実装され、ビットコインのブロックヘッダーを同期する。RGB取引を宣言し、RGB資産に対応するCellを操作する際には、まず自分がビットコインUTXO Aの制御者であることを証明する必要がある。証明手順は二段階：
-
CKBチェーン上に実装されたビットコインライトノードに対して、UTXO Aがビットコインチェーン上に存在することを証明する。Merkle Proofを提示する必要がある。
-
デジタル署名を提示し、自分がUTXO Aの所有者であることを証明する。
RGB++スキームでは、ユーザーがフロントエンドでRGB資産の送金を宣言すると、CKBチェーン上で取引が発生し、RGB資産データを記録するCellの内容が書き換えられ、所有権が変更される。もともとはビットコインUTXO 1の制御者がそのCellを所有していたが、所有権変更後はビットコインUTXO 2の制御者が新しい所有者となる。これらすべてはCKBチェーン上で可視である。
注意すべきは、BTCチェーン上のコミットメントに関わる作業プロセスは依然としてBTCメインネット上で行われるということだ。つまり、RGB++は依然としてビットコインチェーン上にコミットメントを発行し、CKB上で発生したRGB資産取引記録と関連付ける必要がある。このステップは従来のRGBプロトコルと変わらない。
しかし違いは、従来のRGBプロトコルでクライアントがオフチェーンで自分で担当していた作業（取引相手が資産由来を検証、クライアントがローカルに資産由来データを保存、コントラクト発行にサードパーティチャネルを利用など）をすべてCKBが肩代わりする点である。これにより、ユーザーが自分でクライアントを運営する必要がなくなる。
これにより、RGBクライアントのデータ孤島問題と、コントラクトステートのグローバル不可視性という欠陥が解決される。同時に、RGBコントラクトを直接CKBチェーン上に展開できるようになり、グローバルに可視な状態でRGB Cellが参照できる。これにより、RGBプロトコルのコントラクト発行における一連の奇妙な操作が回避される。
要するに、CKBはCellスクリプトのプログラマブル性を利用して、まずRGB送金の発信者が確かにRGB資産に関連するビットコインUTXOを所有していることを確認し、検証が通れば、ユーザーが送金を通じてRGB資産データを記録するCellを他人に譲渡することを許可する。
簡潔に言えば、CKBはRGB資産の公開データホスティングプラットフォームとして、データ保存とグローバルに可視なコントラクト発行機能、所有権検証および計算機能を提供する。さらに簡略化すれば、CKBがRGBのクライアントを代替し、他の問題も同時に解決していると言える。
もちろん、RGB++はグローバルに可視なデータ発行を実現したため、プライバシーはRGBプロトコルに比べて低下する。しかし、その代償として使いやすさが大幅に向上する。
したがって、RGB++の本質はプライバシーを犠牲にして使いやすさを得ることであり、RGBプロトコルでは実現不可能なユースケースをもたらす。製品のシンプルさと機能の完全性を重視するユーザーはRGB++を好み、プライバシーと「Verify by yourself」のセキュリティを追求するユーザーは従来のRGBプロトコル
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
