原作者: A Jian、Wu Shuo Blockchain
この記事は、ビットコインの資産発行プロトコルである RGB (オフチェーン スマート コントラクト システムとしても理解できます) について簡潔に説明することを試み、同じことを達成することを目的とした他のプロトコルとは大きく異なることを指摘します。これらの違いにより、RGB プロトコルはそれらよりもはるかにスケーラブルになり、より広いプログラミング領域が確保されます。 RGB の完成したデザインを紹介することに加えて、これらのプログラミングの可能性も探っていきます。
RGBプロトコルとは何ですか?
ビットコインで資産を発行するというアイデアは長い間存在していました。しかし、ビットコイン プロトコルには独自の特徴があります。その状態はビットコイン UTXO (「未使用のトランザクション出力」) によってのみ表現されます。UTXO は、独自の額面 (ビットコインの値) と「スクリプト公開キー」( 「ロック スクリプト」とも呼ばれます)、資金を支出するための条件をプログラムするために使用されます。たとえば、特定の公開鍵の署名を提供します。ロック スクリプトのプログラミングを許可するオペコードは、次の条件を満たす場合にビットコインのコンセンサス ルールによって決定されます。任意のセキュリティ ルールを実装するために使用することはできません。したがって、UTXO 内に他のアセットを作成することはできません。ビットコイン スクリプトはこれらのアセットのセキュリティ チェックをプログラムできません。これは、ビットコインで資産を発行するためのすべてのアイデアは、本質的にビットコインのブロックスペースを創造的に利用することであることを意味します。これは、オフチェーンのスマート コントラクト システムを設計し、コントラクトの状態を変更するステップに関する情報が必要であることを意味します。たとえば、コントラクト A はパラメータを変更し、B は一定量の資産を C に転送します - ブロックチェーンにアップロードします、この情報を収集することで、このスマート コントラクト システムの最新のステータスを取得できます。
大まかな設計アイデアは、コントラクト状態を変更するステップの情報をそのままビットコイン ブロックチェーンにアップロードすることです。これは確かに機能しますが、いくつかの問題に直面します: (1) 完全な情報がアップロードされるため、ユーザーが契約のステータスを変更する必要がある場合 (譲渡など)、より多くのブロック スペースを消費する可能性があります。より多くのオンチェーン手数料を支払う必要があります。特に、そのようなオフチェーン契約システムがビットコインよりも優れたプログラマビリティを備えていることを期待する場合、プログラマビリティの向上は、より多くのブロック領域を消費することを犠牲にして実現される可能性があります; (2) ブロック内のほとんどすべての情報が 1 か所にあると、その情報が変更される可能性があります。スマートコントラクトはチェーンの外側にあるため、ユーザーはオフチェーンコントラクトシステムの最新状況を知るためにすべてのビットコインブロックデータを取得する必要があり、検証コストが高くなります; (3) オフチェーンスマートコントラクトの設計に応じて契約システムでは、ビットコインと同等かそれ以上のプライバシーしか取得できない可能性があり、より多くのプライバシーを提供できる場合は、より多くのブロック スペースを消費する必要がある可能性があります。
以前は、「オムニ」と呼ばれる広く使用されていたプロトコルでは、オフチェーン契約トランザクションの完全な情報はアップロードされず、トランザクションのハッシュ値のみがアップロードされました。このアプローチは上記の問題 1 を解決し、オフチェーン契約トランザクションの複雑さを経済的コストから切り離しますが、ユーザーは依然としてオムニ プロトコルの最新ステータスを取得するために全量のビットコイン ブロック データを取得する必要があります。プライバシーの具体的な強化はありません。
RGB は、「使い捨てシール」と呼ばれる新しいパラダイムを使用します。その使用法は非常に簡単です: RGB では、各コントラクトのすべての状態が特定のビットコイン UTXO に関連付けられる必要があり、この状態を変更したい場合は、この UTXO を使用し、それを使用するトランザクションにブロックチェーンの確認を取得させる必要があります。さらに、ビットコインを使用するビットコイン トランザクションは、変更された状態にアタッチされた UTXO を示すために、状態遷移の内容のハッシュも提供する必要があります。
RGB 開発者にとって、このデザインは番号付きのプラスチック シールに似ています。剥がされたかどうかが簡単にわかり、一度剥がすと再利用できません。しかし、別の見方としては、所持しているUTXOをこの状態の容器、あるいは陶器の貯金箱とみなすこともでき、貯金箱の中のお金を取り出したい場合は、貯金箱を割って中のお金を取り出さなければなりません。新しい瓶の中のお金。
この設計は、ブロック全体を大きな書き込みボードとして扱う以前のプロトコルとは大きく対照的であり、UTXO をコンテナとして使用するということは、この UTXO を使用しないトランザクションがコンテナ内のコントラクト状態に影響を与えることができないことを意味します。あるコントラクトの特定の状態であれば、すべてのブロックのデータを取得する必要はなく、必要なのは、一連のビットコインのトランザクションと、そのビットコインのトランザクションが特定のブロックに存在する証拠と、これらのビットだけです。通貨交換（関連するビットコイントランザクションとの1対1のペア）で十分です。チェーンに接続できるこれらのデータにより、この契約の初期状態にまで遡ることができ、この状態の本質を特定できるようになります。
オンチェーン スマート コントラクト システム (イーサリアムなど) に精通している読者にとって、このプロセスについて理解するのが難しいことの 1 つは、ブロックチェーンのコンセンサス (つまり、ブロックチェーンの初期状態) に依存しない場合であるということです。契約とすべての状態変更は各ノードによって検証されます)、このスマート コントラクト システムのセキュリティはどのように保証されますか?受け取る資産が希望するものであることを確認する方法、またその資産が違法に発行されていないことを確認する方法は?
答えも非常に簡単です。これは「クライアント側検証」と呼ばれるもので、自分で検証します。オンチェーン コントラクト システムでは、ノードは公開状態遷移ルールに従って各状態遷移操作を検証し、無効な操作を拒否し、初期状態に基づいて最新の状態を計算します。ただし、状態遷移ルールと初期状態がわかっていれば、オンチェーンコンセンサスによる検証だけが唯一の方法ではなく、ユーザーは、状態遷移の各ステップが、最初に定義された状態遷移に従っているかどうかを、提供される情報に基づいて検証できます。支払者のルール。このようにして、検証側 (資産の受信者であると想定される) も、違法な状態遷移を検出し、それらの受け入れを拒否することができます。
最後に、例を使用して RGB プロトコルの特性を示します。
現在、アリスは、RGB プロトコルに従って発行された資産 Y の X ユニットを保持する UTXO A を所有しており、Y の Z ユニットをボブに転送したいと考えています。この一連の資産は、アリスの手に届くまでに、合計 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. ビットコイントランザクションに埋め込まれているのはハッシュ値のみです。つまり、1 つの RGB アセットを 100 個の部分 (RGBトランザクション自体は非常に大きくなります)、ビットコイン トランザクションに埋め込む必要があるハッシュは 1 つだけです。注 6 で述べたように、このようなハッシュ値を埋め込むには 2 つの方法があります: 1 つは OP_RETURN 出力を使用することで、これはハッシュ値のオンチェーン領域を消費することを意味します; もう 1 つは、スクリプトの公開キー出力を非表示にすることです。 Taproot コミットされたスクリプト ツリー上 - これはオンチェーン スペースを消費しません。これは、ユーザーがプログラマビリティのために経済性を犠牲にする必要がなく、オンチェーン料金のみを考慮する必要があることも意味します。
2. 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) がすでに存在しており、これを使用してコントラクトのクロスアクセス機能を実現しています11。これは非常に新しい分野であり、これまでのビットコイン研究ではほとんど触れられていなかった領域に切り開かれており、そこにはいくつかの驚きが隠されている可能性があります。
結論は
この記事で読者は、推論と空想のすべてのプロセスで頻繁に言及され使用される概念、「UTXO」があることに気づくでしょう。これはまさに私の意図です。 UTXO を理解していなければ、RGB のようなプロトコル設計の出発点を理解することも、RGB プロトコル設計の利点を理解することも、人々がそれをどのように使用するかを想像することもできません。 RGB プロトコルの特性は、主に、UTXO の 1 回限りのシールされた形式によって形成されます。同様に、ビットコイン研究分野で蓄積されたUTXOに関する研究は、RGBに関する研究にも応用することができます。
これは、ビットコインを理解していない人が RGB を理解するのが難しい理由も説明しています。ビットコインが好きな人なら、RGB が作ったデザインに気づくでしょう。
