不是給 Bitcoin 再套一層 EVM_TBC 如何讓 UTXO 成為可編程計算層

By: foresightnews.pro|2026/09/21 08:16:20

面向開發者：UTXO 狀態傳遞、並行驗證、公開代碼與審計複驗。

Bitcoin 的 UTXO 擅長回答一個問題：誰有權花掉這筆輸出？複雜應用卻需要繼續追問：這筆輸出來自哪裡、下一筆交易必須長什麼樣、狀態怎樣延續、不同合約能否同時執行？多數網絡選擇在 Bitcoin 外部增加一套執行環境，TBC 則把問題帶回 UTXO 本身。

這條路線是否成立，不該由口號決定。代碼、開發工具、基準方法和審計記錄，才是技術讀者需要檢查的答案。

一、比特幣可編程性的難點，不只是腳本少幾個操作碼

Bitcoin Script 有意保持克制。一個 UTXO 帶著明確的金額和花費條件，被消費後生成新的輸出；節點驗證簽名和腳本，不需要維護類似 EVM 的全局賬戶狀態。這種模型邊界清楚，也讓互不相關的輸出具備並行驗證的可能。

困難出現在狀態需要跨交易延續時。AMM 要記住儲備量，代幣合約要驗證發行與轉移規則，NFT 要維護所有權和元數據，鏈上訂單簿還要處理訂單、成交和結算之間的關係。原始腳本能夠約束當前花費，卻不方便驗證一條持續演進的業務狀態。

主流做法是把複雜邏輯搬到側鏈、Rollup 或另一套虛擬機中。這些方案已經形成成熟的開發環境，但也帶來新的邊界：資產可能需要橋接，狀態要在不同系統之間同步，執行層還要建立自己的驗證和升級機制。問題並沒有消失，只是從「UTXO 怎樣表達狀態」變成了「多個系統怎樣維持一致」。

二、TBC 的選擇：讓交易自己攜帶狀態

TBC 保留 SHA256 PoW 與 UTXO 路線，同時引入 TuringTXID、TuringContract 和 BVM。它沒有把合約狀態集中進一棵全局賬戶樹，而是讓狀態存在於合約 UTXO 及其後繼交易中：舊輸出被消費，新輸出攜帶更新後的狀態繼續存在。

關鍵並非把 UTXO 改名為賬戶，而是讓腳本能夠驗證「父代」和「子代」的關係。這樣，合約規則可以隨交易向後傳遞，每次狀態變化仍是一筆可獨立檢查的 UTXO 交易。

這也劃出一條清楚的邊界：TBC 是一條採用 Bitcoin 式架構的獨立公鏈，並不是把合約直接塞進 BTC 主網。它要證明的，是 UTXO 原生執行能否成為賬戶模型之外的另一種工程選擇。

三、三項改動，把孤立輸出連接成可驗證狀態機

1. TuringTXID：只帶驗證所需的數據

普通 TXID 把整筆交易壓成一個哈希。合約若只想核對歷史交易中的某個字段，往往仍需拿到更多上下文。TBC 白皮書描述的 TuringTXID 採用分層哈希，讓交易的不同部分擁有可組合的摘要；無關數據可以裁剪，關鍵字段仍能沿哈希路徑驗證。

結果不是「鏈上數據免費」，而是合約驗證局部歷史時不必反覆搬運整筆祖先交易。對於狀態持續多代的 UTXO 合約，這直接影響腳本大小、網絡傳輸和節點驗證成本。

2. OP_PUSH_META 與 OP_PARTIAL_HASH：檢查交易上下文

OP_PUSH_META 把當前輸入、前序輸出及輸出摘要等交易元數據送入腳本，使腳本能夠看到自己正在驗證的交易結構。OP_PARTIAL_HASH 用於對分段數據繼續計算哈希，讓腳本可以重建並核對關鍵摘要。

兩者配合後，合約能夠約束後繼輸出：新狀態必須繼續採用指定腳本，資產只能按預設規則移動，某些字段必須與前序狀態保持關係。這裡的「記憶」不是一個鏈外數據庫，而是由每一代 UTXO 攜帶、由下一次花費重新驗證的狀態連續性。

3. BVM 與並行驗證：隔離狀態，減少無關競爭

在全局賬戶狀態機中，多筆交易若讀寫相同狀態，執行順序會影響結果。TBC 把合約狀態拆進不同 UTXO，不相關輸入之間沒有共享寫入點，節點因而可以把它們分配給多個計算核心驗證。

這並不意味著所有合約天然無限並行。爭用同一 UTXO、訪問同一熱點池或形成前後依賴的交易，仍然必須排序；磁碟 I/O、網絡傳播和簽名驗證也會成為瓶頸。TBC 公開的 13,000+ TPS 是項目性能口徑，不是脫離交易類型與硬件環境的通用常數；ParaUTXO 的百萬級吞吐仍應被理解為研發目標，而非已經兌現的主網能力。

四、極客不只看架構圖，還要看能不能運行

TBC 目前最直接的公開入口是 TBCNODE 與 tbc-contract。前者提供全節點代碼，後者是面向 JavaScript 開發者的智能合約 SDK。官方快速開始給出的安裝命令只有一行：

npm i tbc-contract

SDK 已經覆蓋鏈上數據查詢、UTXO 獲取、交易組裝、簽名和廣播，並提供 MultiSig、NFT、FT 與 Pool 等工作流。開發者可以先在 testnet 生成交易、檢查原始交易結構，再決定是否進入更複雜的合約場景。tbc-lib-js 與錢包連接組件則提供更底層的交易和簽名能力。

這比只放一份白皮書前進了一步，但距離成熟開發平台仍有差距。文檔的一致性、可復現基準、本地調試、索引服務、測試框架和第三方教程，都需要繼續補齊。對於極客來說，這些不足不是應當隱藏的負面信息，而是判斷一個網絡是否歡迎外部開發者的測試題。

五、兩份節點審計，證明的是修復過程而非絕對安全

2026 年 8 月，CertiK 與 SlowMist 先後公開了 TBCNODE 審計記錄。CertiK 的人工審查覆蓋 21 個文件，共記錄 11 項發現，其中 9 項標記為 Resolved、2 項為 Acknowledged；沒有 Critical，1 項 Major 已解決。SlowMist 針對 TBCNODE v3.3.1 進行白盒審計，同樣記錄 11 項發現，整體結論為 Low Risk，唯一 High 項標記為 Fixed。

兩份報告的分類方法不同，不能簡單相加成 22 個獨立漏洞。更有意義的事實是：審計對象落在核心節點軟件，問題、版本和處理狀態有公開記錄。專業讀者可以檢查哪些問題已經修復，哪些風險被項目方確認接受。

審計也不是永久安全證明。它只覆蓋特定提交、約定範圍和時間點，無法自動擔保後續版本、節點配置、密鑰管理或真實負載下的運行表現。TBC 若要把這項優勢繼續積累下去，需要讓審計提交、修復矩陣、複測和版本發布保持綁定。