著者：A・ジアン

この記事は、ビットコイン上の資産発行プロトコルである RGB (オフチェーン スマート コントラクト システムとしても理解できます) について簡潔に説明することを試み、それが他のプロジェクトとは大きく異なることを指摘します。同じまたは類似の機能プロトコルを実現する場合、これらの違いにより、RGB プロトコルはそれらよりもはるかにスケーラブルになり、より広いプログラミング空間が残ります。 RGB の完成したデザインを紹介することに加えて、これらのプログラミングの可能性も探っていきます。

RGBプロトコルとは何ですか?

ビットコインで資産を発行するというアイデアは長い間存在していました。しかし、ビットコイン プロトコルには独自の特徴があります: その状態はビットコイン UTXO (「未使用のトランザクション出力」) によってのみ表現されます。UTXO は 2 つのデータのみを保持します: 独自の額面 (ビットコインの値) と「スクリプト公開キー」(これも「ロッキング スクリプト」として知られています)、このファンドの支出条件をプログラムするために使用されます。たとえば、特定の公開鍵の署名を提供すること、ロッキング スクリプトのプログラムに使用されるオペコードをビットコインのコンセンサス ルールによって決定できるようにすることなどです。任意のセキュリティ ルールを実装するために使用される可能性があります。したがって、UTXO 内に他のアセットを作成することは不可能です。ビットコイン スクリプトはこれらのアセットのセキュリティ チェックをプログラムできません。これは、ビットコインで資産を発行するためのすべてのアイデアは、本質的にビットコインのブロックスペースを創造的に利用することであることを意味します。これは、オフチェーン スマート コントラクト システムを設計し、コントラクトの状態を変更する手順を必要とすることを意味します。たとえば、コントラクト A はパラメーターを変更し、B は一定量の特定の資産を C に転送します。情報はブロックチェーンにアップロードされるため、この情報を収集することでスマートコントラクトシステムの最新の状況を把握することができます。

大まかな設計アイデアは、コントラクト状態を変更するステップの情報をそのままビットコイン ブロックチェーンにアップロードすることです。これは確かに機能しますが、いくつかの問題に直面します。

(1) 完全な情報をアップロードするため、より多くのブロック容量を消費する可能性があり、ユーザーが契約ステータスを変更する必要がある場合（転送など）、オンチェーン手数料もより多く支払う必要があります。特に、そのようなオフチェーンコントラクトシステムがビットコインよりも優れたプログラマビリティを備えていることを期待する場合、プログラマビリティの向上はより多くのブロックスペースを消費するという犠牲を伴う可能性があります。

(2) ブロック内のほぼすべての情報がチェーンの外側のスマート コントラクトを変更する可能性があるため、ユーザーはオフチェーン コントラクト システムの最新の状態を取得するためにすべてのビットコイン ブロック データを取得する必要があります。

(3) オフチェーン スマート コントラクト システムの設計によっては、ビットコインと同等かそれ以上のプライバシーしか取得できない場合があり、より多くのプライバシーを提供できる場合は、より多くの領域を消費する必要がある場合があります。ブロックスペース。

以前は、「オムニ」と呼ばれる広く使用されていたプロトコルでは、オフチェーン契約トランザクションに関する完全な情報はアップロードされず、トランザクションのハッシュ値のみがアップロードされました。このアプローチは上記の問題を解決し、オフチェーン契約トランザクションの複雑さを経済的コストから切り離しますが、ユーザーは依然としてオムニ プロトコルの最新ステータスを取得するために全量のビットコイン ブロック データを取得する必要があります。プライバシーを強化するために特別に設計されたものではありません。

RGB は、「使い捨てシール」と呼ばれる新しいパラダイムを使用します。その使用法は非常に簡単です: RGB では、各コントラクトのすべての状態を特定のビットコイン UTXO に添付する必要があり、この状態を変更したい場合は、この UTXO を使用し、それを使用するトランザクションに確認を取得させる必要があります。さらに、ビットコインを使用するビットコイン トランザクションは、変更された状態にアタッチされた UTXO を示すために、状態遷移の内容のハッシュも提供する必要があります。

