序文

BTCに基づく資産の発行は、常にホットな話題となっています。 2011年の初期のカラーコインから最近人気のあるオーディナルプロトコルまで、BTCコミュニティは一貫して新しいプレーヤーとコンセンサスを生み出すことができましたが、定着している人はほとんどいません。 しかし、Lightning Labsは、Taproot Assetsをベースにしたステーブルコインを開発するという野心的な計画を明らかにしました。 テザーはまた、ビットコインのレイヤー1でUSDTを鋳造するためにRGBプロトコルを利用すると発表しました。

これは、かつて有名だったOmniLayer(旧Mastercoin)が、もはやBTCエコシステムの最大のプレーヤーではないことを意味します。 また、クライアントサイド検証(CSV)アセットプロトコルは、すべての人のビジョンに入り始めています。 これらのプロトコルは、従来のビットコイン資産プロトコルの整合性を維持するだけでなく、スケーラビリティも向上させます。 しかし、ビットコインエコシステム内の一連の資産プロトコルは、適切な質問を提起します:それらは互いにどのように異なり、この状況の中でどのようにナビゲートし、機会をつかむべきですか?

この記事は、ビットコインの歴史の中で出現したさまざまな資産プロトコルの包括的なレビューを通じて読者を導くことを目的としています。 さらに、近い将来、ビットコインベースの資産プロトコルの進化の潜在的な軌跡を掘り下げようとしています。

カラーコイン

カラーコインのコンセプトは、2012年3月27日にeToroのCEOであるYoni Assia氏が、彼の独創的な記事「bitcoin 2.X(別名Colored bitcoin)」で初めて明確にしました。 この記事は、ビットコインの基盤となるテクノロジーは、HTTPがインターネットの場合と同じくらい基本的で完璧であると仮定しました。 そのため、Colored CoinsトークンプロトコルはBTCの上に設計されました。

Yoni Assiaは、このイノベーションを通じてBTC 2.0経済の創造を構想し、あらゆるコミュニティがこの方法で複数の通貨を生成できるようにします。 ビットコインの基盤技術を取引決済や二重支出の防止に活用することは、当時としては先駆的なアイデアでした。

カラーコインは、ビットコインブロックチェーン上で資産を発行するために設計されたプロトコルです。 これは、ビットコインの特定の部分を「色付け」して、他の資産を示すことによって動作します。 これらのマークされたビットコインは、元の機能を保持していますが、別の資産または価値も表しています。 しかし、差し迫った問題は、このアイデアがビットコインネットワーク上でどのように実現できるかということでした。

2014年7月3日、ChromaWayは、開発者向けのカラーコインの作成プロセスを大幅に簡素化するEnhanced Colored Coins Order-based Protocol(EPOBC)を開発し、大きな進歩を遂げました。 これは、ビットコイン Scriptの OP_RETURN 機能を採用した最初のプロトコルでした。

結果は次のようになります。

このような実装は非常に簡潔ですが、多くの問題ももたらします。

1. 代替可能性と最小結合価値の問題 着色コインのジェネシストランザクションで1000サットを結合することにより、その色付きコインの最小単位は1サットになります。 これは、理論的には資産またはトークンを最大1000ユニットに分割できることを意味します(ただし、実際には、ダスト攻撃を防ぐために低くなります。 たとえば、サトシの最小値はかつて546SATに設定されていましたが、Ordinalsの場合はさらに高くなります)。
2. バリデーションの課題 カラーコインの真正性と所有権を判断するためには、その取引履歴をジェネシストランザクションから現在のUTXOまでさかのぼって検証する必要があります。 したがって、専用のウォレット、フルノード、さらにはスキャナーを開発する必要があります。
3. マイナーの検閲リスクの可能性 ColoredTransactionには、出力にメタデータを書き込むなどの明確な特性があり、マイナーの検閲の可能性をもたらします。

カラーコインは基本的に、ビットコインの検証ルールを使用して資産の転送を追跡する資産追跡システムです。 ただし、特定の出力 (txout) が特定の資産を表していることを証明するには、資産の発行元からの転送チェーン全体を提供する必要があります。 つまり、トランザクションの有効性を検証するには、長いプルーフチェーンが必要になる場合があります。 これに対処するために、BTCで直接カラーコイン取引を検証するのに役立つ OP_CHECKCOLORVERIFY のような提案がなされましたが、提案は採用されませんでした。

暗号の最初のICO:マスターコイン

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

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

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

両者の主な違いは、ブロックチェーン上では、Mastercoinは様々な種類の取引行動のみを記録し、関連する資産情報を保存しないことです。 マスターコインのノードでは、ビットコインブロックをスキャンすることによって状態モデルのデータベースが維持され、このデータベースはブロックチェーン外のノードに存在します。

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

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

