ビットコイン資産発行プロトコル RGB の真の可能性はどこにあるのか？

著者：阿剣、ウー・シュオ・ブロックチェーン

この記事では、ビットコイン上の資産発行プロトコルRGBについて簡潔に説明し（外部のスマートコントラクトシステムと理解することもできます）、他の同様の機能を実現するプロトコルとの違いを指摘します。これらの違いにより、RGBプロトコルのスケーラビリティはそれらを遥かに上回り、より広範なプログラミングスペースを残します。RGBの設計がすでに完成していることを紹介するだけでなく、これらのプログラミングの可能性についても探ります。

RGBプロトコルとは？

ビットコイン上で資産を発行するという考えは古くからあります。しかし、ビットコインプロトコルには独自の特性があります：その状態はビットコインのUTXO（"未使用の取引出力"）によってのみ表現されます；1つのUTXOは2つのデータを持っています：それ自体の額面（ビットコインの価値）と、資金の使用条件をプログラムするための「スクリプト公開鍵」（「ロックスクリプト」とも呼ばれる）です。たとえば、特定の公開鍵の署名を提供することです。ロックスクリプトをプログラムするための操作コードはビットコインのコンセンサスルールによって提供されており、任意のセキュリティルールを実現するためには使用できません。したがって、UTXO内部で他の資産を創造することは不可能です ------ ビットコインスクリプトではこれらの資産のセキュリティチェックをプログラムできません。これは、ビットコイン上で資産を発行するという考えは本質的にビットコインのブロックスペースの創造的な使用であることを意味します。つまり、私たちは外部のスマートコントラクトシステムを設計する必要があり、契約状態を変更するステップ ------ たとえば、契約Aがパラメータを変更し、Bが特定の資産の数量をCに移転する ------ の情報をブロックチェーンにアップロードする必要があります。これにより、これらの情報を収集することで、このスマートコントラクトシステムの最新の状態を取得できます。

粗い設計思考の1つは、契約状態を変更するステップの情報をそのままビットコインブロックチェーンにアップロードすることです。これは確かに機能しますが、いくつかの問題に直面します：（1）完全な情報をアップロードするため、ブロックスペースを多く消費する可能性があり、ユーザーが契約の状態を変更する必要があるとき（たとえば、送金時）には、より多くのオンチェーン手数料を支払う必要があります。特に、私たちがこのような外部契約システムにビットコインよりも優れたプログラマビリティを持たせたいと考えると、プログラマビリティの向上はより多くのブロックスペースを消費することを意味する可能性があります；（2）ブロック内のほぼすべての情報は外部のスマートコントラクトを変更する可能性があるため、ユーザーはこの外部契約システムの最新の状態を得るためにすべてのビットコインブロックデータを取得する必要があり、つまりその検証コストが高くなります；（3）外部スマートコントラクトシステムの設計に依存するため、ビットコインと同等のプライバシーしか得られないか、さらに悪化する可能性があります；もしより多くのプライバシーを提供できる場合、さらに多くのブロックスペースを消費する可能性があります。

過去に、広く使用されていたプロトコルは「Omni」と呼ばれ、外部契約取引の完全な情報をアップロードせず、取引のハッシュ値のみをアップロードします。このアプローチは、上記の問題1を解決し、外部契約取引の複雑さとその経済的コストを切り離しました。しかし、ユーザーは依然としてOmniプロトコルの最新の状態を得るために全てのビットコインブロックデータを取得する必要があります；さらに、プライバシーを特に強化するものではありませんでした。

一方、RGBは「一度きりの封印（single-use seals）」という新しいパラダイムを使用しています。その使い方は非常にシンプルです：RGBは、各契約の各状態が必ず特定のビットコインUTXOに付随する必要があると要求します；そして、この状態を変更する場合は、このUTXOを消費し、その消費した取引がブロックチェーンで確認される必要があります；さらに、消費したビットコイン取引は、状態変換の内容のハッシュ値を提供し、変更後の状態が付随するUTXOを示す必要があります。

