TAP の発展を目の当たりにする分離の第 3 段階は、ビットコインの 2.0 段階の到来を告げることになるのでしょうか?

原作者：Fu Shaoqing、SatoshiLab、Wanwudao BTC Studio

1.はじめに

「ビットコインの Segregated Witness テクノロジーと 3 つのバージョンアップを徹底解説」という記事を書き終えた後、私は深く考えるようになりました。

ビットコインは誕生以来、スケーリングとパワー強化の両方を模索してきました。TAP（Taproot Assets Protocol）の登場は、ビットコインのスケーリングとパワー強化のための強固なアーキテクチャ基盤と実現可能な道筋を築きました。現在、TAPは無限のデータ空間へのスケーリングを可能にしていますが、パワー強化も無限、すなわちチューリング完全性に到達できるのでしょうか？本稿では、理論的かつ実践的に探求可能ないくつかの道筋を分析します。ビットコインが完全なスケーリングとパワー強化を実現できれば、統一されたブロックチェーンのシナリオが生まれるでしょう。このプロセスは継続的で、長く、困難を伴い、集合知と実践的な経験を必要とします。この問題に関心のある皆様の議論と開発への参加を歓迎します。

2. 3回目の隔離で新たな扉が開かれた。

簡単な結論から始めましょう。3 番目の Segregated Witness によって開かれた新しい扉は、無限のデータ空間の利用可能性であり、これによりチューリング完全な仮想マシン (VM) の開発が可能になります。

まず、第 3 の Segregated Witness テクノロジによってもたらされた主な変更点を確認し、次に階層化プロトコルの観点から Bitcoin のさらなる発展を検討してみましょう。

2.1. TaprootAssets プロトコルはどのような基盤を築きましたか?

前回の記事「ビットコインのSegregated Witness技術とその3つのバージョンアップを徹底解説」では、OP_RETURNの初期の検討と、その後のSegregated Witnessの3つのバージョンアップについて解説しました。下の図をご覧ください。

Segregated Witness (SegWit) プロトコルの 3 回目のアップグレードでは、2 つの重要な変更が行われます。

1. 無制限のデータスペースを使用するため、拡張に関してはすでに限界に達しています。

2. アーキテクチャは BTCscript の VM を TAP の VM から分離し、将来の機能開発に適したアーキテクチャ基盤を構築します。

ビットコイン メインネットに影響を与えることなく、ビットコイン ネットワーク上でチューリング完全性を実現する可能性を独自に探究することが可能であり、この探究は段階的に実行することができます。

この記事では、ビットコインのスケーリングポテンシャルを分析します。TAPテクノロジーのサポートにより、ビットコインのスケーリングとパワーが共に究極の目標を達成できれば、ビットコインの広範な応用に向けた強固な基盤が築かれるでしょう。

2.2.ビットコインの開発には、階層化されたプロトコル設計アプローチが必要です。

ビットコインが世界的な影響力を獲得するには、幅広い応用シナリオと大規模なエコシステムの構築が不可欠です。このような大規模で複雑なシステムに対して、人類は既に関連する経験と方法論、すなわち階層化設計哲学を有しています。TCP/IPのようなプロトコルは、既に優れた応用例と貴重な教訓を提供しています。

私の記事「ビットコイン レイヤー2 構築の基礎に関する包括的な概要 (V2.0)」では、階層化プロトコルについてより詳細な説明をしています。階層化設計とは、人間が複雑なシステムを扱うための手法およびアプローチです。システムを複数のレイヤーに分割し、各レイヤー間の関係性と機能を定義することで、モジュール性、保守性、拡張性を実現し、システムの設計効率と信頼性を向上させます。

階層化プロトコルの利点:各層は独立しており、優れた柔軟性を提供し、構造的に分離可能で、実装と保守が容易で、標準化を促進します。

階層化モジュール設計は、複数の人々の連携と継続的な改善を必要とする大規模なエンジニアリングプロジェクトを扱う技術分野において、一般的なアプローチです。これは実証済みかつ効果的な手法です。TCP/IPプロトコルは、人類史上における大規模階層化プロトコルの成功例の代表例であり、インターネット全体がその上に構築されています。

未来のWeb3.0（価値のインターネットとも呼ばれる）は、ビットコインを第一層とするネットワーク上に構築されます。ビットコインの階層化設計コンセプトは既に初期の開発段階にあります。レイヤー2アーキテクチャの模索的な事例は既にいくつか存在し、代表的なものとしては、ブロックチェーンベースのレイヤー2、分散システムベースのレイヤー2（ライトニングネットワークなど）、そしてLNP/BPプロトコルに基づくRGBなどが挙げられます。RGBがBPプロトコルに基づく場合はレイヤー2アーキテクチャ、LNPプロトコルに基づく場合はレイヤー3アーキテクチャとなります。

