第三次隔離見證TAP的發展是否會將比特幣帶入了2.0階段

原文作者：付少慶，SatoshiLab，萬物島BTC 工作室

1.前言

當我寫完了《徹底理解比特幣「隔離見證」技術與它的三個版本升級》那篇文章，引起了我的深度思考。

比特幣從誕生以來就一直在擴容與擴能兩個方向上不斷探索。直到TAP（TaprootAssets Protocol）協議的出現，應該是為比特幣的擴容與擴能打下了堅實的架構基礎與可行路線。目前TAP 可以讓擴容發展到無限資料空間，那麼擴能是否也可以達到無限，也就是圖靈完備呢？我們從理論和現實可以探索的路徑上做一些分析。如果比特幣可以實現完全的擴容與擴能，那麼萬鏈歸一的情況就會出現。這個過程會是持續、漫長、且充滿挑戰的，需要眾人的智慧與實踐。歡迎有興趣的朋友一起討論這個問題，並參與其中的建設。

2.第三次隔離見證打開了新大門

先給一個簡單的結論：第三次隔離見證打開的新大門是，可以使用的無限資料空間，可以發展出圖靈完備的虛擬機器VM。

我們先回顧第三次隔離見證技術產生的重要變化，再從分層協議的角度看待比特幣的進一步發展。

2.1. TaprootAssets 協定打下了哪些基礎？

從我寫作的上一篇文章《徹底理解比特幣「隔離見證」技術與它的三個版本升級》中，可以看到早期的OP_RETURN 探索，以及後面的三次隔離見證版本變化。如下圖所示：

我們將看到隔離見證的第三次升級TAP 協議產生了兩個重要的變化：

1. 已經在擴容上可以達到極限－使用無限的資料空間。

2. 在架構上將BTCscript 的VM 與TAP 的VM 進行了分離，這為未來功能的發展打下了良好的架構基礎。

可以在不影響比特幣主網的情況下，獨立的探索在比特幣網路上實現圖靈完備的可能性，並且這種探索可以循序漸進的方式進行。

本文會沿著比特幣的擴能可能性進行分析，如果在TAP 技術的支援下，比特幣的擴容與擴能都可以達到終極目標，就會為比特幣的廣泛應用打下堅實的基礎。

2.2.比特幣的發展需要分層協議設計思想

比特幣如果想要有全球的影響力，那麼它一定要有龐大的應用場景，形成一個龐大的生態。對於這樣的大型系統與複雜系統，我們人類已經有相關的經驗與方法論，也就是分層設計思想。如TCP/IP 這樣的協定中，已經有非常好的應用案例與參考經驗。

在我寫作的《一文梳理比特幣二層（Layer2）建設的基礎知識體系V2.0 版》文章中有對分層協議的更詳細描述。分層設計是一種人類處理複雜系統的手段和方法論，透過將系統劃分為多個層次結構並定義各層之間的關係和功能，以實現系統的模組化、可維護性和可擴展性，從而提高系統的設計效率和可靠性。

協議分層的優點：各層級之間是獨立的、彈性好、結構上可分割開、易於實現和維護、能促進標準化工作。

分層模組化設計思想是技術領域對待一項功能龐大，需要多人協作，並不斷改進工程項目的常見處理方法，並且是經過實踐檢驗，行之有效的方法。人類歷史上成功的大型分層協議代表是TCP/IP 協議，它使得整個互聯網都在這個協議基礎上建立。

未來web3.0（也可以成為價值互聯網）將會在比特幣為一層網路的基礎上建立。比特幣的分層設計思想已經有了初步的發展。現在已經有了多種探索的二層案例，其中典型的是基於鏈的二層和基於分散式系統的二層（如閃電網路），還有基於LNP/BP 協定的RGB，當RGB 基於BP 協定時，它是一個二層，當RGB 基於LNP 協定時，它是一個三層。

但這次TAP 給帶來的變化，並沒有那麼像分層協議，更像是事物的1.0 與2.0 的發展。原因是TAP 協定和比特幣主網是如此的相似與連結緊密，表現為以下幾點：

