RGB はビットコインとライトニング ネットワークのスケーラビリティとプライバシー機能を強化します

TL; DR

• RGB は、ビットコインおよびライトニング ネットワークのクライアント側検証パラダイム上のレイヤー 2/3 ソリューションとして動作し、ビットコイン トランザクションの外部にあるすべてのスマート コントラクト データを格納します。この設計により、ライトニング ネットワーク上でのシステムの動作が保証され、LN プロトコルを変更する必要がなくなります。
  
• RGB スマート コントラクトは、拡張性と機密性を考慮して設計されています。このシステムは、プライベートおよび相互所有権をサポートし、懸念事項を抽象化して分離し、新しいトークンを導入する必要のないポストブロックチェーン、チューリング完全な形のトラストレス分散コンピューティングを表します。
  
• RGB コントラクトは「シャード」と呼ばれる個別のセグメントに編成され、それぞれに独自の履歴とデータが含まれるため、スケーラビリティが向上し、異なるコントラクトの履歴の混合が防止されます。これらは、Lightning Network 上の Bifrost プロトコルを介して対話し、Lightning Network 上で動作する DEX と同様に、複数の当事者間で調整された変更を可能にします。
  
• RGBは使い捨てシールを採用 defiセキュリティのためにビットコイン UTXO を使用しません。スマート コントラクトの状態履歴を所有する当事者は、ビットコインのスクリプトを利用してその一意性を検証できます。 defi所有権とアクセス権。
  
• RGB では、状態の所有権と検証は別個のエンティティです。所有権は、非チューリング完全システムであるビットコイン スクリプトによって管理されます。一方、検証ルールは、Turing Complete Simplicity/Contractum/Rust スクリプトを使用して RGB スキーマによって指示されます。
  
• 各 RGB スマート コントラクトは、使い捨てシールを使用して固有の状態に関連付けられます。シールと状態は、契約の作成者によって設定された特定のルールと検証に従い、「スキーマ」によって管理されます。このスキーマは、クライアント側でコントラクト データをチェックするためのルール セットのように機能し、高レベルのプロトコルのスケーラビリティとプライバシーを実現します。
  
• RGB の設計は、既存のビットコインおよびライトニング ネットワーク テクノロジーとの相互運用性が高く、これらのプラットフォームとのシームレスな統合や将来のアップグレードを容易にします。
  
• 多くのブロックチェーン プラットフォームの命令型プログラミング スタイルとは異なり、RGB は宣言型スタイルを採用しています。このアプローチでは、望ましい結果を達成するための具体的な手順を詳しく説明するのではなく、望ましい結果の概要を説明することに重点を置いています。
  
• RGB は、確定的ポータブル コンピューティング タスク用の AluVM、部分的に複製された無限ステート マシン コンピューティング用の PRISM、zk-proofs を使用したエスクローベースのトラストレス ストレージ用の Storm など、さまざまな高度なテクノロジーを利用しています。これらのテクノロジーは、RGB の堅牢性、機密性、拡張性に貢献します。
  
• RGB (v0.10) では、ユーザー エクスペリエンスと統合プロセスに注目すべき機能強化が導入され、操作が合理化され、依存関係が最小限に抑えられます。更新されたバージョンは、より統合されたライブラリ API とコマンドライン ツールを備えており、よりアクセスしやすく、ユーザーフレンドリーになっています。

簡単な説明

RGB は、プライバシーが強化され、ライトニング ネットワークとの互換性を備えたビットコイン ネットワーク上でトークンを発行するために設計されたプロトコルです。これは、ビットコイントランザクションのメタデータがトークン転送を示す OmniLayer プロトコルで使用されるような「カラーコイン」の概念に基づいて構築されています。たとえば、OmniLayer 上の USDT トランザクションは、USDT トークンの動きの詳細を示す追加データで強化されたビットコイン トランザクションとして機能します。ただし、これらの方法は、OP_RETURN 出力のデータ サイズの制約、集中的なブロックチェーン スキャン、オンチェーンの可視性に起因するプライバシーの制限などの制限に直面しています。

RGB は、検証プロセスの大部分をビットコイン ブロックチェーンから遠ざけることでこれらの問題に対処します。クライアント側の検証を採用し、使い捨てシールを使用してトークンをビットコインの UTXO に接続すると同時に、ユーザーのプライバシーを保護します。

トークンは、ビットコイン トランザクション内の RGB 支払い情報を含むメッセージにコミットすることによって転送され、ビットコイン トランザクション グラフに痕跡を残さずにトークンを 1 つの UTXO から別の UTXO に移動できます。これにより、プライベート オフチェーン チャネルを介して RGB 固有のデータが渡され、RGB トランザクションがトークンを慎重に「テレポート」するため、プライバシーが大幅に強化されます。