しかし、今回のTAPによる変更は、階層化されたプロトコルというよりも、何かのバージョン1.0から2.0への進化に近いと言えるでしょう。これは、TAPプロトコルとビットコインのメインネットが非常に類似しており、密接に結びついているためです。これは以下の点からも明らかです。

1. データ構造に関して、TAPはメインネットと同じUTXO構造（vUTXO）を採用しています。これらのvUTXOの生成、転送、マージ、分割はビットコインメインネットと整合性があり、メインネットのUTXOとの分散スワップが可能です。SegWitのvByteからTAPのvUTXOに至るまで、これは同じ設計哲学の継承と発展です。

2. アドレスの種類と実行されるスクリプト命令の点では、TAPはビットコインメインネットと高い類似性を維持しており、そのアーキテクチャは拡張性も備えています。ビットコインメインネットで放棄された命令を復元できるだけでなく、必要に応じて新しい命令を追加することも可能です。さらに、これらの命令は別の仮想マシン（VM）内で実行されます。

3. ビットコインメインネットのコンセンサスプロトコルを使用しています。TAPはスケーラビリティとパワー拡張において多くのブレークスルーを達成していますが、独立したブロックチェーンや独立した外部システムではありません。すべての変更はビットコインメインネットのコンセンサスプロトコルの使用を必要とし、動作にはビットコインメインネットに依存する拡張機能です。

そのため、TAP関連の機能設計においては、TAPプロトコルを階層化プロトコル手法で捉え、組織的な分業体制を構築してきました。しかし、モノの進化という観点から、この変化をBTC2.0の発展と捉えることで、両者の密接な関係性や依存関係を維持しやすくなり、BTC2.0の開発に必要なリソースの調整・配置も容易になると考えています。

RGBプロトコルを上記の3つの観点から分析すると、違いが見えてきます。RGBプロトコルは特性1と特性2を完全に欠いており、ビットコインメインネットのコンセンサスプロトコルを使用している点のみが類似点です。このことから、RGBはビットコインメインネットの延長ではなく、完全に階層化されたプロトコルであることが分かります。

3. BTC 1.0とBTC 2.0

TAPプロトコルによってもたらされた大きな変化は、ビットコインの新たな発展のための強固な基盤と出発点となりました。前のセクションの分析で示したように、ビットコインのメインネットはTAPに大きく依存しています。この記事では、ビットコインのメインネットと、TAPの創設によってもたらされたビットコインネットワークの拡張と変化を区別するために、BTC1.0とBTC2.0という用語を使用します。

3.1.基本定義

ここでは、BTC1.0をビットコイン・メインネット上の開発と定義します。ビットコイン・メインネット上のすべての変更と探究はBTC1.0の範囲に含まれます。TAP技術の登場以前は、ほぼすべての探究はBTC1.0に基づいていました。これには、BTC1.0の特定の可能性を検証することを目的とした様々なビットコインフォークも含まれます。

BTC2.0は、ビットコインメインネット外、特にTAPのようなプロトコル（そして将来的には同様のプロトコルも）の探究として定義されます。このスコープはビットコインメインネットへの変更を伴いません。主にビットコインメインネット外におけるスケーリングとパワー強化の探究に焦点を当てていますが、ビットコインメインネットのコンセンサスプロトコルと基本機能に大きく依存しています。ビットコインメインネットとの関係は非常に密接であるため、独立した概念を用いてビットコイン開発から切り離すことは困難です。

3.2.区別する方法

BTC 1.0の開発原則は、分散化、耐検閲性、プライバシーなど、ビットコインメインネットの基本的な特性を維持し、ビットコインメインネットの安全で安定した運用を確保することです。この開発原則が明確に記述または明確化されていない場合は、階層化プロトコルの観点から、最下位プロトコルが備えるべき特性を検討する必要があります。最下位プロトコルの特性を考慮すると、命令を拡張してチューリング完全な計算を実現しようとするほとんどすべての試みは、BTC 1.0の開発原則に準拠していません。コンパイラの原則の観点から、仮想マシンを第2段階に進化させるすべての取り組み（状態分岐と条件分岐の導入）も原則に反しています。さらに、この標準から、ビットコインの歴史における命令の歴史的な枝刈りは、より厳格なBTC 1.0標準の維持を目的としてきました。