RGB開発者の見解では、この設計は番号付きのプラスチックシールに似ています：それが開封されたかどうかは簡単に判断でき、開封されると再利用できなくなります。しかし、別の視点として、付随するUTXOをこの状態のコンテナまたは陶器の貯金箱と見なすこともできます ------ 貯金箱の中のお金を取り出したい場合は、この貯金箱を壊し、中のお金を新しい貯金箱に移さなければなりません。

この設計は、以前の全体のブロックを大きな書き板と見なすプロトコルと鮮明に対比されます：UTXOをコンテナとして使用することは、このUTXOを消費しない取引がコンテナ内の契約状態に影響を与えないことを意味します。したがって、特定の契約の特定の状態を検証するために、すべてのブロックデータを取得する必要はありません。必要なのは、一連のビットコイン取引、これらのビットコイン取引が特定のブロックに存在する証拠、これらのビットコイン取引が約束するRGB状態変換（関連するビットコイン取引とペアになる）だけです。このようにしてデータを連結することで、契約の初期状態に遡ることができ、その状態の本質を識別できるようになります。

オンチェーンスマートコントラクトシステム（例えば、イーサリアム）に精通している読者にとって、このプロセスの理解が難しい点は、ブロックチェーンのコンセンサスに依存しない場合（これは契約の初期状態と各状態変化がすべてのノードによって検証されることを意味します）、このスマートコントラクトシステムのセキュリティがどのように保証されるかということです。自分が受け取った資産が本当に自分が望むものであることをどう保証するのか、資産が不正に増発されていないことをどう確保するのか？

答えは非常にシンプルで、「クライアント検証（client-side validation）」と呼ばれます ------ 自分で検証することです。オンチェーン契約システムでは、ノードは公開された状態変換ルールに基づいて、各状態変換操作を検証し、無効な操作を拒否することで、初期状態から最新の状態を計算します。しかし、状態変換ルールと初期状態が知られている限り、オンチェーンコンセンサスによる検証は唯一の方法ではありません。ユーザーは支払い側が提供する情報に基づいて、状態変換の各ステップが最初に定義された状態変換ルールに従っているかどうかを自分で検証できます。この方法により、検証側（仮に資産の受取人とします）も不正な状態変換を検出し、受け入れを拒否することができます。

最後に、RGBプロトコルの特徴を示す例を挙げます：

現在、アリスはUTXO A'を持っており、RGBプロトコルに基づいて発行されたX単位の資産Yを保存しています。彼女はZ単位のYをボブに移転したいと考えています。この資産は合計で5人の前所有者（資産発行者を含む）を経てアリスの手に渡りました。したがって、アリスはボブにこの4回の状態変換の証拠を提供する必要があります（その中の最初の3回の証拠は前所有者からアリスに提供されたものです）。これには契約の初期状態と状態変換ルール、各転送に使用されたビットコイン取引、各ビットコイン取引が約束するRGB取引、これらのビットコイン取引が特定のブロックで確認された証拠が含まれ、これらをボブに送信します。ボブは契約の状態変換ルールに基づいて、これら4回の転送がルールに違反していないことを検証し、その後受け入れるかどうかを決定します。アリスがRGB取引を構築する際、ZがXより小さいため、彼女は残りの部分を受け取るためのUTXOを自分に割り当てる必要があります。最終的に、アリスはこのRGB取引のハッシュ値をUTXO A'を消費するビットコイン取引に埋め込み、この支払いを完了させます。

最終的に、UTXOコンテナを使用することで、RGB契約の最新状態は、子孫を持たない有向非循環グラフ上の点として表現できます（各点はUTXOコンテナ内に保存されている状態を示します）。そして、下の図の所有者Pにとって、彼は契約の初期状態Gから彼のプロセス、つまり赤い円で示されたプロセスにしか気づかず、灰色の点については何も知りません：