さらに、所有権を確保しインフレを防ぐために、受信者は受信したトークンのトランザクション履歴全体を検証する必要があります。 RGB により、ハード フォークを必要とせずに将来のアップグレードが可能になり、マイナーが資産の流れを追跡できなくなるため、検閲に対する耐性が高まります。従来のブロックチェーン構造とは異なり、RGB はブロックやチェーンを必要とせずに動作し、非ブロック分散プロトコルとして位置付けられ、高い機密性、セキュリティ、およびスケーラビリティを約束します。

はじめにとビジョン

一発ギャグ： クライアントによって検証された状態と、ビットコインおよびライトニング ネットワークのレイヤー 2/3 で動作するスマート コントラクト システム。

詳細：

RGB は、ビットコインおよびライトニング ネットワーク用のスケーラブルで機密性の高いスマート コントラクト システムです。 RGB スマート コントラクトは以下で動作します クライアント側の検証 パラダイム、住宅 すべてのスマートコントラクトデータは外部にあります ビットコイン トランザクション、つまりビットコイン ブロックチェーンまたは Lightning チャネルの状態。これにより、LN プロトコルを変更することなくシステムが Lightning Network 上で動作できるようになり、高レベルのプロトコルのスケーラビリティとプライバシーの基盤も提供されます。

スマート コントラクトは、私的所有権と相互所有権、抽象化、関心の分離の原則を具体化しています。これらは、トークンの導入を必要としない、トラストレス分散コンピューティングの「ポストブロックチェーン」、チューリング完全な形を表します。

RGB コントラクトは、「シャード」と呼ばれる個別のセグメントで動作します。各シャードには独自の履歴とデータがあり、異なるコントラクトの履歴が混在することはありません。この方法により、スケーラビリティが向上します。 「シャード」という用語は、RGB がイーサリアムのシャード概念で意図されたものと同様の目標を達成することを示すために使用されます。

RGB コントラクトは独立して機能しますが、Lightning Network 上の Bifrost プロトコルを通じて対話できます。これにより、複数の関係者間で調整された変更が可能になります。たとえば、DEX が Lightning Network 経由で機能できるようになります。

テクノロジーとアーキテクチャ

RGB 操作と使い捨てシールの概要

図 1. RGB の動作の概要。
出典: LNP/BP Association Github。

セキュリティ メカニズムとして、RGB は 使い捨てシール defiこれは、スマート コントラクトの状態履歴を持つ当事者がその一意性を検証できる機能を提供します。本質的に、RGB はセキュリティ モデルにビットコイン スクリプトを利用しており、 defiNES 所有権 および アクセス権.

図 2. RGB の高レベルの動作原理。
出典: Waterdrip Capital 著「Driving Mass Adoption of Crypto: How the RGB Protocol is Illumination the Future of Bitcoin」。

各 RGB スマート コントラクトは、 defiによってネッド ジェネシス状態によって作られました。 スマートコントラクト発行者 (または、簡単に言えば、発行者) と有向非巡回グラフ (DAG) 状態遷移 クライアントが検証したデータとして維持されます。

図 3. 取引、封印と証人。
出典: LNP/BP Association Github。

これを次のように要約できます。各トランザクションには UTXO があり、この UTXO の所有権により、所有者に状態を所有する権利が付与されます。所有権により、誰がブロックチェーンの状態を変更して UTXO を「使用」できるかが決まります。国家を保持する個人は当事者と呼ばれます 所有状態.

当事者は、新しい状態遷移を生成し、以前の状態を含む出力を利用してトランザクションでそれを確認することにより、スマート コントラクト状態の関連セクションを変更する権限を保持します。

そのプロセスが意味するのは、 状態遷移に対する封印の終了、支出トランザクションと、状態遷移に関する対応するトランザクション外データで構成されるペアは、 目撃者 (上の画像に示されています)。

所有権とアクセス: コアプロパティ

図 4. 所有権とアクセス。
出典: LNP/BP Association Github。

状態の所有権と検証は別の概念です。検証ルールは、状態がどのように変化するかを指定しますが、誰が変更を実行できるかは特定しません。 

一方、所有権はビットコインブロックチェーンレベルでビットコインスクリプトによって制御されますが、これはチューリング完全ではありません。対照的に、検証ルールは、Simplicity/Contractum Script、つまり Turing Complete を利用した RGB スキーマによって管理されます。 

RGBスキーマ