要約すると:

MastercoinとColored Coinsの主な違いは、Mastercoinはプロトコルに必要なすべてのデータをブロックチェーン上に保持していないことです。 代わりに、ビットコインのコンセンサスシステムに便乗して、独自のトランザクションの公開と順序を管理し、オフチェーンデータベースで状態を維持します。

OmniBoltが提供する情報によると、 Omni Layerは、Taprootのアップグレードを利用する新しいUBA(UTXO Based Asset)アセットプロトコルをTetherに提案しています。 このプロトコルは、資産情報をTapleafに埋め込み、条件付き支払いなどの機能を可能にします。 同時に、OmniBoltはStarkをOmni Layerのライトニングネットワークインフラストラクチャに統合することに取り組んでいます。

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

クライアントサイド検証(CSV)の概念を理解したい場合は、カラーコインとマスターコインが登場した翌年、つまり2013年にさかのぼる必要があります。 その年、初期のビットコインと暗号の研究者であるピーター・トッドは、「暗号コインマイニングのもつれを解く:タイムスタンプ、公開証明、および検証」というタイトルの記事を発表しました。 タイトルにはクライアントサイド検証について明示的に言及されていませんが、注意深く読むと、これがこの概念を導入した最も初期の文書の1つであることがわかります。

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

ピーター・トッドの考えに従うには、まずビットコインが実際にどのような問題を解決するかを理解する必要があります。 ピーター・トッド氏によると、ビットコインは3つの問題に対処しています。

1. プルーフ・オブ・パブリケーション:プルーフ・オブ・パブリケーションの本質は、二重支出の問題を解決することです。 たとえば、アリスがボブにビットコインを送金したい場合、ボブに送金するトランザクションに署名したにもかかわらず、ボブはそのようなトランザクションが存在することを物理的に知らない可能性があります。 したがって、トランザクションを公開するための公開場所が必要であり、誰もがそこからトランザクションを照会できます。
2. 順序のコンセンサス:コンピュータシステムでは、私たちが通常経験する物理的な時間は存在しません。 分散システムでは、時間は多くの場合、物理的な時間の尺度を提供するのではなく、トランザクションを順序付けるLamportタイムスタンプです。
3. 検証(オプション):ビットコインでの検証には、署名とBTCトランザクションで転送された金額の検証が含まれます。 しかし、ピーター・トッドは、この検証はビットコインの上にトークンシステムを構築するために必要ではないと考えています。これは単なる最適化オプションです。

ここで、前に説明した OmniLayer を思い出すかもしれません。 OmniLayer自体は、状態の計算と検証をビットコインに委任しませんが、ビットコインのセキュリティを再利用します。 一方、カラーコインは、状態の追跡をビットコインに委託します。 これら2つのシステムの存在は、検証が必ずしもブロックチェーン上で行われる必要はないことをすでに示しています。

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

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

1. 状態 (トランザクション ロジックの検証)
2. 二重支出を防ぐために、入力 (TxIn) が有効であることを確認します。

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

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

Peter Todd が提案したコミットメントツリー構造は、以下の通りです。

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

しかし、このようなコミットメントツリーをブロックチェーンに保存するにはどうすればよいでしょうか? そこで紹介するのが「使い捨てシール」という概念です。

使い捨てシール

使い捨てシールは、CSVを理解するための中心的な概念の1つです。 これは、貨物コンテナを保護するために使用される物理的な1回限りのシールに似ています。 使い捨てシールは、メッセージ上で一度だけ閉じることができる一意のオブジェクトです。 簡単に言えば、使い捨てシールは、二重支出を防ぐために使用される抽象的なメカニズムです。

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

基本要素:

1. L:シール
2. m: メッセージ (情報またはトランザクション)
3. W:証人、封印を確認できる人または何か

基本操作: 次の 2 つの基本的なアクションがあります。

1. Close(l, m) → w: メッセージ m のシール l を閉じ、証人 w を生成します。
2. Verify(l, w, m) → bool: メッセージ m でシール l が閉じられたかどうかを確認します。

単独使用シール実装のセキュリティは、攻撃者が Verify 関数が同じシールに対して true を返すような 2 つの異なるメッセージ m1 と m2 を見つけることができないことを意味します。

簡単に言うと、シングルユースシールは、特定の資産またはデータが一度だけ使用またはロックされることを保証します。 ビットコインのコンテキストでは、これは通常、UTXOが一度しか使用できないことを意味します。 したがって、ビットコイントランザクションの出力は使い捨てのシールと見なすことができ、出力が別のトランザクションの入力として使用される場合、そのシールは「壊れている」または「使用されている」です。

