紹介

BTCに基づく資産の発行は、常にホットな話題となっています。 2011年のカラードコインの登場から、最近人気のオーディナルプロトコルまで、BTCコミュニティは常に新しいプレイヤーとコンセンサスを生み出すことができました。 しかし、時の試練に耐えてきたものはほとんどありません。 野心的なLightling LabsがTaproot Assetsの上にステーブルコインを構築する計画を発表し、Tetherがビットコインの最初のレイヤーでUSDTを鋳造するためにRGBを選択したと宣言したことで、かつて有名だったOmniLayer(マスターコイン)がもはやBTCエコシステムの最大のプレーヤーではないことは明らかです。 クライアントサイド検証(CSV)資産プロトコルは、ビットコインのスケーラビリティのための機能も組み込んでいることで、従来のBTC資産プロトコルとは異なり、注目を集め始めています。 しかし、BTCエコシステムにおけるこれほど多数の資産プロトコルに直面して、それらの違いは何なのかを問わなければなりません。 そして、これらの数多くの資産プロトコルの中から、どのように選択し、独自の機会を見つけるべきでしょうか?

この記事は、ビットコインの歴史に登場したさまざまな資産プロトコルをレビューする際に読者をガイドし、近い将来のビットコインベースの資産プロトコルの潜在的な軌跡を掘り下げることを目的としています。

カラーコイン

カラードコインのアイデアは、2012年3月27日に書かれた「ビットコイン2.X(別名カラービットコイン)」というタイトルの記事で、eToroの現在のCEOであるYoni Assiaによって最初に提案されました。 この記事は、HTTPがインターネットの基盤であるのと同じように、基盤となるテクノロジーとしてのビットコインが完璧であると仮定しました。 そのため、BTCの再利用に基づいて、Colored Coinsトークンプロトコルが設計されました。

Yoni Assiaは、この方法でBTC 2.0経済を作成することを目指しました-どのコミュニティもこの方法でさまざまな通貨を作成できます。 取引を清算し、二重支出を回避するための基盤技術としてビットコインを使用するというこのアプローチは、間違いなく当時非常に大胆なアイデアでした。

ビットコインに基づいて資産を発行するためのプロトコルとして、カラーコインの方法は、これらの資産を表すために一定量のビットコインを「色付け」することです。 これらのマークされたビットコインは、機能的にはビットコインのままですが、別の資産または価値も表しています。 しかし、このアイデアをどのようにビットコインに実装できますか?

2014年7月3日、ChromaWayは、開発者がカラーコインを作成するプロセスを簡素化するEnhanced Pay-to-Script-Hash(P2SH)ベースのColored Coinsプロトコル(EPOBC)を開発しました。 これは、ビットコイン ScriptのOP_RETURN機能を採用した最も初期のプロトコルでした。

最終的な実装を次の図に示します。

)

この実装は非常に簡潔ですが、多くの問題も引き起こします。

均質化されたトークンと最小バインディング値

ジェネシストランザクションでは、カラーコインが1000サットでバインドされている場合、このカラーコインの最小分割単位は1サットです。 これは、資産またはトークンを最大1000の部分に分割または割り当てることができることを意味します(ただし、これは理論上のものであり、たとえば、SATは546SATに設定されていましたが、後に序数のいずれか高い方に設定されていました)。

検証の問題

カラーコインの真正性と所有権を確認するには、資産のジェネシストランザクションから現在のUTXOまでを追跡し、検証する必要があります。 したがって、専用のウォレットとそれに付随するフルノード、さらにはブラウザを開発することが不可欠です。

マイナー検閲の潜在的なリスク

ColoredTransactionには、メタデータ情報を出力に書き込むという明確な特性があるため、マイナーによる検閲が行われる可能性があります。

カラーコインは本質的に資産追跡システムであり、ビットコインの検証ルールを利用して資産の転送を追跡します。 ただし、特定の出力(txout)が特定の資産を表すことを証明するには、資産の起源から現在までの転送チェーン全体が必要です。 つまり、取引の正当性を検証するには、長い証明の連鎖が必要になる場合があります。 この問題に対処するために、BTCでのカラーコイン取引の正確性を直接検証するOP_CHECKCOLORVERIFYの提案がありましたが、この提案は可決されませんでした。