RGB スマート コントラクトでは、使い捨てシールによって各コントラクトに固有の状態が割り当てられます。これらの印鑑には、州とともに、契約の作成者によって最初に設定された特定のルールと検証が設けられています。この設定は「スキーマ」によって管理され、クライアント側で契約データを検証するための一連のルールとして機能します。スキーマには、コントラクトのロジックに不可欠な複雑なスクリプトを含めることができます。

図 5. RGB スキーマ。
出典: LNP/BP Association Github。

クライアント側の検証と設計原則

図 6. RGB クライアント側検証。
出典: LNP/BP Association Github。

1. 強い所有権: RGB では、スマート コントラクトには明らかに defiネッドのオーナー。指定された所有者のみが契約の状態を変更する権限を持っています。これらの契約は、公開 (すべての人がアクセス可能) または所有 (所有者に制限) に分類される個別の権利または操作の概要を示します。
2. 守秘義務： 契約内の情報は機密に保たれ、参加者、特に州の所有者のみが知ります。参加者には特定のデータを公開するオプションがありますが、デフォルトではすべての情報が非公開になります。この機密性により、外部分析ツールによるデータへのアクセスが防止され、機密情報が公開台帳に保存されることがなくなります。
3. 関心事の分離： RGB は、それぞれに特定のタスクが割り当てられた個別のレイヤーを備えたモジュラー設計を特徴としています。これらの層は独立して動作するため、下位層が上位層の構造を認識する必要がなくなります。この設計により、システムの組織化と効率が向上します。
4. 拡張性： このシステムは簡単に拡張可能で、コア プロトコルを変更したり、RGB ライブラリ全体を再コンパイルしたりすることなく、高度なスマート コントラクトの作成と統合が可能になります。
5. 決定論: RGB の検証ロジックは決定論的であり、同じ入力と基盤となるブロックチェーンまたはライトニング ネットワーク チャネルの一般的な状態から一貫して同じ結果が得られます。この一貫性は、次の 2 つの主要なコンポーネントによって実現されます。 Rust で書かれたコア検証ロジックは、RGB を実行しているすべてのシステムで同じです。 b.コントラクト固有の検証ロジックは、プラットフォームに関係なく一貫した命令セットを提供する仮想マシンである AluVM 上で実行されます。
6. LNP/BP の相互運用性: RGB は、既存のビットコインおよびライトニング ネットワーク テクノロジーとシームレスに連携するように設計されています。また、これらのテクノロジーへの将来のアップグレードにも対応できるように構築されています。
   

RGB のアプローチと Pure Blockchain/L1 アプローチ

純粋なブロックチェーン/L1 アプローチは間違っている、と RGB チームは述べています。

図 7. ブロックチェーン/L1 アプローチに関する RGB コメント。
出典: LNP/BP Association Github。

RGB のアプローチ: 宣言型プログラミングと命令型プログラミング:

• イーサリアムを含むほとんどのブロックチェーン プラットフォームは、命令型スタイルで記述されたスマート コントラクトを利用します。このアプローチでは、コントラクトは、正確で詳細なレシピに似た、タスクの段階的な実行を明示的に指示するプログラムとして機能します。
• これらの命令型プログラムは多くの場合、非常に制限的であり、基盤となるブロックチェーン プラットフォームの機能によって制限されます。これらはチューリング完全と呼ばれることもありますが、重大な制限があります。

RGB スマート コントラクトの宣言的な性質:

• 一方、RGB は命令型プログラミングを使用しません。代わりに、特別な形式の関数型プログラミングを採用しており、スマート コントラクトは defi宣言的にネッドします。
• 宣言型プログラミングでは、何かを行う方法を詳しく説明するのではなく、結果がどうなるかを説明します。段階的な調理手順を提供するのではなく、食事がどのようなものであるかを概説するようなものです。
• RGB の「スキーマ」は宣言型です defiスマートコントラクトの成立。契約のルールと条件を指定しますが、それらを達成するための操作の正確な順序は指定しません。

プログラミングにおけるパラダイムシフト:

• スマート コントラクト プログラミングにおけるイーサリアムの命令型スタイルから RGB の宣言型スタイルへの移行は、一般的なソフトウェア開発における従来の命令型プログラミングから関数型または宣言型プログラミングへの移行に似ています。
• この変化には、異なる考え方が必要です。つまり、「方法」 (結果を達成するための具体的な手順) ではなく、「何を」 (望ましい結果) に焦点を当てる必要があります。

単純

当初の計画では、Simplicity を RGB に組み込むことが含まれており、初日から互換性を確保することに努力が払われました。しかし、Simplicity 開発の遅々として進まないことと、リリース スケジュールをめぐる不確実性を考慮すると、Simplicity に依存するのは非現実的であることが明らかになりました。現在準備中の RGB リリースでは、Simplicity が含まれるかどうかについて疑問が生じました。