ビットコイン上の資産の場合、ビットコイン自体が使い捨てシールの「証人」(w)として機能します。 これは、ビットコイントランザクションを検証するために、ノードはトランザクションの各入力が有効で未使用のUTXOを参照していることを確認する必要があるためです。 トランザクションがすでに使用されているUTXOを二重に使おうとすると、ビットコインのコンセンサスルールと誠実なノードのネットワークはそのトランザクションを拒否します。

もっと簡単に言うと、

シングルユースシールは、ブロックチェーンをデータベースのように扱い、特定のメッセージへのコミットメントを保存し、そのステータスを未使用または未使用として維持します。

上記をまとめると、クライアント側の検証を使用するアセットには、次の特性があります。

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

クライアント側の検証でアセットを使用している場合は、次の点に注意してください。

オフチェーンでクライアント側の検証で資産を取引・検証する場合、資産を保持する秘密鍵を提示するだけでなく、対応する資産の完全なマークルパス証明を提供する必要があります。

CSVのパイオニアであるRGB

RGBのコンセプトは、2015年以降、コミュニティで有名な人物であるGiacomo Zuccoによって提案されました。 これは、イーサリアムが台頭し、ICO(イニシャルコインオファリング)が急増し、マスターコインやカラーコインなど、ビットコインを超えたプロジェクトを作成する多くの試みが行われた時期でした。

ジャコモ・ズッコはこれらの展開に失望した。 彼は、これらのプロジェクトのどれもビットコインの可能性と一致しておらず、ビットコインにトークンを実装する以前の試みは不十分であると信じていました。 この間、彼はピーター・トッドに出会い、クライアントサイド検証(CSV)に関するトッドのアイデアに魅了されました。 これがきっかけで、RGBのアイデアを提案しました。

クライアント側の検証を使用するアセットの前述の特性とは別に、RGBおよび以前のアセットプロトコルとの主な違いは、チューリング完全コントラクト実行用の実行VM(仮想マシン)の追加です。 コントラクトデータのセキュリティを確保するために、スキーマとインターフェイスが設計されました。 スキーマはイーサリアムと同様に、コントラクトの内容と機能を宣言し、インターフェイスはプログラミング言語のインターフェイスに似た特定の機能の実装を担当します。

これらのコントラクトのスキーマは、VM の実行中に期待を超える動作を制限する役割を担います。 たとえば、RGB20とRGB21は、それぞれトランザクション中に代替可能トークンと非代替性トークンに特定の制限を課す責任があります。

RGB、Pedersen Hashで使用されるコミットメントメカニズム

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

RGBのシンプルさを実現する仮想マシン設計 → AluVM

RGBは、クライアント側で検証されたアセットプロトコルを実装するだけでなく、チューリング完全な仮想マシンの実行とコントラクトプログラミングに拡張することも目指しました。 当初、RGBはSimplicityと呼ばれるプログラミング言語を使用しており、実行証明を生成し、そこに記述された契約の正式な検証(バグを回避するため)を可能にすると主張していました。 しかし、この言語の開発は計画通りには進まず、最終的にRGBプロトコル全体を妨げる複雑な問題を引き起こしました。 最終的に、RGBはマキシムが開発したAluVMと呼ばれるVMの使用を開始し、元のSimplicityと同様に、未定義の動作を回避することを目標としました。 新しいAluVMは、将来的にはContractumと呼ばれるプログラミング言語に置き換えられ、現在のRustの使用から離れると言われています。

RGBレイヤー2のスケーリング方向:ライトニングネットワークまたはサイドチェーン?

クライアント側で検証された資産は、トランザクションの公開と注文をL1に依存しているため、オフチェーンで安全に継続的に取引することはできません。 つまり、レイヤー 2 スケーリング ソリューションがない場合、トランザクション速度は L1 監視のブロック生成速度によって制限されます。 これは、RGBトランザクションが厳格なセキュリティ要件の下でビットコインで直接実行される場合、2つの関連するトランザクション間の時間は少なくとも10分間隔(BTCのブロック時間)である必要があり、これはしばしば許容できないほど遅いことを意味します。

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

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

RGBは、RGB自身に適した決済チャネル契約の詳細を設計することで、独自のライトニングネットワークインフラストラクチャを構築できます。 しかし、ライトニングネットワークは複雑性が高いため、特にライトニングラボのこの分野での長年の取り組みとLNDの90%以上の市場シェアを考えると、このようなインフラの構築は容易ではありません。

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