1. 在資料的結構上TAP 也採用和主網一樣的UTXO 結構，稱為vUTXO。這些vUTXO 的創建、轉移、合併、分割都與比特幣主網保持一致，並且可以與主網的UTXO 進行去中心化的Swap。從SegWit 中的vByte，到TAP 中的vUTXO，是同一種設計思想的延續發展。

2. 在位址類型和執行的腳本指令方面，TAP 也與比特幣主網保持高度的相似性，並且架構上留下了擴展的空間。不僅可以恢復比特幣主網放棄的指令，還可以根據需求增加新指令。並且這些指令在一個獨立的虛擬機器VM 中執行。

3. 使用比特幣主網的共識協議。 TAP 雖然在擴容與擴能上做出了很多突破，但它並不是一個獨立的區塊鏈，也不是一個獨立的外部系統，它的所有變化需要使用比特幣主網的共識協議，是依靠比特幣主網運行的擴展部分。

所以在設計TAP 相關的功能時候我們採用分層協議的方法論來看待TAP 協議和處理組織分工，但從事物進化的角度，我們將這次變化看待成BTC2.0 的發展會更容易保持兩者之間的緊密關係和依賴關係，而且容易協調與安排BTC2.0 發展需要的資源。

如果從上面的三個角度分析RGB 協議，我們可以看到明星的差異。 RGB 協議完全不具有1，2 兩個特點，只有在使用比特幣主網的共識協議方面有相似性，這決定了RGB 是一個完全的分層協議，而不是比特幣主網的延續發展。

3. BTC1.0 與BTC2.0

TAP 協議帶來的巨大變化，為比特幣的新發展提供了一個很好的基礎與開端。從上一節的分析，可以看出比特幣主網與TAP 的緊密依賴關係，在本文中我使用BTC1.0 與BTC2.0 來區分比特幣主網，以及TAP 產生後帶來比特幣網路的擴展變化。

3.1.基礎定義

這裡我們將BTC1.0 定義成在比特幣主網上的發展，所有在比特幣主網上的變更與探索都是BTC1.0 的範圍。在TAP 技術出現之前，幾乎所有的探索都是基於BTC1.0 的探索。包括比特幣的各種分叉鏈，也是為了驗證BTC1.0 的某些可能性。

BTC2.0 定義為在比特幣主網之外，特別是像TAP 這樣協議的探索（也許以後還會有其他類似的協議）。這個範圍不涉及比特幣主網的變動，主要是在比特幣主網之外，進行的擴容與擴能的探索，但又非常依賴比特幣主網的共識協議與基礎特徵，它與比特幣主網關係極其緊密，很難用獨立的概念來劃分出去的比特幣發展。

3.2.如何區分

BTC1.0 的發展原則是維持比特幣一層主網的基礎特性，如去中心化能力，抗審查能力，隱私性等，確保比特幣主網安全穩定的運作。如果從這個發展原則沒有描述清楚或明顯區分，要從分層協議的角度看最底層協議應該具有的特性。從最底層協議的特點考慮，幾乎所有期望擴充指令，完成圖靈完備的計算都不符合BTC1.0 的發展原則。也可以從編譯原理的角度，看所有期望將一個虛擬機器發展到第二階段（引入狀態和條件分支）等努力都是不符合原則的。並且從這個標準來看，比特幣史上的刪減指令，就是維持更嚴格的BTC1.0 標準。

BTC2.0 的發展原則是滿足所有想在比特幣一層主網上期望做的改動需求，但又違反BTC1.0 發展原則的部分。例如，擴展OP_CAT 指令；期望把比特幣主網發展成圖靈完整的系統等需求。也可以描述成所有不適合在比特幣主網做的擴容與擴能需求，都可以在BTC2.0 發展。

在TAP 協定中，已經透過universe 將空間擴充到了無限，那麼只剩下是否將TAP-VM 發展成圖靈完備這個問題。在下一節內容中我們主要分析TAP-VM 發展成圖靈完備的可能性與可能分成哪幾個階段。

註：TAP 是一個完整的協議，包括TAP-VM，所以後續內容都使用TAP 這個字。

• TAP 發展成圖靈完備的幾個階段