暗号通貨業界で最初のICA:マスターコイン

マスターコインの最初のコンセプトは、J.R.ウィレットによって提案されました。 2012年、彼は「第2回ビットコインホワイトペーパー」というタイトルのホワイトペーパーを発表し、後に「マスターコイン」として知られるビットコインの既存のブロックチェーン上に新しい資産またはトークンを作成するという概念を説明しました。 その後、Omni Layerに改名されました。

Mastercoinプロジェクトは、2013年に最初のトークンセール(今日ではICOまたはイニシャルコインオファリングと呼ばれています)を実施し、数百万ドルの資金調達に成功しました。 これは史上初のICOと見なされています。 Mastercoinの最も注目すべきアプリケーションは、最も有名な法定通貨であるTether(USDT)で、当初はOmni Layerで発行されました。

実際、マスターコインの概念はカラーコインよりも前から存在していました。 ここで2番目に議論されている理由は、カラーコインと比較して、マスターコインは比較的複雑なソリューションであるためです。 マスターコインは完全なノードレイヤーを確立し、それによってより複雑な機能(スマートコントラクトなど)を提供しましたが、カラーコインはよりシンプルで直接的であり、主に他の資産を表すためにビットコインUTXOを「色付け」またはマーキングすることに焦点を当てていました。

カラーコインとの主な違いは、Mastercoinはチェーン上でさまざまな種類の取引動作のみを公開し、関連する資産情報を記録しないことです。 マスターコインノードでは、オフチェーンノードのビットコインブロックをスキャンすることで、状態モデルデータベースが維持されます。

カラーコインと比較して、Mastercoinはより複雑なロジックを実行できます。 また、チェーン上で状態を記録して検証を実行しないため、そのトランザクションは継続性(連続色付け)を必要としません。

しかし、Mastercoinの複雑なロジックを実装するには、ユーザーはノードのオフチェーンデータベースの状態を信頼するか、検証のために独自のOmni Layerノードを実行する必要があります。

要約すると:

MastercoinとColored Coinsの主な違いは、Mastercoinがプロトコルに必要なすべてのデータをオンチェーンで保持しないことを選択したことです。 代わりに、BTCのコンセンサスシステムを寄生的に使用して、オフチェーンデータベースで状態を維持しながら、独自のトランザクションの公開と順序付けを実装しました。

OmniBoltから提供された情報によると、 Omni Layerは、Taprootのアップグレードを利用して資産情報をTapleafにエンコードし、条件付き支払いなどの機能を可能にする新しいUBA(UTXO Based Asset)アセットプロトコルをTetherに提案しています。 一方、OmniBoltはStarkをOmniLayerのライトニングネットワークインフラストラクチャに導入しています。

クライアント側検証の概念

クライアント側の検証の概念を理解するには、カラーコインとマスターコインが登場した翌年、つまり2013年にさかのぼる必要があります。 同年、ピーター・トッドは「暗号コインマイニングの解脱:タイムスタンプ、プルーフ・オブ・パブリケーション、検証」という記事を発表しました。 この記事のタイトルはクライアント側の検証とは直接関係がないように見えますが、注意深く読むと、クライアント側の検証に関する最も初期の啓蒙的な考えが含まれていることがわかります。

ビットコインと暗号学の初期の研究者であるピーター・トッドは、ビットコインの運用をより効率的にする方法を常に模索してきました。 彼は、タイムスタンプの概念に基づいて、クライアント側の検証のより複雑な概念を開発しました。 また、後述する「使い捨てシール」という概念を紹介しました。

ピーター・トッドの考えに従って、まずBTC(ビットコイン)が実際に解決した問題を理解しましょう。 ピーター・トッドの見解では、BTCは3つの問題を解決しました。

プルーフ・オブ・パブリケーション