RGBプロトコルの現在のメンテナであるLNP-BPは、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 Assets Protocol: Taproot Assets

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

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

Taproot Assetsのエンコーディング構造は、以下の通りです。

by roasbeef, CTO of Lighting Labs (ライティング ラボ CTO)

また、CSVアセットプロトコルとして、Taproot AssetsはRGBと比較してより簡潔なデザインになっています。 アプリケーションのスケーラビリティに関するTaproot AssetsとRGBの最大の違いは、 実行VMにあり、 Taproot AssetsはBTCのネイティブデフォルトと同じTaprootScript VMを使用します。 近年、BTCのための研究の多くが 近年、BTCのインフラ研究はTapScriptをベースにしたものが多いですが、BTCのアップグレードが遅いため、短期間で適用することはできないため、Taproot Assetsは将来的にこれらの新鮮なアイデアの実験場になることが予想されます。

TaprootアセットとRGBの違い

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

Taproot Assetsは、サムツリーの実装により、高い検証効率とセキュリティを備えています。 これにより、取引履歴全体をトラバースすることなく、証明を所有するだけで状態の検証と取引を行うことができます。 対照的に、RGBはペダーセンコミットメントを使用しているため、インプットの妥当性を効果的に検証することが困難になっています。 その結果、RGBは入力のトランザクション履歴をさかのぼる必要があり、時間の経過とともにトランザクションが蓄積されるにつれて大きな負担になる可能性があります。 また、メルケルのサムツリーの設計により、Taproot Assetsは、以前はビットコイン上に構築されたアセットプロトコルでは利用できなかった機能であるライトノードの検証を簡単に促進することができます。

2. 実行VM

Taproot Assetsは、ビットコインネットワークのTaprootアップグレードに対応して開発されました。 これは、Taprootのアップグレード後にビットコインに付属するスクリプト実行エンジンであるTaprootScriptVMを利用しています。 さらに、ビットコインのPSBTの変種であるvPSBTを使用しており、Taproot Assetsのライトニングチャネルメカニズムが開発されると、LND(ライトニングネットワークデーモン)の現在のインフラストラクチャとライトニングラボの以前の製品(LNDは現在ライトニングネットワークで90%以上の市場シェアを保持しています)をすぐに再利用できることを示しています。 さらに、最近好評を博したBitVMの提案はTaprootScriptに基づいており、理論的には、これらすべての改善が最終的にTaproot Assetsに利益をもたらす可能性があることを意味します。

ただし、RGBの動作は多少異なります。 その仮想マシンと検証ルール(SCHEMA)は自己完結型システムの一部であり、やや閉鎖的なエコシステムを形成しています。 RGBは独自のエコシステム内で運営されており、より広範なビットコインエコシステムとの関係は、一部の人が考えるほど緊密ではありません。 例えば、Taprootのアップグレードに関して、RGBの唯一の実際の相互作用は、Witness TapLeafのブロックチェーンにコミットメントデータをエンコードすることです。 これは、RGBとTaprootのアップグレードが最小限の接続しか行われていないことを示しています。

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

RGBの現在の実装では、コントラクトとVMが非常に強調されています。 しかし、 Taproot Assetsでは、少なくとも今のところ、スマートコントラクトに焦点が当てられているようには見えません。 現在のRGB実装では、グローバルステートへの変更が個々のコントラクトシャード(UTXO)とどのように同期するかはまだ説明されていません。 さらに、ペダーセンのコミットメントは資産の総額を保証することができますが、これについてあまり説明されていないため、他の州が改ざんからどのように保護されるかは不明です。

一方、Taproot Assetsはよりシンプルな設計ですが、現在、資産残高のみを保存し、より複雑な状態を処理していないため、スマートコントラクトの議論は時期尚早です。 しかし、Lightning Labsによると、来年はTaproot Assetsのスマートコントラクト設計に注力する計画があるとのことです。

4. 同期センター

クライアント側で検証される資産に関する前述の基本原則は、証明を保持することが秘密鍵を保持することと同じくらい重要であることを示しています。 ただし、証明はクライアント側で保持されるため、紛失するリスクがあります。 これにどのように対処できますか? Taproot Assetsでは、 この問題は「ユニバース」を使用することで回避できます。 ユニバースは、1 つ以上の資産をカバーする、公的に監査可能な疎マークル ツリーです。 標準のTaprootアセットツリーとは異なり、ユニバースはTaprootアセットの保管には使用されません。 代わりに、1 つ以上の資産履歴のサブセットにコミットします。