討論TAP 要發展成圖靈完備是一個非常專業的問題，它涉及了程式語言和虛擬機器設計的核心知識。從編譯原理的理論和編譯器的發展歷史來看，一個虛擬機器（VM）從非圖靈完備發展到圖靈完備，通常會經歷一個由簡到繁、由安全到強大、由專用到通用的演化過程。 （這句話將在本文中重複多次）

從編譯原理的理論分析來看，一個虛擬機器肯定是可以從非圖靈完備發展到圖靈完備的。這樣就只剩下個問題TAP 是否有發展成圖靈完備系統的必要性？ （這個問題不在本文討論）

如果TAP 一定要發展到圖靈完備，那麼它的發展過程有哪些可以遵循與借鏡的過程與方法呢？

4.1.從編譯原理看圖靈完備

圖靈完備：一切可計算的問題都能計算，這樣的虛擬機器或程式語言稱為圖靈完備的。一個能計算出每個圖靈可計算函數（Turing-computable function）的計算系統稱為圖靈完備的。一個語言是圖靈完備的，意味著該語言的運算能力與一個通用圖靈機（Universal Turing Machine）相當，這也是現代電腦語言所能擁有的最高能力。

在可計算理論中，當一組資料運算的規則（一組指令集，程式語言，或元胞自動機）滿足任意資料按照一定的順序可以計算出結果，稱為圖靈完備（turing complete）。一個有圖靈完備指令集的設備被定義為通用計算機。如果是圖靈完備的，它（電腦設備）有能力執行條件跳轉（“if” 和“goto”語句）以及改變記憶體資料。如果某樣東西展現出了圖靈完備，它就有能力表現出可以模擬原始計算機，而即使最簡單的計算機也能模擬出最複雜的計算機。所有的通用程式語言和現代電腦的指令集都是圖靈完備的（C++ template 就是圖靈完備的），都能解決記憶體有限的問題。圖靈完整的機器都被定義有無限內存，但是機器指令集通常定義為只工作在特定的，有限數量的RAM 上。

一個虛擬機器（VM）從非圖靈完備發展到圖靈完備，通常會經歷一個由簡到繁、由安全到強大、由專用到通用的演化過程。這包含兩個主要問題：

1.為什麼要從非圖靈完備開始？ 為了安全和可靠性。非圖靈完備的系統可以保證所有程式都會終止（Halting Problem 可判定），不會有無限循環，這對於諸如智能合約、配置語言、模板引擎等場景至關重要。

2.為什麼要向圖靈完備發展？ 為了表現力和功能性。只有圖靈完備的系統才能實現各種複雜的邏輯與演算法，成為一個通用的程式設計平台。

因此，一個VM 從非圖靈完備發展到圖靈完備，本質上是其設計目標從「絕對安全可控」向「強大通用」擴展的過程。而現代VM 的最高追求，是嘗試同時兼具兩者：即在提供圖靈完備的強大能力的同時，透過精巧的設計最大限度地保留安全性和可控性。

4.2.一個VM 從非圖靈完備發展到圖靈完備的幾個明顯階段

一個虛擬機器（VM）從非圖靈完備發展到圖靈完備，通常會經歷一個由簡到繁、由安全到強大、由專用到通用的演化過程。我們可以將其概括為以下幾個典型的階段：

1. 階段一：純粹計算器（非圖靈完備）

特徵：只有基本的表達式運算能力，無狀態、無控制流。

• 能力：支援基本的算術運算（加減乘除）、邏輯運算、位元運算等。它像一個高階計算器，每次計算都是獨立的，不依賴先前的狀態。
• 無狀態性：沒有記憶體的概念，或記憶體是唯讀的，無法修改。無法定義和修改變數。
• 無控制流：沒有條件分支（if/else）、迴圈（for/while）或跳轉指令。指令只能依序執行。
• 為何非圖靈完備：無法實現循環或條件判斷，無法模擬圖靈機無限長的紙帶與狀態轉換。
• 歷史實例：最早的某些極為簡單的配置或表達式求值引擎。

2. 階段二：引入狀態與條件分支（邁向完備的關鍵一步）

特徵：增加了可變狀態（記憶體）和簡單的條件判斷，但缺乏真正的循環。