Simplicity の信頼できるスケジュールが存在しないことを認識し、代替案 (WASM、EVM (冗談として)、IELE など) の検討を開始しました。最終的に、RGB 用に独自の仮想マシンを開発することが、当初の Simplicity への依存に代わる唯一の実行可能な選択肢であることが明らかになりました。

そこで私たちは作成することにしました AluVM – クライアント側で検証されたスマート コントラクト (RGB)、ライトニング ネットワーク、決定論的な分散コンピューティングおよびエッジ コンピューティングのための、純粋に機能的で移植性の高い Rust ベースの仮想マシン。

プリズム

PRISM は、「部分的に複製された無限ステート マシン」コンピューティングの略です。

RGBテクノロジー defiスキーマと呼ばれる基本レベルでスマート コントラクトを進化させるルールはありますが、単一の包括的なアルゴリズムでコントラクトの今後のすべてのアクションを制限するわけではありません。代わりに、ネットワーク上の各ノードが個別の操作を実行し、これらの操作がスキーマのルールに準拠している限り、コントラクトの状態とコントラクト自体の両方が有効のままです。 

さらに、このアプローチは、事前に決定されたアルゴリズムによる契約の歴史的進化を制約しません。したがって、各変更が特定の検証ルールを満たしている限り、コントラクトはさまざまな動作を示すことができます。この方法は、グローバル アルゴリズムではなくローカル ルールに焦点を当てています。

対照的に、イーサリアムはグローバル アルゴリズムを使用しており、あらゆる操作がスマート コントラクトの状態全体に影響を与えます。 RGB では、コントラクトの状態の一部のみを操作し、ルールをローカルに適用します。これにより、契約の進化の可能性がさらに広がります。

以下に、状態チャネルとクライアント側検証の違いの概要を示します。 

図 8. 分散システムの分離。
出典: LNP/BP Association Github。

より具体的な違いは次のとおりです。 

図 9. 状態チャネルとクライアント側検証の比較。
出典: LNP/BP Association Github。

AluVM

AluVM – (アルゴリズム ロジック ユニット VM) は、確定的なポータブル コンピューティング タスク用に設計された純粋な機能の RISC 仮想マシンです。

AluVM は、ランダム メモリ アクセスを禁止するレジスタベースのシステムを採用することで特徴を備えています。この設計により、スマート コントラクト、リモート コード実行、分散コンピューティングおよびエッジ コンピューティングなどのアプリケーションに対する AluVM の適合性が強化されます。 AluVM の中核的な強みは、その決定性、堅牢性、および正式なコード分析の能力にあります。

主な特徴： 例外のない、移植性、サンドボックス、セキュリティ、拡張性。

AluVM の命令セット アーキテクチャ (ISA) は適応性があるように設計されており、さまざまなアプリケーションに対して異なるランタイム環境を作成できます。 AluVM 自体は、予測可能性が高く、機能的な、レジスタベースの仮想マシンおよび ISA です。 

AluVM ISA は、ランダム メモリ アクセスを制限しながら、楕円曲線に関連するタスクを含む算術タスクの実行に優れています。独特な点として、VM の環境は AluVM ISA を拡張でき、VM のレジスタへのデータのロードや、特定のアプリケーションに合わせた特殊な命令 (SIMD など) のサポートなどの機能の追加が可能になります。

AluVM は主に、処理速度よりも異なるプラットフォーム間での一貫性と信頼性が重要な分散システムでの使用を目的としています。適切な ISA 拡張機能を備えた AluVM の主な用途には、ブロックチェーン テクノロジー、ネットワーク内のコンセンサスに重要な計算、エッジ コンピューティング、マルチパーティ コンピューティング (決定論的機械学習をカバー)、クライアント側の検証、制限付き Internet2 コンピューティング、および遺伝的アルゴリズムが含まれます。これらのアプリケーションは、さまざまな環境で一貫して安全に実行できる AluVM の機能の恩恵を受けます。

図 10. AluVM の比較。
出典: LNP/BP Association Github。

契約書

Contractum は、Haskell の機能能力と Rust に見られるベアメタルへの近さを融合することで、他のスマート コントラクト プログラミング言語とは一線を画しています。これは、以前はスマート コントラクトがアクセスできなかったニッチな領域を占めています。

図 11. Contractum、Simplicity、およびその他の言語の比較。
情報源： コントラクタム.org

Contractum は、RGB コントラクトの作成に使用されるプログラミング言語です。 Contractum で作成された契約は、クライアント側検証と呼ばれる方法を使用してチェックされます。このアプローチはビットコイン ブロックチェーンにデータを追加しません。これはシャーディング テクノロジーの一種と比較でき、ゼロ知識証明を使用することでさらに改良されます。 

