BTC資産発行プロトコルRGBの真の可能性とは?

著者**|**A Jian

元のリンク:

この記事では、BTC上の資産分配プロトコル(オフチェーンのスマートコントラクトシステムとしても理解できます)であるRGBの簡潔な説明を試み、RGBプロトコルを実際よりもはるかにスケーラブルにし、プログラミングの余地を残す、同じまたは類似の機能を実現することを目的とした他のプロトコルとの違いを指摘します。 RGBの完成した設計を紹介するだけでなく、これらのプログラミングの可能性も探ります。

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

BTCで資産を発行するというアイデアは、長い間存在していました。 しかしBTCプロトコルには独自の特徴があり、その状態はBTC UTXO(「未使用のトランザクションアウトプット」)によってのみ表現され、UTXOは独自のデノミネーション(BTC値)と、公開鍵の署名の提供など、資金が使われる条件をプログラムするために使用される「スクリプト公開鍵」(「ロックスクリプト」とも呼ばれる)の2つのデータしか保持せず、ロックスクリプトをプログラムできるようにするオペコードは、BTCのコンセンサスルールによって提供され、任意のセキュリティルールを実装するために使用することはできません。 その結果、UTXO内に他のアセットを作成することはできません — BTCスクリプトはそれらのアセットのセキュリティチェックをプログラムできません。 つまり、BTCで資産を発行するというアイデアは、本質的にBTCブロックスペースの創造的な使用です。 つまり、オフチェーンのスマートコントラクトシステムを設計し、コントラクトの状態を変更するステップ(例えば、コントラクトAがパラメータを変更し、Bが一定量の資産をCに転送するなど)に関する情報をブロックチェーンにアップロードし、この情報を収集することでスマートコントラクトシステムの最新の状態を取得できるようにする必要があります。

大まかな設計アイデアは、コントラクトの状態を変更するステップの情報をそのままBTCブロックチェーンにアップロードすることです。 もちろん、これはうまくいきますが、いくつかの問題に直面します:(1)完全な情報をアップロードするため、より多くのブロックスペースを消費する可能性があり、ユーザーが契約の状態(送金など)を変更する必要がある場合、より多くのオンチェーン料金を支払う必要があります。 特に、このようなオフチェーンのコントラクトシステムにBTCよりも優れたプログラマビリティを持たせたい場合、プログラマビリティの向上は、より多くのブロックスペースを消費する代償としてもたらされる可能性があります:(2)ブロック内のほぼどこでも、情報はオフチェーンのスマートコントラクトを変更する可能性があるため、ユーザーはオフチェーンのコントラクトシステムの最新の状態を取得するためにBTCブロックデータをすべて取得する必要がある、つまり、検証にコストがかかる、(3)オフチェーンのスマートコントラクトシステムの設計によっては、BTCと同じかそれ以上のプライバシーしか得られない可能性があり、より多くのプライバシーを提供できる場合は、より多くのブロックスペースを消費する必要があるかもしれません。

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

一方、RGBは「使い捨てシール」と呼ばれる新しいパラダイムを使用しています。 RGBでは、各コントラクトのすべての状態をBTC UTXOにアタッチする必要があり、その状態が変更されると、UTXOを使用したトランザクションがブロックチェーンによって確認されるようにUTXOを使用する必要があり、それを使用するBTCトランザクションは、変更された状態がアタッチされているUTXOを示すために状態遷移のハッシュも提供する必要があります。

RGB開発者の目には、このデザインは番号付きのプラスチックシールに似ており、取り外されたかどうかが簡単にわかり、一度取り外すと使用できなくなります。 しかし、別の見方をすれば、この状態では、所持しているUTXOを容器やセラミックの貯金箱として使用することで、貯金箱からお金を取り出すには、貯金箱を壊して中のお金を新しい貯金箱に入れる必要があります。