能力：

(1) 狀態（State）：引入了可讀寫的記憶體（如堆疊、暫存器、堆疊），可以定義和修改變數。這使得計算可以依賴歷史，而不再是孤立的。

(2) 條件分支（Conditional Branching）：引入了基於條件的跳躍指令（如if_eq, if_lt, jmp 到指定偏移量）。這是實現邏輯判斷的關鍵。

• 為何仍可能非圖靈完備：如果該VM 的指令集或設計刻意禁止了向後跳轉（backward jump），即只能跳到後續的指令（向前跳轉），那麼它就無法形成循環。沒有循環，就無法實現圖靈完備所要求的「無限計算」潛力（儘管物理上是有限的，但理論模型上是無限的）。
• 歷史/現代實例：比特幣的腳本語言（Bitcoin Script）在早期就是一個經典的例子。它是刻意設計為無循環，只有條件分支和向前跳轉，以防止無限循環程式碼阻塞網絡，從而保證了腳本一定能在有限步驟內執行完畢。

註：我個人認為比特幣的腳本語言主要功能都處於階段一，有一小部分階段二的特徵。若用比例來說明，大致是階段一佔比大於90%，階段二佔比小於10%。像後來在Taproot 中引入的MAST（默克爾抽象語法樹），在比特幣主網並不能很好的發揮作用，反而會在TAP 中發揮強大的作用。很大的原因也是比特幣主網要盡量保持虛擬機器限制在階段一的能力範圍內。

3. 階段三：引入循環或遞歸（實現圖靈完備）

特徵： 提供了形成循環結構的能力。

能力：

(1) 向後跳轉（Backward Jump）： 允許跳轉指令跳回先前的指令位址。這直接可以形成循環。

(2) 循環指令： 提供專門的循環指令（如loop）。

(3) 間接跳轉/函數呼叫： 透過支援函數呼叫和遞歸，同樣可以實現循環的效果。因為遞歸可以等價地取代循環。

• 為何此時圖靈完備：一旦擁有了條件分支和向後跳轉/循環/遞歸的能力，這個VM 就具備了實現條件判斷和重複執行的能力。這兩者結合，理論上就可以模擬任何圖靈機的計算過程，因此達到了圖靈完備。
• 歷史實例：幾乎所有通用語言的虛擬機器（如JVM, Python VM, .NET CLR）從誕生之初就是圖靈完備的，因為它們的設計目標就是運行通用程式語言。它們的演進更多是性能和安全特性的增強。

4. 階段四：在圖靈完備基礎上增強（安全、性能、特性）

一旦達到圖靈完備，VM 的發展重點就不再是運算能力，而是其他面向：

• 效能：引入JIT（即時編譯）、AOT（預先編譯）、最佳化編譯器、更有效率的垃圾回收演算法等。
• 安全性：強化沙箱機制、引入能力系統（Capability System）、更精細的記憶體隔離與控制。 WebAssembly 是一個絕佳的現代例子，它在提供圖靈完備能力的同時，透過線性記憶體、結構化控制流和沙箱環境等手段，大大增強了安全性和確定性。
• 特性：支援協程（Coroutine）、非同步/等待（Async/Await）、泛型、反射等高階語言特性。
• 確定性：對於一些區塊鏈虛擬機器（如Ethereum EVM 的後繼者），在圖靈完備的基礎上，追求執行結果的確定性（所有節點結果一致）和可終止性（透過Gas 機制限制實際執行步驟）成為重點。

從編譯原理的的專業知識，我們可以看到VM 發展的四個階段。參考這個發展路線，我們也可以大致看到TAP 發展的幾個階段（也就是BTC2.0 發展的幾個階段）。

4.3. TAP 的第一階段：輕度探索擴充BTCScript 的指令

前面我們提到早期比特幣主網指令超出了它能力的範圍，已經部分像通用VM 的第二個階段能力範圍，這導致了後面的刪減指令行為。精簡指令後的比特幣主網上的BTCScript 指令滿足了編譯原理中的第一階段能力要求，這些都是為了確保比特幣主網的安全性與穩定性。