BTC2.0の開発原則は、BTC1.0の開発原則に反する、ビットコイン・メインネットに求められるあらゆる変更点を満たすことです。例えば、OP_CAT命令の拡張や、ビットコイン・メインネットをチューリング完全なシステムに発展させたいという願望などです。また、ビットコイン・メインネットには適さないスケーリングや電力増強の要件も、BTC2.0で実装可能です。

TAPプロトコルでは、空間は既に宇宙を通して無限に拡張されており、TAP-VMをチューリング完全なシステムに発展させるかどうかという問題のみが残っています。次のセクションでは、主にTAP-VMがチューリング完全なシステムに発展する可能性と、その段階について分析します。

注: TAP は TAP-VM を含む完全なプロトコルであるため、以下のコンテンツでは TAP という用語が使用されます。

• TAP がチューリング完全になるまでの段階。

TAP のチューリング完全性への進化を議論することは、プログラミング言語と仮想マシン設計のコア知識を必要とする非常に専門的なトピックです。コンパイラ理論とコンパイラ開発の歴史の観点から見ると、仮想マシン (VM) の非チューリング完全からチューリング完全への進化は、典型的には、単純なものから複雑なものへ、安全なものから強力なものへ、そして特殊なものから汎用的なものへと移行するプロセスを伴います。(この文はこの記事の中で何度か繰り返されます。)

コンパイラ原理の理論的分析から、仮想マシンは非チューリング完全からチューリング完全へと進化することは確かに可能です。ここで残る疑問はただ一つ、「TAPがチューリング完全なシステムへと進化する必然性はあるのだろうか？」という点です（この疑問については、この記事では議論しません）。

TAP をチューリング完全性まで開発する必要がある場合、その開発からどのようなプロセスと方法に従い、学ぶことができますか?

4.1.コンパイラ原理の観点から見たチューリング完全性

チューリング完全：あらゆる計算可能な問題を計算できる仮想マシンまたはプログラミング言語は、チューリング完全と呼ばれます。あらゆるチューリング計算可能な関数を計算できる計算システムも、チューリング完全と呼ばれます。チューリング完全な言語とは、その計算能力が万能チューリングマシンと同等であることを意味し、これは現代のコンピュータ言語が持つことができる最高の能力です。

計算可能性理論において、任意のデータを特定の順序で計算できるデータ操作規則（命令セット、プログラミング言語、またはセルオートマトン）の集合は、チューリング完全と呼ばれます。チューリング完全な命令セットを持つデバイスは、汎用コンピュータと定義されます。チューリング完全であれば、そのコンピュータデバイスは条件分岐（if文やgoto文）を実行し、メモリデータを変更することができます。チューリング完全性を示すものは、原始的なコンピュータをシミュレートする能力を持ち、最も単純なコンピュータでさえ最も複雑なコンピュータをシミュレートすることができます。すべての汎用プログラミング言語と現代のコンピュータの命令セットはチューリング完全であり（C++テンプレートもチューリング完全です）、メモリ制限の問題を解決できます。チューリング完全なマシンは無限のメモリを持つと定義されていますが、その命令セットは通常、特定の有限量のRAMでのみ動作するように定義されています。

仮想マシン（VM）を非チューリング完全からチューリング完全へと進化させるには、通常、複雑さ、セキュリティ、汎用性の向上というプロセスを経る必要があります。これには主に2つの問題が伴います。

1. なぜ非チューリング完全システムから始めるのか？安全性と信頼性のためです。非チューリング完全システムは、すべてのプログラムが必ず終了すること（停止問題は決定可能）と無限ループがないことを保証します。これは、スマートコントラクト、設定言語、テンプレートエンジンなどのシナリオにとって非常に重要です。

2. なぜチューリング完全性を追求するのか？表現力と機能性のためです。チューリング完全なシステムだけが、様々な複雑なロジックやアルゴリズムを実装でき、汎用的なプログラミングプラットフォームとなることができます。

したがって、VM が非チューリング完全からチューリング完全へと進化する過程は、本質的には、その設計目標を「絶対的なセキュリティと制御性」から「強力かつ汎用的」へと拡張するプロセスです。現代の VM の究極の目標は、この両方を同時に実現することです。つまり、チューリング完全性の強力な機能を提供しながら、独創的な設計によってセキュリティと制御性を最大限に高めることです。

4.2.非チューリング完全からチューリング完全へのVMの進化におけるいくつかの明確な段階

仮想マシン（VM）が非チューリング完全からチューリング完全へと進化するには、通常、複雑さ、セキュリティ、汎用性の向上というプロセスを経る必要があります。これは、以下の典型的な段階に要約できます。

1. フェーズ1: 純粋計算機（非チューリング完全）

