RGB++と同型結合：CKB、Cardano、FuelがBTCを強化する方法

Author: Shew, geekweb3

Abstract:

- CKBチームによって提案されたRGB++アセットプロトコルは、「同型バインディング」というアイデアを提唱している。「同型バインディング」のアイデアは、CKBと、Cardano、FuelなどのUTXOプログラミングモデルに基づくブロックチェーンを、RGBアセットの「コンテナ」を運ぶ機能拡張レイヤーとして使用することです。この同型バインディングは、Atomical、Runes、およびUTXO機能を持つ他のビットコインエコアセットプロトコルにも適用され、ビットコインのオフチェーンスマートコントラクトレイヤーを簡単に構築できます。

- RGB++プロトコルでは、取引データを個人的に検証するためにクライアントを実行する代わりに、ユーザーは資産の有効性の検証やデータの保存などの作業を、CKBやCardanaoのようなUTXOチェーンに引き継ぐことができます。上記のパブリックチェーンのセキュリティが信頼できると「楽観的」である限り、自分で検証を行う必要はありません。

- RGB++プロトコルは、ユーザーがクライアント側の検証モードに切り替えることをサポートします。RGB++プロトコルはアセットがチェーンを渡る必要がないため、ビットコインアカウントを通じてCKBチェーン上のアセットを操作することができ、ビットコインチェーンへのコミットメントの頻度を減らすことができます。コントラクトシステムにいる場合、RGB++の多くの機能はうまくサポートされません。要約すると、同型バインディングを実装するのに適したパブリックチェーン/機能拡張レイヤーは、以下の特徴を持つべきです:

1. UTXOモデルまたは同様の状態格納スキームを使用する。strong>かなりのUTXOプログラマビリティを持ち、開発者はロック解除スクリプトを書くことができます;

3. 資産の状態を保存できるUTXO関連の状態空間があります;

4.スマートコントラクトまたは他の手段でサポートすることができます。

- CKB 以外に、Cardano や Fuel も同型バインディングをサポートできますが、後者2つはスマートコントラクトの言語やコントラクトの設計の詳細の点でお荷物になる可能性があり、現時点では後者2つよりも CKB の方が優れているようです。CKBはビットコインアセットプロトコルの機能拡張レイヤーとして、後者の2つよりも適している。

RGB++Protocol LightPaperの中で、Nervos CKBの共同創設者であるサイファー氏は、同形結合積のアイデアを最初に紹介しました。他のBitcoin Layer2ソリューションと比較して、同型バインディングはRGB、Runes、Atomicalなどのアセットプロトコルとのより良い互換性を可能にし、アセットクロスチェーニングのような追加のセキュリティ負担を生む要因を回避します。

簡単に言うと、同型バインディングは、RGBのようなUTXOタイプのアセットを表現するための「コンテナ」として、CKBとCardanoチェーン上のUTXOを使用し、それにプログラマビリティとより複雑なシナリオを追加します。以前、geek web3はFrom BTC to Sui, ADA & Nervos: The UTXO Model and Its Related Expansionsの中で、一連のプログラム可能なブロックチェーンについてまとめました。UTXOブロックチェーン、この記事ではこれらのブロックチェーンが同型結合スキームに適応できるかどうかをさらに探ります。

RGB++と同型バインディング

異なるUTXOチェーンの同型バインディングとの互換性の程度を分析する前に、同型バインディングの原理を紹介したいと思います。同型バインディングはCKBチームによってRGB++プロトコルで導入された概念であるため、ここではRGB++ワークフローを取り上げ、CKBベースの同型バインディングとは何かを紹介します。

RGB++プロトコルを紹介する前に、RGBプロトコルについて簡単に見ておきましょう。RGBはビットコインチェーンの下で動作するアセットプロトコル/P2Pネットワークで、ライトニングネットワークのようなものです。寄生とは、RGBクライアントがビットコインチェーン上で特定のRGB資産がどのUTXOに紐づいているかを宣言することを意味します。