プルーフ・オブ・パブリケーションの本質は、二重支払いの問題を解決することです。 たとえば、アリスがボブに送金したいビットコインを持っているとします。 ボブに譲渡するトランザクションに署名しますが、ボブはトランザクションの存在を物理的に知らない場合があります。 したがって、誰もがトランザクションを照会できる、トランザクションを公開するための公開場所が必要です。

注文コンセンサス

コンピュータシステムでは、私たちが通常知覚する物理的な時間は存在しません。 分散システムでは、時間は多くの場合、物理的な時間を測定するのではなく、トランザクションを順序付けるLamportタイムスタンプで表されます。

検証 (オプション)

BTCの検証とは、署名とBTCの送金金額の検証を指します。 しかし、ここでピーター・トッドは、この検証はBTCの上にトークンシステムを構築するために必要ではなく、最適化オプションであると考えました。

この時点で、前述のOminilayerを思い浮かべるかもしれません。 Ominilayer自体は、状態の計算と検証をBTCに委任していませんが、BTCのセキュリティを再利用しています。 一方、カラーコインは、状態追跡をBTCに委任します。 両方の存在は、検証が必ずしもオンチェーンで行われる必要はないことを示しています。

では、クライアント側の検証では、どのようにトランザクションを効果的に検証するのでしょうか。

まず、何を検証する必要があるかを見てみましょう。

• 状態 (トランザクション ロジックの検証)

• 入力 TxIn の有効性 (二重支出を防ぐため)

BTCで発行された資産の場合、各トランザクションでは、参照されたインプットが使用されておらず、状態が正しいことを確認するために、関連するトランザクション履歴全体を検証する必要があることは明らかです。 これは非常に非効率的です。 では、どうすれば改善できるのでしょうか?

Peter Todd氏は、検証の焦点を変えることで、このプロセスを簡素化できると考えている。 このメソッドは、アウトプットが二重に使用されていないことを確認する代わりに、トランザクションのインプットがパブリッシュされ、他のインプットと競合していないことを確認することに重点を置いています。 各ブロックの入力を順序付け、マークルツリーを使用することで、各検証に必要なデータはごく一部で、その入力のチェーン履歴全体は必要ないため、このタイプの検証をより効率的に行うことができます。

ピーター・トッドは、コミットメント・ツリーの構造を次のように提案しました。

CTxIn -> CTxOut -><merkle path> -> CTransaction -><merkle path> -> CTxIn

しかし、そのようなコミットメントツリーをチェーンに保存するにはどうすればよいでしょうか? これは、使い捨てシールの概念につながります。

使い捨てシール

使い捨てシールは、現実世界で貨物輸送コンテナを保護するために使用される物理的な 1 回限りのシールと同様に、クライアント側の検証を理解するための中心的な概念の 1 つです。 使い捨てシールは、メッセージを一度だけ正確に閉じることができるユニークなオブジェクトです。 要するに、使い捨てシールは、二重支出を防ぐために使用される抽象的なメカニズムです。

SealProtocol には、3 つの要素と 2 つのアクションがあります。

基本要素:

1. L:シール、つまりシール
2. m:メッセージ、メッセージ
3. In:witness, witness (証人、証人)

基本操作: 次の 2 つの基本操作があります。

1. Close(l,m) → w: in messagemupper closing seall, generate a witnessIn。
2. 確認(l,w,m) → bool: 確認 seallAre you in the news?mis closed.

単独使用シールの実装は、セキュリティの観点から、攻撃者によって 2 つの異なるメッセージを見つけることができませんm1とm2、および検証関数が同じ sealtrueof.

まず第一に、シングルユースシールは、特定の資産またはデータが一度だけ使用またはロックされることを保証する概念です。 ビットコインのコンテキストでは、これは通常、UTXO(未使用のトランザクション出力)を一度だけ使用できることを意味します。 したがって、ビットコイントランザクションの出力は1回限りのシールと見なすことができ、この出力が別のトランザクションへの入力として使用される場合、シールは「破損」または「使用済み」になります。