機能: 基本的な式計算機能のみを備えており、ステートレスで制御フローがありません。

• 機能: 基本的な算術演算 (加算、減算、乗算、除算)、論理演算、ビット演算などをサポートします。各計算は独立しており、以前の状態に依存しない高度な計算機のように機能します。
• 状態がない: メモリの概念が存在しない、またはメモリが読み取り専用であり、変更できない。変数を定義または変更できない。
• 制御フローなし：条件分岐（if/else）、ループ（for/while）、ジャンプ命令はありません。命令は順番にのみ実行されます。
• チューリング完全ではない理由: ループや条件判断を実装できず、チューリング マシンの無限に長い紙テープや状態遷移をシミュレートできません。
• 歴史的な例: 最も初期の、非常に単純な構成または式評価エンジンの一部。

2. フェーズ2: 状態分岐と条件分岐の導入 (完全性に向けた重要なステップ)

機能: 変更可能な状態 (メモリ) と単純な条件判断が追加されましたが、真のループが欠けていました。

能力：

(1) 状態：スタック、レジスタ、ヒープなどの読み取り・書き込み可能なメモリを導入し、変数の定義と変更を可能にします。これにより、計算は分離ではなく履歴に依存します。

(2) 条件分岐：条件に基づくジャンプ命令（if_eq、if_lt、指定オフセットへのjmpなど）を導入します。これは論理的判断を実装するための鍵となります。

• なぜチューリング完全ではない可能性があるのか：VMの命令セットまたは設計が意図的に後方ジャンプを禁止している場合、つまり後続の命令へのジャンプ（前方ジャンプ）のみが可能である場合、ループを形成できません。ループがなければ、チューリング完全性に必要な「無限計算」の可能性は実現できません（物理的には有限ですが、理論的には無限です）。
• 歴史的/現代的な例：スクリプト言語であるBitcoin Scriptは、その黎明期における典型的な例です。無限ループによるネットワークのブロックを防ぐため、意図的にループを含まず、条件分岐と前方ジャンプのみで構成されるように設計されており、スクリプトの実行が有限のステップ数内で完了することを保証しています。

注：ビットコインのスクリプト言語は主にフェーズ1で機能し、フェーズ2の特徴を示す部分はごくわずかだと個人的に考えています。大まかに言えば、フェーズ1が90%以上、フェーズ2が10%未満を占めています。例えば、後にTaprootで導入されたMAST（メルケル抽象構文木）は、ビットコインのメインネットではうまく機能しませんが、TAPでは重要な役割を果たしています。その主な理由は、ビットコインのメインネットが仮想マシンをフェーズ1の能力の範囲内に維持することを目指していることです。

3. フェーズ3: ループまたは再帰を導入する（チューリング完全性を達成するため）

機能: ループ構造を形成する機能を提供します。

能力：

(1) 後方ジャンプ：ジャンプ命令で前の命令アドレスに戻ることができます。これにより直接ループを形成できます。

（２）ループ命令：専用のループ命令（ループなど）を用意する。

(3) 間接ジャンプ/関数呼び出し：関数呼び出しと再帰をサポートすることで、ループと同様の効果を実現できます。これは、再帰がループを同等に置き換えることができるためです。

• なぜこの時点でチューリング完全と言えるのでしょうか？条件分岐と後方ジャンプ／ループ／再帰を実行できるようになったことで、このVMは条件判断と繰り返し実行を実装できるようになります。理論的には、これら2つの側面を組み合わせることで、あらゆるチューリングマシンの計算プロセスをシミュレートでき、チューリング完全性を実現できます。
• 歴史的な例：ほぼすべての汎用言語（JVM、Python VM、.NET CLRなど）の仮想マシンは、汎用プログラミング言語を実行するように設計されていたため、当初からチューリング完全でした。その進化は、主にパフォーマンスとセキュリティ機能の強化に重点を置いてきました。

4. フェーズ4: チューリング完全性に基づく機能強化（セキュリティ、パフォーマンス、機能）

チューリング完全性が達成されると、VM 開発の焦点は計算能力ではなく、他の側面に移ります。

• パフォーマンス: JIT (Just-In-Time) コンパイル、AOT (Ahead-of-Time) コンパイル、最適化されたコンパイラ、より効率的なガベージ コレクション アルゴリズムを導入します。
• セキュリティ: 強化されたサンドボックス機構、ケイパビリティシステムの導入、そしてよりきめ細かなメモリ分離と制御。WebAssemblyは、線形メモリ、構造化された制御フロー、そしてサンドボックス環境によってセキュリティと決定論性を大幅に強化しながら、チューリング完全な機能を提供する優れた現代的な例です。
• 機能: コルーチン、async/await、ジェネリック、リフレクションなどの高度な言語機能をサポートします。
• 決定論: 一部のブロックチェーン仮想マシン (Ethereum EVM の後継など) では、チューリング完全性に基づいて、決定論 (すべてのノード間で一貫した結果) と終了 (ガス メカニズムを通じて実際の実行ステップを制限する) の追求に重点が置かれます。