既然TAP 是BTC2.0 的開端，從編譯原理的階段區分來看，目前的TAP-VM 應該會向通用VM 的第二階段發展。 TAP-VM 在探索這個階段的時候，可以適當的擴充BTCScript 的指令，恢復到原來刪除的BTCScript 指令，如，開始逐漸加入類似OP_CAT 這樣的大眾期望的指令。每增加一個指令都需要較多的應用來偵測其功能與安全性。這個階段可以完成像TrustlessSwap 這樣的簡單操作。還可以增加對Taproot 中技術的使用場景，如，使用更功能多樣的MAST 樹。

這一階段應該會滿足初級的BTCFi 的功能，如，簡單的去中心化交易，簡單的借貸功能，簡單的質押功能。目前透過TrustlessSwap 以及部分Tapscript 可以實現這些功能。

4.4. TAP 的第二階段：建構滿足去中心化的BTCFi 指令集

TAP-VM 發展到支援大部分的金融應用，需要增加多少指令，需要從編譯原理和應用兩個方向推導。但這個階段肯定不需要圖靈完備。這個階段需要滿足常見的BTCFi 應用，如Lending，Staking，Mint StableCoin，更複雜的Swap 等功能。

這個階段很接近通用VM 的第二個階段，需要引入狀態與條件分支。在MAST 抽象語法樹中，就是引入了這樣的狀態與條件分支。雖然在BTC1.0 的Taproot 技術中就有了這樣的MAST 樹，但只有當比特幣主網的BTC-VM 與獨立的TAP-VM 分離後，這些條件語句才能有更好發揮作用。

4.5. TAP 的第三階段：更豐富的指令集與初步圖靈完備

TAP-VM 發展到支持金融應用之上的更複雜的應用，這依賴於應用對TAP-VM 的推動作用，這個階段會逐漸接近圖靈完備或初步的圖靈完備。

在這個階段，從編譯原理的角度看，會發展到通用VM 的階段三，開始引入循環和遞歸等特性，能夠實現向後跳轉與間接跳轉，專門的循環指令，甚至出現函數功能。加上階段二能夠支援的條件與分支功能，此時的TAP-VM 理論上就可以模擬所有的計算，從而達到圖靈完備。或因為發展的過程原因，處於圖靈完備的前期，但其已經具有豐富的指令集，能夠完成複雜的功能。

但即使TAP-VM 在這個階段能發展到圖靈完備，和RGB 的圖靈完備也有明顯的差異。大概會像C++與Java 之類的語言對比，5.1 中我們有更詳細的對比。

4.6. TAP 的第四階段：成熟的圖靈完備+豐富的Lib 庫

TAP-VM 發展到這個階段，不僅完成了圖靈完備，並且開始有豐富的類別庫（或函數庫）理論上能完成所有的應用功能，並且具有比較豐富的案例。因為有了豐富的應用案例與類別庫支持，開發者更容易開發出大量的應用。

這個階段的TAP-VM，就像通用VM 的第四階段任務一樣，其發展重點已經不是運算能力，而是效能、安全性、確定性等更高的虛擬機器指標。這會不會是比較遙遠的過程？

發展到這個階段，TAP 的功能因為非常強大，會出現許多與RGB 交疊的領域。很多應用程式既可以用TAP 來實現，也可以用RGB 來實現。這種交疊部分主要集中在金融應用部分，尤其是基於比特幣主網發行的資產。但TAP 與RGB 在大的應用場景下，依然有很大的差異。我們在下一節來大致分析一下這種差異。

5.圖靈完備的系統也有不同的應用場景

在BTC 的生態中，我們主要參考兩種圖靈完備的系統對比：TAP 與RGB，從而說明適合不同的應用場景，或更好的說明TAP 的應用場景。

根據web2 領域的經驗和關於VM 的豐富數據，C/C++開發語言+運行環境可以很好的與Java 開發語言+運行環境形成對比。這種對比，與TAP 與RGB 的對比有一定的參考性。

5.1. C/C++ 與Java 的應用場景對比

核心特性比較表

應用場景總結

1. C/C++ 的主場（需要直接操作硬體或極致效能）

(1) 系統級軟體/基礎設施開發

