RGB++ プロトコルとビットコインの未来: ビットコイン シンガポール 2024 からの Cipher の洞察

3月9日、Nervos FoundationとABCDEが共催したBitcoin Singapore 2024カンファレンスで、CELL Studioの創設者でありRGB++プロトコルの作者であるCipher氏が、「RGB++プロトコルの概要と展望」と題した基調講演を行いました。

Cipher のプレゼンテーションの要点を以下にまとめます。

RGBプロトコルが直面する課題

RGB プロトコルは長年にわたって存在していますが、いくつかの要因により広く採用されていません。

インタラクティブ操作の課題

BTC 、 ETHなどの取引では、受信者はアドレスを提供するだけで、送信者は今日または明日に資金を送金できるため、非常に便利です。対照的に、各RGB取引では、受信者が最初に請求書を発行する必要があります。次に、送信者はRGB取引を構築し、資産履歴の証明を生成して受信者に送信する必要があります。この証明を受け取ったら、受信者はクライアント側の検証（CSV）を実行する必要があります。検証が成功したら、将来の取引のためにこの証明を保存する必要があります。

したがって、RGB トランザクションは、両当事者がオンラインであるだけでなく、両当事者が関連する履歴データを保存していることにも依存します。これは、消費者向け製品にとって大きな障害となります。

データ可用性 (DA) の問題

RGB トランザクションでは、資産の履歴証明を添付することが不可欠です。この証明が失われると、秘密鍵を失うのと同じくらい重大な事態になります。誰がユーザーの資産保存を支援するかという問題は、データの可用性の問題です。プライバシー保護を目的とした元の RGB プロトコルでは、ユーザーの代わりに資産を保存する人は誰もいません。つまり、ユーザーは自分のデータ保存について責任を負わなければなりません。

適切なデータ ストレージがあっても、アリスが RGB 資産をボブに転送したいというシナリオを考えてみましょう。アリスはこれらの資産の履歴証明をボブにどうやって送信するのでしょうか。電子メールを使用するか、Whatsapp を使用するか。明らかに、集中チャネルを介して送信するのは不適切であり、専用の P2P チャネルを使用する必要があります。ただし、P2P チャネルでは機密性の問題が発生します。なぜ誰かがこの機密データの送信を支援するのでしょうか。これは一連の複雑な問題につながります。

相互運用性の問題

RGB 資産の履歴証明データはユーザー自身が保持し、取引中に受信者に渡されますが、公開されません。このため、データはネットワーク内の各個人に分散されます。集中型か分散型かにかかわらず、取引プラットフォームを構築する人にとって、RGB のグローバル状態を維持するには複数のソースからのデータが必要です。アプリケーション開発者のためにこのデータを集中管理して保存する RGB サービス プロバイダーもありますが、このアプローチでは RGB のプライバシーが低下します。このソリューションにもかかわらず、さまざまなユーザーの RGB データを保持するさまざまなサービス プロバイダー間でのデータ転送を容易にするなどの課題が残っています。

スマートコントラクト/スクリプト実行環境に関する問題

RGB のスマート コントラクトまたはスクリプト実行環境には、大きな課題があります。AluVM という仮想マシン (VM) を使用していますが、プログラミング言語の詳細は未だ確定していません。さらに、コンパイラやデバッガーなどの重要な開発ツールも完全には開発されていません。また、共有状態や分散型 (所有者なし) コントラクトのサポートも不足しています。現時点では、AluVM がまだ非常に初期段階にあることは明らかです。

そのため、RGB は数多くの複雑な問題に直面しており、それぞれにかなりの時間と労力が必要です。これらの課題は、RGB の効果的な実装の遅れに大きく影響します。

RGB++ プロトコルの概要

RGB トランザクションは、マッピング プロセスを通じてビットコイン トランザクションと複雑にリンクされています。さらに、RGB トランザクションには、データ可用性 (DA)、クライアント側検証、P2P ネットワーキング、仮想マシン、共有状態、分散型契約を含むオフチェーン インフラストラクチャが必要です。このようなインフラストラクチャを考えるとき、データ管理、検証、仮想マシン統合、P2P ネットワーキング、インセンティブ、スマート コントラクトの機能を考えると、ブロックチェーンが自然に思い浮かびます。RGB++ プロトコルの概念はこの基本的な直感に基づいており、RGB に必要なオフチェーン インフラストラクチャの代替として、UTXO モデル ベースでチューリング完全な CKB ブロックチェーンの使用を提案しています。