コンパイラ原理の観点から見ると、VMの開発には4つの段階があります。この開発経路を参考にすると、TAPの開発にもいくつかの段階（つまり、BTC2.0の開発にもいくつかの段階）があることが大まかに分かります。

4.3. TAPの第一段階: 拡張BTCScript命令の簡単な探索

前述の通り、初期のビットコイン・メインネットの命令は、その能力を超えており、汎用仮想マシン（VM）の第二段階の能力に部分的に類似していました。これがその後の命令の簡素化につながりました。ビットコイン・メインネット上で合理化されたBTCScript命令は、現在、コンパイラ原則の第一段階の能力要件を満たしており、ビットコイン・メインネットのセキュリティと安定性を確保するために採用されています。

TAPはBTC 2.0の始まりであり、コンパイラ原理のフェーズ差別化の観点から、現在のTAP-VMは汎用VMの第2段階へと進化するはずです。この段階を探求する中で、TAP-VMはBTCScript命令を適切に拡張し、以前に削除されたBTCScript命令を復元することができます。例えば、OP_CATのような広く期待されている命令を段階的に追加するなどです。追加された命令ごとに、その機能とセキュリティをテストするためのアプリケーションが増えます。この段階では、TrustlessSwapのような単純な操作を実行できます。また、より汎用性の高いMASTツリーの使用など、Taproot技術のユースケースを増やすこともできます。

この段階では、シンプルな分散型取引、基本的なレンディング、基本的なステーキングといったBTCFiの基本的な機能が実現されるはずです。現在、これらの機能はTrustlessSwapとTapscriptの一部を通じて実現されています。

4.4. TAPの第2フェーズ：分散型BTCFi命令セットの構築

ほとんどの金融アプリケーションをサポートするTAP-VMの開発には、コンパイラ原理とアプリケーションの両方の観点から必要な追加命令を導出する必要があります。ただし、この段階ではチューリング完全である必要はありません。この段階では、レンディング、ステーキング、Mint StableCoin、そしてより複雑なスワップ機能といった一般的なBTCFiアプリケーションをサポートする必要があります。

この段階は、一般的なVMの第2段階に非常に近く、状態分岐と条件分岐の導入が必要になります。このような状態分岐と条件分岐は、MAST抽象構文木に導入されます。このようなMAST木はBTC 1.0のTaproot技術に既に存在していましたが、これらの条件文は、ビットコイン・メインネットのBTC-VMが独立したTAP-VMから分離された後に初めて、より効果的に機能するようになります。

4.5. TAPの第3段階：より豊富な命令セットと予備的なチューリング完全性

金融アプリケーションを超えてより複雑なアプリケーションをサポートするためのTAP-VMの進化は、TAP-VM上でのアプリケーションの駆動力に依存します。この段階では、徐々にチューリング完全性、あるいは予備的なチューリング完全性に近づいていきます。

コンパイラ原理の観点から見ると、このステージは汎用VMの第3ステージに相当し、ループや再帰といった機能を導入し、後方ジャンプや間接ジャンプ、専用のループ命令、さらには関数機能も実現します。第2ステージでサポートされる条件分岐機能と組み合わせることで、この時点でTAP-VMは理論的にはすべての計算をシミュレートでき、チューリング完全性を達成できます。あるいは、開発の性質上、チューリング完全性の初期段階に留まっているものの、複雑な機能を実行できる豊富な命令セットを既に備えている可能性もあります。

TAP-VMが現段階でチューリング完全性を達成したとしても、RGBのチューリング完全性とは依然として大きく異なります。これはC++とJavaのような言語の比較に似ています。より詳細な比較はセクション5.1で行います。

4.6. TAPの第4段階: 成熟したチューリング完全性 + 豊富なライブラリ

開発段階において、TAP-VMはチューリング完全性を達成しただけでなく、理論上すべてのアプリケーション機能を網羅できる豊富なクラスライブラリ（または関数ライブラリ）を備え始めており、比較的豊富なアプリケーションサンプルも提供しています。豊富なアプリケーションサンプルとクラスライブラリのサポートにより、開発者はより多くのアプリケーションをより容易に開発できます。