RGBシステムでは、この役割はStormによって果たされ、ピアツーピア(P2P)ネットワークを介してオフチェーンプルーフデータを同期します。 ただし、RGB開発チームに関連する歴史的な理由により、これらのチームは現在、互換性のないプルーフ形式を使用しています。 RGBエコシステムチームであるDIBAは、この問題に対処するために「カーボナード」を開発することを示唆していますが、その進捗状況は不明です。

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

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

BTCスケーリングの将来について簡単に説明します

議論を続けると、クライアント検証済みの資産プロトコルが従来のプロトコルの範囲を超え、計算スケーリングに向かっていることが明らかになりました。

多くの人々は、将来、ビットコインは「デジタルゴールド」として存在し、他のブロックチェーンはアプリケーションエコシステムを作成すると主張しています。 しかし、私は別の意見を持っています。 ビットコインフォーラムでの多くの議論に見られるように、さまざまなアルトコインとそのつかの間の寿命について多くの話があります。 これらのアルトコインの急速な終焉は、それらを取り巻く資本と努力を泡に変えました。 私たちはすでにコンセンサスの強力な基盤としてビットコインを持っています。アプリケーション プロトコルのためだけに新しいレイヤー 1 (L1) ソリューションを構築する必要はありません。 私たちがすべきことは、この堅牢なインフラストラクチャであるビットコインを活用して、より長期的な分散型の世界を構築することです。

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

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

検証はどこで行われますか? これは非常に重要です。

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

検証ベースの実装の観点から、スケーリングには3つの方向性があります。

1.オンチェーン検証(OP-ZKP)

OP-ZKPをTaprootScriptVMに直接実装することで、ビットコイン自体にZKP検証を実行する機能が与えられます。 これは、いくつかのコヴナント設計決済プロトコルと相まって、ビットコインのセキュリティを継承するZk-Rollupスケーリングソリューションを作成する可能性があります。 ただし、イーサリアムに検証コントラクトを展開するのとは異なり、ビットコインのアップグレードは本質的に遅く、そのような特殊な、潜在的にアップグレードが必要なオペコードを追加することは困難になります。

2.セミオンチェーン(BitVM)での検証

BitVM の設計により、通常のトランザクション ロジックを対象としていないことが保証されます。 また、Robin Linus氏は、BitVMの将来は、様々なサイドチェーンのための無料のクロスチェーン市場を創出することにあると指摘しています。 BitVMのアプローチは、ほとんどの検証計算がオンチェーンではなくオフチェーンで行われるため、セミオンチェーンと見なされます。 ビットコインのTaprootを中心に設計する重要な理由は、理論的にはビットコインのセキュリティを継承し、必要に応じてTapScriptVMを計算検証に利用することです。 このプロセスでは、オプティミスティック ロールアップと呼ばれる 'n' 個の検証者のうち 1 人の誠実な検証者のみを必要とするなど、検証の信頼チェーンも生成されます。

BitVMはオンチェーンのオーバーヘッドを大量に消費しますが、ZKの不正防止を利用して効率を高めることはできるのでしょうか? ZKの不正証明の実装は、ZKP検証をオンチェーンで実行する能力に依存しているため、OP-ZKPアプローチの難しさに逆戻りするため、答えはノーです。

3.オフチェーンでの検証(クライアントサイド検証、ライトニングネットワーク)

完全なオフチェーン検証とは、前述のCSVアセットプロトコルとライトニングネットワークを指します。 これまでの議論で見たように、CSV設計における共謀を完全に防ぐことはできません。 私たちにできることは、暗号技術とプロトコル設計を使用して、悪意のある共謀による被害を制御可能な範囲内に抑え、そのような行動を不利益にすることです。

オフチェーン検証の長所と短所も同様に明確です。 利点は、最小限のオンチェーンリソースを使用し、スケーラビリティの大きな可能性を秘めていることです。 欠点は、ビットコインのセキュリティを完全に継承することはほとんど不可能であり、実行できるオフチェーントランザクションの種類と方法が大幅に制限されることです。 さらに、オフチェーン検証は、データがオフチェーンに保持され、ユーザー自身によって管理されることを意味するため、ソフトウェア実行環境のセキュリティとソフトウェアの安定性に対する要求が高くなります。

スケーリング進化の傾向

現在、イーサリアムの一般的なレイヤー2ソリューションは、パラダイムの観点から、レイヤー1を介してレイヤー2の計算を検証するため、状態の計算はレイヤー2にプッシュダウンされますが、検証はレイヤー1で保持されます。 将来的には、同様に検証計算をオフチェーン化し、現在のブロックチェーンインフラストラクチャのパフォーマンスをさらに解き放つことができます。

免責事項：

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