RGBプロトコルは、ERC-20のようなアセットプロトコルとはまったく異なる動作をします。Ether上のERC-20コントラクトはすべてのユーザーのアセットの状態を記録し、Etherのノードクライアントはすべての転送を同期して検証し、転送後の状態更新をアセットコントラクトに記録します。これは実は以前から知られていたことであり、アセットのステータスに激変がないことを保証するためにイーサのコンセンサスプロセスに依存していることに他なりません。イーサノードの信頼できるコンセンサスのおかげで、ユーザーはクライアントを実行しなくても、ERC-20コントラクトベースのアセットホスティングプラットフォームを「問題なし」とデフォルト設定することができます。

But RGBプロトコルは、プライバシーを強化するために、ブロックチェーンの世界では慣例となっているノード/クライアントのコンセンサスを単純に削除するという点で奇妙です。それはそうだ。ユーザーはRGBクライアントを自分で実行しなければならず、「自分に関連するアセットデータ」のみを受け取って保存し、他のみんなが何をしているのか見ることはできません。

この場合、誰かがあなたにRGB資産を送金しても、あなたはそのお金がどのように作られたのか、誰に渡ったのかを事前に知ることはできません。向こう側のその人が、何もないところから資産を宣言し、その一部をあなたに送金した場合、コインを偽造するというこの邪悪なシナリオはどのように処理されるのでしょうか？

RGBプロトコルは、各送金が実行される前に、受信者が送信者に資産の全履歴を示すよう求めるという考え方を採用しています例えば、資産の作成段階から現在に至るまで、誰がその資産を発行し、誰を経由し、それらの人々の間で資産の各送金が会計簿記ガイドラインに違反することなく行われたかどうか。会計帳簿のガイドライン（一人が足し算、一人が引き算）に違反していないかどうか。

このように、あなたは、RGBの本質は、クライアント検証モデルに基づいて、検証を行うためにクライアントを実行するトランザクションの当事者にさせることである "問題のあるお金 "であるかどうかを知ることができ、合理的な人間のゲームの仮定に対応する限り、合理的な、クライアントソフトウェアの当事者は、クライアントソフトウェアは問題ではないことを保証することができます。クライアント・ソフトウェアは問題なく、疑わしい資産移転が検証できない、あるいは他者に認識されないことを保証します。

注目に値するのは、RGBプロトコルがこのオフチェーン取引データを受け取り、コミットメント（本質的にはメルクルート）に圧縮し、ビットコインチェーンにアップロードすることです。

（RGB プロトコルの相互作用フローチャート）。

RGBクライアントの間にはコンセンサスがないため、RGB資産契約の公表を「極めて確実に」すべてのノードに広めることはできず、契約発行者とユーザーは、電子メールやツイートを介して、非常にカジュアルな方法で、自発的にRGB資産契約の詳細を知らされるだけです。RGB資産契約の詳細は、非常に裁量に任されています。

次の図は、悪意のあるRGB資産移転シナリオを示しており、私たちはRGBユーザーとして、RGB資産契約を自分のクライアントにローカルに保存しています。他の人が私たちに送金するとき、ローカルに保存された資産契約の内容に基づいて、この現在の送金が契約で定義された規則に違反しているかどうかを知ることができます。相手から提供された資産の出所情報（履歴）をもとに、相手の資産の出所に問題がないか（いきなり申告されていないか）を確認できる。

以上のプロセスを確認すると、異なるRGBクライアントが受信・保存するデータは独立したものになりがちで、他人がどのような資産を持っていて、それがいくらになるのかわからないことが多いことがわかります。また、他の人は基本的にあなたの資産の状況も知りません。