また、クライアント側の検証により、契約の開発がブロックチェーン トランザクションから分離されるため、従来のブロックチェーン分析方法ではこれらのトランザクションを追跡または分析することができなくなります。

図 12. Contractum の特徴。
情報源： コントラクタム.org

Contractum の設計に取り組むには、RGB スマート コントラクトで採用されているテクノロジーをよく理解することが重要です。

図 13. RGB スマート コントラクトで使用されるテクノロジー。
情報源： コントラクタム.org

新しいバージョン RGB v0.10 の最近の更新

RGB の最新版 (バージョン 0.10) では、いくつかの高度な技術的機能強化が実装され、複雑なアプリケーション開発のためのフレームワークの機能が強化されました。これらの更新は主に、各 RGB コントラクトのグローバル ステートの導入、コントラクト インターフェイスの統合、および厳密な型システムの採用に焦点を当てています。

RGB 契約における世界的な状態

Global State 機能は、RGB v0.10 の重要な革新であり、各コントラクトが普遍的にアクセス可能な状態を維持できるようになります。この状態は、RGB 仮想マシンだけでなく、ウォレットやその他のアプリケーションなどの外部クライアントからもアクセスできます。

この Global State のユーティリティは、RGB プラットフォーム上で洗練されたアプリケーション、特に合成資産やアルゴリズム ステーブルコインなどの複雑な状態管理を必要とするアプリケーションを構築する場合に極めて重要です。これにより、従来のスマート コントラクト アーキテクチャの制限を超えて、コントラクトの状態とのより動的な対話が可能になります。

コントラクトインターフェイス

RGB v0.10 では、さまざまなスマート コントラクトの標準化された通信プロトコルとして「コントラクト インターフェイス」が導入されています。これらのインターフェイスは、イーサリアムのコントラクト ABI (アプリケーション バイナリ インターフェイス) や ERC (イーサリアム コメント要求) と同様に機能します。

RGB のアプローチの主な特徴は、これらのインターフェイスの非強制的な標準化と、契約による固有のパッケージ化であり、個別の配布の必要性がなくなりました。これにより、ウォレットやその他のソフトウェアのユーザー インターフェイスを介した、ユーザーと契約の間のセマンティックを意識した対話が容易になります。

これらのインターフェイスは静的ではありません。開発者は、時間の経過とともに追加のインターフェイスで既存のコントラクトを拡張し、不変のコントラクト コアを変更することなく機能を強化できます。

厳密な型システム

RGB v0.10 の新しいエンコード形式は、「厳密なタイプ」システムを利用しています。このシステムは、RGB フレームワーク内のコントラクト状態の効率的な表現とイントロスペクションを目的として設計された、新しい関数型データ型アプローチです。

厳密な型システムにより、コンパイル時にデータ サイズが保証されます。これは、メモリ容量が限られたローエンドのハードウェア ウォレットなど、リソースに制約のあるデバイスでの操作に特に有益です。

さらに、バージョン 0.10 の RGB コンセンサス レイヤー全体は厳密なタイプにコンパイルされ、さまざまなソフトウェア リリース間でのバイナリ互換性の正式な証明の基盤を提供します。この機能により、RGB の使用が簡素化され安全になるだけでなく、アセット発行者や契約開発者がアセットや契約に追加のメタデータを追加できるようになります。このようなメタデータは、RGB エコシステム内の資産または契約の ID と信頼性を検証する際に重要な役割を果たすことができます。

Rustベースのスマートコントラクト

RGB スマート コントラクトを Rust で作成できるようになり、型安全性とパフォーマンスに関する言語の機能を活用できます。

厳密なシステム型統合により、Rust データ型を RGB コントラクト構造に直接コンパイルすることが容易になり、コントラクト コードの効率と信頼性が向上します。

強化された状態イントロスペクション機能

RGB v0.10 のスマート コントラクトは、RGB 仮想マシンによって実行される検証コード内で自身の状態をイントロスペクトできます。

この機能は、ビットコイン トランザクション、離散ログ コントラクト、その他の複雑なデータ構造と相互作用する複雑なコントラクトを作成する場合に特に役立ち、RGB スマート コントラクトの範囲と機能を強化します。

URLベースの請求書フォーマット

このアップデートでは、以前の Bech32m でエンコードされたシステムに代わる新しい請求書形式が導入されています。

これらの新しい URL ベースの請求書は大幅に短くなり、よりユーザーフレンドリーになり、検証が容易になり、事前設定されたソフトウェアによる自動開封が容易になります。

WASM (WebAssembly) のサポート