この設計は、ブロック全体を大きなレターボードとして扱う以前のプロトコルとはまったく対照的です:UTXOをコンテナとして使用することは、このUTXOを使わないトランザクションがコンテナ内のコントラクトの状態に影響を与えないことを意味するため、コントラクトの特定の状態を検証するために、すべてのブロックデータを取得する必要はなく、必要なのは一連のBTCトランザクション、これらのBTCトランザクションがブロックに存在することの証明、およびこれらのRGB BTC取引所のコミットメントだけです 状態遷移 (関連する BTC トランザクションとのペア)。 チェーンに連結できるこのデータにより、コントラクトの初期状態までさかのぼることができ、この状態の本質を特定できるはずです。

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

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

最後に、例を使用してRGBプロトコルの特性を説明しましょう。

現在、Alice は RGB ライセンスで発行された X ユニットの資産 Y を保有する UTXO A’ を所有しており、Y の Z ユニットを Bob に譲渡したいと考えています。 アリスにたどり着くまでには、資産の前の所有者(発行者を含む)が合計5人かかりました。 したがって、アリスは、コントラクトの初期状態と状態遷移ルール、各転送に使用されるBTCトランザクション、交換BTCコミットされた各RGBトランザクション、およびこれらのBTCトランザクションがブロックによって確認されたという証拠を含む、これら4つの状態遷移の証拠(最初の3つは前の所有者からアリスに提供されたもの)をボブに提供し、ボブに送信し、ボブはコントラクトの状態遷移ルールに従ってこれら4つを検証します ルールを破らずに転送し、それを受け入れるかどうかを決定します。 アリスがRGBトランザクションを構築するとき、ZはXより小さいので、残りを受け取るためにUTXOも手配します。 最後に、アリスはRGBトランザクションのハッシュをBTCトランザクションに埋め込み、支払いを完了するためにUTXO A’がかかります。

最終的に、UTXOコンテナの使用により、RGBコントラクトの最新の状態は、まだ子孫を持たない有向非巡回グラフ上の点として表すことができます(各点はUTXOコンテナ内に格納された状態を表します)。 そして、下図のオーナーPは、コントラクトの初期状態Gから自分へのプロセス(赤丸で囲んだプロセス)しか知らず、灰色の点については何も知りません。

RGBの利点

クール検証可能なステータス

前述したように、RGBは、これまでBTCで登場した資産発行プロトコル(オフチェーン契約システム)と比較して、検証(契約の特定の状態)のコストを大幅に削減します。 トランザクションの時点で、受信者はコントラクトの状態の変化に関する情報を収集するためにすべてのブロックを反復処理する必要はなく、一連のBTCトランザクション、これらの取引所によって約束されたRGBトランザクション、およびこれらのBTCトランザクションの証拠を含むブロック(ブロックヘッダーのマークルプルーフによる)を取得するだけで、支払者が特定の資産を一定量実際に所有していることを確信できます。

この検証コストの削減により、大規模なインフラストラクチャプロバイダーに対するユーザーの依存(信頼)も大幅に軽減されます。 従来のプロトコルでは、検証コストが高いため、ユーザーが自分でコントラクトの最新の状態を計算することが困難であったため、ユーザーは一部のベンダー(ウォレットが使用するコントラクトステートプロバイダーなど)を信頼する必要があり、同時に、そのような計算コストを負担できるサプライヤーが少なく、ベンダーが中央集権化されていました。 ただし、RGBでは、ユーザーはBTCライトクライアントを使用してトランザクションの一部をBTCでチェックし、RGBプロトコルを使用してRGBトランザクションの一部を確認するだけでよく、余裕があります。

一部のオンチェーンコントラクトシステムと比較して、RGBも軽量です。 これは、RGBがコントラクトの特定の状態を具体的に検証できるという事実に反映されていますが、UTXOに基づいていないシステムでは、UTXOなどのアクセスを制御するメカニズムがないため、任意のトランザクションが任意の状態を変更できるため、特定の状態をターゲットにした方法で検証することはほとんど不可能ですが、すべての最新の状態を計算しながら特定の状態を決定することしかできません-この意味で、「グローバル状態」として表現される機能は実際には「 Uniform State」は、コントラクト間のクロスアクセスを提供しますが、検証にコストがかかり、トラストフリーを取得するのがより困難になるとも判断します。