BTCのCSV資産の場合、ビットコイン自体が1回限りの封印された「証人」として機能します。 これは、ビットコイントランザクションを検証するために、ノードがトランザクションへの各入力が有効で未使用のUTXOを参照していることを確認する必要があるためです。 トランザクションがすでに使用されているUTXOを二重に使おうとすると、ビットコインのコンセンサスルールとネットワーク全体の正直なノードがトランザクションを拒否します。

もっとシンプルにできますか?

使い捨てシール つまり、どのブロックチェーンもデータベースと見なされます。 特定のメッセージの約束を何らかの方法でこのデータベースに保存し、そのメッセージの消費済みまたは消費される予定のステータスを維持します。

はい、とても簡単です。

要約すると、クライアント検証済みアセットには次の特性があります。

1. オフチェーンデータストレージ:クライアントが検証した資産の取引履歴、所有権、その他の関連データのほとんどは、オフチェーンで保存されます。 これにより、オンチェーンのデータストレージの必要性が大幅に削減され、プライバシーの向上に役立ちます。
2. コミットメントメカニズム:資産データはオフチェーンに保存されますが、このデータへの変更または転送は、コミットメントを通じてオンチェーンに記録されます。 これらのコミットメントにより、オンチェーントランザクションはオフチェーンの状態を参照できるため、オフチェーンデータの整合性と改ざん防止性が確保されます。
3. オンチェーンの証人(必ずしもBTCではない):ほとんどのデータと検証はオフチェーンですが、クライアントが検証した資産は、オンチェーンに埋め込まれたコミットメントを通じて、基盤となるチェーンのセキュリティ(証明の発行、取引の順序付け)を利用することができます。
4. 検証はクライアント側で行われます: 検証作業のほとんどは、ユーザーのデバイスで行われます。 つまり、すべてのネットワーク・ノードが各トランザクションの検証に参加する必要はなく、関係する参加者のみがトランザクションの有効性を検証する必要があります。

アセットのクライアント側の検証を使用する場合、注意すべき点がもう 1 つあります。

オフチェーンで取引し、クライアントによって検証された資産を検証する場合、資産を保持している秘密鍵を提示するだけでなく、対応する資産の完全なメルケルパスの証明も提示する必要があります。

クライアントサイド検証(CSV)のパイオニア:RGB

RGBのコンセプトは、2015年以降、コミュニティで有名な人物であるGiacomo Zuccoによって提案されました。 イーサリアムの台頭とICOの急増により、ICOの前に、多くの人がマスターコインやカラーコインプロジェクトなど、ビットコインの外で物事をしようとしました。.

ジャコモ・ズッコは失望を表明した。 彼は、これらのプロジェクトはビットコインよりも劣っていると信じており、ビットコインにトークンを実装する以前の方法は不適切であると考えています。 その過程で、彼はピーター・トッドに会い、ピーター・トッドのクライアント側検証のアイデアに魅了されました。 その後、彼はRGBのアイデアを提案し始めました。

RGBと以前のアセットプロトコルの最大の違いは、前述のクライアント側のアセット検証の機能に加えて、チューリング完全コントラクト実行エンジンを実装するための実行VMも追加されていることです。 また、契約データのセキュリティを確保するために、スキーマとインターフェイスも設計されています。 スキーマはイーサリアムに似ており、コントラクトの内容と機能を宣言しますが、インターフェイスはプログラミング言語のインターフェイスと同様に、特定の機能の実装を担当します。

これらのコントラクトのスキーマは、RGB20やRGB21など、VMの実行時に期待される動作を超えない動作を制限する役割を担い、それぞれ代替性トークンと非代替性トークンのトランザクションに対するいくつかの制限を担当します。

RGBのコミットメントメカニズム:ペダーセンハッシュ

コミットメントメカニズムに関しては、RGBはペダーセンハッシュを採用しています。 その利点は、価値を開示せずにコミットできることにあります。 Pedersen Hash を使用してマークル ツリーを構築するということは、プライバシーが保護されたマークル ツリーを作成し、その中の値を隠すことができることを意味します。 この構造は、一部の匿名の暗号通貨プロジェクトなど、特定のプライバシー保護プロトコルで使用できます。 ただし、 Taproot Assetsとの比較で後述するCSVアセットには適していない場合があります。