これは典型的なデータサイロであり、誰もが一貫性のないデータを保存していることを意味します。これは理論的にはプライバシーのレベルを向上させますが、それ相応の手間を生み出します。RGBアセット用のデータを自分のクライアントでローカルに維持しなければならず、このデータの損失は深刻な結果（アセットが利用できなくなる）をもたらす可能性があります。しかし実際には、データをローカルに維持する限り、RGBプロトコルは本質的にメインのビットコインネットワークと同等のセキュリティを提供します。

さらに、RGBクライアント間の通信に使用されるBifrostプロトコルは、他のクライアントとのp2p通信でユーザーを支援し、自分のアセットデータを暗号化して他のノードに伝搬させ、相手側にそれを求めることができます。(暗号化されたデータなので、反対側は平文を知らないことに注意してください)。鍵も失わない限り、ローカルデータが失われた場合でも、ネットワーク内の他のノードを通じて、元々持っていた資産データを復元することができます。

しかし、オリジナルのRGBプロトコルの欠点はまだ明らかです。各取引が2者間で複数回の通信を必要とするという事実から始まり、受信者が送信者の資産の出所を確認し、送信者の送金要求を承認する返信レシートを送信します。このプロセスにより、両者間で少なくとも3通のメッセージが生成される。このような「双方向の送金」は、多くの人が慣れ親しんでいる「非対話的な送金」とは異なる。 誰かがあなたに送金し、あなたに取引データを送って確認させ、送金プロセスを完了する前にあなたの承認メッセージを受け取ることを想像できますか？（フローチャート）。（前の投稿のフローチャート）

第二に、ほとんどのDefiシナリオは、データ透過的で状態検証可能なスマートコントラクトを必要とします。さらに、RGBプロトコルでは、ユーザは自己検証を行うためにクライアントを実行しなければなりません。 >たまたま何万人もの人から手を変え品を変え間接的に受け取った場合、その資産の何万回もの転送を検証しなければなりません。明らかに、すべてをユーザーまかせにすることは、製品自体のプロモーションや採用に資するものではありません。

上記の問題に対して、RGB++の解決策は、ユーザーにクライアントサイドの自己検証モードとサードパーティホスティングモードを自由に切り替えさせることです。POWパブリック・チェーンが信頼できるものであることを楽観的に信頼する必要がある。手元に大量の資産があるなど、セキュリティとプライバシーをより強く追求する特定の人々は、元のRGBモデルに戻ることもできる。ここで強調しておきたいのは、RGB++とオリジナルのRGBプロトコルは、理論的には互いに互換性があり、「彼なくして私なし」というわけではないということです。

()RGB++ プロトコル相互作用フローチャート [短縮版])

前回の記事「RGB から RGB++ へ: CKB がビットコインを強化する方法以前の記事「RGBからRGB++へ：CKBがビットコインのエコアセットプロトコルを強化する方法」では、RGB++の「同型バインディング」について簡単に取り上げましたので、ここで簡単に復習しておきましょう：

CKBにはCellと呼ばれる独自の拡張UTXOがあり、これはBTCチェーン上のUTXOよりもはるかにプログラム可能です。同型バインディング」とは、CKBチェーン上のCellをRGBアセットデータの「コンテナ」として使用し、RGBアセットの主要パラメータをCellに書き込むことです。

RGB アセットは Bitcoin UTXO にバインドされているため、アセットの論理形式で UTXO の特性を持ちます。UTXOの特性も持つCellは、当然、RGBアセットの「コンテナ」として適しています。RGBアセットのトランザクションが発生するときはいつでも、対応するCellコンテナは、「同型結合」の本質である、実体とその影の関係のように、同様の特性を示すことができます。

例えば、アリスがビットコインチェーン上で100個のRGBトークンとUTXO Aを所有しており、同時にCKBチェーン上に「RGBトークン残高：100」とラベル付けされたセルがあり、ロック解除条件が関連付けられているとします。UTXO Aが関連付けられています。