RGB 標準ライブラリは、Web ページやブラウザ プラグインなど、I/O やファイル システムへのアクセスが不足している環境と互換性を持つようになりました。

これにより、RGB の潜在的な使用例が拡大し、幅広い Web ベースのアプリケーションや拡張機能でシームレスに動作できるようになります。

タップルート記述子とカスタム導出

RGB v0.10 はタップルートベースの OP_RETURN コミットメント (タップレットと呼ばれます) を利用しており、調整された出力を持つトランザクションを認識するためにウォレットの記述子レベルのサポートが必要です。

このバージョンでのカスタム導出インデックスの導入により、非 RGB ウォレットが RGB アセットを含む出力を誤って使用することがなくなり、これらのアセットの整合性が保護されます。

簡略化された依存関係

バージョン 0.10 の RGB コンセンサス レイヤーは依存関係を減らし、特に Grin プロジェクトから派生したカスタムの防弾実装から離れています。

この依存関係の削減により、API の安定性とシステム全体の堅牢性が向上します。

合理化された統合プロセス

このアップデートにより、複数の API 呼び出しや複雑な言語間データ構造エンコーディングの必要性が軽減され、運用ワークフローが簡素化されます。

RGB コントラクト状態が JSON オブジェクトとして表現されるようになり、さまざまなプログラミング言語間で直接シリアル化できるようになりました。

ユーザーエクスペリエンスの向上

新しいバージョンの RGB は、以前はバラバラだったコンポーネントを統合されたライブラリ API とコマンドライン ツールに統合することにより、ユーザー エクスペリエンスを簡素化します。

RGB ノードは引き続きホーム サーバー上で動作できますが、RGB システムと対話するためにその使用は必須ではなくなり、ユーザーとウォレット アプリケーションの参入障壁が軽減されます。

このセクションには、「暗号通貨の大量採用の推進: RGB プロトコルがビットコインの将来をどのように照らすか」というタイトルの記事で最新機能にスポットライトを当てた Waterdrip Capital に対する特別な謝意が含まれています。

RGB 競合他社

図 14. 簡単に言えば、FRGB とイーサリアムの比較。
出典: LNP/BP Association Github

Taproot

以前は Taro として知られていた Taproot Assets は、ビットコイン ネットワーク上でトークンを起動するために設計されたプロトコルです。このプロトコルは、Taproot の UTXO モデルと、Tapscript や Taptweak などの関連ソリューションを活用します。これらのツールは、ビットコイン取引データ内の資産の供給と残高に関する情報を保存するために使用されます。

図 15. Taproot Assets トークンに関する情報を保存するためのスキーム。
出典: Voltage 著「Taproot Assets: ビットコインで資産を発行」

Taproot Assets は Ordinals の概念に類似した方法を採用しており、BRC-20 トークンは列挙された SATOSHI のメタデータに供給情報を格納します。逆に、Taproot Assets は、「スパース マークル ツリー」として知られるものを利用して、この情報をビットコイン トランザクションの Taproot 出力に埋め込みます。基本的に、Taproot Assets はマークル ツリーをビットコイン トランザクションに組み込み、特定のユーザーの残高と全体的なトークン供給量の証明として機能します。このツリーは、完全な資産履歴を保持し、トークン発行者によって管理されるリポジトリである「ユニバース」からのデータを反映します。

図 16. デジタル状態ツリー。
出典: Voltage 著「Taproot Assets: ビットコインで資産を発行」

State Digital Tree – Taproot Assets のアーキテクチャは、バランスプルーフのための 2 つのオプションを提供します。Universe からのオフチェーン データ、または UTXO に埋め込まれたスパース マークル ツリーです。

動作の仕組み

1. トークン作成者は、Taproot Assets プロトコルを使用して P2TR (Pay to Taproot) トランザクションを実行します。 
2. アセットに関する情報は、マークル ツリーの形式で、このトランザクションの UTXO (事実上、ジェネシス ブロック) に保存されます。 
3. トークンを転送するには、Taproot キーの所有者がマークル ツリー内の残高情報を変更し、全体的な資産供給が一定に保たれるようにします。 
4. このような変更は、新しい Taproot トランザクションを通じて導入されます。ただし、トークン転送ごとに個別のオンチェーン トランザクションは必要ありません。ロールアップやライトニング ネットワークと同様に、このプロトコルを使用すると、所有者は送金の「バッチ」を処理し、その後残高の更新された状態を公開できます。

Taproot アセットの利点

• Taproot Assets の主な利点の 1 つは、Lightning Network との完全な互換性があり、スケーラビリティの可能性を高め、トランザクション コストを削減できることです。
• Taproot Assets は、カスタム トークンを使用して操作を記録するための個別のレイヤーを作成します。主にオフチェーン データに依存していますが、メイン ネットワーク上の残高の状態を公開します。 
• このアプローチは BRC-20 と比較してより柔軟で、スケーラブルで、包括的ですが、経験の浅いユーザーにとってはより複雑になります。