RGBの仮想マシン設計:シンプルさからAluVMまで

RGBは、クライアント検証済みのアセットプロトコルを実装するだけでなく、チューリング完全仮想マシンの実行とコントラクトプログラミングにまで拡張することを目指しています。 RGBの初期設計では、Simplicityと呼ばれるプログラミング言語を使用すると主張していました。 この言語は、式の実行中に実行証明を生成することを特徴とし、そこに記述されたコントラクトを形式的に検証しやすくします(バグを回避するため)。 しかし、この言語の開発は理想的ではなく、最終的には困難に直面しました。 これは、その年のRGBプロトコルの困難な誕生に直接つながりました。 最終的に、RGBはマキシムが開発したAluVMの使用を開始し、初期のSimplicityと同様に、未定義の動作を回避することを目標としました。 新しいAluVMは、将来的には、現在Rustを使用しているContractumと呼ばれるプログラミング言語に置き換えられると言われています。

RGBのレイヤー2拡張方向:ライトニングネットワークかサイドチェーンか?

クライアントが検証した資産は、オフチェーンで安全に継続的な取引を行うことはできません。 クライアント検証済みアセットは、トランザクションの公開と順序付けを引き続き L1 に依存しているため、トランザクション速度は L1 監視のブロック生成速度によって制限されます。 つまり、RGBトランザクションが厳格なセキュリティ要件の下でビットコイン上で直接実行される場合、2つの関連するトランザクション間の時間は少なくとも10分(BTCのブロック時間)である必要があります。 間違いなく、このようなトランザクション速度は、ほとんどの場合、ほとんど受け入れられません。

RGBとライトニングネットワーク

簡単に言えば、ライトニングネットワークの原則は、取引に関与する2つの当事者がオフチェーンで一連の契約(コミットメント取引)に署名することです。 これにより、いずれかの当事者が契約に違反した場合、被害を受けた当事者は契約(コミットメント取引)をBTCに提出して決済し、資金を回収し、相手方にペナルティを科すことができます。 言い換えれば、ライトニングネットワークは、プロトコル設計とゲーム理論を通じてオフチェーントランザクションのセキュリティを確保します。

RGBは、自社に適した決済チャネルの契約ルールを設計することで、独自のライトニングネットワークインフラを構築することができますが、ライトニングネットワークの複雑さは極めて高く、このシステムの構築は容易ではありません。 しかし、それとは対照的に、Lightnling Labsは長年この分野を開拓しており、LNDは90%以上の市場シェアを持っています。

RGBのサイドチェーン:プライム

LNP-BPは現在RGBプロトコルを維持しており、マキシムは2023年6月に、顧客検証済みの資産拡張スキームであるPrimeと呼ばれる提案をリリースしています。 その中で、彼は既存のサイドチェーンとライトニングネットワークの拡張スキームは開発が複雑すぎると批判しました。 マキシムは、Primeの他に、NUCLEUSマルチノードLightningチャネルとArk/Enigmaチャネルファクトリなどの拡張方法があり、どちらも2年以上の開発期間が必要であると考えていることを示しました。 しかし、プライムはわずか1年で完了することができます。

Primeは、従来のブロックチェーン設計ではなく、クライアント検証用に設計されたモジュール式のプルーフパブリケーションレイヤーであり、4つの部分で構成されています。

1. タイムスタンプサービス:トランザクションシーケンスを最短10秒で決定します。

2. プルーフ: PMT 形式で保存され、ブロック ヘッダーと共に作成および公開されます。

3. ワンタイムシール:抽象的なワンタイムシールプロトコルで、二重支払いの保護を保証します。 ビットコインに実装された場合、現在のRGBデザインと同様にUTXOにバインドできます。

4. スマートコントラクトプロトコル:シャード化可能なコントラクト - RGB(交換可能)。