RGBの利点

クールな検証可能な状態

前述のように、ビットコイン上で発生した資産発行プロトコル（外部契約システム）と比較して、RGBは検証（特定の契約の特定の状態）のコストを大幅に削減しました。取引時に、受取人は契約状態が変更された情報を収集するためにすべてのブロックを遍歴する必要がなく、一連のビットコイン取引と、これらの取引が約束するRGB取引、これらのビットコイン取引が含まれるブロックの証拠（ブロックヘッダーのマークル証拠に基づく）を取得するだけで、支払い側が本当に一定数量の特定の資産を持っていることを確信できます。

この検証コストの削減は、ユーザーの大型インフラ供給者への依存（信頼）を大幅に減少させます。以前のプロトコルでは、検証コストが高いため、ユーザーは契約の最新状態を自分で計算することが難しく、したがってユーザーは供給者（たとえば、自分のウォレットが使用する契約状態供給者）を信頼しなければなりませんでした；同時に、そのような計算コストを負担できる供給者は少ないため、供給者の集中化を意味します。しかし、RGBでは、ユーザーはビットコインの軽量クライアントを使用してビットコイン取引の部分を確認し、RGBプロトコルを使用してRGB取引の部分を確認することで、自分で負担できます。

いくつかのオンチェーン契約システムと比較して、RGBもまた軽量であることが示されています。これは、RGBが特定の契約の特定の状態をターゲットにして検証できることに現れます；UTXOに基づかないシステムでは、UTXOのようなアクセス制御メカニズムが欠如しているため、任意の取引が任意の状態を変更する可能性があるため、特定の状態をターゲットにして検証することはほぼ不可能であり、すべての最新状態を計算しながら特定の状態を確認するしかありません ------ この意味で、「グローバル状態（global state）」として表現される特性は実際には「ユニフォーム状態（uniform state）」と呼ばれるべきであり、契約間の交差アクセスの特性を提供しますが、これにより検証コストが高くなり、信頼性を得ることが難しくなります。

これらのオンチェーン契約プロトコルにおいて、重要な最適化手段は、ブロックヘッダーが最新状態（「状態ルート」）を約束することを要求し、軽量クライアントがこれらの約束に基づいて全ノードから得た特定の契約の特定の状態を検証できるようにすることです。これは、すでに発生した計算（全ノードが実行した計算）を再利用する方法であり、非常に効率的です。したがって、信頼性を考慮しなければ、RGBよりも効率的であると考えられます。しかし、これは結局、軽ノードが取引の基本検証と契約状態計算の両方で全ノードに依存することを意味します。一方、ビットコインの軽量クライアントを使用するRGBウォレットでは、依存する信頼仮定は関連するビットコイン取引が有効な取引であることであり、契約状態に関連する部分はクライアントが自ら検証したものであるため、信頼性がより良好です。欠点は、検証の遅延が長く、保管するデータが多くなることです。

スケーラビリティ

RGBのスケーラビリティは2つの側面に現れます：

1. ビットコイン取引に埋め込まれるのは単なるハッシュ値であり、これはRGB取引のサイズ（契約がカスタマイズしたルールを除いて）に制限がないことを意味します ------ たとえRGB資産を100分割しても（RGB取引自体は非常に大きくなるでしょう）、ビットコイン取引に埋め込む必要があるのは1つのハッシュ値だけです。注6に述べたように、このようなハッシュ値を埋め込む方法は2つあります：1つはOP_RETURN出力を使用することで、これは1つのハッシュ値のオンチェーンスペースを消費します；もう1つは、Taproot出力のスクリプト公開鍵が約束するスクリプトツリーに隠すことです ------ これはオンチェーンスペースを消費しません。この点は、ユーザーがプログラマビリティのために経済性を犠牲にする必要がないことも意味します ------ オンチェーン手数料のみを考慮すれば。

