2 月 23 日、CELL Studio の創設者 / Nervos CKB の共同創設者 / RGB++ プロトコルの作者 Cipher、Web3 華語 KOL 花椒、RGB 中国布道者大胖墩、極客 Web3 の創設者 Fasut、CKB エコシステム基金 CMO/SeeDAO の発起人 Baiyu、そして CKB コミュニティ大使 CyberOrange が、X Space のライブイベントで RGB++ プロトコルの前世今生について話しました。
このライブは 1 時間半続き、非常に多くの有益な情報がありました。まだ聴いていない方は、下のリンクをクリックして音声の再放送をお聴きください：https://twitter.com/ckbcell/status/1760995772840268105?s=61&t=IYlGL8YIKMjrbZkcBRmuJA
以下は音声に基づいて整理した重要な内容です：
1. RGB プロトコルの発展の歴史#
RGB プロトコルは、2016 年に Peter Todd が提唱したクライアント検証に遡ることができます。その核心思想は、すべてのものをチェーン上に置く必要はなく、ブロックチェーンができること、例えば軽量な検証を行うことだけを行えばよいということです。これが初代です。
二代目は Giacomo Zucco で、彼は Peter Todd の考えに触発され、RGB プロトコルを最初に概念化しましたが、この MVP は非常に不完全でした。
三代目は現在の Maxim Orlovsky です。RGB プロトコルの 90% 以上のコードは Maxim 博士が貢献したもので、彼は資金調達を行わず、寄付と自己負担で運営していますが、寄付は個人の経済問題を解決するだけで、大量のエンジニアを雇うための十分な資金はありませんでした。また、Maxim 博士は LNP/BP 標準協会を設立し、RGB プロトコルの実用化を推進しています。
RGB プロトコルと LNP/BP 標準協会についての詳細は、Web3 華語 KOL 花椒が制作した YouTube のシリーズ動画をご覧ください：https://www.youtube.com/playlist?list=PL9_Eoig1ztix_j6N6hqswuvDv3FDiSoJO
RGB 中国布道者大胖墩は、RGB が比較的正統なビットコインのスケーリングソリューションと見なされ、多くの人々に期待されていると補足しました。しかし、LNP/BP 標準協会は非営利で、主に寄付に依存しており、開発者を雇うための十分な資金がないため、RGB プロトコルの進展が遅れており、現在のところロードマップもなく、多くの不確実性が存在し、これがさらに RGB に基づく他のプロジェクトの開発進度を遅らせる「悪循環」を生んでいます。
さらに、現在 RGB およびその協会の管理権は主に Maxim 博士に集中しており、大胖墩は協会がもっとオープンであるべきだと考えています。
2. RGB++ の誕生背景#
Cipher は、数ヶ月前に RGB に関する記事を見た際、RGB プロトコルがデータ伝送やユーザーインタラクションなどの面で劣っていることが指摘されているのを見たと紹介しました。例えば、RGB の送金には双方が同時にオンラインである必要があり、インタラクティブな操作が必要で、送信者は資産の履歴データの証明を提供する必要があります。Cipher は RGB プロトコルが非常に優雅であると考えていますが、ユーザー体験が十分に友好的ではなく、むしろ面倒であり、アプリケーションレイヤーの実践において多くの問題が存在すると述べています。例えば、RGB のデータが各人の手に分散しているため、DeFi や DEX などのアプリケーションを行うのが非常に困難です。
製品マネージャー出身の彼は、RGB プロトコルのこれらの困難や劣位を直接ブロックチェーン上で解決できると敏感に察知しました。例えば、誰の P2P ネットワークにも依存せず、データを共有し、取引を検証できる仮想マシン、非インタラクティブな操作体験などです。これが RGB++ の初期の核心アイデアであり、RGB プロトコルのチェーン外のクライアント検証が行うべきことを、UTXO モデルと PoW コンセンサス機構に基づくチューリング完全なブロックチェーンに委託することです。
RGB++ の利点は多く、例えば取引の非インタラクティブ性、取引の折り畳み、ユーザー体験が非常に友好的であることなどがありますが、欠点はプライバシーが RGB そのものほど良くないことですが、ビットコインブロックチェーンのプライバシー保護レベルに低下するだけです。また、RGB のプライバシー保護も完璧ではなく、送信者は資産のすべての履歴証明を提供する必要があり、受信者は送信者の以前の取引記録を見ることができます。CKB 上では、実際には Mimblewimble プロトコルを使用して取引金額を隠し、取引履歴を断ち切ることで、RGB++ がより良いプライバシーを持つことができますが、第一段階のチームはこれを行う余裕がありませんでした。
さらに、Cipher は X 上での RGB++ プロトコルに関するいくつかの論争にも言及し、皆が学術的な議論を行うことはできるが、最初からそれを詐欺だと決めつけるべきではないと考えています。こちらをクリックして Cipher の論争に対する応答を確認してください。
最後に、Cipher は互換性の問題についても触れました。RGB は AIuVM を使用しており、RGB++ の第一版は CKB-VM を使用しているため、技術的には互換性がありませんが、CKB-VM が RISC-V 命令セットを使用しているため、後に AIuVM を CKB-VM にコンパイルして RGB 互換レイヤーを作成することができます。それに加えて、ジャンプの方法を通じて資産の通行を実現することも可能です。
3. RGB++ プロトコルが RGB と異なる点#
CyberOrange は、RGB の最も重要な 2 つの技術は一回限りの封印とクライアント検証であり、前者は RGB 資産をビットコインブロックチェーンの保護下に置き、後者は主に RGB 資産の取引を検証することだと述べました。RGB++ プロトコルは、RGB ユーザーがクライアント検証を使用できるだけでなく、CKB チェーン上での検証という選択肢も提供します。取引の金額がそれほど大きくない場合、ユーザーは自分で完全なクライアント検証を行う必要はなく、CKB スクリプトの検証を選択できます。
第二点はプライバシーです。RGB++ プロトコルはデータを CKB チェーン上に置き、CKB を DA 層として機能させ、そのプライバシーはオリジナルの RGB プロトコルよりも低く、これについては前述の Cipher が詳しく説明しています。コインには両面があるように、CKB を DA 層として使用することで、DEX や他の DeFi アプリケーションの設計がはるかに簡単になります。
第三点はスケーラビリティの違いです。理論的には RGB のスケーラビリティはやや強い可能性がありますが、実際には RGB++ プロトコルも他のいくつかのメカニズムを利用してスケーラビリティを実現できます。
最後に、CyberOrange は RGB++ と RGB が互換性を持つことも可能であると述べました。RGB はジャンプのような操作をサポートしており、RGB 資産をある UTXO チェーンから別の UTXO チェーンにジャンプさせることができ、CKB ブロックチェーンもこの機能をサポートしているため、RGB 資産と RGB++ 資産を通じて接続できます。
「極客 Web3」の創設者 Fasut は、RGB の多くの理念が状態チャネルに似ており、自己検証が必要であると述べました。RGB ネットワークは無数の OTC プレイヤーで構成されており、送金にはすべての人の合意を得る必要はなく、取引の双方の同意があれば十分であり、取引の内容は取引の双方だけが知っています。
しかし、Fasut は、RGB 取引の送信者が資産のすべての履歴を提供する必要があるため、資産が特に多くの手を経て転送される場合、データ量が大きくなり、ストレージと伝送の圧力を引き起こす可能性があると指摘しました。また、RGB には資産の断片化ストレージの問題もあり、各人は自分に関連する資産データのみを保存し、各人のクライアントが保存するデータは異なります。もし特定のユーザーのクライアントに問題が発生し、データがバックアップされていなければ、その資産は永遠に動かなくなります。したがって、Fasut は RGB がプライバシーを得るために可用性を犠牲にしたと考えています。
Fasut の見解では、RGB++ は「楽観的 RGB」に似ており、楽観的ロールアップのように、ユーザーが第三者（ここでは CKB ブロックチェーン）を信じる必要があります。RGB++ は RGB のすべてのデータを CKB チェーン上に置き、CKB ノードが RGB 資産の取引を検証することで可用性を実現し、従来の RGB プロトコルの多くの問題を解消しました。RGB と RGB++ について、「極客 Web3」は非常に包括的な記事を発表しており、まだ見ていない方はこちらをクリックして読むことをお勧めします。
しかし、CyberOrange は、RGB++ はユーザーに CKB を信じさせることを強制するのではなく、追加の選択肢を提供していると考えています。ユーザーはもちろん RGB クライアントを使用してすべての取引を検証することもできます。
前述のデータストレージの圧力について、花椒はこれが問題ではなくなったと明言しました。Maxim 博士は以前からこの点を考慮しており、ウォレットにはローカルデータベースが組み込まれているため、ユーザーが個別に RGB ノードを運営する必要はありません。RGB 取引の請求書について、花椒は RGB 開発者に相談し、メインネット上でオフライン取引を実現できるが、ライトニングネットワークのチャネル内では不可能で、取引の双方が同時にオンラインである必要があると述べました。無主契約について、RGB にはグローバルステートがないため、RGB に基づく DeFi アプリケーションの構築は非常に困難であり、Maxim 博士はこれに対処するために Bifrost を設計しました。これはライトニングネットワークのサブバージョンに相当し、各 Bifrost のチャネルは Layer3 に相当し、より多くの意味でのスケーラビリティを実現できます。
4. RGB++ のタイムライン#
Cipher は、今年の 3 月末までに RGB++ プロトコルの第一版 MVP を完成させ、RGB++ のメインネットへの導入、Layer2 上でのファンジブルトークンと NFT をサポートする DEX、対応するウォレットとブラウザを含めることを希望しています。
さらに、Cipher は RGB++ プロトコルのために Rust と C 言語に精通した開発者を募集しており、興味のある方は彼に直接連絡することができます。
5. Q&A セッション#
Q1：RGB++ は開発者にとってどれほど友好的ですか？
Cipher：RGB でも RGB++ でも、開発者の主な作業はチェーン外で行われ、ビットコインチェーン上ではありません。RGB の場合、開発者の大部分の作業は RGB 取引をどう組み立てるか、RGB 証明をどう生成するか、RGB 上で契約をどう書くかなどであり、RGB++ でも同様のことを行いますが、多くのことは CKB ブロックチェーンが直接解決しています。DEX を作る場合、CKB 上では RGB++ 資産を受け入れる DEX をどう作るかということになり、その開発の難易度は CKB 上で他の契約を開発するのと大差ありません。現在、CKB 上の開発ツールは比較的整っており、熟練した開発者は数日間の学習の後、すぐに取り組むことができるでしょう。
Q2：RGB++ と CKB トークンの関係は何ですか？
Cipher：RGB++ の各取引は、ビットコイン取引と CKB 取引を同時に発行します。RGB++ エコシステム内の各ユーザーの取引や資産、状態は CKB チェーン上に対応する UTXO（セル）を持ち、CKB の一部を占有し使用します。また、開発者は CKB チェーン上で契約を開発します。
Q3：CKB は RGB の取引を取得した後、圧縮しますか？
Cipher：「RGB++ Protocol Light Paper」には取引の折り畳みが記載されており、複数の CKB 取引を 1 つのビットコイン RGB++ 取引に対応させることができ、これにより低速で低スループットのビットコインチェーンを高性能の CKB チェーンで拡張することができます。
また、状態圧縮については、CoTA プロトコルが早くから実現しており、あなたが持っているトークンの数量に関係なく、32 バイトのスペースに圧縮できます。RGB++ が同様の状態圧縮を実現できるかどうかは、まだあまり研究されていませんが、これは良い方向性です。
Q4：CKB 上で開発する場合、Subgraph や Oracle などの関連ツールはありますか？それとも第三者のサポートを待つ必要がありますか？
CyberOrange：現在、CKB チェーン上には予言機はありません。他のいくつかのインターフェースについては、CKB にはデータのエンコードとデコードの標準があり、その標準を使用してデータを解析できますが、手動でいくつかのものを作成する必要があるかもしれません。
Q5：CKB の TPS はどのくらいですか？
CyberOrange：単純な送金の場合、CKB の TPS は 300 以上に達することができます。
Q6：RGB++ の安全性に関する記事では、ビットコインは 6 つのブロック確認でほぼリバートされないとされていますが、CKB は約 20 ブロック必要です。これが RGB++ のユーザー体験に影響を与えるのではないでしょうか？ユーザーはそんなに待ちたくないかもしれません。
Cipher：もしあなたが単一のレイヤー取引を発行するだけなら、それは CKB の取引を同時に発行します。これは主にビットコインのブロック生成速度に依存し、そんなに多くのブロック確認を待つ必要はありません。実際にはビットコインでの送金体験と同じです。あなたが言及した 6 つのブロック確認を待つ必要があるのは、資産がビットコインの Layer1 から CKB にジャンプする場合で、安全性を保証するために、6 つのビットコインブロック確認が必要です。その後、CKB チェーン上の操作は、CKB の 10 秒のブロック生成時間を待つだけで済みます。ビットコインチェーンに戻るためにジャンプする場合、安全性を保証するために、20 ブロック以上の CKB 確認を待つ必要があります。ジャンプ操作は頻繁ではないため、ユーザー体験への影響はそれほど大きくなく、他のクロスチェーンソリューションも通常はかなり長い時間を待つ必要があります。
Q7：3 月末までに出る予定の DEX は、ビットコインのインプリントなどの資産をサポートしますか？
Cipher：はい。