BiHelix RGB V0.11バージョンの展望：資産発行概要

著者: Zoom, Echo, BiHelix

はじめに

Nervosの共同創設者CipherがRGB++という提案を発表したことで、RGBネイティブプロトコルに関する市場での議論と関心が高まっています。RGBは、LNP/BPスタンダード協会によって構築された拡張可能で機密性のあるビットコインとライトニングネットワークのスマートコントラクトシステムであり、ビットコインエコシステムの開発者にとって非常に魅力的な存在であり、BTCネイティブ拡張プロトコルの中で大きな潜在能力を持つ要素と見なされています。ビットコインの分散型金融（BTCfi）とアプリケーション（DApps）の基盤として、RGBはビットコインの実用性を単なる価値保存機能からより広範な分野へと拡張することを示しており、これは歴史的なマイルストーンです。その技術革新は刺激的であるだけでなく、暗号通貨エコシステム全体に新たな発展の方向性と可能性をもたらします。

2023年末、RGBネイティブチームLNP/BPスタンダード協会は、市場の挑戦により良く対応し、ビットコインエコシステムの繁栄を促進するために、RGBがv0.11バージョンにアップグレードされることを発表しました。この記事では、RGB v0.11プロトコルのアップグレード機能と技術的基盤について詳しく説明し、信頼できる証明コンセンサス、スケーラビリティの最適化、重要なセキュリティ強化を含むRGB v0.11がサポートする資産生成機能と取引機能を包括的に概説します。既存のコンセンサス方案と比較した信念証明の基本原理とトレードオフ、ならびに証明v0.11によるガス節約とスループット増加の定量的ベンチマークについても詳しく調査しました。

RGB資産生成

現在、RGBプロトコルv0.11バージョンには、RGB20（トークン）、RGB21（NFT）、RGB25の3つの資産タイプが組み込まれています。RGB20を例にとり、現在のプロトコルの実装手順と実行権について議論します。

1. まず、契約の発行者はRGB20プロトコルに基づいてRGBトークンの初期状態を設定する必要があります。たとえば、契約の詳細を定義します：資産の名称、初期発行量、総供給量、増発、名称変更、破棄などの権限。
2. 次に、契約発行者は初期発行量を受け取るUTXOを指定します。これにより、シンプルなRGB資産を作成できます。状態変更は資産の所有権の変更権に適用でき、他のタイプの権利にも適用できます。たとえば：

• 増発インターフェース：契約が増発権限を開放するとき、増発された資産を受け取るアドレスを指定する必要があります。もちろん、RGB20は増発の上限を制限しており、契約発行者は無限に増発することはできません。
• 破棄インターフェース：契約発行者は、トークンの破棄権限を持つ1人または複数の人を指定できます。RGB20はP2P取引を採用しているため（取引については後述）、ユーザーはトークンをブラックホールアドレスに送信して破棄することが難しいです。
• 名称変更インターフェース：契約は資産名称を更新できます。

RGB契約コードはオフチェーンに保存されているため、契約発行者がオープンソースを許可しない限り、ユーザーは資産情報を検証することが難しいです。RGB契約が一度発行されると、ユーザーも発行者も契約発行時の状態定義を遵守しなければならず、発行者の悪行を防ぎます。

RGB資産譲渡

RGBの取引モデルはP2P（ピアツーピア）譲渡を採用しており、ETHとは大きく異なります。この譲渡モデルでは、両者がオンラインである必要があります。たとえば、「AがBに100トークンを送信する」操作は次のようになります：

1. Bが100トークンを送信するための請求書を作成します。
2. 受取人Aが送金を提案します。
3. Bが送金を確認し、署名します。
4. Aが取引をブロードキャストします。
5. AとBが取引を受け入れます。

この中で、Bはこの請求書をAに送信し、Aは請求書を受け取った後、請求書の内容に従って100トークンをBに送信する必要があります。Bは100トークンを受け取ったことを確認しなければ成功とはなりません。

