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++ プロトコルライトペーパー」には取引の折りたたみについて言及されており、複数の 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：はい。