汎用VMプロジェクトの第4フェーズと同様に、現段階のTAP-VM開発の焦点はもはやコンピューティング能力ではなく、パフォーマンス、セキュリティ、決定論といったより高度な仮想マシン指標に移っています。これはかなり遠い将来のプロセスなのでしょうか？

開発段階において、TAPの強力な機能により、RGBとの重複部分が大きくなっています。多くのアプリケーションはTAPとRGBのどちらを使用しても実装可能です。この重複部分は主に金融アプリケーション、特にビットコインメインネットで発行される資産に集中しています。しかしながら、より広範なアプリケーションシナリオにおいては、TAPとRGBには依然として大きな違いがあります。これらの違いについては、次のセクションで分析します。

5.チューリング完全なシステムには、さまざまなアプリケーション シナリオもあります。

BTC エコシステムでは、主に 2 つのチューリング完全システム (TAP と RGB) の比較を参照し、さまざまなアプリケーション シナリオにどちらが適しているかを示します。さらに、TAP のアプリケーション シナリオを示します。

Web2分野での経験と仮想マシン（VM）に関する豊富なデータに基づき、C/C++開発言語とランタイム環境は、Java開発言語とランタイム環境と適切に比較できます。この比較は、TAPとRGBの比較と同様に、いくつかの貴重な知見をもたらします。

5.1. C/C++とJavaのアプリケーションシナリオの比較

コア機能比較表

アプリケーションシナリオの概要

1. C/C++の領域（ハードウェアの直接的な操作や極めて高いパフォーマンスを必要とする）

（１）システムレベルのソフトウェア／インフラ開発

• オペレーティング システム (Linux、Windows カーネルなど)
• データベース管理システム（MySQL、PostgreSQLなど）
• コンパイラ/インタープリタ (GCC や JVM など) は実際には C++ で書かれています。
• Web サーバー / 高性能ネットワーク フレームワーク (Nginx、Node.js 基盤レイヤーなど)

（２）ハードウェアドライバと組み込みシステム

• デバイス ドライバー: ハードウェア レジスタとの直接のやり取りが必要です。
• 組み込み/モノのインターネット (IoT) デバイス: リソースが非常に制限されており (マイクロコントローラ MCU など)、メモリと電力消費を正確に制御する必要があり、JVM のオーバーヘッドを許容できません。

（３）高性能コンピューティングとゲーム開発

• ゲーム エンジン (Unreal や Unity の基盤システムなど) は、複雑なグラフィックスや物理計算を実行するためにハードウェアのパフォーマンスを最大限に活用する必要があります。
• 科学計算/金融取引システム: マイクロ秒レベルの遅延も重要です。
• グラフィック/画像/オーディオ/ビデオ処理: Photoshop、FFmpeg など。

（4）メモリとリソースのきめ細かな制御を必要とするシナリオ

シナリオによっては、手動のメモリ管理の方がガベージ コレクションよりも予測可能であり、GC によって発生するレイテンシ ジッターを回避できます。

2. Javaの本拠地（高い開発効率、クロスプラットフォームの互換性、エンタープライズグレードの信頼性が求められる）

（1）大規模エンタープライズアプリケーションのバックエンド開発

• Web アプリケーション バックエンド: Spring Boot フレームワークは、大規模で分散された高同時実行バックエンド サービスの構築に使用される、Java エンタープライズ開発の絶対的なリーダーです。
• マイクロサービス アーキテクチャ: Java および JVM に基づく多数のマイクロサービス フレームワーク (Spring Cloud など)。
• 分散システム: ビッグデータ分野の Hadoop や Kafka など。

（2）Androidアプリケーション開発

Android の歴史的な公式の優先言語 (現在は Kotlin が優先言語ですが、基礎となるコードとエコシステムの大部分は依然として Java です)。

（３）ビッグデータとクラウドコンピューティング

Hadoop、Spark、Flink などのビッグデータ処理フレームワークのコア コンポーネントは、ほとんどが Java または Scala (JVM 言語) で記述されています。

（4）高い信頼性と長いライフサイクルを必要とするシステム

銀行、金融、電子商取引などのコアシステムでは、堅牢性、セキュリティ、強力なコミュニティ エコシステムのサポートが重要です。

（5）クロスプラットフォームデスクトップアプリケーション

Web ほど普及していませんが、Swing/JavaFX はクロスプラットフォームの GUI プログラムの開発に使用できます。

3. どうやって選ぶの？

• C/C++ を選択する場合:

パフォーマンスは絶対に最優先事項です (ゲーム、取引システム)。

オペレーティング システムまたはハードウェア (ドライバー、組み込みシステム) と直接対話する必要があります。