RGBトランザクションの確認時間の問題を解決するために、Primeはタイムスタンプサービスを使用してオフチェーントランザクションを迅速に確認し、トランザクションとIDをブロックにカプセル化します。 同時に、プライムのトランザクションプルーフは、PMTを介してさらにマージされ、チェックポイントと同様の方法でBTCに固定されます。

TaprootベースのCSV Asset Protocol: Taproot Assets

Taproot Assetsは、TaprootをベースにしたCSVアセットプロトコルで、ビットコインブロックチェーン上でクライアント検証済みのアセットを発行するために使用されます。 これらの資産は、ライトニングネットワークを通じて、即座に、大量に、低コストで取引することができます。 Taproot Assetsの中核は、ビットコインネットワークのセキュリティと安定性、およびライトニングネットワークのスピード、スケーラビリティ、低コストを活用することにあります。 このプロトコルは、ビットコインクライアント(BTCD)とライトニングネットワーククライアント(LND)の両方の開発を個人的に主導し、BTCを深く理解しているこの地球上で唯一の人物であるLightnling LabsのCTOroasbeefによって設計および開発されました。

Taprootトランザクションは、 Asset Scriptのルートハッシュのみを伝送するため、 ハッシュ自体が汎用的で、 任意のデータを表すことができるため、 外部のオブザーバーがTaproot Assetsに関係しているかどうかを識別することは困難です。 Taprootのアップグレードにより、ビットコインはスマートコントラクト(TapScript)の機能を獲得しました。 これに基づいて、 Taproot Assetsのアセットコーディングは、 ERC20やERC721に似たトークン定義を作成するのと似ています。 したがって、ビットコインは資産定義の機能だけでなく、スマートコントラクトを作成する機能も備えており、ビットコイン上のトークンスマートコントラクトインフラストラクチャの基礎を築きます。