RGB++ は、同型バインディング技術と呼ばれる概念を導入しています。各 Bitcoin トランザクションには出力が含まれます。RGB トランザクションの場合、Bitcoin 出力内に OP_RETURN セグメントを含める必要があります。このセグメントには、コミットメントと呼ばれる特定のハッシュ データが含まれます。このコミットメントが別のパブリック ブロックチェーン上のトランザクションのハッシュと一致し、両方のトランザクションの入力と出力が同型 (つまり、構造が対応している) であり、この代替ブロックチェーンの UTXO (未使用トランザクション出力) がチューリング完全な計算機能と状態ストレージ機能を備えていると仮定すると、Bitcoin ブロックチェーン上のトランザクションは、この別のブロックチェーン上のトランザクションと完全に統合またはバインドされます。CKB (共通知識ベース) ブロックチェーンは、これらの前提条件を満たしています。したがって、Bitcoin でトランザクションを実行することは、実質的に CKB チェーンで対応するトランザクションを実行することと同じです。Bitcoin トランザクションの状態の変更は、CKB に存在する契約制約に従って、CKB チェーン上のトランザクションの状態の変更を反映します。これは、同型バインディング技術の本質を要約したものです。ただし、この概念には、トランザクションの一貫性の維持や二重支出の防止など、現時点では詳細に説明されていない複雑な技術的側面が数多く含まれています。

同型バインディング技術により、ビットコインの状態機能が強化されます。たとえば、次の図に示す btc_utxo#1 を考えてみましょう。このビットコイン UTXO (未使用トランザクション出力) は通常、ロック スクリプトと残高を表す金額の 2 つの状態のみを示します。ただし、図に示すように、CKB (共通知識ベース) ブロックチェーン上の対応する青いセルでは、機能がより広範囲になります。ビットコイン UTXO の残高表示のみに限定された機能とは異なり、CKB チェーン上のこの同型セルは、残高データだけでなく、さまざまな他の種類のデータも保存できます。

データ コンポーネントに加えて、セルにはタイプ スクリプトがあります。このスクリプトは、アセットが受信される条件を定義し、アセット タイプに制限を課すという特定の目的を果たします。

さらに、セルにはロック スクリプトが含まれており、この場合は btc_utxo#1 に明示的にリンクされています。このリンクは、CKB ブロックチェーン上のセルは btc_utxo#1 が消費された場合にのみ使用できることを意味します。

CKB プラットフォームでは、ビットコイン ライト ノードを実装しています。ビットコイン トランザクションが開始されると、リレー メカニズムによってキャプチャされ、このトランザクションが証明の形式として CKB ブロックチェーンに転送されます。このプロセスには、ビットコイン ライト ノードでのトランザクションの存在の確認と、コミットメントがトランザクションと同型であることを確認することが含まれます。

このアプローチにより、ビットコインの機能が大幅に拡張されます。これにより、ビットコイン上で直接さまざまな資産を発行する道が開かれ、チューリング完全な契約の拡張が容易になります。

このアプローチの利点は、ビットコイン レイヤー 1 (L1) とほぼ同じセキュリティ ステータスを維持しながら、チューリング完全なスクリプトをビットコイン領域に導入できたことです。これは、すべての履歴レコード、トランザクション、およびコミットメントがビットコイン L1 の UTXO チェーンを通じてリンクされているためです。

ただし、そのトレードオフとして、プライバシーがわずかに低下します。RGB の場合、データは個々のユーザー間で分散されるため、他のユーザーが特定のユーザーの RGB データにアクセスすることは困難です。RGB++ では、すべてのオフチェーン データが CKB ブロックチェーン上に公開され、これらの状態が維持されるため、プライバシーが低下します。ただし、最悪のシナリオでも、ビットコイン取引のプライバシー レベルまで低下するだけで、IP アドレスや個人の身元情報は公開されません。

実際、CKB に強化されたプライバシー レイヤーを実装できます。4 年前、私たちは Grin コミュニティと協力して、CKB で Mimblewimble テクノロジを使用してこの強化されたプライバシー レイヤーを作成することについて議論した論文を書きました。将来的には、このレイヤーを RGB++ に統合して、取引額の隠蔽だけでなく、取引履歴のリンクを切断することもできます。その結果、RGB よりも強力なプライバシーが実現します。

