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

1. 前言

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

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

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

先給出一個簡單的結論：第三次隔離見證打開的新大門是，可以使用的無限數(shù)據(jù)空間，可以發(fā)展出圖靈完備的虛擬機 VM。

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

2.1. TaprootAssets 協(xié)議打下了哪些基礎？

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

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

1. 已經在擴容上可以達到極限——使用無限的數(shù)據(jù)空間。

2. 在架構上將 BTCscript 的 VM 與 TAP 的 VM 進行了分離，這為今后功能的發(fā)展打下了良好的架構基礎。

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

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

2.2. 比特幣的發(fā)展需要分層協(xié)議設計思想

比特幣如果想要有全球的影響力，那么它一定要有巨大的應用場景，形成一個龐大的生態(tài)。對于這樣的大型系統(tǒng)和復雜系統(tǒng)，我們人類已經有相關的經驗與方法論，也就是分層設計思想。如 TCP/IP 這樣的協(xié)議中，已經有非常好的應用案例與參考經驗。

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

協(xié)議分層的優(yōu)點：各層次之間是獨立的、靈活性好、結構上可分割開、易于實現(xiàn)和維護、能促進標準化工作。

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

未來 web3.0（也可以成為價值互聯(lián)網）將會在比特幣為一層網絡的基礎上建立。比特幣的分層設計思想已經有了初步的發(fā)展。現(xiàn)在已經有了多種探索的二層案例，其中典型的是基于鏈的二層和基于分布式系統(tǒng)的二層（如閃電網絡），還有基于 LNP/BP 協(xié)議的 RGB，當 RGB 基于 BP 協(xié)議時，它是一個二層，當 RGB 基于 LNP 協(xié)議時，它是一個三層。

但這次 TAP 給帶來的變化，并沒有那么像分層協(xié)議，更像一個事物的 1.0 與 2.0 的發(fā)展。原因是 TAP 協(xié)議和比特幣主網是那么的相似與連接緊密，表現(xiàn)為如下幾點：

1. 在數(shù)據(jù)的結構上 TAP 也采用和主網一樣的 UTXO 結構，稱為 vUTXO。這些 vUTXO 的創(chuàng)建、轉移、合并、拆分都與比特幣主網保持一致，并且可以與主網的 UTXO 進行去中心化的 Swap。從 SegWit 中的 vByte，到 TAP 中的 vUTXO，是同一種設計思想的延續(xù)發(fā)展。

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

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

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

如果從上面的三個角度分析 RGB 協(xié)議，我們能看到明星的區(qū)別。RGB 協(xié)議完全不具有 1，2 兩個特點，只有在使用比特幣主網的共識協(xié)議方面有相似性，這決定了 RGB 是一個完全的分層協(xié)議，而不是比特幣主網的延續(xù)發(fā)展。

3. BTC1.0 與 BTC2.0

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

3.1. 基礎定義

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

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

3.2. 如何區(qū)分

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

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

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

注釋：TAP 是一個完整的協(xié)議，包括 TAP-VM，所以后續(xù)內容都使用 TAP 這個詞語。

• TAP 發(fā)展成圖靈完備的幾個階段

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

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

如果 TAP 一定要發(fā)展到圖靈完備，那么它的發(fā)展過程有哪些可以遵循與借鑒的過程與方法？

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

圖靈完備：一切可計算的問題都能計算，這樣的虛擬機或者編程語言稱為圖靈完備的。一個能計算出每個圖靈可計算函數(shù)（Turing-computable function）的計算系統(tǒng)被稱為圖靈完備的。一個語言是圖靈完備的，意味著該語言的計算能力與一個通用圖靈機 （Universal Turing Machine）相當，這也是現(xiàn)代計算機語言所能擁有的最高能力。