ビットVM

BitVM は、ビットコインを完全分散型コンピューティング プラットフォームに変換することを目的とした最先端のプロジェクトです。 9 年 2023 月 XNUMX 日に発表された BitVM ホワイト ペーパーでは、現在テスト段階にあり、その可能性を最大限に発揮するにはさらなる開発が必要なテクノロジーが紹介されています。

BitVM のコア機能と概念

BitVM はその中核として、オプティミスティック ロールアップの概念を採用してスマート コントラクトの計算をネットワークから外部化し、その後「不正証明」に基づいてオンチェーン検証を実行します。理論的には、スマート コントラクト情報が Taproot トランザクション (バイナリ コードとして) に記録されると、データ交換と計算が当事者間で直接行われることになります。このアプローチは、ブロックチェーンの混雑を軽減するように設計されています。ただし、証明者（証明する当事者、つまり契約所有者）が誤ったデータを送信した場合、検証者はオンチェーンチェックを開始できます。このプロセスは、不正行為防止の概念の基礎を形成します。

計算量が制限されたネットワークでのオンチェーン検証の処理

本質的にこのような計算をサポートしていないネットワークで動作確認をどのように行うかが課題となります。これに対処するために、BitVM はマークル ツリーを利用して論理 NAND ゲート スキームを作成し、それが Taproot トランザクションに記録されます。基本的に、トランザクション データ内のマークル ツリーは NAND スキームとして機能し、各「ブランチ」は 1 つの値 (0 または XNUMX) のいずれかを保持します。オンチェーンの計算はビットごとに進行し、XNUMX つの「ブランチ」の出力は次のようになります。次への入力。スマートコントラクト当事者間では、価値検証のためのトランザクション交換が定期的に行われます。証明者の計算バージョンが正しくないことが判明した場合、検証者は Taproot トランザクションでロックされた資産を受け取ります。

図 17. NAND の回路図。
出典: 「The Big Deal with BitVM: Arbitrary Computation now possible on Bitcoin without a fork」（Bitcoin Magazine）

Taproot と Merkle Tree を使用した NAND の構築

BitVM がタップルート ツリーとマークル ツリーを使用して NAND の構築を容易にする方法と、その計算への影響に関する詳細情報は、技術ドキュメントで参照できます。

このアプローチにより、ブロックチェーンの整合性とセキュリティの原則に沿って、スマート コントラクトの計算を段階的に正確に検証できます。

スマートコントラクトの二国間主義に関する課題

BitVM では、サードパーティの関与を排除し、検証者と証明者の間でのみ直接データ交換を促進するスマート コントラクトの双方向構造により、重大な問題が依然として残っています。この制約は dApp 開発を妨げ、複数当事者による契約構築のための補足ソリューションを義務付けます。 

さらに、BitVM の複雑で低レベルの特性は、この基盤を活用した機能製品の構築が数年に及ぶ可能性があることを示唆しています。この基礎技術を実用化するには、大幅な開発と革新が不可欠です。

詳細については、躊躇せずに BitVM を読んでください。 Whitepaper – https://bitvm.org/bitvm.pdf 

まとめ

RGB プロトコルは、ビットコイン エコシステムの技術開発であり、スマート コントラクトの実装とビットコイン ネットワークに直接関連付けられたトークン発行のための機能を導入します。これは、クライアント側の検証と使い捨てシールの利用を組み合わせることによって実現され、トランザクションのプライバシーを維持しながらトークンをビットコインの UTXO にリンクします。

RGB の主な技術的利点の 1 つは、スケーラビリティとプライバシーへのアプローチです。 RGB は、検証作業の大部分をビットコイン ブロックチェーンから移行し、トランザクション検証に暗号化手法を採用することにより、ブロックチェーン上のデータ負荷を効果的に軽減します。このアプローチは、特にトランザクション量が増加した場合に、ネットワークの効率を維持するのに役立ちます。

RGB の Lightning Network との互換性も重要な側面であり、よりスケーラブルで効率的なトランザクション処理が可能になります。この機能は、暗号通貨分野でより高速でコスト効率の高い取引方法に対する需要が高まっていることを考えると、特に重要です。

ただし、RGB テクノロジーの複雑な性質により、ユーザーのアクセシビリティと理解の点で課題が生じます。プロトコルのアーキテクチャと採用されている高度な暗号化手法は、特にブロックチェーン テクノロジーを初めて使用する人にとっては、理解して実装するのが難しい場合があります。この複雑さにより、広範な導入とユーザー エンゲージメントが妨げられる可能性があります。