要約すると、RGB のビジョンをよりシンプルな方法で実現し、その機能をさらに拡張しました。

ビットコイン L1 資産の可能性を解き放つ

ここで、飛躍のコンセプトを簡単に紹介します。

ビットコインに適用できる準同型バインディング技術は、ライトコイン、Liquid、およびその他の UTXO ベースのチェーンにも同様に適用できます。前述のように、RGB システムと RGB++ システムの両方で、受取人はビットコイン UTXO であり、支出の唯一の権限が与えられています。ビットコインで RGB++ トランザクションを作成する場合、受取人をビットコイン UTXO ではなく、ライトコイン UTXO として指定するオプションがあります。その結果、この資産はライトコインに「ジャンプ」します。これは、その後の支出にはライトコイン UTXO によるロック解除が必要になるためです。同様に、この資産は Liquid にジャンプすることも、ビットコインに戻ることさえできます。

もちろん、考慮すべき特別なケースがあります。資産が CKB ブロックチェーンにジャンプすると、そのデータ解釈レイヤー、契約レイヤー、所有権はすべて CKB 上にあります。つまり、他のチェーンに依存せず、CKB 上の取引に直接関与し、スマート コントラクトとやり取りできるようになります。これは、L2 へのジャンプと説明できます。L2 では、誰かが資産をビットコインに戻すことを決定するまで、ユーザーは数千、あるいは数万の取引を行うことができます。これは、トランザクション フォールディングと呼ばれるものです。RGB であれ RGB++ であれ、取引はビットコイン ブロックチェーン上で行われ、マイニング料金が高額になります。ただし、資産が CKB にジャンプしてトランザクション フォールディングを経ると、手数料が大幅に低くなり、いつでも簡単にビットコイン ブロックチェーンに戻ることができます。このプロセス全体は、マルチ署名ブリッジや個人への信頼に依存しません。必要なのは、さらにいくつかのブロック確認を待つことだけです。ビットコイン ブロックチェーンから CKB ブロックチェーンにジャンプするには、6 つのビットコイン ブロック確認を待つ必要があります。 CKB ブロックチェーンからビットコインに戻るには、ブロックのリバートを防ぐために 24 回の CKB ブロック確認が必要です。

これが、私たちが新しいパラダイムを導入したと言っている理由です。もちろん、これは私たちの発明ではなく、RGB の初期の素材に存在していたアイデアであり、RGB アセットは異なる UTXO チェーン間をジャンプできます。チューリング完全性と CKB へのジャンプを組み合わせた結果、潜在的なアプリケーションは広範囲に及び、Ethereum のマルチ署名ブリッジの従来の物語とは大きく異なることがわかりました。

今後の展望

次に、スケーラビリティについて説明しましょう。ビットコインのトランザクション レートは 1 秒あたり約 7 トランザクション (TPS) ですが、CKB はピーク時に約 200 TPS に達します。契約の実行とスクリプトの検証コストを考慮すると、TPS は約 50 にまで低下する可能性があります。これは、ビットコインの 10 倍未満の拡張です。これではまったく十分ではありません。では、スケールアップのオプションは何でしょうか。2 つの主な方向性が考えられます。

• ステート チャネル: ステート チャネルは究極のスケーリング ソリューションであり、非常に高いパフォーマンスの上限を提供します。ただし、マルチパーティ コントラクトの実装が複雑であるという課題があり、ステート チャネルは支払いトランザクションや個人とサーバーのやり取りにより適したものになります。Jan は、ステート チャネルの研究を進めるチームの先頭に立つことになっています。

  
  

• AppChain スタック: UTXO モデルに基づいてレイヤー 2 (L2) ソリューションを構築することで、L2 AppChain は CKB へのアンカーを確保し、CKB と同型に整合します。このアプローチにより、この新しいパラダイム内で革新的なスケーリング戦略を開発できます。これは、来年の CELL Studio の重要な焦点でもあります。

  
  

最後に、RGB++ のミッションとロードマップについて概説したいと思います。RGB++ は、サードパーティの開発者やユーザーが簡単に使用および統合できるように、基礎的なプロトコル モジュールを開発することを目的としています。RGB++ プロトコルのロードマップは次のとおりです。このプロトコルはすでに Bitoin メインネットで稼働しており、 RGB++ SDKは 4 月 3 日にリリースされました。

CELL Studio の創設者であり、RGB++ プロトコルの作者である Cipher による作品。