Taproot Assetsのコーディング構造は以下の通りです。 [説明はここで終わり、 記事の次の部分では、 Taproot Assetsのコーディング構造の技術的な詳細を掘り下げる可能性が高いことを示しています。

画像: Lightning Labs CTO roasbeef

CSV(CoinSwap)資産プロトコルとして、Taproot AssetsはRGBと比較してより合理化されるように設計されています。 これらは、TaprootのアップグレードやPSBT(部分的に署名されたビットコイントランザクション)など、BTCエコシステムの現在の進歩を最大限に活用します。 アプリケーションの拡張性に関するTaproot AssetsとRGBの最も大きな違いは、実行VM(仮想マシン)にあります。 Taproot Assetsは、BTCが使用するネイティブVMと同じTaprootScriptVMを採用しています。 近年、BTCのインフラ研究の多くはTapScriptをベースにしています。 しかし、BTCのアップグレードのペースが遅いため、これらの調査はすぐには実施されておらず、Taproot Assetsはこれらの新しいアイデアの潜在的な実験場となっています。

Taproot AssetsとRGBの違いは?

1. トランザクション検証とライトノードとの親和性

サムツリーの実装により、 Taproot Assetsは高い検証効率とセキュリティを誇っています(検証とトランザクションは、トランザクション履歴全体をトラバースすることなく、保有証明だけで実行できます)。 対照的に、RGBがPedersenコミットメントを使用すると、インプットの効果的な検証が妨げられ、RGBはトランザクション履歴をさかのぼる必要があり、時間の経過とともに大きな負担になります。 また、Merkelのサムツリーの設計は、 BTC上に構築された以前のアセットプロトコルにはなかった機能である、 Taproot Assetsでのライトノードの検証を容易にします。

1. 実行仮想マシン

Taproot Assetsは、Taprootのアップグレード後に登場しました。 彼らは、ビットコインのポストTaprootアップグレードに固有のスクリプト実行エンジンであるTaprootScriptVMと、BTCのPSBTの変種であるvPSBTを利用しています。 Taproot Assetsのライトニングチャネルメカニズムが完成すると、現在のすべてのLNDインフラストラクチャと過去のLightning Labs製品をすぐに再利用できます(LNDは現在、ライトニングネットワークの90%以上を支配しています)。 最近のBitVMの提案もTaprootScriptに基づいており、理論的にはTaproot Assetsをサポートしています。 ただし、RGBのVMとバリデーションルール(SCHEMA)は自己完結型であり、比較的クローズドなエコシステムを形成しています。 RGBの開発は主にそのエコシステム内に限定されており、ビットコインエコシステムとの統合は思ったほど緊密ではありません。 例えば、RGBとTaprootのアップグレードの唯一の関係は、チェーンコミットメントデータをWitnessのTapLeafにエンコードすることです。

1. スマートコントラクト

RGBの現在の実装では、コントラクトとVMが非常に強調されています。 しかし、スマートコントラクトはまだTaproot Assetsに登場していません。 現在、RGBは、グローバルステートへの変更が個々のコントラクトシャード(UTXO)とどのように同期するか、また、総資産量を保証するだけのペダーセンコミットメントが他のステートとの改ざんをどのように検出するかを説明していません。 対照的に、Taproot Assetsは、よりシンプルな設計で、現在、資産残高のみを保管し、広範な状態ストレージがないため、スマートコントラクトの議論は時期尚早です。 しかし、Lightning Labsは、 Taproot Assetsが来年、スマートコントラクトの設計に注力することを示唆しています。

1. 同期ハブ

クライアント側の資産検証の基本原則から理解されるように、証明の保持は秘密鍵の保持と同じくらい重要です。 しかし、ユーザーのクライアント側で証明が失われた場合はどうなるでしょうか? Taproot Assetsでは、この問題は「ユニバース」を通じて対処できます。 ユニバースは、公的に監査可能なまばらなマークルツリーであり、1つ以上の資産をカバーしています。 従来のTaprootアセットツリーとは異なり、 UniverseはTaprootアセットをホストしません。 代わりに、1 つ以上の資産履歴のサブセットにコミットします。 RGBでは、この役割はStormが担い、P2Pを介してオフチェーンプルーフデータを同期します。 ただし、RGBの開発チームの歴史的な理由により、これらのプルーフ形式は現在互換性がありません。 RGBのエコシステムチームであるDIBAは、この問題を解決するために「カーボナード」を開発していると報じられていますが、進捗状況は不明です。

1. エンジニアリングの実装

ライトニングラボには独自のビットコインクライアント(BTCD)、ライトニングネットワーククライアント(LND)、および多数のウォレットライブラリ実装があるため、Taproot Assetsで使用されるすべてのライブラリは、タイムテスト済みです。 対照的に、RGBで使用されるほとんどのライブラリは自己定義であり、業界標準の観点から見ると、RGBの実装はまだ実験段階にあります。

BTC拡大の将来についての簡単な議論

議論が進むにつれて、アセットプロトコルのクライアント側の検証がプロトコル仕様の領域を超え、計算の拡張に向けて冒険していることが明らかになります。

多くの人々は、ビットコインが将来デジタルゴールドとして存在し、他のチェーンがアプリケーションエコシステムを作成すると信じています。 しかし、私は別の意見を持っています。 BTCフォーラムでの多くの議論に見られるように、それらはしばしばさまざまなアルトコインとその短命な存在を中心に展開します。 これらのアルトコインの急速な終焉は、資本とそれらを取り巻く努力を泡に変えます。 ビットコインの強力なコンセンサス基盤により、アプリケーションプロトコル用に新しいL1を構築する必要はありません。 私たちがする必要があるのは、ビットコインのこの堅牢なインフラストラクチャを活用して、より長期的な分散型世界を構築することです。

オンチェーン計算を減らし、オンチェーン検証を増やす

設計の観点から、ビットコインは早い段階でオンチェーン計算ではなく、検証中心の哲学(スマートコントラクトのチューリング完全性と状態)に焦点を当てることを選択しました。 ブロックチェーンは本質的に複製されたステートマシンです。 チェーンのコンセンサスがオンチェーン計算に基づいている場合、ネットワーク内のすべてのノードにこれらの計算を繰り返すことの理論的根拠とスケーラビリティを正当化することは困難です。 検証に重点を置く場合、オフチェーン取引の有効性を検証することが、BTCにとって最も適切な拡張戦略となる可能性があります。

検証はどこで行われますか? これは重要です

ビットコイン上のプロトコル開発者にとって、重要な検証にビットコインを使用する方法、さらには検証をオフチェーンに配置する方法、およびセキュリティスキームを設計する方法は、プロトコル設計者自身の問題です。 これらは、チェーン自体に関連付けるべきではありませんし、関連付ける必要もありません。 したがって、検証がどのように実装されるかは、BTCのさまざまな拡張戦略につながります。

バリデーション実装の観点では、3つの方向性があります。

1. 1.オンチェーンバリデーション(OP-ZKP)
2. OP-ZKPがTaprootScriptVMに直接実装されている場合、ZKP検証機能をBTC自体に統合し、決済プロトコルのいくつかのCovenant設計と相まって、BTCのセキュリティを継承するZk-Rollup拡張計画を作成することを意味します。 しかし、イーサリアムに検証コントラクトを展開するのとは異なり、BTCのアップグレードプロセスは遅く、このような特殊なアップグレードが必要なオペコードと相まって、それを困難にしています。
4. 2.セミオンチェーン検証(BitVM)
5. BitVM の設計は、通常のトランザクション ロジックを提供することを意図したものではありません。 また、Robin Linus氏は、BitVMの将来は、さまざまなサイドチェーンのための無料のクロスチェーン市場を作ることにあると指摘しました。 BitVMのアプローチは、これらの検証計算のほとんどがオンチェーンではなくオフチェーンで行われるため、セミオンチェーンと見なされます。 しかし、BTCのTaprootを中心に設計する重要な理由は、理論的にはBTCのセキュリティを継承し、必要に応じてTapScriptVMを計算検証に利用することです。 このプロセスでは、検証信頼チェーンも生成されます。 たとえば、'n' 個のバリデーターの 1 つが正直であれば十分です (オプティミスティック ロールアップに似ています)。
6. BitVMのオンチェーンコストは高いですが、ZKの不正防止を利用して効率を向上させることはできるのでしょうか? ZKの不正証明の実装は、ZKP検証をオンチェーンで実行する能力に基づいているため、OP-ZKPスキームのジレンマに戻るため、答えはノーです。
8. 3.オフチェーン検証(クライアントサイド検証、ライトニングネットワーク)
9. 検証は完全にオフチェーンで行われるため、前述のCSVアセットプロトコルとライトニングネットワークに戻ります。 以前の議論では、CSV設計では、共謀的な改ざんを完全に防ぐことはできないと指摘されました。 私たちにできることは、暗号技術とプロトコル設計を使用して、悪意のある共謀被害を制御可能な範囲に抑え、そのような行動を不利益にすることです。
10. オフチェーン検証の長所と短所は明らかです。 利点は、オンチェーンリソースの使用が最小限に抑えられることであり、拡張の大きな可能性を秘めています。 欠点は、BTCのセキュリティを完全に活用することがほとんど不可能であり、オフチェーン取引の種類と方法が大幅に制限されることです。 さらに、オフチェーン検証は、データがオフチェーンに保持され、ユーザーによって管理されることを意味するため、ソフトウェア実行環境のセキュリティとソフトウェアの安定性に対するより高い要件が要求されます。

拡張進化の傾向

現在、イーサリアムで人気のあるLayer2は、本質的にLayer1を使用してLayer2の計算効率を検証しています。 つまり、状態計算は Layer2 にプッシュダウンされますが、検証は Layer1 に残ります。 将来的には、同様に検証計算をオフチェーンに押し下げて、現在のブロックチェーンインフラストラクチャのパフォーマンスをさらに解き放つことができます。

免責事項：

1. この記事は[mirror]からの転載です。 すべての著作権は原作者に帰属します [Ben77]。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。