リソースは非常に限られており、JVM のメモリと CPU のオーバーヘッドに耐えられません。

プログラムの動作 (メモリ レイアウト、実行フロー) を完全に制御する必要があります。

• Java を選択する場合:

大規模で複雑なエンタープライズ アプリケーション (Web バックエンド、マイクロサービス) を開発する必要があります。

最終的なパフォーマンスよりも、開発効率、保守性、チームワークの方が重要です。

強力なクロスプラットフォーム機能が必要であり、プラットフォームごとに個別にコンパイルする必要はありません。

メモリ管理エラーを回避し、オープンソース ライブラリとフレームワークの豊富なエコシステムを活用したいと考えています。

このプロジェクトでは、高い信頼性と長期にわたる安定した運用が求められます。

つまり、C/C++ はハードウェア層やオペレーティング システム層などの下位レベルでの作業に適しており、Java はビジネス層やアプリケーション層での作業に適しています。

5.2. TAPとRGBのアプリケーションシナリオの比較

コア機能比較表（今後、皆様のご協力を得て、この比較表を徐々に改善していきたいと考えています）。

アプリケーションシナリオの概要（TAP-VMはまだ完全には開発されておらず、RGBのアプリケーション事例は多くないため、以下はすべて特性に基づく推測です）

1. TAPの本拠地（ビットコインの特性を持つ基本機能が必要）

（１）現金モデルにおける資産発行

（２）ビットコインネットワーク上のBTCFi

（３）分散型基盤プロトコル

2. RGBのホームグラウンド（ほぼすべてのDappタイプに適しています）

（１）ビットコインネットワーク上のスマートコントラクトアプリケーション

（２）より高度で複雑な資産発行とDeFiアプリケーション

（３）分散型アイデンティティやDAOガバナンスなどの高レベルWeb3アプリケーション。

(4) その他のWeb3アプリケーション

3. どうやって選ぶの？

• TAP-VMを選択:

Bitcoin UTXO との直接的なやり取り。

キャッシュモデル資産の発行。

Bitcoin スクリプト タイプの機能を直接拡張します。

分散型ビットコイン金融アプリケーション。

• RGBを選択:

複雑なロジックを必要とするスマート コントラクト。

より高度で複雑な DeFi。

非金融 Web3 アプリケーション。

要約すると、TAP-VM は Bitcoin メインネット上のアプリケーション、または Bitcoin メインネットに基づくアプリケーションの直接的な拡張に近いです。一方、RGB は、ユーザー層に近い複雑なロジック機能を持つアプリケーションに適しています。

6. BTC 2.0 をより良く開発するにはどうすればよいでしょうか?

このセクションは、主に著者の過去の業務やプロジェクトエンジニアリングの経験に基づく主観的な判断に大きく依存しています。そのため、不備や偏りが含まれている可能性があります。著者は、特にこの分野で製品開発に携わった方々からのフィードバックをいただき、これらの予測と判断をより洗練させていきたいと考えています。

これまでの議論に基づいて、ビットコインを BTC1.0 フェーズと BTC2.0 フェーズに分けることができれば、いくつかの明らかな利点がもたらされるでしょう。

6.1.明確な分業と標準化された手順

この段階的な分割のもう一つの利点は、労働と責任の分担が明確になることです。

1. 判断と意思決定の原則が確立されることで、設計者はBTC 1.0の原則に準拠した機能をビットコインメインネットに、またBTC 2.0の設計原則に準拠した機能をTAPプロトコルに組み込むことが容易になります。これにより、紛争が減少するだけでなく、組織間の連携も強化されます。

BTC2.0 は、コンパイラの原理や他の成熟した製品の開発プロセスを参照して、TAP の開発の段階的な計画をより明確にすることもできます。

2. 一部のプロトコルや標準は、より適切な名称が付けられ、審査基準も確立されています。例えば、TAPの7つのプロトコルは現在、以下のように命名されています。

• BIP-TAP-ADDR：Taproot Asset On Chainアドレス草案
• BIP-TAP-MS-SMT：マークル和スパースマークル木ドラフト
• BIP-TAP-PROOF：Taproot アセットフラットファイルプルーフフォーマットドラフト
• BIP-TAP-PSBT：Taproot Assets PSBT ドラフト
• BIP-TAP-UNIVERSE: Taproot アセットユニバース ドラフト
• BIP-TAP-VM: Taproot アセット スクリプト v1 ドラフト
• BIP-TAP：TAP: Taproot Assets Protocol ドラフト

BTC2.0 の分類方法がすべての人に受け入れられれば、BIP2 で始まる名前が付けられることは間違いありません。