• 作業系統（如Linux、Windows 核心）
• 資料庫管理系統（如MySQL、PostgreSQL）
• 編譯器/解譯器（如GCC、JVM 本身其實是用C++寫的）
• Web 伺服器/高效能網路框架（如Nginx、Node.js 底層）

(2) 硬體驅動與嵌入式系統

• 裝置驅動程式：需要直接與硬體暫存器互動。
• 嵌入式/物聯網（IoT）設備：資源極度受限（如單晶片MCU），需要精確控制記憶體和功耗，無法承擔JVM 的開銷。

(3) 高效能運算與遊戲開發

• 遊戲引擎（如Unreal, Unity 的底層）：需要榨乾硬體效能，進行複雜的圖形和實體運算。
• 科學計算/金融交易系統：微秒級的延遲都至關重要。
• 圖形/影像/音視訊處理：如Photoshop、FFmpeg。

(4) 需要精細控制記憶體和資源的場景

在某些場景下，手動管理記憶體比垃圾回收更可預測，可以避免GC 帶來的延遲抖動。

2. Java 的主場（需要高開發效率、跨平台和企業級可靠性）

(1) 大型企業級應用後端開發

• Web 應用後端：Spring Boot 框架是Java 在企業級開發中的絕對霸主，用於建立大型、分散式、高並發的後端服務。
• 微服務架構：大量基於Java 和JVM 的微服務框架（如Spring Cloud）。
• 分散式系統：如大數據領域的Hadoop、訊息佇列Kafka。

(2) Android 應用程式開發

Android 官方歷史首選語言（雖然現在Kotlin 已成為首選，但底層大量程式碼和生態仍是Java）。

(3) 大數據與雲端運算

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 的主場（需要比特幣特性的基礎功能）

(1) 現金模型的資產發行

(2) 比特幣網路上的BTCFi

(3) 去中心化的底層協議

2. RGB 的主場（幾乎適合所有的Dapp 類型）

(1) 比特幣網路上的智能合約應用

(2) 更高級，更複雜的資產發行與DeFi 應用

(3) 更高層級的web3 應用，如去中心化身分、DAO 治理等應用

(4) 其他更廣泛的web3 應用

3. 如何選擇？

• 選擇TAP-VM：

直接與比特幣UTXO 進行的互動。

現金模型的資產發行。

直接擴展比特幣腳本類型的功能。

去中心化的比特幣金融應用。

• 選擇RGB：

需要複雜邏輯的智能合約。

更高階等級更複雜的DeFi。

非金融的Web3 應用。

簡單總結：TAP-VM 更接近比特幣主網的應用，或基於比特幣主網的直接擴展應用；RGB 適合邏輯功能複雜，更貼近用戶層的應用。

6.如何能更好的發展BTC2.0

本節內容較多憑藉著個人的主觀判斷來做的一些描述，主要來自於作者以往的工作經驗和專案工程化經驗。所以一定會有不足與偏差，希望能夠聽到更多的聲音，來完善這種預測與判斷，尤其是期望聽到在這個領域開發產品項目方的意見。

透過前面的討論，如果我們可以將比特幣分為BTC1.0 階段和BTC2.0 階段，還會帶來一些明顯的優勢。

6.1.清晰的分工和規範

這種階段劃分的另一個好處是能夠明確分工與職責。

1. 有了判斷與決策的參考原則。這樣就容易從設計者的角度，將符合BTC1.0 原則的功能設計到比特幣主網中，將符合BTC2.0 設計原則的功能設計到TAP 協定中。不僅能夠降低爭議，也能夠帶來更好的組織間的協作。

BTC2.0 也可以參考編譯原理和其他成熟產品的發展過程，將TAP 的發展做更清楚的階段規劃。

2. 一些協議和標準也能更好的命名和製定評審標準。如TAP 的7 個協議，目前命名是：

• BIP-TAP-ADDR：Taproot Asset On Chain Addresses Draft
• BIP-TAP-MS-SMT：Merkle Sum Sparse Merkle Trees Draft
• BIP-TAP-PROOF：Taproot Asset Flat File Proof Format Draft
• BIP-TAP-PSBT：Taproot Assets PSBT Draft
• BIP-TAP-UNIVERSE：Taproot Asset Universes Draft
• BIP-TAP-VM：Taproot Asset Script v1 Draft
• BIP-TAP：TAP: Taproot Assets Protocol Draft

