2023年下半期には、さまざまなBTCデリバティブプロトコルのエコシステムが急速に発展するでしょう。 OrdinalsプロトコルやBRC20の復活に加えて、AtomicalsやTaproot Assetsなどのプロトコルも市場から広く注目を集めています。 本記事では、BTCエコシステムにおいて非常に重要な資産発行プロトコルであるRGBプロトコルについて、Beosinが詳しく解説します。 ### **I. RGBプロトコルの開発**RGBプロトコルの役割は、ユーザーがオフチェーンでプライバシー保護トランザクションを実行できるようにするゼロ知識証明ベースのステートチャネルプロトコルであるライトニングネットワーク上のビットコインにスマートコントラクト機能を追加することです。 **RGBはトークンプロトコルではありませんが、スケーラブルでプログラム可能な機密性の高い複数の資産を発行・管理する能力があり、金融以外の多くの業界で重要な役割を果たす可能性があります。 そのプロトコルの開発は、最初の構想から、ビットコインとライトニングネットワークにスマートコントラクト機能をもたらす現在のRGB v0.10バージョンまで、いくつかの重要な段階を経てきました。1. 2016年、Giacomo Zuccoは、Peter Toddの概念に基づいてRGBプロトコルの最初のアイデアを提案しました。2. 2017年、BHB Networkは、Poseidon GroupがサポートするRGBプロトコルのオリジナルバージョンを発表しました。3. 2019年、マキシム・オルロフスキーとジャコモ・ズッコは、RGBを実用化するためにLNP/BP規格協会を設立し、マキシム・オルロフスキー博士はRGBプロトコルの再設計を開始しました。4. 2021年、同協会はRGBプロトコルのチューリング完全仮想マシン(AluVM)を展示し、ライトニングネットワーク上でも動作を開始しました。5. 2022年、ビットコインとライトニングネットワーク用のRGBスマートコントラクトを作成するための新しい言語であるContractumが立ち上げられ、その新しいWebサイトが開設されました。6. 2023年4月、RGB v0.10がリリースされ、ビットコインとライトニングネットワークにスマートコントラクトの完全なサポートをもたらし、RGBプロトコルの開発の最も重要な段階を示しました。### **II. RGBプロトコル設計ロジック**RGBプロトコルの核となる考え方は、コンセンサスとオフチェーンデータストレージを中心に構築されています。まず第一に、分散システムの最も重要な価値はコンセンサスの維持であり、ビットコンセンサスレイヤーを使用すると、台帳イベントへの短い暗号化コミットメントを維持するだけで済み、特定のデータの存在を証明するが、実際のデータの内容を明らかにしない技術であり、通常はハッシュ関数を介して実装され、これらの提出物をチェーンに保存するだけで、データの真正性と整合性が保証され、オンチェーンデータの負担が軽減されます。RGBによる台帳データはオフチェーンに保存されるため、すべてのコントラクトデータと状態遷移はブロックチェーン上ではなくオフチェーンのままです。 使い捨てのシールと状態遷移を使用してスマートコントラクトの状態を追跡および検証し、すべてのデータをオンチェーンに保存することなく、スマートコントラクトの状態とトランザクションを効率的に処理および検証します。 RGBのベースレイヤーは、ナカモトPoWコンセンサスとトランザクション台帳を含むビットコインブロックチェーンです。 オンチェーンでデータを保存する必要はありませんが、既存のインフラストラクチャに従い、これらのコミットメントのストレージとしてビットコイントランザクションを利用する必要があります。#### **2.1 クライアント認証**クライアント側の検証モードのRGBスマートコントラクトでは、ビットコインブロックチェーンやライトニングネットワークチャネルの状態など、すべてのデータがビットコイントランザクションの外部に残り、システムがライトニングネットワーク上で動作することを可能にし、高レベルのプロトコルスケーラビリティとプライバシーの基盤を提供します。#### **2.2 RGBスマートコントラクト**RGBスマートコントラクトの基本構造は、Genesis、State、Transitionsで構成されており、それぞれに異なる機能と役割があります。**創世記(创世)**ジェネシスはスマートコントラクトの初期化宣言であり、コントラクトの基本的なプロパティとルールを定義します。 これには、契約の種類、その目的、および初期設定が含まれます。 コードでは、ジェネシス部分で、最初の ID 情報を指定できる認証コントラクトなどのコントラクトの開始点を定義します。**State(状态)**状態は、任意の時点での契約の現在の状態を表し、すべての変数値と資産情報を含む契約データのリアルタイムのスナップショットです。**トランジション(转换)**遷移は、ある状態から別の状態への遷移を定義するルールです。 これらのルールは、コントラクト ロジックに基づいて状態がどのように変化するかを決定します。 op Vocation と op Transfer は、ある ID 状態から別の ID 状態への転送方法、またはトークン間での転送方法を定義する変換の例です。これら 3 つのコンポーネントは、さまざまな操作とプロトコルを定義して実行する方法を提供します。 Genesisは基礎となるルールとパラメータを設定し、Stateはコントラクトの現在の情報を維持し、Transitionsはステート間の変更のロジックを規定し、これらが一緒になってRGBスマートコントラクトのコアアーキテクチャを形成します。#### **2.3 一次性密封(single-use-seals)**ユーザーのプライバシーを保護しながら、資産移転を安全かつ効率的に管理するため。 RGBプロトコルは「シングルユースシール」アプローチを使用しており、資産(トークンなど)をビットコインの特定のトランザクション出力に結び付けることができるため、資産の転送ごとに古いシールを「開く」ことと新しいシールを「作成」する必要があります。 **1 回限りのカプセル化は、資産の所有権または契約ステータスを表すために使用されます。 状態の転送またはトランザクションが発生するたびに、関連するカプセル化が閉じられ、新しいカプセルが作成されるため、各シールは一度しか使用できないため、資産の再利用や二重支払いを防ぎ、トランザクションのセキュリティを確保し、資産の転送が改ざんできないようにします。同時に、これらの操作はすべてブロックチェーンに保存されるのではなく、クライアント側で実行されるため、ユーザーのプライバシー保護が大幅に強化され、ブロックチェーンスペースの占有が削減され、ネットワーク全体の効率とスケーラビリティが向上します。使い捨てシールの論理的な手順:1. 各 RGB コントラクトの開始はジェネシス操作であり、初期状態と関連する 1 回限りのカプセル化が定義され、コントラクトで定義されたアセットまたはアクセス許可の初期割り当てを表します。2. コントラクトでは、状態は現在の資産または権限設定を表すために使用されます。 各ステータスは、現在の所有権または権限を表す 1 回限りのカプセル化に関連付けられます。3. アセットや権限を譲渡または変更する必要がある場合、関係する状態の遷移があります。 このプロセスでは、現在の 1 回限りのカプセル化 (古い状態を表す) を閉じ、新しいカプセル化 (新しい状態を表す) を作成します。4. パッケージを閉じるには、その整合性を検証し、再利用を防ぐために使用済みとしてマークする必要があります。 次に、コントラクト ルールに基づいて、新しい状態を表す新しいカプセル化が作成されます。5. 取引が発生すると、契約参加者は、取引の正当性を確保するために、関連する 1 回限りのカプセル化が有効であることを確認する必要があります。 この検証プロセスは自動で行われ、RGBノードと参加ウォレットが協力して行われます。### **3. RGBプロトコルの特徴**RGBの特徴は、RGBスマートコントラクトの革新に反映されており、以下はあなたにとっていくつかの重要なポイントです。**1. スキーマの概念**RGBプロトコルは、オブジェクト指向プログラミングのクラスと同様に、スキーマの概念を使用します。 モードは、RGB資産**の標準を定義するために使用され、ウォレット、取引所、ブラウザ、およびBTCノードがRGB資産を簡単にサポートできるようにします。 このフレームワークでは、具象RGBコントラクトは、スキーマのコンストラクタ(「ジェネシス操作」)によって作成されるパターンのインスタンスです。 このアプローチでは、コントラクト開発者 (パターン開発者) とコントラクト発行者の役割が分離され、コントラクト発行者がプログラミングやセキュリティの知識を持つ必要がなくなります。**2. AluVM 仮想マシン**RGBプロトコルは、イーサリアムのEVMに似たチューリング完全仮想マシンであるAluVM仮想マシンも導入しています。 ほぼすべての種類の計算を実行できますが、操作ステップの数によって制限されます。 AluVMは、イーサリアムのガス消費メカニズムと同様に、計算の複雑さを累積的に測定することで計算を制限します。**3. 契約定義例**コントラクトの定義に関しては、RGB プロトコルは、コントラクトの直接的な部分ではありませんが、複数のコントラクトで共有できる PgpKey などの特定のデータ型を使用します。 ID や失効などのコントラクトの状態とアクションは、コントラクトの状態と可能な状態遷移のコンポーネントとして定義されます。**4. コントラクト インスタンスと状態遷移**コントラクトのインスタンス化は、特定の状況にパターンを適用することによって行われ、例えば、meSatoshiNakamotoは、初期状態を定義してワンタイムシールに割り当てるDecentralizedIdentityパターンを実装しています。 Vocation 操作などによる状態遷移には、ID の更新と新しいワンタイム シールへの割り当てが含まれます。**5. 拡張コントラクト機能**RGBプロトコルは、コントラクトで所有可能な状態として表されるIOU(I owe you)トークンを追加するなど、コントラクトの機能を拡張できます。 さらに、IOYTicker や IOYName など、コントラクトのグローバル プロパティであり、どの当事者も直接所有していないグローバル状態があります。**6. 状態拡張の概念**状態拡張の概念により、公衆は、バーンを宣言するなどして、契約の特定の論理的な部分に参加できます。 状態拡張操作では、ブロックにカプセル化されていないビットコイントランザクションと同様に、オンチェーンコミットメントを行うことなく、誰でも状態拡張を作成できます。**7.合约接口(Contract Interface)**標準化された通信: コントラクト インターフェイスは、RGB ノードと通信するための標準的な方法を提供し、意味的に意味のある状態を返し、操作を作成する必要があります。イーサリアムのERC標準に類似:これらのインターフェースはイーサリアムのERC標準に似ており、汎用インターフェースは「RGBxx」と呼ばれ、スタンドアロンのLNP/BP標準として定義されています。**8. ユニバーサル・トークン・インターフェースの作成例**インタフェース定義: グローバル状態(ティッカーや名前など)と所有状態(インフレーションや資産など)、および操作(発行や転送など)を定義します。インターフェイスの実装: インターフェイスが実装されると、特定のモードの状態と操作がインターフェイスにバインドされます。 たとえば、FungibleToken インターフェイスは、DecentralizedIdentity パターンのグローバル状態バインディングと所有状態バインディングを実装します。### **4. RGBプロトコルアプリケーション****金融アプリケーション:**1.会社またはプロジェクトの株式を表すトークンを作成するために使用され、中央集権的に発行されますが、市場の流動性と透明性を向上させるために分散的に取引されます。2.ローンと債券を管理し、スマートコントラクトを通じてローンと債券の発行と返済を自動化します。3. ライトニングネットワーク上で動作するステーブルコインを作成し、これらのステーブルコインを支払い手段として使用します。4.分散型取引所(DEX)を作成します。5. アルゴリズム的に過剰に担保されたステーブルコインなどのAMMソリューションを適用して、市場に流動性と安定性を提供します。非財務アプリケーション:1. 個人がデジタル ID 情報を制御および管理できるようにする自己完結型の ID ソリューションを管理するために使用されます。2. ドメイン名やその他のウェブ識別子を登録・管理できるように、分散型のグローバル名登録システムを構築します。3. 著作権やライセンスなど、デジタルコンテンツの所有権とライセンス権を管理します。4.アートワークをトークン化するために使用され、アーティストやコレクターに新しいデジタル所有権と取引プラットフォームを提供します。5. 分散型の意思決定とガバナンスのためにDAOを管理する。6.ビジネスとプロジェクトの透明性と信頼性を高めるために、証明可能で検証可能な監査ログシステムを作成するために使用されます。### **V. 現行のRGBプロトコルのリスク**#### **1. 不安定**現在のRGBプロトコルは、スマートコントラクトを完全にサポートする最初のバージョンであり、将来的にRGBプロトコルにいくつかの大きな更新や変更がある可能性があり、その結果、現在のコントラクトの開発が後続のバージョンで安全かつ安定して実行されなくなる可能性があります。 RGBのクライアントバリデーターはまだ更新中であり、安定版はまだありません。#### **2. 複雑さ**RGBプロトコルの設計と実装は非常に複雑であり、RGBプロトコルに基づいて開発されたスマートコントラクトには、RGBプロトコルの多くの機能を考慮する必要があります。 例えば、RGBプロトコルに基づいて発行されたトークンが失敗したり、RGBノードによって確認されなかったりした場合、これらのトークンはどのUTXOにも属さず、バーンされるのと同等であり、開発者やプロジェクト関係者は、そのような状況がプロジェクトのトークンエコノミーに与える影響を慎重に検討する必要があります。### **まとめ**RGBプロトコルはまだ非常に初期段階にあります。 RGBプロトコルは、独自のスキーマ定義、AluVM仮想マシン、柔軟なコントラクト状態管理およびスケーリングメカニズムを通じて、BTCスマートコントラクトの分野での革新を実証し、ビットコインネットワークとライトニングネットワーク上の複数の資産の発行と転送をサポートしています。 しかし、現状ではRGBプロトコルはライトニングネットワークと完全に互換性がなく、スマートコントラクトの開発と運用は安全ではないため、ユーザーはRGBプロトコルを使用する際のリスクを認識する必要があります。 **
RGBプロトコルの分析:設計原理、技術的特性、およびセキュリティ上の課題
2023年下半期には、さまざまなBTCデリバティブプロトコルのエコシステムが急速に発展するでしょう。 OrdinalsプロトコルやBRC20の復活に加えて、AtomicalsやTaproot Assetsなどのプロトコルも市場から広く注目を集めています。 本記事では、BTCエコシステムにおいて非常に重要な資産発行プロトコルであるRGBプロトコルについて、Beosinが詳しく解説します。
I. RGBプロトコルの開発
RGBプロトコルの役割は、ユーザーがオフチェーンでプライバシー保護トランザクションを実行できるようにするゼロ知識証明ベースのステートチャネルプロトコルであるライトニングネットワーク上のビットコインにスマートコントラクト機能を追加することです。 **
RGBはトークンプロトコルではありませんが、スケーラブルでプログラム可能な機密性の高い複数の資産を発行・管理する能力があり、金融以外の多くの業界で重要な役割を果たす可能性があります。 そのプロトコルの開発は、最初の構想から、ビットコインとライトニングネットワークにスマートコントラクト機能をもたらす現在のRGB v0.10バージョンまで、いくつかの重要な段階を経てきました。
2016年、Giacomo Zuccoは、Peter Toddの概念に基づいてRGBプロトコルの最初のアイデアを提案しました。
2017年、BHB Networkは、Poseidon GroupがサポートするRGBプロトコルのオリジナルバージョンを発表しました。
2019年、マキシム・オルロフスキーとジャコモ・ズッコは、RGBを実用化するためにLNP/BP規格協会を設立し、マキシム・オルロフスキー博士はRGBプロトコルの再設計を開始しました。
2021年、同協会はRGBプロトコルのチューリング完全仮想マシン(AluVM)を展示し、ライトニングネットワーク上でも動作を開始しました。
2022年、ビットコインとライトニングネットワーク用のRGBスマートコントラクトを作成するための新しい言語であるContractumが立ち上げられ、その新しいWebサイトが開設されました。
2023年4月、RGB v0.10がリリースされ、ビットコインとライトニングネットワークにスマートコントラクトの完全なサポートをもたらし、RGBプロトコルの開発の最も重要な段階を示しました。
II. RGBプロトコル設計ロジック
RGBプロトコルの核となる考え方は、コンセンサスとオフチェーンデータストレージを中心に構築されています。
まず第一に、分散システムの最も重要な価値はコンセンサスの維持であり、ビットコンセンサスレイヤーを使用すると、台帳イベントへの短い暗号化コミットメントを維持するだけで済み、特定のデータの存在を証明するが、実際のデータの内容を明らかにしない技術であり、通常はハッシュ関数を介して実装され、これらの提出物をチェーンに保存するだけで、データの真正性と整合性が保証され、オンチェーンデータの負担が軽減されます。
RGBによる台帳データはオフチェーンに保存されるため、すべてのコントラクトデータと状態遷移はブロックチェーン上ではなくオフチェーンのままです。 使い捨てのシールと状態遷移を使用してスマートコントラクトの状態を追跡および検証し、すべてのデータをオンチェーンに保存することなく、スマートコントラクトの状態とトランザクションを効率的に処理および検証します。
RGBのベースレイヤーは、ナカモトPoWコンセンサスとトランザクション台帳を含むビットコインブロックチェーンです。 オンチェーンでデータを保存する必要はありませんが、既存のインフラストラクチャに従い、これらのコミットメントのストレージとしてビットコイントランザクションを利用する必要があります。
2.1 クライアント認証
クライアント側の検証モードのRGBスマートコントラクトでは、ビットコインブロックチェーンやライトニングネットワークチャネルの状態など、すべてのデータがビットコイントランザクションの外部に残り、システムがライトニングネットワーク上で動作することを可能にし、高レベルのプロトコルスケーラビリティとプライバシーの基盤を提供します。
2.2 RGBスマートコントラクト
RGBスマートコントラクトの基本構造は、Genesis、State、Transitionsで構成されており、それぞれに異なる機能と役割があります。
創世記(创世)
ジェネシスはスマートコントラクトの初期化宣言であり、コントラクトの基本的なプロパティとルールを定義します。 これには、契約の種類、その目的、および初期設定が含まれます。 コードでは、ジェネシス部分で、最初の ID 情報を指定できる認証コントラクトなどのコントラクトの開始点を定義します。
State(状态)
状態は、任意の時点での契約の現在の状態を表し、すべての変数値と資産情報を含む契約データのリアルタイムのスナップショットです。
トランジション(转换)
遷移は、ある状態から別の状態への遷移を定義するルールです。 これらのルールは、コントラクト ロジックに基づいて状態がどのように変化するかを決定します。 op Vocation と op Transfer は、ある ID 状態から別の ID 状態への転送方法、またはトークン間での転送方法を定義する変換の例です。
これら 3 つのコンポーネントは、さまざまな操作とプロトコルを定義して実行する方法を提供します。 Genesisは基礎となるルールとパラメータを設定し、Stateはコントラクトの現在の情報を維持し、Transitionsはステート間の変更のロジックを規定し、これらが一緒になってRGBスマートコントラクトのコアアーキテクチャを形成します。
2.3 一次性密封(single-use-seals)
ユーザーのプライバシーを保護しながら、資産移転を安全かつ効率的に管理するため。 RGBプロトコルは「シングルユースシール」アプローチを使用しており、資産(トークンなど)をビットコインの特定のトランザクション出力に結び付けることができるため、資産の転送ごとに古いシールを「開く」ことと新しいシールを「作成」する必要があります。 **1 回限りのカプセル化は、資産の所有権または契約ステータスを表すために使用されます。 状態の転送またはトランザクションが発生するたびに、関連するカプセル化が閉じられ、新しいカプセルが作成されるため、各シールは一度しか使用できないため、資産の再利用や二重支払いを防ぎ、トランザクションのセキュリティを確保し、資産の転送が改ざんできないようにします。
同時に、これらの操作はすべてブロックチェーンに保存されるのではなく、クライアント側で実行されるため、ユーザーのプライバシー保護が大幅に強化され、ブロックチェーンスペースの占有が削減され、ネットワーク全体の効率とスケーラビリティが向上します。
使い捨てシールの論理的な手順:
各 RGB コントラクトの開始はジェネシス操作であり、初期状態と関連する 1 回限りのカプセル化が定義され、コントラクトで定義されたアセットまたはアクセス許可の初期割り当てを表します。
コントラクトでは、状態は現在の資産または権限設定を表すために使用されます。 各ステータスは、現在の所有権または権限を表す 1 回限りのカプセル化に関連付けられます。
アセットや権限を譲渡または変更する必要がある場合、関係する状態の遷移があります。 このプロセスでは、現在の 1 回限りのカプセル化 (古い状態を表す) を閉じ、新しいカプセル化 (新しい状態を表す) を作成します。
パッケージを閉じるには、その整合性を検証し、再利用を防ぐために使用済みとしてマークする必要があります。 次に、コントラクト ルールに基づいて、新しい状態を表す新しいカプセル化が作成されます。
取引が発生すると、契約参加者は、取引の正当性を確保するために、関連する 1 回限りのカプセル化が有効であることを確認する必要があります。 この検証プロセスは自動で行われ、RGBノードと参加ウォレットが協力して行われます。
3. RGBプロトコルの特徴
RGBの特徴は、RGBスマートコントラクトの革新に反映されており、以下はあなたにとっていくつかの重要なポイントです。
1. スキーマの概念
RGBプロトコルは、オブジェクト指向プログラミングのクラスと同様に、スキーマの概念を使用します。 モードは、RGB資産**の標準を定義するために使用され、ウォレット、取引所、ブラウザ、およびBTCノードがRGB資産を簡単にサポートできるようにします。 このフレームワークでは、具象RGBコントラクトは、スキーマのコンストラクタ(「ジェネシス操作」)によって作成されるパターンのインスタンスです。 このアプローチでは、コントラクト開発者 (パターン開発者) とコントラクト発行者の役割が分離され、コントラクト発行者がプログラミングやセキュリティの知識を持つ必要がなくなります。
2. AluVM 仮想マシン
RGBプロトコルは、イーサリアムのEVMに似たチューリング完全仮想マシンであるAluVM仮想マシンも導入しています。 ほぼすべての種類の計算を実行できますが、操作ステップの数によって制限されます。 AluVMは、イーサリアムのガス消費メカニズムと同様に、計算の複雑さを累積的に測定することで計算を制限します。
3. 契約定義例
コントラクトの定義に関しては、RGB プロトコルは、コントラクトの直接的な部分ではありませんが、複数のコントラクトで共有できる PgpKey などの特定のデータ型を使用します。 ID や失効などのコントラクトの状態とアクションは、コントラクトの状態と可能な状態遷移のコンポーネントとして定義されます。
4. コントラクト インスタンスと状態遷移
コントラクトのインスタンス化は、特定の状況にパターンを適用することによって行われ、例えば、meSatoshiNakamotoは、初期状態を定義してワンタイムシールに割り当てるDecentralizedIdentityパターンを実装しています。 Vocation 操作などによる状態遷移には、ID の更新と新しいワンタイム シールへの割り当てが含まれます。
5. 拡張コントラクト機能
RGBプロトコルは、コントラクトで所有可能な状態として表されるIOU(I owe you)トークンを追加するなど、コントラクトの機能を拡張できます。 さらに、IOYTicker や IOYName など、コントラクトのグローバル プロパティであり、どの当事者も直接所有していないグローバル状態があります。
6. 状態拡張の概念
状態拡張の概念により、公衆は、バーンを宣言するなどして、契約の特定の論理的な部分に参加できます。 状態拡張操作では、ブロックにカプセル化されていないビットコイントランザクションと同様に、オンチェーンコミットメントを行うことなく、誰でも状態拡張を作成できます。
7.合约接口(Contract Interface)
標準化された通信: コントラクト インターフェイスは、RGB ノードと通信するための標準的な方法を提供し、意味的に意味のある状態を返し、操作を作成する必要があります。
イーサリアムのERC標準に類似:これらのインターフェースはイーサリアムのERC標準に似ており、汎用インターフェースは「RGBxx」と呼ばれ、スタンドアロンのLNP/BP標準として定義されています。
8. ユニバーサル・トークン・インターフェースの作成例
インタフェース定義: グローバル状態(ティッカーや名前など)と所有状態(インフレーションや資産など)、および操作(発行や転送など)を定義します。
インターフェイスの実装: インターフェイスが実装されると、特定のモードの状態と操作がインターフェイスにバインドされます。 たとえば、FungibleToken インターフェイスは、DecentralizedIdentity パターンのグローバル状態バインディングと所有状態バインディングを実装します。
4. RGBプロトコルアプリケーション
金融アプリケーション:
1.会社またはプロジェクトの株式を表すトークンを作成するために使用され、中央集権的に発行されますが、市場の流動性と透明性を向上させるために分散的に取引されます。
2.ローンと債券を管理し、スマートコントラクトを通じてローンと債券の発行と返済を自動化します。
4.分散型取引所(DEX)を作成します。
非財務アプリケーション:
個人がデジタル ID 情報を制御および管理できるようにする自己完結型の ID ソリューションを管理するために使用されます。
ドメイン名やその他のウェブ識別子を登録・管理できるように、分散型のグローバル名登録システムを構築します。
著作権やライセンスなど、デジタルコンテンツの所有権とライセンス権を管理します。
4.アートワークをトークン化するために使用され、アーティストやコレクターに新しいデジタル所有権と取引プラットフォームを提供します。
6.ビジネスとプロジェクトの透明性と信頼性を高めるために、証明可能で検証可能な監査ログシステムを作成するために使用されます。
V. 現行のRGBプロトコルのリスク
1. 不安定
現在のRGBプロトコルは、スマートコントラクトを完全にサポートする最初のバージョンであり、将来的にRGBプロトコルにいくつかの大きな更新や変更がある可能性があり、その結果、現在のコントラクトの開発が後続のバージョンで安全かつ安定して実行されなくなる可能性があります。 RGBのクライアントバリデーターはまだ更新中であり、安定版はまだありません。
2. 複雑さ
RGBプロトコルの設計と実装は非常に複雑であり、RGBプロトコルに基づいて開発されたスマートコントラクトには、RGBプロトコルの多くの機能を考慮する必要があります。 例えば、RGBプロトコルに基づいて発行されたトークンが失敗したり、RGBノードによって確認されなかったりした場合、これらのトークンはどのUTXOにも属さず、バーンされるのと同等であり、開発者やプロジェクト関係者は、そのような状況がプロジェクトのトークンエコノミーに与える影響を慎重に検討する必要があります。
まとめ
RGBプロトコルはまだ非常に初期段階にあります。 RGBプロトコルは、独自のスキーマ定義、AluVM仮想マシン、柔軟なコントラクト状態管理およびスケーリングメカニズムを通じて、BTCスマートコントラクトの分野での革新を実証し、ビットコインネットワークとライトニングネットワーク上の複数の資産の発行と転送をサポートしています。 しかし、現状ではRGBプロトコルはライトニングネットワークと完全に互換性がなく、スマートコントラクトの開発と運用は安全ではないため、ユーザーはRGBプロトコルを使用する際のリスクを認識する必要があります。 **