• Q：なぜ両者がオンラインである必要があるのですか？
• A：請求書には有効期限があるため、一定の時間使用しないと無効になります。したがって、AはBの請求書を受け取った後、すぐに送金する必要があります。Bも請求書がすぐにAによって使用されることを確認する必要があるため、請求書を作成します。これにより、両者は請求書の有効期限内に送金を完了する必要があります。

図：ライトニングネットワークチャネル取引

RGBが使用する取引チャネルはライトニングネットワークを統合しているため、取引プロセスはライトニングネットワークの譲渡プロセスを参考にできますが、「受取人が再確認する必要がある」というステップが追加されています。このような取引ステップにより、受取人は無関係なフィッシングコインを受け取ることがなくなり、ユーザーのウォレットの安全が保護されます。

RGB資産取引

RGB資産移転プロセスにおける技術的ポイント

1. 一回限りの封印

この技術は、2016年にPeter Toddによって最初に提案されました。主な意味は「メッセージに封印を加え、そのメッセージが一度だけ使用されることを保証することです。メッセージを知るためには封印を取り除かなければなりません」。

簡単な方法は、公証の第三者サービスを設定することです。特定の封印が開かれたり閉じられたりするたびに、公開の登録所に証明書を発行します。これにより、誰でも自分が関心を持つ封印の状態を検証できます。

信頼できる実体を使用せずに一回限りの封印機能を実現する場合、ビットコインのUTXOを封印として使用できます。ビットコインの任意のUTXOは一度だけ使用できるため、UTXOを封印として使用すると、UTXOが作成されたときにロックし、使用するときに開くことができます。

RGBはこの「一回限りの封印」技術を利用しており、RGB資産の情報、契約の状態などをUTXOの中に「包み込んで」います。UTXOが使用されると、資産の所有権や契約の状態が変化します。これは、RGB取引が発生するたびに、実際には送信者が特定の契約（移転される権利を定義したもの）に対して一度の状態変更を作成していることを意味します。

2. クライアント検証

RGBの検証は従来の「グローバルコンセンサス」検証とは異なり、「クライアント検証」技術を採用しています。従来のビットコイン検証方式では、ネットワークに接続されたノードがブロックや取引プール内の取引を継続的にダウンロードし、検証します（フルノード）。このようなノードは、チェーン全体のUTXOセット（ブロックチェーン上のすべての未使用出力の集合）に対してリアルタイムで更新されたビューを持ち、新しい取引を見たとき、その有効性を検証するためには、その取引のすべての入力が最新のUTXOセットの一部であることを確認するだけで済みます。

しかし、RGBにとっては、データがグローバルに伝播しないため、そのようなUTXOセットのグローバルビューは存在しません。RGBクライアントは取引を受け取った後、その取引の最新の状態が有効であることを検証するだけでなく、取引に関連する過去のすべての状態変化についても同様の検証を行い、契約の初期状態まで遡る必要があります。これは明らかな欠点をもたらすように見えます：検証に時間がかかることです。しかし、これは「長い取引履歴を持つ資産」にのみ現れるものであり、データ共有層（自発的な場合）を通じてこの部分の取引履歴データを事前に検証することができます。

これにより明らかな利点ももたらされます：クライアントは、グローバルで発生するすべての取引を知る必要も、検証する必要もありません。なぜなら、クライアントは自分のウォレットに関連する取引だけを知っていればよく、他の取引を検証する必要がないため、各クライアントが検証するデータ量は少なく、システムのスケーラビリティが明らかに向上します。クライアント検証の完全なチェーンの問題について、BiHelixは再帰的ゼロ知識証明方案を提案し、これを徹底的に解決しました。

3. 決定論的ビットコインコミットメント

RGBは「二重支払い」を防ぐためにRGBコミットメントを実現しています。このようなコミットメントは次のことを実現する必要があります：

• 契約に関連する複数の状態変化を単一のビットコイン取引にコミットできること
• 各契約の状態変化は、ビットコイン取引に一度だけコミットできること

実現の具体的な方法は：