如果BTC2.0 的分類方式被大家接受，完全可以命名成BIP2 開頭：

• BIP2：Taproot Asset On Chain Addresses Draft
• BIP2：TAP Merkle Sum Sparse Merkle Trees Draft
• BIP2：Taproot Asset Flat File Proof Format Draft
• BIP2：Taproot Assets PSBT Draft
• BIP2：Taproot Asset Universes Draft
• BIP2：Taproot Asset Script v1 Draft
• BIP2：TAP: Taproot Assets Protocol Draft

6.2.資源的整合與組織再規劃

目前比特幣的主網主要由Bitcoin Core 團隊在負責（截止2025 年6 月全網90%在使用Bitcoin Core）。 TAP 協定由閃電網路實驗室在負責。

目前BitcoinCore 軟體已經運作超過了15 年，核心功能已經趨於穩定，後面再大幅增加功能的場景應該不多，或者如果需要大幅的改動，大機率都會發生在TAP 協定之上。 TAP 協議目前剛剛發展，如果按照可預測的規劃，還有很長的路要走，需要大量的開發資源。如果可以將原有的開發資源很好的複用，將會極大的推動BTC2.0 的發展。更重要的是這些比特幣主網的開發人員在開發環境、語言類型上，都與TAP 的開發有這非常大的共同特點，主要的差異僅在於開發的指導原則產生了變化。

當然這樣會面臨很大的挑戰，因為TAP 目前是閃電網路中的一個協議，並不是閃電網路的全部工作。是否能夠將TAP 獨立成BTC2.0 項目，再規劃發展與整合資源都是需要很多的協調工作。

如果TAP 一定會發展成BTC2.0，那麼比特幣主網專案（BTC1.0），新的BTC2.0，閃電網路會是三個比較獨立又緊密相連的專案。 BTC2.0 部分會和閃電網路有更深入的功能集成，基於BTC2.0 的新特性，閃電網路也會有更大的發展。

6.3.發展與競爭

前面第5 節描述了TAP 與直接競爭者的一些特性對比，也可以看作是BTC2.0 與外部分層協定的對比。在目前發展階段，RGB 與TAP 會產生許多的直接競爭。表現在幾個領域：資產的發行、資產的交易、更廣泛的BTCFi。雖然在與比特幣主網緊密關聯的部分，TAP 優於許多協議，但如果TAP 無法盡快的完成階段一的發展，圖靈完備的RGB 將會先佔領這個領域。 RGB 僅憑依賴比特幣主網共識協議一個特性，就能吸引無數的比特幣原生主義的愛好者，畢竟功能實現更吸引人。如果TAP 無法完成或落後第二階段的發展，TAP 也將落後於RGB。

TAP 是否會發展成BTC2.0？發展過程是什麼情況？最終會是什麼樣的格局，依賴許多外部情況。這些比特幣領域可能的發展充滿了想像空間，充滿了挑戰，但不管過程如何，TAP 都為我們打開了一扇大門。

寫在最後：如果TAP 是BTC2.0 的發展，那麼TaprootAssets Protocol 的名稱是不是過於具體和代表當前，是否升級為另一個名稱才能更好的代表BTC2.0 的發展？

參考文獻

註記說明：因為本文是TAP 的綜合預測與分析，很多內容都是一些知識的概括總結，不具體到某篇文章。本文的一些內容使用了AI 助手，並且內容根據作者的行業經驗判斷，認為是比較準確後，才引入了文章中。其中包括：C/C++與Java 的應用場景對比。

編譯原理部分參考了大學電腦專業的課本資料與零散的網路文章。

其他具體相關的參考文章如下：

1. https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki ，Taproot Assets Protocol 相關的7 個協議

2. 《徹底理解比特幣「隔離見證」技術與它的三個版本升級》，

3. 《一文梳理比特幣二層（Layer2）建設的基礎知識體系V2.0 版》，