これらのオンチェーンコントラクトプロトコルの大幅な最適化は、ブロックヘッダーが最新の状態(「ステートルート」)にコミットするための要件であり、ライトクライアントはこれらのコミットメントに対してフルノードからコントラクトの特定の状態を検証できます。 これは、すでに発生した計算(フルノードによってすでに実行されている計算)を再利用する方法であり、非常に効率的でもあるため、トラストレスを考慮しない場合、RGBよりも効率的であると見なすことができます。 ただし、ライトノードは、トランザクションベースの検証とコントラクト状態の計算をフルノードに依存していることを意味します。 BTCライトクライアントを使用するRGBウォレットでは、トランザクションが有効BTC関連性があるという信頼の前提に依存しており、コントラクトの状態に関する部分はクライアント自身によって検証されるため、トラストレスの方が良いです。 欠点は、検証の遅延が長くなり、より多くのデータを保持する必要があることです。

スケーラビリティ

RGBのスケーラビリティには2つのメリットがあります。

1. BTCトランザクションに埋め込まれるハッシュは1つだけで、RGBトランザクションのサイズに制限はありません(コントラクトでカスタマイズされたルールを除く) - 1つのRGBアセットを100に分割しても(RGBトランザクション自体は非常に大きくなります)、トランザクションに埋め込む必要があるハッシュBTC 1つだけです。 注6で述べたように、 このようなハッシュを埋め込むには、 OP_RETURNアウトプット(オンチェーンスペースのハッシュを1つ消費する)を使用する方法と、 Taprootアウトプットのスクリプト公開鍵で約束されたスクリプトツリーに隠す方法(オンチェーンスペースを消費しない)の2つの方法があります。 これは、ユーザーがプログラマビリティのために経済性を犠牲にする必要がなく、オンチェーン料金だけを犠牲にする必要があることも意味します。

2. RGBコントラクトの最新の状態は、子孫を持たない有向非巡回グラフ上の独立した点です - これは、これらの状態が互いに影響を与えることなく独立して変更できる、つまり並行性が許可されることを意味します。 これもUTXOから継承された機能です。 これは、1 つのブランチで発生した無効な変更 (無効なトランザクション) が他のブランチに影響を与えず、ましてや契約全体が凍結する原因にもならないことも意味するため、セキュリティ上の利点と見なすこともできます。

RGBは、送金のたびに、受取人は初期状態から支払者状態まで、関連するすべての取引を検証する必要があり、資産移転の数が増えると、後続の受取人の検証負担が増加するというスケーラビリティが批判されています。 この批判は本当です。 最適化とは、すでに発生した計算を再利用する方法を見つけることを意味します。 SNARKsなどのプルーフシステム技術は、そのようなソリューションを提供することが期待されています。

資産定義と税関申告メカニズムの差別化

最後の利点は、UTXOのロックスクリプティングメカニズムをどのように理解するかにもよりますが、依然としてUTXOに関連しています。

ロックスクリプトを使用して、ファンドのロックが解除される条件をプログラムできるため、カストディアルルールを実装できます。 たとえば、ロック スクリプトに公開キーが 1 つしか含まれていない場合、対応する秘密キーの所有者のみがそれを制御できることを意味します。 しかし、このようなカストディアル・ルールは、BTC契約上のプロトコル・プログラミングの基礎にもなります。 例えば、2-of-2マルチシグロックスクリプトを使用するUTXOはライトニングチャネルであり、チャネルの運用中、2つの当事者は、資金のオンチェーン形式を変更することなく、ほぼ無限にお互いに支払うことができます。 言い換えれば、この時点では、2-of-2マルチシグロックスクリプトは、オンチェーンファンドの形態を変えることなく、両者が価値を移転することを可能にする価値移転メカニズムを構成しています。

このようなメカニズムは、UTXOが保有するBTCの価値や、当然のことながら、UTXOが保有するRGBアセットにも使用できます。 RGBアセットを発行し、それを2-of-2マルチシグネチャーUTXOにアタッチし、ライトニングチャネルのメカニズムを使用して、お互いに無制限に支払うことができます。 同様に、RGBアセットは、他のBTCスクリプトベースのコントラクトでも使用できます。

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