在可計算理論中，當一組數(shù)據(jù)操作的規(guī)則（一組指令集，編程語言，或者元胞自動機）滿足任意數(shù)據(jù)按照一定的順序可以計算出結果，被稱為圖靈完備（turing complete）。一個有圖靈完備指令集的設備被定義為通用計算機。如果是圖靈完備的，它（計算機設備）有能力執(zhí)行條件跳轉（“if” 和 “goto”語句）以及改變內存數(shù)據(jù)。如果某個東西展現(xiàn)出了圖靈完備，它就有能力表現(xiàn)出可以模擬原始計算機，而即使最簡單的計算機也能模擬出最復雜的計算機。所有的通用編程語言和現(xiàn)代計算機的指令集都是圖靈完備的（C template 就是圖靈完備的），都能解決內存有限的問題。圖靈完備的機器都被定義有無限內存，但是機器指令集卻通常定義為只工作在特定的，有限數(shù)量的 RAM 上。

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

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

2.為什么要向圖靈完備發(fā)展？ 為了表現(xiàn)力和功能性。只有圖靈完備的系統(tǒng)才能實現(xiàn)各種復雜的邏輯和算法，成為一個通用的編程平臺。

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

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

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

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

特征：只有基本的表達式計算能力，無狀態(tài)、無控制流。

• 能力：支持基本的算術運算（加減乘除）、邏輯運算、位運算等。它像一個高級計算器，每次計算都是獨立的，不依賴于之前的狀態(tài)。
• 無狀態(tài)性：沒有內存的概念，或者內存是只讀的，無法修改。無法定義和修改變量。
• 無控制流：沒有條件分支（if/else）、循環(huán)（for/while）或跳轉指令。指令只能順序執(zhí)行。
• 為何非圖靈完備：無法實現(xiàn)循環(huán)或條件判斷，無法模擬圖靈機無限長的紙帶和狀態(tài)轉換。
• 歷史實例：最早的某些極其簡單的配置或表達式求值引擎。

2. 階段二：引入狀態(tài)和條件分支（邁向完備的關鍵一步）

特征：增加了可變狀態(tài)（內存）和簡單的條件判斷，但缺乏真正的循環(huán)。

能力：

(1) 狀態(tài)（State）：引入了可讀寫的內存（如棧、寄存器、堆），可以定義和修改變量。這使得計算可以依賴于歷史，而不再是孤立的。

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

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

注釋：我個人認為比特幣的腳本語言主要功能都處于階段一，有一小部分階段二的特征。如果用比例來說明，大致是階段一占比大于 90%，階段二占比小于 10%。像后來在 Taproot 中引入的 MAST（默克爾抽象語法樹），在比特幣主網并不能很好的發(fā)揮作用，反而會在 TAP 中發(fā)揮強大的作用。很大的原因也是比特幣主網要盡量保持虛擬機限制在階段一的能力范圍內。

3. 階段三：引入循環(huán)或遞歸（實現(xiàn)圖靈完備）

特征： 提供了形成循環(huán)結構的能力。

能力：

(1) 向后跳轉（Backward Jump）： 允許跳轉指令跳回到之前的指令地址。這直接可以形成循環(huán)。

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

(3) 間接跳轉/函數(shù)調用： 通過支持函數(shù)調用和遞歸，同樣可以實現(xiàn)循環(huán)的效果。因為遞歸可以等價地替代循環(huán)。

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

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

一旦達到圖靈完備，VM 的發(fā)展重點就不再是計算能力，而是其他方面：

• 性能：引入 JIT（即時編譯）、AOT（預先編譯）、優(yōu)化編譯器、更高效的垃圾回收算法等。
• 安全性：強化沙箱機制、引入能力系統(tǒng)（Capability System）、更精細的內存隔離和控制。WebAssembly 是一個絕佳的現(xiàn)代例子，它在提供圖靈完備能力的同時，通過線性內存、結構化控制流和沙箱環(huán)境等手段，極大地增強了安全性和確定性。
• 特性：支持協(xié)程（Coroutine）、異步/等待（Async/Await）、泛型、反射等高級語言特性。
• 確定性：對于一些區(qū)塊鏈虛擬機（如 Ethereum EVM 的后繼者），在圖靈完備的基礎上，追求執(zhí)行結果的確定性（所有節(jié)點結果一致）和可終止性（通過 Gas 機制限制實際執(zhí)行步驟）成為重點。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