• BIP2: Taproot Asset On Chainアドレス草案
• BIP2: TAP マークルサム スパース マークルツリー ドラフト
• BIP2: Taproot アセットフラットファイル証明フォーマットのドラフト
• BIP2: Taproot Assets PSBT ドラフト
• BIP2: Taprootアセットユニバースドラフト
• BIP2: Taproot アセット スクリプト v1 ドラフト
• BIP2: TAP: Taproot Assets Protocol ドラフト

6.2.リソース統合と再編計画

現在、ビットコインのメインネットは主にビットコインコアチームによって管理されています（2025年6月現在、ネットワーク全体の90%がビットコインコアを使用しています）。TAPプロトコルはライトニングネットワークラボによって管理されています。

Bitcoin Coreソフトウェアは15年以上稼働しており、そのコア機能は比較的安定しています。今後、大幅な機能追加が必要となるシナリオは多くなく、大規模な変更が必要な場合でも、TAPプロトコルで発生する可能性が高いでしょう。TAPプロトコルはまだ開発の初期段階にあり、計画通りに進んだとしても、長い道のりが待ち受けており、多大な開発リソースが必要になります。既存の開発リソースを効果的に再利用することで、BTC 2.0の開発が大きく促進されます。さらに重要なのは、ビットコインメインネットの開発者は、開発環境やプログラミング言語の面でTAPの開発と多くの類似点を共有しており、主な違いは開発ガイドラインの変更のみであるということです。

TAPは現在ライトニングネットワーク全体ではなく、その中の1つのプロトコルであるため、これは間違いなく大きな課題となるでしょう。TAPを独立したBTC 2.0プロジェクトとして開発できるかどうか、そしてその開発とリソースをどのように統合するかについては、相当な調整が必要となるでしょう。

TAPが実際にBTC 2.0へと進化するのであれば、ビットコイン・メインネット・プロジェクト（BTC 1.0）、新しいBTC 2.0、そしてライトニング・ネットワークは、それぞれ比較的独立しつつも密接に連携した3つのプロジェクトとなるでしょう。BTC 2.0はライトニング・ネットワークとの機能統合がより深まり、BTC 2.0の新機能に基づいてライトニング・ネットワークもより発展していくでしょう。

6.3.開発と競争

第5章では、TAPと直接の競合相手との比較において、いくつかの特徴について説明しました。これは、BTC 2.0と外部階層化プロトコルとの比較とも言えます。現開発段階では、RGBとTAPは、資産発行、資産取引、そしてより広範なBTCFiエコシステムといったいくつかの分野で、大きな直接的な競争に直面することになります。TAPはビットコインメインネットに密接に関連する分野で多くのプロトコルを凌駕していますが、TAPがフェーズ1の開発を迅速に完了できない場合、チューリング完全なRGBが最初にこの分野を支配するでしょう。RGBがビットコインメインネットのコンセンサスプロトコルに依存しているだけでも、その機能性は魅力的であるため、無数のビットコインネイティブ愛好家を魅了するのに十分です。TAPがフェーズ2の開発を完了できなかったり、遅れをとったりした場合、RGBにも遅れをとることになります。

TAPはBTC 2.0へと進化するのでしょうか？その開発プロセスはどのようなものになるのでしょうか？最終的な形は多くの外部要因に左右されます。ビットコイン分野におけるこうした潜在的な発展は、想像を絶するほどの困難と課題に満ちていますが、そのプロセスに関わらず、TAPは私たちに新たな扉を開いてくれました。

結論として、TAPがBTC 2.0の開発を象徴するのであれば、「TaprootAssets Protocol」という名称はあまりにも具体的で、現状を象徴しすぎているのではないでしょうか。BTC 2.0の開発をより適切に表す別の名称に変更すべきではないでしょうか。

参考文献

注記：この記事はTAPに関する包括的な予測と分析を提供するため、内容の多くは一般的な知識の要約であり、特定の記事に特化したものではありません。この記事の一部にはAIアシスタントが活用されており、その正確性は記事に組み込む前に著者の業界経験に基づいて判断されています。これには、C/C++とJavaのアプリケーションシナリオの比較も含まれます。

コンパイラの原則に関するセクションでは、大学のコンピュータサイエンス プログラムの教科書の資料や、散在するオンライン記事が参照されました。

その他の関連記事は以下の通りです。

1. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki 、Taproot Assets Protocol に関連する 7 つのプロトコル。

2. ビットコインの分離証人技術とその3つのバージョンアップの徹底的な理解

3. 「ビットコイン レイヤー2 構築の基礎に関する包括的な概要 (V2.0)」