RGB 開発者にとって、このデザインは番号付きのプラスチック シールに似ています。剥がされたかどうかが簡単にわかり、一度剥がすと再利用できません。しかし、別の見方としては、この状態で所持しているUTXOをコンテナ、つまり陶器製の貯金箱とみなして、貯金箱の中のお金を取り出すには、貯金箱を壊して中にお金を入れる必要があります。新しい瓶に。

この設計は、ブロック全体を大きな書き込みボードとして扱う以前のプロトコルとは大きく対照的であり、UTXO をコンテナとして使用するということは、この UTXO を使用しないトランザクションがコンテナ内のコントラクト状態に影響を与えることができないことを意味します。あるコントラクトの特定の状態であれば、すべてのブロックのデータを取得する必要はなく、必要なのは、一連のビットコインのトランザクションと、そのビットコインのトランザクションが特定のブロックに存在する証拠と、これらのビットだけです。通貨交換（関連するビットコイントランザクションとの1対1のペア）で十分です。チェーンに接続できるこれらのデータにより、この契約の初期状態にまで遡ることができ、この状態の本質を特定できるようになります。

オンチェーン スマート コントラクト システム (イーサリアムなど) に精通している読者にとって、このプロセスについて理解するのが難しいことの 1 つは、ブロックチェーンのコンセンサス (つまり、ブロックチェーンの初期状態) に依存しない場合であるということです。契約とすべての状態変更は各ノードによって検証されます)、このスマート コントラクト システムのセキュリティはどのように保証されますか?受け取る資産が希望するものであることを確認する方法、またその資産が違法に発行されていないことを確認する方法は?

答えも非常に簡単です。これは「クライアント側検証」と呼ばれるもので、自分で検証します。オンチェーン コントラクト システムでは、ノードは公開状態遷移ルールに従って各状態遷移操作を検証し、無効な操作を拒否し、初期状態に基づいて最新の状態を計算します。ただし、状態遷移のルールと初期状態がわかっていれば、オンチェーンコンセンサスによる検証だけが唯一の方法ではなく、状態遷移の各ステップが当初定義された状態遷移に従っているかどうかを、ユーザーが提供する情報に基づいて検証することができます。支払者のルール。このようにして、検証側 (資産の受信者であると想定される) も、違法な状態遷移を検出し、それらの受け入れを拒否することができます。

最後に、例を使用して RGB プロトコルの特性を示します。

現在、アリスは、RGB プロトコルに従って発行された X ユニットの資産 Y を保持する UTXO A を所有しており、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 のようなアクセスを制御するメカニズムが欠如しているため、トランザクションによって状態が変更される可能性があるため、特定の状態を具体的に検証することはほぼ不可能であり、最新の状態をすべて計算しながら特定の状態を決定することしかできません。この意味で、「グローバルな状態」として表現される特性は、実際には「均一な状態」と呼ばれるはずですが、契約間のクロスアクセス機能を提供する一方で、検証コストが高くなり、トラストレス性の確保がより困難になると判断しています。

これらのオンチェーン コントラクト プロトコルでは、主要な最適化手段は、ブロック ヘッダーが最新の状態 (「状態ルート」) にコミットすることを要求することです。これにより、ライト クライアントは、フル ノードから取得したコントラクトの特定の状態を、以下に基づいて検証できるようになります。これらの取り組み。これは、既に行われた計算（フルノードで実行された計算）を再利用する方法であり、効率も非常に高いため、トラストレス性を考慮しなければRGBよりも効率的であると考えられます。ただし、結局のところ、ライトノードは基本的なトランザクションの検証と契約ステータスの計算をフルノードに依存していることを意味します。ビットコインライトクライアントを使用するRGBウォレットでは、関連するビットコイントランザクションが有効なトランザクションであり、契約ステータスに関連する部分はクライアントによって個人的に検証されているため、より信頼性が高くなります。無料です。欠点は、検証の遅延が長くなり、より多くのデータを保持する必要があることです。

スケーラビリティ

RGB のスケーラビリティは、次の 2 つの側面に反映されます。