2. RGB契約の最新状態は、子孫を持たない独立した点としての有向非循環グラフです ------ これは、これらの状態が独立して変更され、互いに影響を与えないことを意味し、つまり並行性を許可します。これは実際にはUTXOから引き継がれた特性でもあります。この点は、あるブランチで発生した無効な変更（無効な取引）が他のブランチに影響を与えず、全体の契約が停止することもないため、安全性の利点とも見なすことができます。

RGBのスケーラビリティに対する批判の1つは、各転送ごとに受取人が初期状態から支払い者の状態に関与するすべての取引を検証する必要があることです ------ 資産の転送回数が増えるにつれて、後続の受取人の検証負担が増加します。この批判は真実です。そして、それを最適化するためには、すでに発生した計算を再利用する方法を見つける必要があります。証明システム技術（例えばSNARKs）は、このような解決策を提供する可能性があります。

資産定義と保管メカニズムの分化

最後の利点は、依然としてUTXOに関連しており、UTXOのロックスクリプトメカニズムをどのように理解するかに依存します。

ロックスクリプトは、資金の解放条件をプログラムするために使用できるため、保管ルールを実現できます。たとえば、ロックスクリプトが1つの公開鍵のみを含む場合、それは対応する秘密鍵の所有者のみがそれを制御できることを意味します。しかし、このような保管ルールは、ビットコイン契約型プロトコルプログラミングの基礎でもあります。たとえば、2-of-2のマルチシグロックスクリプトを使用するUTXOは、ライトニングチャネルである可能性があります；チャネルが稼働している間、両者はほぼ無限回の相互支払いを行うことができ、資金のオンチェーン形式は変わりません。言い換えれば、この時点で2-of-2のマルチシグロックスクリプトは、両者がオンチェーン資金形式を変更せずに価値を移転するメカニズムを構成します。

このようなメカニズムは、UTXOが保持するビットコインの価値に使用できるだけでなく、当然RGB資産にも使用できます。私たちは、RGB資産を発行し、それを2-of-2のマルチシグUTXOに付随させることで、ライトニングチャネルのメカニズムを利用して、両者間でこの資産を無限に相互支払いすることができます。同様に、RGB資産も他のビットコインスクリプトに基づく契約に入ることができます。

ここで、UTXOのスクリプトとRGBプロトコルは機能的に分化しています：前者は価値の保管と価値の移転のルールを実現することに専念し、後者は資産定義に焦点を当てています。これにより、資産の保管と資産の定義を分離できます。これは重要な安全性の向上であり、他のいくつかのオンチェーン契約システムで人々が追求しているものです。

RGBが行った設計

上記の特性は、実際にはすべてのUTXO一度きりの封印とクライアント検証に基づくプロトコルに当てはまります。しかし、その基盤の上に、RGBプロトコルはさらに設計を進めました。

現在のRGBプロトコルの開発において、開発者たちは特にプロトコルのプライバシーに注目しており、したがってRGBは2つの側面でプライバシーを強化しています：

• ブラインドUTXO。RGB取引では、受取人は混乱したUTXO識別子を使用して資産を受け取るだけで、実際に資産を受け取るUTXOの特性を公開する必要がありません。これは、受取人が次の所有者に証拠を提供する能力に全く影響を与えず、同時に後続の資産受取人が前の資産所有者の覗き見に対抗できるようにします。

• Bulletproof。各取引の具体的な金額を隠すために使用できます。しかし、後続の資産所有者は、以前に増発が発生していないことを検証できます。

探求可能なスペース

この部分では、RGBプロトコルがさらに探求できるスペースについて、主にプログラマビリティに関連して議論します。

現在、提案されているRGB契約テンプレート（スキーマ）は資産発行に集中しています。しかし、RGBが「クライアント検証」パラダイムを使用しているため、実際には、UTXOという構造の制限を受けるだけで、クライアント検証を通じて確保できる任意の特性を追加できます。