アリスが30トークンをボブに渡したい場合、コミットメントを行うことができます。これは「UTXO Aに関連付けられた30 RGBトークンをボブに、70を彼女の管理下にある他のUTXOに送金する」というステートメントです。その後、CKBチェーン上でトランザクションが開始され、100 RGBトークンを保持するCellコンテナが消費され、2つの新しいコンテナが生成される。1つは30トークンを保持するコンテナ（Bob用）、もう1つは70トークンを保持するコンテナ（Aliceの管理下）である。このプロセスでは、アリスの資産の有効性と取引明細の有効性を検証する作業は、ボブが介入する必要なく、コンセンサスによって進むCKBネットワークノードによって行われる。

これは、EtherのERC-20コントラクトが、コントラクトの状態が変化するたびにクライアント側の検証を実行する必要がないのと似ています。クライアント側の検証を置き換えるために、ノードネットワークが使用されます。さらに、すべての人のRGB資産データはCKBチェーン上に保存され、グローバルな検証可能性があるため、流動性プールや資産質権協定などのDefiシナリオの実装が容易になります。

これは実際に重要な信頼の前提を導入しています。ユーザーは、CKBチェーン、またはコンセンサスプロトコルに依存する多数のノードで構成されるネットワークプラットフォームが信頼でき、エラーがないことを楽観視する傾向があります。もしCKBを信用しないのであれば、オリジナルのRGBプロトコルの対話型コミュニケーションと検証プロセスに従って、自分でクライアントを実行することもできます。

もちろん、誰かがRGB++クライアントを自分で実行し、他人の資産履歴の出所を検証することを望むなら、CKBチェーン上のRGB資産コンテナCellに関連付けられた履歴を検証すればよいのです。CKBライトノードを実行し、Merkle ProofとCKBブロックヘッダを受信するだけで、受信した履歴データがネットワーク内の悪意のある攻撃者によって改ざんされていないことを確認できる。ここでもCKBが履歴データ保存レイヤーとして機能していると言えます。

簡単に言うと、同型バインディングはRGBだけでなく、RunesやAtomicalなどのUTXO機能を持つさまざまなアセットプロトコルにも適用されます。Cardanoやその他のUTXO型パブリックチェーンに保存され、ホスティングされます。上記のUTXO型アセットプロトコルは、CKBやCardanoのUTXOモデルを「コンテナ」として使用し、アセットの形状や状態を示すことができます。

そして同型バインディングプロトコルの下では、ユーザーはクロスチェーンを使用することなく、CKBのようなUTXOチェーン上のRGBアセットコンテナをビットコインアカウントで直接操作することができます。CellのUTXO機能を活用して、Cellコンテナのロック解除条件を特定のビットコインアドレス/ビットコインUTXOに関連付けるように設定するだけです。Cellの機能については、geekweb3の前回のRGB++サイエンスの記事ですでに説明しているので、ここでは繰り返しません。

RGB資産取引の両当事者がCKBのセキュリティを信頼し、ビットコインチェーン上にコミットメントを頻繁に投稿する必要さえない場合、多くのRGBの集合体を送信することが可能です。これは「トランザクションの折り畳み」として知られており、使用コストを削減します。

しかし、同型バインディングに使用される「コンテナ」は、多くの場合、UTXOモデルをサポートするパブリックチェーン、または状態保存の点で同様の特性を持つインフラを必要とすることに注意することが重要であり、これは明らかに、技術的な実装で多くの穴に遭遇するEVMチェーンには適していません。まず、前述のように、RGB++は「CKBチェーン上のアセットコンテナのクロスチェーン操作を必要としない」のですが、これは基本的にEVMチェーンでは実装不可能です。クライアントを実行したり、資産データをローカルに保存したりする必要はありません。ERC-20を使って全員の資産残高をコントラクトに記録する場合、誰かがクライアントサイドの自己検証に戻りたいと考え、誰かの資産の出所を確認したいと申し出た場合、資産コントラクトと相互作用するすべての取引記録をスキャンしなければならない可能性があり、非常にストレスがかかります。