RGBが設計されました

上記の機能は、UTXOのワンタイムシーリングとクライアント側の検証に基づく事実上すべてのプロトコルに当てはまります。 しかし、それに加えて、RGBプロトコルはさらに設計されています。

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

*盲検化されたUTXO。 RGBトランザクションでは、受信者は難読化されたUTXO識別子を使用して資産を受け取るだけでよく、実際に資産を受け取るUTXOの特性を公開する必要はありません。 これは、次の所有者に証拠を提供する受取人の能力を損なうものではなく、同時に、資産の後続の受取人が前の資産所有者の詮索好きな目から身を守ることを可能にします。 *防弾。 これは、各トランザクションの正確な金額を隠すために使用できます。 ただし、その後の資産所有者は、以前に追加の発行が行われていないことを確認できます。

探索可能な空間

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

現在、提案されているRGBコントラクトテンプレート(スキーマ)は、アセットの発行に焦点を当てています。 しかし、RGBは「クライアント側の検証」パラダイムを使用しているため、実際には、クライアント側の検証によって保証できるものは何でも追加できます。

制限

UTXOに加えて、プログラマビリティを広げる概念を「コベナンツ」と呼びます。 制限条項の本来の意図は、金額を送金できる宛先を制限することです。 この機能を使用すると、次のような多くの興味深いアプリケーションをプログラムできます。

*非インタラクティブな引き出しのための資金のプール。 同じUTXOに多くの人の資金をプールし、制限を使用して、他の人の助けを借りずに自分の資金を引き出すことができないことを保証することができます。 これは、ブロックスペースの需要が高い場合に、人々が低コストでリスクの高い場所から脱出するのに役立ちます。 *ボールト契約。 資金をどこかに行かせ、自由に使う前にタイムロックを通過し、タイムロック中に金庫の所有者が緊急キーでプロセスを中断し、すぐに資金を別の場所に移動させることができます。 このようなデバイスは、セルフストレージにとって大きな助けになります。

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

しかし、「資産の定義とカストディの差別化」の利点をいくらか犠牲にすることをいとわない限り、RGB資産でそのような機能を試すことができ、この機能をRGBコントラクトのレベルで実装することができます - ただし、それを使用するRGB資産に対してのみ機能します(BTCでは機能しません)が、興味深い空間が開かれることは間違いありません。

既存の制限の調査では、UTXOベースのトランザクションのプログラミング空間が広がり、多くの機能が提供されることが示されています。 しかし、これらの研究は基本的にBTCに基づいており、このようなBTCプロトコルについてはもう少し保守的になります。 RGBでは、制限条項のコア機能(スクリプトレベルでコストがかかるトランザクションを読み取る機能)を大胆に一般化して、より柔軟なプログラマビリティ、つまりコントラクトへのクロスアクセス機能を提供することができます。

クロスアクセス

minimal restriction句は、UTXOが使用されると、そのスクリプトが支出トランザクションの出力を読み取ることができることを意味します。 しかし、完全に一般化された制限は、コストがかかったトランザクションのすべての部分を読み取ることができることを意味します。 これは、トランザクションの他のインプットも読み取ることができることを意味し、他のインプットを同じコントラクトに制限しない場合は、他のコントラクトの状態を読み取ることができることを意味します。

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

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

まとめ

この記事では、読者は推論とファンタジーの過程で頻繁に言及される概念が1つあることに気付くでしょう:「UTXO」。 それはまさに私が意図したことです。 UTXOを理解していないと、RGBのようなプロトコルの設計の出発点、RGBプロトコル設計の利点、そして人々がそれを使用する方法を理解することはできません。 RGBプロトコルの性質は、ワンタイムシールの一種であるUTXOによって大きく左右されます。 これに対応して、BTC研究分野で蓄積されたUTXOの研究は、RGBの研究にも応用できます。

これは、BTCを理解していない人がRGBを理解するのに苦労する理由も説明しています。 そして、BTCが好きな人は、RGBがすでに作ったデザインに気づくでしょう。