制限条項

UTXOの基盤の上に、プログラマビリティを拡張できる概念として「制限条項（covenants）」があります。制限条項の本来の意味は、資金が移転できる目的地を制限することです。この能力を持つことで、私たちは多くの興味深いアプリケーションをプログラムできます。たとえば：

• 非対話型引き出しの資金プール。多くの人々の資金を同じUTXOに集め、制限条項を使用して、誰も他の人の助けを借りずに自分の資金を引き出せるようにします。これは、ブロックスペースの需要が高まっているときに、低コストで人々が高リスクの場所から退出するのを助ける役割を果たすことができます。

• 金庫契約。資金がまず特定の場所に消費され、時間ロックを経て自由に消費できるようにします；時間ロックの期間中、金庫の所有者は緊急鍵を使用してこのプロセスを中断し、資金を即座に他の場所に移転できます。この装置は、自主保管を大いに助けることができます。

現在のビットコインスクリプトにはこの能力がないため、ビットコインスクリプトで制限条項を有効にするにはソフトフォークが必要です。

しかし、私たちが「資産定義と保管メカニズムの分化」によってもたらされるいくつかの利点を犠牲にすることを望むなら、RGB資産上でこのような特性を実験することができます。RGB契約レイヤーでこの機能を実現できます ------ ただし、これはそれを使用するRGB資産にのみ有効であり（ビットコインには有効ではありません）、間違いなく興味深いスペースを開くことになります。

既存の制限条項の研究は、それがUTXOに基づく取引のプログラミングスペースを拡張し、多くの特性を提供できることを示しています。しかし、これらの研究は基本的にビットコインに基づいており、ビットコインのようなプロトコルでは、私たちはより保守的になります。しかし、RGBでは、制限条項の核心的な能力 ------ スクリプトレイヤーで自分自身の取引を読み取る能力 ------ をさらに一般化し、より柔軟なプログラマビリティを提供できます：契約の交差アクセスの能力です。

交差アクセス

最小の制限条項は、UTXOが消費されるとき、そのスクリプトが消費取引の出力を読み取ることを意味します。しかし、完全に一般化された制限条項は、消費した取引のすべての部分を読み取ることができることを意味します。これは、他の入力が同じ契約から来る必要がない場合、他の契約の状態を読み取ることができることを意味します。

RGBでは、各契約が独立した宇宙であり、自身の有向非循環グラフを持つことを前提としています。しかし、ユーザーが同時に2つの異なる契約の状態を持つ場合があるかもしれません。RGB取引が2つの契約からの資産を同時に消費することを許可するなら、このような交差アクセス能力にはアプリケーションシナリオがあるかもしれません（取引の検証がより複雑になることを想像できますが）。

実際、UTXOに類似した構造を持つオンチェーン契約システム（例：Nervos Network）が、これを使用して契約の交差アクセス能力を実現しています。これは非常に新しい分野であり、従来のビットコイン研究がほとんど触れてこなかった領域であり、驚きが隠されているかもしれません。

結論

この記事では、読者は「UTXO」という概念が頻繁に言及され、推論と幻想のすべてのプロセスに貫かれていることに気づくでしょう。これは私の意図です。UTXOを理解しなければ、RGBのようなプロトコルの設計の出発点を理解することはできず、RGBプロトコル設計の利点を理解することもできず、人々がそれを使用する方法を想像することもできません。RGBプロトコルの特性は、非常に大きな程度でそのUTXOという一度きりの封印の形式によって形作られています。それに応じて、ビットコイン研究分野に蓄積されたUTXOに関する研究も、RGBの研究に応用できます。

これもまた、ビットコインを理解していない人がRGBを理解するのが難しい理由を説明しています。そして、ビットコインを好む人々は、RGBがすでに行った設計を認めるでしょう。