単刀直入に言うと、ERC-20 のようなアセット契約は、全員のアセット状態を一緒に結合するので、そのうちの一人のアセット変更の履歴を個別にチェックしたい場合、それは非常に難しくなります。ちょうど、共同チャットルームで誰が Wang Gang にメッセージを送ったかを調べたい場合、チャットルーム全体を調べて、メッセージログをひっくり返さなければならないのと同じです。公共のチャットルームで、誰が王牙にメッセージを送ったか知りたければ、チャットルーム全体を調べなければならないのと同じだ。一方、UTXOは1対1のプライベートチャットチャンネルのようなもので、履歴をチェックするのは簡単だ。

まとめると、同型バインディングを実装するのに適したパブリック チェーン/機能拡張レイヤーは、次のような特徴を持つべきです:

1. UTXO モデルまたは同様のステート ストレージ スキームを使用すること。

2. 実質的なUTXOのプログラマビリティがあり、開発者がロック解除をスクリプト化できること;

3. 資産の状態を保存するためのUTXO関連の状態空間の存在;

4. ビットコイン関連のブリッジまたはライトノードの存在;

もちろん、私たちは次のことも望んでいます。私たちは、同型バインディングに使用されるパブリックチェーンが強力なセキュリティを持っていることを望みますが、その一方で、そのパブリックチェーン上のUTXOのロックを解除するための条件がプログラム可能であることも望みます。

現在、CKB上のUTXOのロックスクリプトはプログラム可能で、異なるパブリックチェーンの署名スキームと公式に互換性があります。 同型バインディングについては、CKBネットワークは基本的に上記の特徴に準拠していますが、他のUTXOベースのパブリックチェーンについてはどうでしょうか？私たちはFuelとCardanoを予備的に調べましたが、理論的には同型バインディングをサポートできると考えています。

Fuel：UTXOベースのEther OP Rollup

Fuel はUTXOベースのEther OP Rollupであり、Ether Layer2のエコシステムにプルーフ・オブ・フラウドの概念を導入した先駆者でもあります。通常のUTXO機能のサポートについては、FuelとBTCは基本的に同じです。p>入力メッセージ: メッセージを配信するために使用されるUTXOで、主にメッセージの受信者などのフィールドが含まれます。

ユーザーがUTXOを使用すると、以下の出力が生成されます:

出力コイン: 標準的なアセットコールで使用されるUTXOです。

Output Contract : コントラクトの相互作用から生成される出力で、内部的には相互作用後のコントラクトの状態のルートを含んでいます;

Output Contract Created :コントラクトの特別な種類です。すべてのコントラクトの状態を含むCKBのCellとは異なり、FuelのUTXOは実際にはトランザクションに関連するすべてのコントラクトの状態を持ち運びません。Fuelはコントラクトの状態ツリーのルートであるStaterootのみをUTXO内に持ち運びます。コントラクトの完全な状態は、スマートコントラクトが所有するFuelのステートリポジトリに保存されます。

Fuelのコントラクトは、スマートコントラクトの状態を扱うという点で、またプログラミングの形式という点でさえも、solidityのコントラクトと思想的に同じであることは言及に値します。次の図は、FuelのSway言語で書かれたカウンターコントラクトを示しています。

Swayコントラクトを書くロジックは、一般的なSolidityコントラクトと似ていることがわかります。最初にコントラクトのABIを与え、次にコントラクトのステート変数を与え、次にコントラクトの具体的な実装を与えます。すべてのコード記述プロセスは、FuelのUTXOシステムに関与しません。

したがって、Fuelのコントラクトプログラミングの経験は、CKBやCardanaoのようなUTXOベースのプログラミング言語とは異なり、FuelはEVMスマートコントラクトプログラミング開発に近い経験を提供します。.開発者はSway言語を使って、特殊な署名アルゴリズム検証ロジックや、複数署名などの複雑なロック解除ロジックを実装するロック解除スクリプトを構築することもできます。