發(fā)展到這個階段，TAP 的功能因為非常強大，會出現(xiàn)很多與 RGB 交疊的領域。很多應用既可以用 TAP 來實現(xiàn)，也可以用 RGB 來實現(xiàn)。這種交疊部分主要集中在金融應用部分，尤其是基于比特幣主網發(fā)行的資產。但 TAP 與 RGB 在大的應用場景下，依然有很大的區(qū)別。我們在下一節(jié)來大致分析一下這種區(qū)別。

5. 圖靈完備的系統(tǒng)也有不同的應用場景

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

根據(jù) web2 領域的經驗和關于 VM 的豐富數(shù)據(jù)，C/C 開發(fā)語言 運行環(huán)境可以很好的與 Java 開發(fā)語言 運行環(huán)境形成對比。這種對比，與 TAP 與 RGB 的對比有一定的參考性。

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

核心特性對比表

應用場景總結

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

(1) 系統(tǒng)級軟件/基礎設施開發(fā)

• 操作系統(tǒng)（如 Linux、Windows 內核）
• 數(shù)據(jù)庫管理系統(tǒng)（如 MySQL、PostgreSQL）
• 編譯器/解釋器（如 GCC、JVM 自身其實是用 C 寫的）
• Web 服務器/高性能網絡框架（如 Nginx、Node.js 底層）

(2) 硬件驅動與嵌入式系統(tǒng)

• 設備驅動程序：需要直接與硬件寄存器交互。
• 嵌入式/物聯(lián)網（IoT）設備：資源極度受限（如單片機 MCU），需要精確控制內存和功耗，無法承擔 JVM 的開銷。

(3) 高性能計算與游戲開發(fā)

• 游戲引擎（如 Unreal, Unity 的底層）：需要榨干硬件性能，進行復雜的圖形和物理計算。
• 科學計算/金融交易系統(tǒng)：微秒級的延遲都至關重要。
• 圖形/圖像/音視頻處理：如 Photoshop、FFmpeg。

(4) 需要精細控制內存和資源的場景

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

2. Java 的主場（需要高開發(fā)效率、跨平臺和企業(yè)級可靠性）

(1) 大型企業(yè)級應用后端開發(fā)

• Web 應用后端：Spring Boot 框架是 Java 在企業(yè)級開發(fā)中的絕對霸主，用于構建大型、分布式、高并發(fā)的后端服務。
• 微服務架構：大量基于 Java 和 JVM 的微服務框架（如 Spring Cloud）。
• 分布式系統(tǒng)：如大數(shù)據(jù)領域的 Hadoop、消息隊列 Kafka。

(2) Android 應用開發(fā)

Android 官方歷史首選語言（雖然現(xiàn)在 Kotlin 已成為首選，但底層大量代碼和生態(tài)仍是 Java）。

(3) 大數(shù)據(jù)與云計算

Hadoop、Spark、Flink 等大數(shù)據(jù)處理框架的核心組件大多用 Java 或 Scala（JVM 語言）編寫。

(4) 需要高可靠性、長生命周期的系統(tǒng)

銀行、金融、電商等核心系統(tǒng)，其健壯性、安全性和強大的社區(qū)生態(tài)支持至關重要。

(5) 跨平臺桌面應用

雖然不如 Web 流行，但 Swing/JavaFX 仍可用于開發(fā)跨平臺的 GUI 程序。

3. 如何選擇？

• 選擇 C/C 當：

性能是絕對第一要求（游戲、交易系統(tǒng)）。

你需要直接與操作系統(tǒng)或硬件交互（驅動、嵌入式）。

資源極其有限，無法承受 JVM 的內存和 CPU 開銷。

你對程序的行為需要有絕對的控制力（內存布局、執(zhí)行流程）。

• 選擇 Java 當：

你要開發(fā)大型、復雜的企業(yè)級應用（Web 后端、微服務）。

開發(fā)效率、可維護性和團隊協(xié)作比極致的性能更重要。

你需要強大的跨平臺能力，且不希望為每個平臺單獨編譯。

你希望避免內存管理錯誤，享受豐富的開源庫和框架生態(tài)。

項目要求高可靠性和長期穩(wěn)定的運行。

簡單總結：C/C 是適合更接近于底層，硬件層或操作系統(tǒng)層；Java 更適合接近業(yè)務層與應用層。

5.2. TAP 與 RGB 的應用場景對比

