原作者：Ben（X：@wooooer）
序文
BTCに基づく資産発行は常にホットな話題です。 2011 年に初めて登場した Colored Coins から、最近人気の Ordinal プロトコルまで、BTC コミュニティでは常に新しいプレーヤーとコンセンサスが生まれていますが、残っているプレーヤーはほとんどありません。しかし、野心的なLightling LabsがTaproot Assetsに基づいてステーブルコインを構築する計画を発表したとき、TetherはビットコインレイヤーでのUSDTの鋳造にRGBを選択することも発表しました。
これは、かつて有名だったオムニレイヤー (マスターコイン) が、もはや BTC エコシステムの最大のプレーヤーではないことを意味します。クライアント側検証 (CSV) 資産プロトコルがすべての人の視野に入り始めています。従来の BTC 資産プロトコルとの違いは、 BTCの特性を拡張するためにも持ち込みます。しかし、BTC エコシステムに非常に多くの資産プロトコルがあることを前に、人々は「それらの違いは何ですか? 非常に多くの資産プロトコルに直面して、どのように選択し、独自の機会を見つけるべきでしょうか?」と尋ねずにはいられません。この記事は、誰もが BTC の歴史に登場した資産プロトコルを見直し、BTC 資産プロトコルの開発の将来を探求するきっかけとなることを願っています。
カラーコイン: カラーコイン
Colored Coins のアイデアは、現在 eToro の CEO である Yoni Assia によって最初に書かれたというタイトルの記事でした。bitcoin 2.X (aka Colored bitcoin)紹介された記事。この記事では、HTTP がネットワークの基盤であるのと同様に、基盤となるテクノロジーとしてのビットコインは完璧であると考えています。したがって、トークン プロトコル Colored Coins は、BTC の再利用に基づいて設計されました。
Yoni Assia は、どのコミュニティでも複数の通貨を作成できるような方法で BTC 2.0 経済を構築したいと考えています。トランザクションをクリアし二重支払いを回避するための基盤テクノロジーとしてビットコインを使用するこの方法は、間違いなく当時非常に大胆なアイデアでした。
Colored Coins は、ビットコインに基づいて資産を発行するためのプロトコルであり、そのアプローチは、特定の数のビットコインを「色付け」してこれらの資産を表すことです。これらのトークン化されたビットコインは機能的にはビットコインですが、別の資産または価値も表します。しかし、そのようなアイデアはどのようにしてビットコインに実装できるのでしょうか?
2014 年 7 月 3 日、ChromaWay は、開発者がカラー コインを作成するプロセスを簡素化する拡張フィルオーダーベース カラーリング プロトコル (EPOBC) を開発しました。これは、ビットコイン スクリプトの OP_RETURN 関数を採用した最初のプロトコルです。
最終的な効果を次の図に示します。
この実装は非常に単純ですが、多くの問題も引き起こします。
1. 代替可能なトークンと最小拘束値
ジェネシストランザクションで 1000 sat が染色コインにバインドされている場合、染色コインの最小分割単位は 1 sat です。これは、資産またはトークンを最大 1,000 株に分割または配布できることを意味します (ただし、これは理論上のものであり、粉塵攻撃を防ぐため、たとえば、今年の SAT は 546 SAT に設定されますが、その後は 546 SAT に設定されます)。順序が高くなります)。
2. 検証の問題
カラーコインの信頼性とその所有権を判断するには、資産の起源のトランザクションから現在のUTXOまで検証を追跡する必要があります。したがって、ウォレットやフルノード、さらにはブラウザをサポートするものを特別に開発する必要があります。
3. 潜在的なマイナー検閲リスク
ColoredTransaction の特徴は、メタデータ情報が出力に書き込まれるというより明らかなため、マイナーレビューの可能性をもたらします。
カラーコインは実際には、ビットコインの検証ルールを使用して資産の移転を追跡する資産追跡システムです。ただし、特定の出力 (txout) が特定の資産を表すことを証明するには、資産の発信元から現在までの完全な転送チェーンを提供する必要があります。これは、トランザクションの正当性を検証するには長い証明の連鎖が必要になる可能性があることを意味します。この問題を解決するために、最初に誰かが提案したのが、OP_CHECKCOLORVERIFYビットコインでのカラーコイン取引の正確性を直接検証するのに役立ちますが、提案は通過しませんでした。
暗号業界初の ICO: マスターコイン
マスターコインの元の概念は JR Willett によって提案されました。 2012年に彼は、"The Second Bitcoin Whitepaper"ホワイトペーパーでは、後に「MasterCoin」として知られるようになった、ビットコインの既存のブロックチェーン上に新しい資産またはトークンを作成するという概念について説明しました。その後、Omni Layer に名前が変更されました。
Mastercoin プロジェクトは 2013 年に初期トークンセール (今日では ICO または初期コインセールと呼んでいます) を実施し、史上初の ICO と考えられるもので数百万ドルの調達に成功しました。 Mastercoin の最も有名なアプリケーションは Tether (USDT) です。これは最も有名な法的ステーブルコインであり、元々は Omni Layer で発行されました。
実は、Mastercoin のアイデアは Colored Coins よりも早く登場しましたが、ここで 2 番目のアイデアとして説明する理由は、MasterCoin が Colored Coins と比較して比較的重いソリューションであるためです。 MasterCoin はより複雑な機能 (スマート コントラクトなど) を提供するために完全なノード層を構築しますが、Colored Coins はよりシンプルかつ単純で、主に「色付け」または他の資産を表すためにビットコイン UTXO をマークすることに焦点を当てています。
Colored Coins との最大の違いは、Mastercoin はチェーン上のさまざまなタイプのトランザクション動作のみを公開し、関連する資産情報を記録しないことです。 Mastercoin ノードでは、状態モデルのデータベースは、ビットコイン ブロックをスキャンすることによってオフチェーン ノードに維持されます。
カラーコインと比較すると、完成できるロジックはより複雑です。また、ステータスはチェーン上で記録および検証されないため、トランザクション間の連続性 (連続的な色付け) の要件はありません。
ただし、マスターコインの複雑なロジックを実装するには、ユーザーがノードのオフチェーン データベースのステータスを信頼するか、オムニ レイヤー ノードが自身でステータスを検証できるようにする必要があります。
要約:
Mastercoin と Colored Coins の最大の違いは、プロトコルに必要なすべてのデータをチェーン上で維持することを選択するのではなく、BTC コンセンサス システムに寄生して独自のトランザクションの公開とソートを実装し、ステータスを維持することです。オフチェーン データベース。
OmniBolt が提供した情報によると、Omni Layer は新しい UBA (UTXO Based Asset) 資産プロトコルを TEDA に提案しています。これは、Taproot アップグレードを使用して資産情報を Tapleaf に組み込み、条件付き支払いやその他の機能を実現します。同時に、OmniBolt は OmniLayer の Lightning Network 施設に Stark を導入しています。
クライアント側検証のアイデア
クライアント側検証の概念を理解したい場合は、Colored Coins と Mastercoin が登場した 2 年目、つまり 2013 年に戻る必要があります。ピーター・トッドは、この年に次のような記事を発表しました。Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation。記事名からはクライアントサイド検証とは何の関係もないように思えますが、よく読むとこれがクライアントサイド検証に関する最も初期の啓蒙思想であることがわかります。
ピーター・トッドはビットコインと暗号学の初期の研究者であり、ビットコインの動作をより効率的にする方法を常に模索していました。彼は、タイムスタンプの概念に基づいて、より洗練されたクライアント側の検証概念を開発しました。さらに後述する「使い捨てシール」という概念も提案した。
さて、ピーター・トッドの考えに従い、まずBTCが実際にどのような問題を解決するのかを理解しましょう。 Peter Todd 氏によると、BTC は合計 3 つの問題を解決するようです。
出版証明
証明の公開の本質は、二重支払い問題を解決することです。たとえば、アリスはビットコインをボブに送金したいと考えています。彼女はトランザクションに署名してボブに送金しましたが、ボブは必ずしもそのような送金が存在することを知っているわけではありません。物理的に。したがって、トランザクションを公開し、誰もがそこからトランザクションをクエリできる公開の場所が必要です。
トランザクションの順序付け (注文のコンセンサス)
コンピュータ システムには、私たちが通常経験しているような物理的な時間は存在しません。分散システムでは、この時間は通常、分散クロック ランバーです。このクロックは物理的な時間を測定するものではなく、トランザクションの順序を決定します。
トランザクションの検証 (オプション)
BTC での検証は、署名と BTC 送金額の検証についてです。しかし、ここでピーター・トッドは、この検証はBTC上にトークンシステムを構築するために必要ではなく、単なる最適化オプションであると信じています。
これを見て実は先ほどの Ominilayer のことを思い出したのですが、OminiLayer 自体は状態の計算や検証を BTC に引き渡すのではなく、BTC のセキュリティも再利用しています。 Colored Coins はステータス追跡を BTC に引き渡します。これら 2 つの存在は、検証をオンチェーンで行う必要がないことを証明しました。
では、クライアント側の検証はどのようにしてトランザクションを効果的に検証するのでしょうか?
まず、確認する必要があるものを見てみましょう。
1.ステータス（トランザクションロジック検証）
2. 入力 TxIn が有効かどうかを確認します (二重支出を防ぐため)
ビットコインで公開されている資産を見つけるのは簡単ですが、各トランザクションは関連するトランザクション履歴全体を検証して、参照された入力が消費されておらず、ステータスが正しいことを確認する必要があります。これは非常に不合理なので、どうすれば改善できますか？
Peter Todd は、検証の焦点を変えることでこのプロセスを簡素化できると信じています。このアプローチは、出力が二重に支出されていないことを確認するのではなく、トランザクションの入力が転記され、他の入力と競合していないことを確認することに重点を置いています。各ブロック内の入力をソートし、マークル ツリーを使用することにより、各検証にはその入力のオンチェーン履歴全体ではなく、データのごく一部のみが必要となるため、この検証をより効率的に行うことができます。
Peter Todd によって提案されたコミットメント ツリー構造は次のとおりです。
CTxIn -> CTxOut ->
しかし、そのようなコミットメント ツリーをチェーンにどのように保存するのでしょうか?そこでここでは、使い捨てシールの概念をご紹介します。
使い捨てシール
クライアント側の検証を理解する上で中心となる概念の 1 つは使い捨てシールです。これは、現実世界で輸送用コンテナを保護するために使用される物理的な使い捨てシールに似ています。使い捨てシールは、メッセージに対して 1 回だけ閉じることができるユニークなオブジェクトです。つまり、ワンショットシールは二重支払いを防ぐために使用される抽象的なメカニズムです。
SealProtocol には、3 つの要素と 2 つのアクションがあります。
基本要素：
l： seal,つまりシール
m： message,情報
w：witness,目撃者
基本操作: 基本操作は 2 つあります。
Close(l,m) → w: メッセージ m のシール l を閉じ、証人 w を作成します。
Verify(l, w,m) → bool: メッセージ m でシール l が閉じられていることを確認します。
セキュリティの観点から、使い捨てシールの実装により、攻撃者は 2 つの異なるメッセージ m 1 と m 2 を見つけることができなくなり、同じシールに対して Verify 関数が true を返すようになります。
まず、使い捨てシールは、特定の資産やデータが 1 回だけ使用またはロックされることを保証する概念です。ビットコインのコンテキストでは、これは通常、UTXO (未使用のトランザクション出力) が 1 回しか使用できないことを意味します。したがって、ビットコイントランザクションの出力は 1 回限りのシールとみなすことができ、この出力が別のトランザクションへの入力として使用される場合、シールは「壊れた」または「使用された」ことになります。
BTC 上の CSV 資産の場合、ビットコイン自体が単一のシールの「証人」として機能します。これは、ビットコイン トランザクションを検証するために、ノードはトランザクションへの各入力が有効で未使用の UTXO を参照していることを確認する必要があるためです。トランザクションがすでに使用されている UTXO を二重に使用しようとすると、ビットコインのコンセンサス ルールとネットワーク上の誠実なノードがトランザクションを拒否します。
もっとシンプルにできないでしょうか？
シングルユースシールとは、あらゆるブロックチェーンをデータベースとして扱い、あるメッセージの約束を何らかの方法でこのデータベースに保存し、消費された状態、または消費される予定の状態を維持することです。
はい、とても簡単です。
要約すると、クライアントが検証したアセットには次の特徴があります。
オフチェーン データ ストレージ:クライアントが検証した資産のほとんどは、取引履歴、所有権、その他の関連データがオフチェーンに保存されています。これにより、オンチェーンのデータ ストレージのニーズが大幅に軽減され、プライバシーの向上に役立ちます。
コミットメントメカニズム:資産データはオフチェーンに保存されますが、このデータへの変更または転送はコミットメントを通じてオンチェーンに記録されます。これらのコミットメントにより、オンチェーンのトランザクションがオフチェーンの状態を参照できるようになり、オフチェーン データの整合性と改ざん不可能性が保証されます。
オンチェーン証人 (必ずしも BTC であるとは限りません):データと検証の大部分はオフチェーンですが、クライアントが検証した資産は、オンチェーンに埋め込まれたコミットメントを通じて、基礎となるチェーンのセキュリティ (証明の発行、トランザクションの順序付け) を引き続き利用できます。
ジョブ クライアントが完了したことを確認します。検証作業のほとんどはユーザーのデバイス上で行われます。これは、すべてのネットワーク ノードが各トランザクションの検証に参加する必要はなく、関係する参加者のみがトランザクションの有効性を検証する必要があることを意味します。
クライアント側の資産検証を使用する場合は、次の点に注意する必要があります。
オフチェーンで取引し、クライアントが検証した資産を検証する場合、資産を保持する秘密鍵を提示するだけでなく、対応する資産の完全なメルケルパスの証明も提示する必要があります。
クライアント側検証 (CSV) のパイオニア: RGB
RGB の概念は、コミュニティ内で有名なジャコモ ズッコ氏によって 2015 年以降に提案されました。イーサリアムの台頭と ICO の急増により、また ICO の前には、多くの人々がビットコイン以外の何かをしようとしました。マスターコインとカラーコインプロジェクト。
ジャコモ・ズッコ氏は失望を表明した。彼は、これらのプロジェクトはビットコインよりも劣っていると信じており、ビットコインにトークンを実装する以前の方法は不適切であると信じています。その過程で、彼は Peter Todd に出会い、Peter Todd のクライアント側検証のアイデアに魅了されました。それから彼はプロポーズを始めましたRGBアイデア。
RGB と以前のアセット プロトコルの最大の違いは、前述のクライアント側アセット検証機能に加えて、チューリング完全コントラクト実行エンジンを実装するための実行 VM も追加されていることです。また、契約データのセキュリティを確保するためにスキーマやインターフェースも設計されています。スキーマはイーサリアムに似ており、コントラクトの内容と機能を宣言しますが、インターフェイスはプログラミング言語のインターフェイスと同様に、特定の機能の実装を担当します。
これらのコントラクトのスキーマは、RGB 20 や RGB 21 など、VM の実行時に予期される動作を超えない動作を制限する役割を果たします。RGB 20 や RGB 21 はそれぞれ、代替可能トークンと代替不可能なトークンのトランザクションに対するいくつかの制限を担当します。
RGB のコミットメント メカニズム PerdersenHash
コミットメントメカニズムの観点から、RGB は Perdersen ハッシュを使用します。利点は、値を公開せずに約束できることです。 Pedersen ハッシュを使用してマークル ツリーを構築すると、その中の値を隠すプライバシーを保護するマークル ツリーを作成できることになります。この構造は、一部の匿名暗号通貨プロジェクトなど、特定のプライバシー保護プロトコルで使用できます。ただし、CSV アセットには適用できない場合があります。これについては、Taproot Assets との比較で後述します。
RGB 仮想マシン設計 Simplicity → AluVM
RGB の目標は、クライアント検証済みのアセット プロトコルを実装するだけでなく、チューリング完全な仮想マシンの実行とコントラクト プログラミングに拡張することでもあります。 RGB の初期の設計では、Simplicity と呼ばれるプログラミング言語を使用すると主張していました。この言語の特徴は、式を実行するときに実行証明を生成し、記述したコントラクトを形式化しやすくすることです。バグを回避します）。しかし、言語の開発は理想的なものではなく、トラブルに終わりました。これは最終的に、その年の RGB プロトコル全体の困難に直接つながりました。最後に、RGB は、オリジナルの Simplicity と同様に、未定義の動作を回避することを目的として、Maxim によって開発された AluVM と呼ばれる VM の使用を開始しました。新しいAluVMは、将来的には現在使用されているRustに代わるContractumと呼ばれるプログラミング言語を使用すると言われています。
RGB レイヤー 2 の拡張方向: ライトニング ネットワークかサイドチェーンか?
セキュリティを確保しながら、クライアント側の検証資産をオフチェーンで継続的に取引する方法はありません。クライアントによって検証されたアセットは、トランザクションのパブリッシュとシーケンス処理に依然として L1 に依存しているため、L2 拡張計画がない場合、そのトランザクション速度は依然として L1 監視のブロック生成速度によって制限されます。これは、厳格なセキュリティ要件の下で RGB トランザクションがビットコイン上で直接実行される場合、2 つの関連するトランザクション間の時間は最大 10 分（BTC のブロック時間）離れる必要があることを意味します。このようなトランザクション速度がほとんどの場合許容できないことは疑いの余地がありません。
RGBとライトニングネットワーク
簡単に言うと、ライトニング ネットワークの原理は、トランザクションの 2 つの当事者がオフチェーンで一連の契約 (コミットメント トランザクション) に署名し、どちらかの当事者が契約に違反した場合、違反した当事者が契約を変更できるようにするというものです (コミットメント トランザクション) ）をBTCに提出して決済し、自分の資金を引き出して相手を罰します。言い換えれば、ライトニングネットワークはプロトコルとゲームの設計を通じてオフチェーントランザクションのセキュリティを保証します。
RGB は、RGB に適用される独自の決済チャネル契約内容を設計することで、独自のライトニング ネットワーク機能を構築できますが、ライトニング ネットワークの複雑さは非常に高く、この機能を構築するのは容易ではありません。しかし、Lightnling labs はこの分野で長年取り組んできており、LND は 90% 以上の市場シェアを持っています。
RGB サイドチェーン プライム
LNP-BP現在のRGBプロトコルの保守者として、マキシムは2023年6月に**と呼ばれる提案をリリースしました。Prime** のクライアントは資産拡張計画を検証し、既存のサイドチェーンとライトニング ネットワークの拡張計画は開発の観点から複雑すぎると批判しています。Maxim同氏は、Prime に加えて、他の拡張方法には NUCLEUS マルチノード ライトニング チャネルと Ark/Enigma チャネル ファクトリが含まれると考えていると述べましたが、どちらも 2 年以上の開発が必要です。しかし、Prime の完成には 1 年しかかかりません。
Prime は従来の意味でのブロックチェーン設計ではなく、クライアント検証用に設計されたモジュール式の証明公開レイヤーであり、次の 4 つの部分で構成されます。
タイムスタンプサービス:トランザクションシーケンスはわずか 10 秒で完了します。
証明する：PMT形式で保存することでブロックヘッダーとともに生成・公開されます。
使い捨てシール:二重支出を防ぐには、抽象的な 1 回限りのシーリング プロトコルで十分です。ビットコインで実装された場合、現在の RGB デザインと同様に、UTXO にバインドできます。
スマートコントラクト契約:シャーディングコントラクト-RGB (交換可能)
実際、このことから、RGB トランザクション確認時間の問題を解決するために、Prime はタイムスタンプ サービスを使用してオフチェーン トランザクションを迅速に確認し、トランザクションと ID をブロックにロードしていることがわかります。同時に、プライム上のトランザクション証明は PMT を通じてさらにマージされ、チェックポイントのような方法で BTC に固定されます。
Taproot に基づく CSV アセット プロトコル: Taproot Assets
Taproot Assets は、Taproot に基づく CSV 資産プロトコルであり、ビットコイン ブロックチェーン上でクライアントが検証した資産を発行するために使用されます。これらの資産は、ライトニング ネットワークを通じて大量かつ低手数料で即座に取引できます。 Taproot Assets はその中核として、ビットコイン ネットワークのセキュリティと安定性を、ライトニング ネットワークの速度、拡張性、低料金で活用しています。このプロトコルは、Lightnling labs の CTO である roasbeef によって設計および開発されました。Roasbeef は、Odaily でビットコイン クライアント (BTCD) とライトニング ネットワーク クライアント (LND) の開発を個人的に主導し、BTC を深く理解している唯一のビットコイン開発者である可能性があります。 。
タップルート トランザクションはアセット スクリプトのルート ハッシュのみを伝送します。ハッシュ自体は普遍的であり、任意のデータを表す可能性があるため、外部の観察者がタップルート アセットが関与しているかどうかを特定するのは困難です。 Taproot のアップグレードにより、ビットコインはスマート コントラクト (TapScript) 機能を獲得しました。これに基づいて、Taproot Assets の資産コーディングは、ERC 20 または ERC 721 と同様のトークン定義を作成することと同等です。このように、ビットコインは資産定義の機能だけでなく、スマート コントラクトを作成する機能も備えており、ビットコインのトークン スマート コントラクト インフラストラクチャのプロトタイプが構築されています。
Taproot アセットのエンコード構造は次のとおりです。
Lightning Labs CTO のローアスビーフからの画像
また、CSV アセット プロトコルとしても、Taproot Assets は RGB よりもシンプルな設計になっています。また、Taproot アップグレードや PSBT など、BTC エコシステムの現在の進歩を最大限に活用しています。アプリケーションのスケーラビリティに関する Taproot Assets と RGB の最大の違いは実行 VM で、Taproot Assets は BTC のネイティブ デフォルトと同じ TaprootScriptVM を使用します。近年、BTCに関するインフラストラクチャ研究はTapScriptに基づいて多く行われていますが、BTCのアップグレードが遅いため、短期間での適用は困難であり、Taproot Assetsがそのテストフィールドとなることが予想されます。将来の新鮮なアイデア。
Taproot アセットと RGB の違いは何ですか?
1. トランザクション検証とライトノードの使いやすさ
Taproot Assets は、サムツリーの実装により高い検証効率とセキュリティを備えています（すべての取引履歴を走査して入力する必要がなく、保有証明のみでステータスを確認して取引を行うことが可能です）。 RGB で使用されるペダーセンコミットメントでは、入力の正当性を効果的に検証することができないため、RGB は入力トランザクションの履歴を遡る必要があり、後段のデリバティブトランザクションは非常に大きな負担となります。メルケル和の設計により、Taproot Assets は、BTC に基づく以前の資産プロトコルでは利用できなかったライト ノード検証を簡単に実装することもできます。
2.VMの実行
Taproot Assets は、Taproot アップグレードに応じて誕生しました。使用する TaprootScriptVM は、Taproot アップグレード後にビットコインに付属するスクリプト実行エンジンであり、使用される vPSBT は、BTC の PSBT のレプリカです。これは、かつてライトニング チャネルが開発されたことを意味します。 Taproot Assets のメカニズムが完成し、以前の Lightning labs 製品と同様に、現在のすべての LND インフラストラクチャをすぐに再利用できます (LND は現在、Lightning Network の 90% 以上を占めています)。そして、最近の注目の BitVM 提案はすべて TaprootScript に基づいており、理論的には、これらすべての改善は最終的に Taproot Assets に役立つ可能性があります。
しかし、RGB の場合、その VM と検証ルール (SCHEMA) は自己完結型であり、ある程度、比較的閉じられた小さなエコシステムです。 RGB ベースの構築は独自のエコシステム内でのみ機能し、ビットコイン エコシステムとの関係は誰もが想像するほど密接ではありません。 Taproot アップグレードのフォローアップを例にとると、RGB と Taproot アップグレードの間の唯一の関係は、オンチェーン コミットメント データを Witness の TapLeaf にエンコードすることです。
3. スマートコントラクト
現在の RGB の実装設計では、コントラクトと VM が非常に強調されている部分です。ただし、Taproot Assets にはまだスマート コントラクトがありません。ただし、現在のグローバル状態での RGB の現在の変更が各独立コントラクト シャード (UTXO) とどのように同期されるかについては説明されていません。さらに、ペダーセン氏は保証できるのは資産の総数のみであると約束しており、他の州で改ざんを確実に特定する方法についてはこれ以上説明がないようだ。 Taproot Assets に関しては、設計はシンプルではあるものの、現状ではステートの保存は資産残高のみであり、ステートが存在しないため、当面はスマートコントラクトについて話すことはできません。しかし、Lightning Labsによると、Taproot Assetsは来年スマートコントラクトの設計に注力する予定だという。
4. 同期センター
前述のクライアント側で検証される資産の基本原則から、Proof の保持は秘密鍵の保持と同じくらい重要であることがわかりますが、Proof が常にユーザークライアント上にある場合、簡単に紛失してしまう可能性があるため、どうすればよいでしょうか?毛織物? Taproot Assets では、ユニバースを通じてそのような問題を回避できます。ユニバースは、1 つ以上の資産を対象とする公的監査可能 (MS-SMT) です。通常の Taproot アセット ツリーとは異なり、ユニバースは Taproot アセットをホストするために使用されません。代わりに、ユニバースは 1 つ以上のアセット履歴のサブセットにコミットします。
RGB のこの部分を担当するのは Storm で、p2p を通じてオフチェーンのプルーフ データを同期および保存しますが、RGB の開発チームの歴史的な理由により、これらのチームのプルーフ フォーマットは現在互換性がありません。 RGBエコロジーチームDIBAは現在、carbonadoこの問題を解決するために取り組んでいますが、進捗状況はまだ明らかではありません。
5. プロジェクトの実施
Lightning ラボには独自の Bitcoin クライアント (BTCD)、Lightning Network クライアント (LND)、および多数のウォレット ライブラリ実装があるため、Taproot Assets で使用されるすべてのライブラリは実績のあるものです。一方で、RGB の実装に使用されるライブラリのほとんどは自己定義されており、業界標準の観点から見ると、RGB の実装はまだ実験段階にあります。
BTC 拡大の将来についての簡単なディスカッション
議論のこの時点で、クライアント検証済み資産プロトコルがプロトコルの範囲から外れ、コンピューティングの拡張に向けて動き始めていることに誰もが気づきました。
将来的にはビットコインがデジタルゴールドとして存在し、他のチェーンがアプリケーションエコシステムを構築すると多くの人が言っています。しかし、これについて私は異なる見解を持っています。 btc フォーラムと同様に、さまざまなアルトコインとその短い寿命について多くの議論が行われています。これらのアルトコインの急速な終焉により、かつてそれらを取り囲んでいた資本と努力はバブルに変わりました。私たちはすでにビットコインのような強力なコンセンサス基盤を持っており、アプリケーション プロトコル用に新しい L1 を構築する必要はありません。私たちがしなければならないのは、最強のインフラであるビットコインをどう活用し、長期的な分散型世界を構築するかです。
オンチェーンの計算を減らし、オンチェーンの検証を増やす
アプリケーション設計の観点から見ると、ビットコインは長い間、その中心目標としてオンチェーン コンピューティングではなく、検証に基づく設計哲学を選択してきました (Turing completeness and state for smart contract）。ブロックチェーンの本質は複製されたステートマシンであり、チェーンのコンセンサスがチェーン上で計算される場合、ネットワーク内のすべてのノードでこれらの計算を繰り返すことが合理的でスケーラブルであるとは言いがたいです。検証が主な焦点である場合、オフチェーントランザクションの正当性を検証することがBTC拡大に最適なソリューションとなる可能性があります。
検証はどこで行われますか?それは重要です
ビットコインに基づくプロトコル開発者にとって、ビットコインを鍵検証に使用する方法、さらには検証をオフチェーンに置く方法、およびセキュリティ ソリューションを設計する方法は、実際にはプロトコル設計者自身の仕事であり、その必要はありません。チェーン自体とは何の関係もないはずです。したがって、検証をどのように達成するかによって、BTC のさまざまな拡大計画が生まれます。
したがって、検証実装の観点に基づいて、次の 3 つの拡張方向があります。
1. 検証はオンチェーンで行われます (OP-ZKP)
OP-ZKP を TaprootScriptVM に直接実装すると、BTC 自体に ZKP 検証機能を追加することと同等となり、一部の Covenant 設計決済プロトコルを使用して、BTC のセキュリティを継承できる Zk-Rollup 拡張ソリューションを作成できます。しかし、イーサリアム上で検証コントラクトを展開するのとは異なり、BTC 自体のアップグレードは遅く、普遍的ではなくその後のアップグレードが必要になる可能性があるオペコードの追加は困難になることが予想されます。
2. 検証はハーフチェーン (BitVM) で行われます。
BitVM の設計は通常のトランザクション ロジックとして機能しないように設計されており、Robin Linus は、BitVM の将来はさまざまなサイドチェーンの自由なクロスチェーン マーケットとして機能することであるとも述べました。 BitVM のソリューションがハーフチェーンで発生する理由は、ほとんどの場合、これらの検証計算がチェーン上では発生せず、オフチェーンで発生するためです。ただし、BTC の Taproot を中心に設計する重要な理由は、必要に応じて計算検証に TapScriptVM を使用できるようにすることであり、理論的には BTC のセキュリティを継承することでもあります。このプロセスでは、たとえば、n 人の検証者のうちの 1 人が正直である限り、つまりオプティミスティック ロールアップである限り、検証の信頼チェーンも生成されます。
BitVM のオンチェーンのオーバーヘッドは膨大ですが、ZK の不正防止を使用して効率を向上させることはできますか?答えは「ノー」です。ZK 不正証明の実装は ZKP がチェーン上で検証できるという事実に基づいており、OP-ZKP スキームのジレンマに戻ります。
3. 検証はオフチェーンで行われます (クライアント側検証、ライトニング ネットワーク)
検証は完全にオフチェーン、つまり、前述した CSV アセット プロトコルと Lightning Network で行われます。これまでの議論からもわかるように、CSVの設計において共謀改ざんの発生を完全に防ぐことはできませんが、できることは、暗号やプロトコルの設計を活用して、悪意のある共謀被害の範囲を制御可能な範囲に抑えることです。この動作を不利益なものにします。
オフチェーン検証の長所と短所も非常に明白ですが、利点は、チェーン上で使用するリソースが非常に少なく、拡張の可能性が非常に大きいことです。欠点は、BTC のセキュリティを完全に再利用することがほぼ不可能であるため、実行できるオフチェーン トランザクションの種類と方法が大幅に制限されることです。また、オフチェーン検証は、データがオフチェーンにあり、ユーザー自身によって保管されることも意味するため、ソフトウェア実行環境のセキュリティとソフトウェアの安定性に対してより高い要件が課されます。
拡大と進化のトレンド
パラダイムの観点から見ると、現在イーサリアムで普及しているレイヤー 2 は、レイヤー 1 を使用してレイヤー 2 の計算の妥当性を検証します。つまり、状態計算はレイヤー 2 にプッシュダウンされますが、検証は依然としてレイヤー 1 に保持されます。将来的には、検証計算をオフチェーンにプッシュして、現在のブロックチェーン インフラストラクチャのパフォーマンスをさらに解放することもできます。
References
Assia, Y. (n.d.). Colored Bitcoin. Retrieved from https://yoniassia.com/coloredbitcoin/
CryptoAdventure. (n.d.). A Brief History of Colored Coins: What Made Them Special. Retrieved from https://cryptoadventure.com/a-brief-history-of-colored-coins-what-made-them-special/
Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from https://bitcoil.co.il/BitcoinX.pdf
Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html
Livera, S. (n.d.). Episode 501. Retrieved from https://stephanlivera.com/episode/501/
Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/
Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d
Burtey, N. (n.d.). Twitter Post. Retrieved from https://twitter.com/nicolasburtey/status/1703705962664669225
Burtey, N. (n.d.). Twitter Post. Retrieved from https://x.com/nicolasburtey/status/1703710347889127585?s=20
Bosworth, A. (n.d.). Twitter Post. Retrieved from https://twitter.com/alexbosworth/status/1703423563288473769
BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from https://www.youtube.com/watch?v=9fz34ef5GSk&ab_channel=BitcoinShooter
Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin
Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE
Todd, P. ( 2016). OpenTimestamps Announcement. Retrieved from https://petertodd.org/2016/opentimestamps-announcement
Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from https://bitcoinops.org/en/topics/client-side-validation/
Todd, P. ( 2016). Commitments and Single-Use Seals. Retrieved from https://petertodd.org/2016/commitments-and-single-use-seals
Todd, P. ( 2014). Setting the Record: Proof of Publication. Retrieved from https://petertodd.org/2014/setting-the-record-proof-of-publication
Bitcoin Magazine. (n.d.). The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality. Retrieved from https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality
Linux Foundation. ( 2015). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59
Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/
Linux Foundation. ( 2023). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html
Salvatoshi. (n.d.). Twitter Profile. Retrieved from https://twitter.com/salvatoshi
Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from https://merkle.fun/
Muneeb. (n.d.). Twitter Post. Retrieved from https://twitter.com/muneeb/status/1712853971948229042
Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/
Todd, P. ( 2013). Disentangling Crypto Coin Mining. Retrieved from https://petertodd.org/2013/disentangling-crypto-coin-mining