Fuel内で同型のバインディングを実装することは基本的に可能ですが、それでも以下のような問題があります：

Fuelは、BTCやCKB、Cardano、RGB、Atomicalsなどに適合するのではなく、スマートコントラクトの設計という点でEVMチェーンに近いSway言語を使用しています。UTXOタイプの資産発行者は、Fuel専用のスマートコントラクトを構築し、CKBのようなチェーンで別のスマートコントラクトを使用するのは非常に複雑です。

Cardano: POSベースのeUTXOパブリックチェーン

CardaonはUTXOモデルを使用するもう一つのブロックチェーンですが、Fuelとは異なり、Layer1のパブリックチェーンです。UTXOプログラミング・モデルを指す。CKBとは対照的に、カルダノ内のeUTXOは以下の構造を含んでいます:

スクリプト:  UTXOをアンロックできることを検証し、状態遷移を実行するスマートコントラクト。strong>Redeemers:  UTXOのロックを解除するために使用されるユーザー提供のデータで、一般的にはビットコインのWitnessに似た署名されたデータです。

Datum:  スマートコントラクトの状態空間。

Transaction Context:  トランザクションの入力パラメータや結果など、UTXOトランザクションのコンテキストデータ（UTXOチェーンのトランザクション計算プロセスはチェーン下で直接実行され、結果はチェーンに提出されます）。検証のため、チェインを上ります。検証に合格すると、取引結果がチェーンにアップロードされます）

開発者は、CKBに似たPlutusCore言語を使用して、カルダノチェーン上でUTXOをプログラムすることができます。同様に、開発者はロック解除スクリプトや状態更新のための関数を書くことができます。

UTXOベースのオークションプロセスを用いて、カルダノのUTXOプログラミングモデルを紹介する。具体的には、ユーザーはUTXOを消費し、このオークションでUTXOを契約し、新しいオークションUTXOを生成します。誰かがより高いオファーを出すと、新しいオークション契約UTXOが生成されるだけでなく、前の人への払い戻しUTXOも生成されます。図:

上記のオークションプロセスを実装するには、オークションのスマートコントラクトUTXO内に、オファーを出した人と現在のオークションの最高価格など、いくつかの状態を保存する必要があります。下図はPlutusCore内のステート宣言で、bBidderとbAmountがオークションのオファーとオファーを出した人のウォレットアドレスを示しているのがわかる。また、Auction Paramsの内部には、オークションに関する基本的な情報が含まれています。

ユーザーがこのUTXOを使うと、コントラクト内のステータスを更新できます。下図は、オークション契約内の具体的な状態更新とビジネスロジックを示しています。例えば、ユーザーのオファーをチェックし、現在のオークションがまだ進行中かどうかをチェックするロジックです。もちろん、PlutusCoreは純粋な関数型プログラミング言語であるHaskellで書かれているので、ほとんどの開発者は直接意味を見ることができないかもしれません。

Cardano 上で同型のバインディングを構築することは可能です。ビットコイン関連の署名アルゴリズムと互換性のある特定のスクリプトを書くことができます。しかし、深刻な問題は、ほとんどのプログラマーがPlutusCoreを使ったコントラクトプログラミングに慣れていない可能性があること、そしてそのプログラミング環境はセットアップが難しく、開発者に優しくないことです。li>

。Fuelは、同型バインディングと互換性があるものの、スマートコントラクトプログラミングの考え方が特殊であるため、いくつかの問題をもたらします。また、Cardaonは、コントラクトプログラミングにHaskellプログラミング言語を使用しており、ほとんどの開発者が迅速にスピードアップするのは困難です。これらの理由から、RISC-V命令セットを使用し、UTXOプログラミングの機能面でよりバランスが取れているCKBは、同型バインディングの機能拡張レイヤとしてより適しているかもしれない。