ビットコイン トランザクションに埋め込まれているのは単なるハッシュ値です。つまり、1 つの RGB アセットを 100 の部分 (RGB トランザクション) に分割した場合でも、RGB トランザクションの量に制限はありません (契約のカスタム ルールを除く)。それ自体は非常に大きくなります)、ビットコイン トランザクションに埋め込む必要があるハッシュ値は 1 つだけです。注 6 で述べたように、このようなハッシュ値を埋め込むには 2 つの方法があります: 1 つは OP_RETURN 出力を使用する方法で、これはハッシュ値のオンチェーン領域を消費することを意味します; もう 1 つはスクリプトのパブリック出力を非表示にすることですTaproot キー内 - これはチェーン上のスペースを消費しません。これは、ユーザーがプログラマビリティのために経済性を犠牲にする必要がなく、オンチェーン料金のみを考慮する必要があることも意味します。

RGB コントラクトの最新の状態は、子孫を持たない有向非巡回グラフ上の独立した点です。これは、これらの状態が相互に影響を与えることなく独立して変更できることを意味し、同時実行が許可されることを意味します。これは実際にはUTXOから継承された機能です。これは、あるブランチで発生した無効な変更 (無効なトランザクション) が他のブランチに影響を与えないことを意味し、ましてやコントラクト全体が停止することはないため、セキュリティ上の利点とも言えます。

RGB のスケーラビリティについて批判されている点の 1 つは、各送金の受信者が初期状態から支払者状態まで関係するすべてのトランザクションを検証する必要があることであり、資産の所有者が変わる回数が増加するにつれて、後続の受信者の検証負担が増加します。どんどん重くなっていきます。この批判は真実です。最適化するということは、すでに行われた操作を再利用する方法を見つける必要があることも意味します。 SNARK などのプルーフ システム テクノロジは、そのようなソリューションを提供することを約束します。

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

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

ロック スクリプトを使用してファンドのロック解除条件をプログラムできるため、保管ルールを実装できます。たとえば、ロック スクリプトに公開キーが 1 つだけ含まれている場合、対応する秘密キーの所有者だけがそれを制御できることを意味します。ただし、このような保管ルールは、ビットコインのコントラクトプロトコルプログラミングの基礎でもあります。たとえば、2-of-2 マルチシグネチャ ロッキング スクリプトを使用する UTXO はライトニング チャネルになる可能性があり、チャネルの動作中、両当事者はオンチェーン形式を変更することなく、ほぼ数え切れないほど互いに支払いを行うことができます。資金。言い換えれば、現時点では、2-of-2 マルチシグネチャ ロッキング スクリプトは、チェーン上の資金の形式を変更せずに双方が価値を転送できるようにする価値転送メカニズムを構成します。

このようなメカニズムは、UTXO が保持するビットコインの価値に使用できますが、当然のことながら、UTXO が保持する RGB アセットにも使用できます。 RGB アセットを発行し、それを 2-of-2 マルチ署名 UTXO にアタッチすることで、ライトニング チャネル メカニズムを使用して、このアセットを無制限に何度でも相互に支払うことができます。同様に、RGB アセットは、ビットコイン スクリプトに基づいて他のコントラクトに入力することもできます。

ここで、UTXO スクリプトと RGB プロトコルは機能的な差別化を形成しています。前者は価値の保管と価値の移転のルールの実現に注力しており、後者は資産の定義に重点を置いています。したがって、資産の保管と資産の定義を分離できます。これは重要なセキュリティの改善であり、他のオンチェーン コントラクト システムでも人々が目指しているものです。

RGB デザインはすでに作成されています

上記の特性は、実際には、UTXO ワンタイム シーリングとクライアント検証に基づくすべてのプロトコルに当てはまります。しかし、これに基づいて、RGB プロトコルはさらに設計されました。

RGB プロトコルの現在の開発では、開発者はプロトコルのプライバシーを特に懸念しているため、RGB は次の 2 つの側面でプライバシーを強化します。

ブラインドUTXO。 RGB トランザクションでは、受信者は、実際にアセットを受信した UTXO の特性を公開することなく、難読化された UTXO 識別子を使用するだけでアセットを受信できます。これは、次の所有者に証拠を提供する受信者の能力を損なうものではなく、その後の資産受信者が前の資産所有者の詮索好きな目から身を守ることを可能にします。