1. まず、特定の契約（または資産ID）に関連するすべての状態変化を決定論的に集約してコミットメントを作成します。
2. 次に、移転されるすべての資産のコミットメントを集約してメルクルツリーを作成します。
3. 最終的なルートハッシュ値が最終的なRGBコミットメントとなります。
4. 他の無関係なRGBと、同様に決定論的ビットコインコミットメントを必要とするプロトコルとの互換性を保証するために、RGBコミットメントと他のプロトコルのコミットメントを再度集約します（LNPBP-4標準に記載されているように）。このように得られたハッシュ値が、実際にビットコイン取引に埋め込まれるメッセージとなります。
5. バッチ処理によるコスト削減

前のセクションからわかるように、任意の数の状態変化を「包み込む」ことができるため、理論的には大規模なバッチ処理を実現し、UTXOサービスプロバイダーにより多くのアプリケーションシナリオを提供できます。

• シナリオ：Aが同時に複数の人に支払いをしたいと考え、BにRGB20資産を移転し、CにRGB21資産を移転し、Dに契約の所有権を移転する。
• 結果： AはB、C、Dそれぞれに対して1つの状態変化を作成し、すべての状態変化を同じビットコイン取引にコミットすればよく、追加のバイトを占有する必要はありません。これは、異なる状態の状態変化が1つのコミットメント内に包み込まれることにより、バッチ処理を実現したことを意味します。各RGB支払いのオンチェーン手数料の限界コストは非常に小さくなり、同じ手数料が任意の数の送金に分配されます。

ここには限界もあります。すなわち、これらの状態変化情報は同じUTXO内に「包み込まれる」必要があり、複数存在する場合はこの取引の入力を増やす必要があり、相応のコストも増加します。しかし、従来の各状態変化が1つの取引を必要とする状況に比べ、すでに大幅な改善が実現されています。

5. クライアント間の通信

クライアント通信は、RGB譲渡の実装プロセスで一般的です。送信者は受取人（たち）に「コンシグメント」を共有する必要があります。このデータ構造には、取引を検証するために必要なすべての情報が含まれており、契約の初期状態まで遡るすべての状態変化が含まれています。これは送信者から受取人に通信手段を通じて転送される必要があります。しかし、RGBプロトコルでは通信チャネルに制限がなく、さまざまなデータ共有方法があります。一般的な2つのデータ共有方法：

• Storm：ライトニングネットワークに基づくピアツーピアの即時通信およびストレージシステム。
• RGBプロキシサーバー：標準化されたHTTP JSON-RPCサーバーで、クライアントはデータをアップロードおよびダウンロードできます。ユーザーは自分のプロキシサーバーを運営することも、第三者のサーバーを使用することもできます。第三者のサーバーに依存することはプライバシーと検閲耐性に影響を与えますが、安全性には影響しません。

クライアント通信について、BiHelixは適応型通信プロトコルを提案し、最適化を図っています。

結論

現在、RGB v0.11バージョンはまだベータ段階にありますが、多くのRGBエコシステムプロジェクトチームが積極的に貢献し、v0.11バージョンの精緻な最適化を共同で推進していることは明らかです。RGBエコシステムプロジェクトおよびRGBプロトコルの提唱者として、BiHelixチームは全力を尽くし、RGBプロトコルのエンジニアリングと商業化の実現に取り組んでいます。ライトニングネットワークとRGBプロトコルの互換性を加速的に推進し、より多くの高品質なアプリケーションエコシステム開発者を積極的に受け入れ、彼らがRGBプロトコルを深く学び、応用することが最優先の目標となります。

RGBプロトコルの成熟した資産発行機能セットは、ビットコインエコシステムにさらなる革新をもたらし、再びビットコインエコシステム全体を新たな高みへと押し上げると信じています。RGBプロトコルがビットコインネットワークで広く適用されるにつれ、この記事もRGBの背後にあるメカニズムと設計を理解するための不可欠な重要な参考資料となるでしょう。この活気に満ちたエコシステムの中で、RGBの未来は明るく、ビットコインの進化に新たな活力と可能性を注入しています。