核心特性對比表（希望今后借助大家的力量逐漸完善這個對比表）

應用場景總結（以下均為根據(jù)特性的推測，因為 TAP-VM 還沒有完全發(fā)展，RGB 還沒有更多的應用案例）

1. TAP 的主場（需要比特幣特性的基礎功能）

(1) 現(xiàn)金模型的資產發(fā)行

(2) 比特幣網絡上的 BTCFi

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

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

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

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

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

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

3. 如何選擇？

• 選擇 TAP-VM：

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

現(xiàn)金模型的資產發(fā)行。

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

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

• 選擇 RGB：

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

更高級級別更復雜的 DeFi。

非金融的 Web3 應用。

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

6. 如何能更好的發(fā)展 BTC2.0

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

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

6.1. 清晰的分工和規(guī)范

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

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

BTC2.0 還可以參考編譯原理和其他成熟產品的發(fā)展過程，將 TAP 的發(fā)展做更清晰的階段規(guī)劃。

2. 一些協(xié)議和標準也能更好的命名和制定評審標準。如 TAP 的 7 個協(xié)議，當前命名是：

• 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. 資源的整合與組織再規(guī)劃

當前比特幣的主網主要由 Bitcoin Core 團隊在負責（截止 2025 年 6 月份全網 90%在使用 Bitcoin Core）。TAP 協(xié)議由閃電網絡實驗室在負責。

當前 BitcoinCore 軟件已經運行超過了 15 年，核心功能已經趨于穩(wěn)定，后面再大幅增加功能的場景應該不多，或者如果需要大幅的改動，大概率都會發(fā)生在 TAP 協(xié)議之上。TAP 協(xié)議當前剛剛發(fā)展，如果按照可預測的規(guī)劃，還有很長的路要走，需要大量的開發(fā)資源。如果可以將原有的開發(fā)資源很好的復用，將會極大的推動 BTC2.0 的發(fā)展。更加重要的是這些比特幣主網的開發(fā)人員在開發(fā)環(huán)境、語言類型上，都與 TAP 的開發(fā)有這非常大的共同特點，主要的區(qū)別僅僅在于開發(fā)的指導原則產生了變化。

當然這樣會面臨很大的挑戰(zhàn)，因為 TAP 當前是閃電網絡中的一個協(xié)議，并不是閃電網絡的全部工作。是否能夠將 TAP 獨立成 BTC2.0 項目，再規(guī)劃發(fā)展和整合資源都是需要很多的協(xié)調工作。

如果 TAP 一定會發(fā)展成 BTC2.0，那么比特幣主網項目（BTC1.0），新的 BTC2.0，閃電網絡會是三個比較獨立又緊密相連的項目。BTC2.0 部分會和閃電網絡有更加深入的功能集成，基于 BTC2.0 的新特性，閃電網絡也將會有更大的發(fā)展。

6.3. 發(fā)展與競爭

前面第 5 節(jié)描述了 TAP 與直接競爭者的一些特性對比，也可以看作是 BTC2.0 與外部分層協(xié)議的對比。在當前發(fā)展階段，RGB 與 TAP 會產生很多的直接競爭。表現(xiàn)在幾個領域：資產的發(fā)行、資產的交易、更廣泛的 BTCFi。雖然在與比特幣主網緊密關聯(lián)的部分，TAP 優(yōu)于很多協(xié)議，但如果 TAP 不能盡快的完成階段一的發(fā)展，圖靈完備的 RGB 將會首先占領這個領域。RGB 僅憑依賴比特幣主網共識協(xié)議一個特性，就能吸引無數(shù)的比特幣原生主義的愛好者，畢竟功能實現(xiàn)更吸引人。如果 TAP 不能完成或落后第二階段的發(fā)展，TAP 也將落后于 RGB。

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

寫在最后：如果 TAP 是 BTC2.0 的發(fā)展，那么 TaprootAssets Protocol 的名稱是不是過于具體和代表當前，是不是升級為另外一個名稱才能更好的代表 BTC2.0 的發(fā)展？

參考文獻

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

編譯原理部分參考了高校計算機專業(yè)的課本材料與零散的網絡文章。

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

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

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

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

AD：

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。