防弾。各取引の特定の金額を非表示にするために使用できます。ただし、その後の資産所有者は、これまでに追加発行が行われていないことを確認できます。

探索すべき空間

このセクションでは、主にプログラマビリティに関連して、RGB プロトコルが引き続き探索できる領域について説明します。

現在、提案されている RGB 契約テンプレート (スキーマ) は、資産の発行に焦点を当てています。ただし、RGB は「クライアント側検証」パラダイムを使用するため、クライアント側検証によって保証できる任意の特性を実際に追加できます (UTXO の構造によってのみ制限されます)。

＃＃ 制限

UTXO に基づいて、プログラマビリティを拡張できる概念は「コベナント」と呼ばれます。制限条項の本来の目的は、送金できる宛先を制限することです。この機能を使用すると、次のような多くの興味深いアプリケーションをプログラムできます。

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

保管庫契約。資金は、自由に使用できるようになる前に、まずどこかで使用され、タイム ロックを通過する必要があります。タイム ロック期間中、金庫の所有者は緊急キーを使用してこのプロセスを中断し、資金をすぐに別の場所に転送できます。このデバイスは、自律的な監護に非常に役立ちます。

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

ただし、「アセット定義と保管メカニズムの差別化」によってもたらされる利点の一部を犠牲にすることをいとわない限り、RGB アセットでそのような機能を実験することができます。そのような機能は RGB コントラクト レベルで実装できます。のみ これを使用する RGB アセット (ビットコインではない) では機能しませんが、間違いなく興味深い空間が開かれます。

制限条項に関する既存の研究では、制限条項が UTXO ベースのトランザクションのプログラミング領域を拡張し、多くの機能を提供できることが示されています。しかし、これらの研究は基本的にビットコインに基づいており、ビットコインのようなプロトコルに基づいているため、私たちはより保守的になります。 RGB では、制限条項の中核となる機能 (スクリプト レベルで消費するトランザクションを読み取る機能) を大胆に一般化して、より柔軟なプログラマビリティ (コントラクトをクロスアクセスする機能) を提供できます。

クロスアクセス

最小限の制限条件とは、UTXO が使用されるときに、そのスクリプトが使用トランザクションの出力を読み取ることができることを意味します。しかし、完全に一般化された制約は、それを消費したトランザクションのすべての部分を読み取ることができることを意味します。これは、トランザクションの他の入力も読み取ることができることを意味します。他の入力を同じコントラクトからのものに制限しない場合、他のコントラクトのステータスを読み取ることができることを意味します。

RGB では、デフォルトでは、各コントラクトが独自の有向非巡回グラフを持つ独立したユニバースであると設定されています。ただし、ユーザーが 2 つの異なる契約のステータスを同時に保持することは可能です。 RGB トランザクションが両方の契約の資産の同時支出を許可する場合、そのようなクロスアクセス機能は応用できる可能性があります (ただし、トランザクションの検証がより複雑になる可能性は考えられます)。

実際、UTXO と同様の構造に基づくオンチェーン コントラクト システム (例: Nervos Network) がすでに存在しており、これを使用してコントラクトのクロスアクセス機能を実現しています。これは非常に新しい分野であり、これまでのビットコイン研究ではほとんど触れられていなかった領域に切り開かれており、そこにはいくつかの驚きが隠されている可能性があります。

＃ 結論は

この記事で読者は、頻繁に言及され、推論と空想のすべてのプロセスに貫かれている概念、「UTXO」があることに気づくでしょう。これはまさに私の意図です。 UTXO を理解していなければ、RGB のようなプロトコル設計の出発点を理解することも、RGB プロトコル設計の利点を理解することも、人々がそれをどのように使用するかを想像することもできません。 RGB プロトコルの特性は、主に、UTXO の 1 回限りのシールされた形式によって形成されます。同様に、ビットコイン研究分野で蓄積されたUTXOに関する研究は、RGBに関する研究にも応用することができます。

これは、ビットコインを理解していない人が RGB を理解するのが難しい理由も説明しています。ビットコインが好きな人なら、RGB が作ったデザインに気づくでしょう。