さらに、RGB は契約データをブロックチェーンから遠ざけることでプライバシーを強化しますが、この側面により、特定のアプリケーションや規制遵守にとって重要なデータの検証可能性や取引を監査する機能についても疑問が生じます。

RGB の最新アップデートであるバージョン 0.10 は、ブロックチェーン技術の進化する状況において、特に Taproot Assets や BitVM などの新興プロトコルに対する注目すべき競合者として位置づけています。ビットコイン ネットワークでのトークン発行に Taproot の UTXO モデルを活用することに重点を置いている Taproot Assets とは異なり、RGB は高度なプライバシー機能とオフチェーン データ処理で差別化されており、スマート コントラクト機能とトークン管理に対する独特のアプローチを提供しています。

同様に、BitVM はビットコイン上の分散コンピューティングの新しい概念を導入していますが、RGB バージョン 0.10 のクライアント側検証、コントラクト インターフェイス、および厳密な型システムの進歩は、ビットコイン エコシステム内でのスケーラビリティとユーザー インタラクションの強化に対する独自のアプローチを示しています。これらの改善は、従来のプロトコルと新興プロトコルがしばしば制限に直面する領域である、スケーラビリティと効率の課題に対処する RGB の優れた能力を浮き彫りにします。

RGB の最新バージョンにおける依存関係と統合プロセスの簡素化は、ユーザー エクスペリエンスとシステムの安定性に焦点を当てていることを示しており、競合他社とは一線を画しています。これにより、RGB は、プライバシーを重視したスケーラブルなスマート コントラクトとトークン発行のための堅牢なプラットフォームとしてだけでなく、より広範なブロックチェーン領域における先進的なソリューションとしても位置付けられます。

結論として、RGB プロトコルはビットコイン ネットワーク内での重要な技術開発であり、スマート コントラクトとトークン発行のための高度な機能を提供します。これはスケーラビリティとプライバシーという重要な問題に対処していますが、複雑さと潜在的な監査可能性の点で課題に直面しています。プロトコルの進行中の開発と将来の反復では、これらの高度な機能とユーザーのアクセシビリティおよび規制上の考慮事項のバランスを取ることに重点が置かれる可能性があります。

用語の参照: 

1. チューリングの完了: 実際には、システムは十分な時間とメモリがあれば、あらゆる計算問題を実行できます。最新のプログラミング言語のほとんどはチューリング完全であり、あらゆる計算問題に対処できる理論的能力を示しています。
   
2. スキーマ: 契約スキーマはスマート コントラクトの実際のコードとして機能し、発行者は外部ソースから提供されるカスタム コードのコーディングや監査を必要とせずに、「契約テンプレート」として使用できます。 RGB スキーマはスクリプトではなくデータ構造です。
   
3. 個別ログ契約 ステート チャネルのコンテキストにおける (DLC) は、主にビットコイン ネットワークで使用される特殊なスマート コントラクトです。これらにより、資産価格などの外部イベントに基づいて、複雑な金融契約をプライベートかつ効率的に実行できるようになります。 DLC はオフチェーンで動作し、契約の詳細と参加者の身元情報の機密性を維持します。彼らは契約解決のために外部データソース、つまりオラクルを利用します。 DLC はステート チャネルと統合されると、ブロックチェーンを混雑させることなく複数のトランザクション決済を可能にすることでスケーラビリティを強化し、現実世界の結果に依存するプライベートで効率的な金融トランザクションに最適になります。
   
4. ストーム – zk-proofs を使用したエスクローベースのトラストレスストレージ。 Storm は、エスクローベースのトラストレス ストレージとゼロ知識証明を組み合わせて、安全でプライベートなトランザクションを促進します。このシステムでは、データまたは資産はエスクローに保持され、特定の条件が満たされた場合にのみ解放され、中央機関を必要としないトラストレス環境が保証されます。 zk-proofs の統合により、基礎的な詳細を明らかにすることなくデータを検証できるため、最大限の機密性を維持しながら、これらのトランザクションの検証が可能になります。
   
5. プロメテウス – 調停ベースのトラストレス分散コンピューティング。 Prometheus は、分散型コンピューティングへのアプローチを表しており、紛争解決のための仲裁メカニズム、安全な分散運用のためのトラストレスな対話、オフチェーン コンピューティング管理のための状態チャネルの効率性を組み合わせています。
   
6. A 削減された命令セットコンピュータ は、他のアーキテクチャでよく見られる高度に特殊化された命令セットではなく、小規模で高度に最適化された命令セットを利用するマイクロプロセッサ アーキテクチャの一種です。