BitVM 完整解析：比特幣上的可驗證計算革命

摘要

BitVM（Bitcoin Virtual Machine）是比特幣生態系統中一項革命性的技術創新，它允許在比特幣區塊鏈上驗證任意計算的結果，而無需對比特幣的核心共識規則進行任何修改。這項技術由 ZeroSync 團隊於 2023 年 10 月首次提出，其核心設計理念借鑒了以太坊的樂觀 rollup（Optimistic Rollup）技術，但針對比特幣的約束條件進行了深度優化。BitVM 的出現填補了比特幣長期以來缺乏圖靈完整智慧合約能力的空白，為比特幣 DeFi 生態的發展打開了全新的可能性空間。本文將從技術原理、架構設計、應用場景、安全模型等多個維度，對 BitVM 進行全面深入的分析。

最後更新時間：2026-03-22

1. BitVM 的誕生背景與設計動機

1.1 比特幣腳本語言的局限性

比特幣的腳本語言（Bitcoin Script）從設計之初就刻意保持簡潔和非圖靈完整。這種設計選擇是有意為之的：中本聰在比特幣白皮書中明確指出，複雜的腳本語言可能導致安全性漏洞和共識失敗的風險。比特幣腳本支援的操作碼（opcodes）非常有限，主要包括：

• 基本運算：OPADD、OPMUL、OPDUP、OPHASH160 等
• 條件執行：OPIF、OPELSE、OP_ENDIF
• 時間鎖：OPCHECKLOCKTIMEVERIFY（CLTV）、OPCHECKSEQUENCEVERIFY（CSV）
• 簽名驗證：OPCHECKSIG、OPCHECKMULTISIG

這些操作碼雖然足以實現 P2PKH（Pay to Public Key Hash）、P2SH（Pay to Script Hash）、P2WSH（Pay to Witness Script Hash）等常見的比特幣交易類型，但難以支援更複雜的智慧合約邏輯，例如：

• 循環結構（Loop）
• 動態狀態存儲
• 複雜的條件分支
• 外部資料輸入

比特幣腳本的這種「刻意設計的局限性」長期以來一直是比特幣與以太坊在智慧合約能力上差距的根本原因。以太坊的 EVM（Ethereum Virtual Machine）從一開始就設計為圖靈完整的，這使得開發者可以在以太坊上構建任意複雜的去中心化應用（dApps）。

1.2 為何不在比特幣上直接實現圖靈完整合約？

從技術角度來看，確實可以修改比特幣共識協議以支援圖靈完整的腳本語言。這正是 2017 年比特幣現金（BCH）社群建議通過硬分叉添加更多操作碼的背景。然而，比特幣社群選擇了不同的路線，原因包括：

安全性考量：圖靈完整的腳本語言更容易產生預期之外的行為和安全漏洞。著名的以太坊 DAO 攻擊事件正是由於 Solidity 合約中的重入漏洞（Reentrancy Bug）導致。比特幣的保守設計哲學認為，安全性應優先於功能性。

共識穩定性：比特幣的共識規則是經過十年以上運行驗證的。對共識規則的任何修改都可能導致網路分裂（Fork）和社區爭議。2021 年的 Taproot 升級是比特幣多年來最大的一次共識變更，整個過程經歷了長達數年的討論和測試。

去中心化權衡：複雜的智慧合約可能導致節點驗證成本的增加，進而威脅網路的去中心化程度。比特幣社群普遍認為，保持節點的低運行成本是維護網路健康的關鍵。

1.3 BitVM 的創新思路：將計算移到鏈下

BitVM 的核心創新在於，它沒有嘗試改變比特幣的腳本語言，而是引入了一種巧妙的「承諾-挑戰-響應」機制，將複雜計算的執行移至鏈下，而只在區塊鏈上進行爭議解決。

這種設計思路類似於以太坊的樂觀 rollup，但有以下關鍵差異：

2. BitVM 的核心技術原理

2.1 密碼學承諾與電路表示

BitVM 的技術基礎是密碼學承諾（Cryptographic Commitment）與布林電路（Boolean Circuit）表示。在深入了解 BitVM 之前，我們需要掌握以下核心概念：

承諾方案（Commitment Scheme）：承諾方案允許承諾者在一個初始階段「隱藏」一個值，然後在後續階段「揭示」該值，同時確保：

• 隱藏性（Hiding）：在揭示之前，任何人都無法得知被承諾的值
• 束縛性（Binding）：承諾者無法在揭示階段提交不同於初始承諾的值

常見的承諾方案包括：

• Pedersen 承諾：基於離散對數假設
• Hash 承諾：基於密碼學雜湊函數

布林電路表示：任意計算都可以轉換為布林電路的形式。布林電路由邏輯門（如 AND、OR、NOT、XOR）組成，每個邏輯門的輸出可以作為其他邏輯門的輸入。將計算表示為布林電路的過程稱為「電路生成」（Circuit Compilation）。

# 將簡單計算轉換為布林電路的示例
def compare_to_circuit(a, b, bits=8):
    """
    比較兩個 8 位元數字的電路表示
    輸出：a < b 的布林值
    """
    # 使用全加器實現減法
    # a - b = a + (~b) + 1 的補碼表示
    b_complement = [not b_i for b_i in b]
    
    # 逐位計算並追蹤進位
    carry = True  # 補碼加 1 的進位初始值
    result_bits = []
    
    for i in range(bits):
        sum_bit = a[i] ^ b_complement[i] ^ carry
        carry = (a[i] & b_complement[i]) | (carry & (a[i] ^ b_complement[i]))
        result_bits.append(sum_bit)
    
    # 最高位為 1 表示 a < b（有借位）
    return result_bits[bits - 1]

2.2 承諾階段的運作機制

在 BitVM 中，假設 Prover（證明者）需要向 Verifier（驗證者）證明自己正確執行了某個計算 F(x) = y。整個過程從承諾階段開始：

承諾階段的完整流程：

1. 電路編譯：Prover 首先將計算 F 編譯為布林電路 C。這意味著 C 的邏輯閘數量與計算複雜度成正比。

1. 輸入承諾：Prover 對計算輸入 x 計算承諾 com_x = Commit(x)。此承諾被寫入比特幣區塊鏈的 Taproot 地址中。

1. 執行追蹤：Prover 執行計算 C(x) 並記錄每個邏輯閘的中間輸出值。這些值構成了「執行追蹤」（Execution Trace）。

1. 追蹤承諾：Prover 對執行追蹤的每個值計算密碼學承諾，並將所有承諾組織為 Merkle 樹結構。

1. 結果承諾：Prover 計算最終結果 y 的承諾 com_y = Commit(y)，並將其與 Merkle 根一同發布到比特幣區塊鏈上。

# BitVM 承諾階段的 Python 偽代碼
class BitVMCommitment:
    """
    BitVM 承諾管理器
    處理計算承諾的創建和驗證
    """

    def __init__(self, bitcoin_rpc):
        self.bitcoin_rpc = bitcoin_rpc
        self.commitments = {}

    def create_commitment(self, computation, input_data):
        """
        創建計算承諾

        參數：
          computation: 可呼叫的計算函數 F(x)
          input_data: 計算輸入 x

        返回：
          commitment_data: 包含所有承諾資訊的字典
        """
        # 步驟 1：電路編譯
        circuit = self.compile_to_circuit(computation)
        gate_count = len(circuit.gates)
        print(f"電路包含 {gate_count} 個邏輯閘")

        # 步驟 2：輸入承諾
        input_commitment = self.hash_commit(input_data)
        print(f"輸入承諾：{input_commitment.hex()[:16]}...")

        # 步驟 3：執行追蹤
        execution_trace = self.execute_circuit(circuit, input_data)
        trace_length = len(execution_trace.intermediate_values)
        print(f"執行追蹤包含 {trace_length} 個中間值")

        # 步驟 4：追蹤承諾（Merkle 樹）
        trace_commitments = []
        for i, value in enumerate(execution_trace.intermediate_values):
            comm = self.hash_commit(value)
            trace_commitments.append({
                "index": i,
                "value_commitment": comm,
                "gate_id": value.gate_id,
                "gate_type": value.gate_type
            })

        merkle_tree = self.build_merkle_tree(trace_commitments)
        merkle_root = merkle_tree.root
        print(f"Merkle 根：{merkle_root.hex()[:16]}...")

        # 步驟 5：結果承諾
        result = execution_trace.final_output
        result_commitment = self.hash_commit(result)
        print(f"結果承諾：{result_commitment.hex()[:16]}...")

        # 步驟 6：構建 Taproot 地址
        taproot_address = self.create_taproot_address(
            merkle_root=merkle_root,
            result_commitment=result_commitment,
            input_commitment=input_commitment
        )

        # 存儲承諾資料
        commitment_data = {
            "circuit": circuit,
            "input_commitment": input_commitment,
            "merkle_root": merkle_root,
            "merkle_proof_path": merkle_tree,
            "result_commitment": result_commitment,
            "final_output": result,
            "execution_trace": execution_trace,
            "taproot_address": taproot_address,
            "gate_count": gate_count,
            "created_at": self.bitcoin_rpc.getblockcount()
        }

        self.commitments[taproot_address] = commitment_data

        return commitment_data

    def compile_to_circuit(self, computation):
        """將計算函數編譯為布林電路"""
        # 實際實現中需要使用電路編譯器（如 circom, bellman）
        # 這裡返回一個示例電路結構
        return Circuit(computation)

    def execute_circuit(self, circuit, input_data):
        """執行電路並生成執行追蹤"""
        trace = ExecutionTrace()
        # 逐步執行每個邏輯閘，記錄中間值
        for gate in circuit.gates:
            output = gate.evaluate(trace)
            trace.add_intermediate_value(output)
        trace.finalize(input_data, circuit)
        return trace

    def create_taproot_address(self, merkle_root, result_commitment,
                                input_commitment):
        """創建 BitVM 專用的 Taproot 地址"""
        # 將承諾數據編碼為 Taproot 內部金鑰
        internal_key = self.derive_internal_key(
            merkle_root, result_commitment, input_commitment
        )

        # 創建 Taproot 地址
        taproot_script = self.create_taproot_script(internal_key)
        address = self.bitcoin_rpc.create_taproot_address(
            internal_key, [taproot_script]
        )

        return address

2.3 挑戰-響應機制的運作原理

當 Verifier 對 Prover 提交的計算結果產生懷疑時，挑戰-響應機制被觸發。這是 BitVM 最核心的部分，它允許任何人（而不僅僅是初始的 Verifier）在區塊鏈上挑戰 Prover 的計算結果。

挑戰遊戲的理論基礎：挑戰遊戲採用二分搜尋法（Binary Search）來定位錯誤。如果 Prover 的計算存在錯誤，二分搜尋可以快速定位到出錯的邏輯閘。

二分搜尋的數學原理：

假設電路包含 N 個邏輯閘，我們懷疑 Prover 的計算結果存在錯誤。標準的二分搜尋過程如下：

搜尋空間：[0, N-1]  // 所有可能的錯誤位置

第 1 輪：
  - 挑戰者要求 Prover 提供前 N/2 個閘的執行追蹤
  - 如果錯誤在前 N/2 個閘中，繼續在 [0, N/2) 搜尋
  - 否則，繼續在 [N/2, N) 搜尋

第 2 輪：
  - 在剩餘的 N/4 個可能位置中重複上述過程
  ...

經過 log₂(N) 輪後，可以精確定位到錯誤所在的邏輯閘

比特幣腳本的實現限制：比特幣腳本不支援直接在鏈上執行二分搜尋。因此，BitVM 採用了一種稱為「小額結算」（Micro-Settlement）的替代方案：

1. Prover 和 Verifier 各自向一個多簽地址存入保證金（例如各 1 BTC）
2. 如果雙方對計算結果沒有爭議，資金自動釋放
3. 如果 Verifier 想要挑戰，他首先發起「挑戰交易」並支付少量手續費
4. Prover 需要在規定時間窗口內回應挑戰
5. 這個來回過程可以重複多輪，每次只有小額資金在遊戲中被「鎖定」
6. 如果某方拒絕回應，另一方可以通過比特幣腳本的時間鎖機制索取爭議中的資金

# BitVM 挑戰-響應機制的 Python 模擬
class BitVMBinaryChallenge:
    """
    BitVM 二分挑戰管理器
    實現挑戰遊戲的邏輯
    """

    def __init__(self, commitment_data, challenger_address):
        self.commitment = commitment_data
        self.challenger = challenger_address
        self.challenge_round = 0
        self.locked_amount = 0.001  # BTC
        self.time_lock_blocks = 144  # 約 24 小時

    def initiate_challenge(self):
        """發起挑戰"""
        self.challenge_round = 1
        print(f"挑戰者 {self.challenger} 發起挑戰")
        print(f"回合 {self.challenge_round}：")

        # 第一輪：Prover 需提供電路的「一半」追蹤
        midpoint = len(self.commitment["execution_trace"].gates) // 2
        requested_range = (0, midpoint)

        print(f"  要求 Prover 提供閘 {requested_range[0]} 到 {requested_range[1]} 的追蹤")
        print(f"  Prover 鎖定 {self.locked_amount} BTC 作為誠信保證")

        return requested_range

    def prover_response(self, range_start, range_end, provided_trace):
        """Prover 回應挑戰"""
        # 驗證 Prover 提供的追蹤是否與承諾一致
        is_valid = self.verify_trace_against_commitment(
            range_start, range_end, provided_trace
        )

        if not is_valid:
            # Prover 提供了不一致的追蹤
            print("  驗證失敗：Prover 的追蹤與初始承諾不一致！")
            self.execute_punishment("prover")
            return {"status": "prover_punished", "reason": "inconsistent_trace"}

        # 追蹤一致，檢查計算是否正確
        gate_count = len(self.commitment["execution_trace"].gates)

        if range_start == 0 and range_end == gate_count:
            # 完整範圍驗證
            is_correct = self.verify_computation(provided_trace)
        else:
            # 部分範圍驗證：需要繼續二分
            mid = (range_start + range_end) // 2

            # 假設這輪沒有發現錯誤，繼續下一輪
            next_challenge_range = self.challenger_request_next_range(
                range_start, range_end, mid
            )

            return {
                "status": "continue",
                "next_round": self.challenge_round + 1,
                "requested_range": next_challenge_range
            }

        if not is_correct:
            print("  驗證失敗：計算結果與預期不符！")
            self.execute_punishment("prover")
            return {"status": "prover_punished", "reason": "wrong_computation"}

        print("  驗證成功：Prover 的計算在該範圍內正確")
        return {"status": "verified"}

    def challenger_request_next_range(self, current_start, current_end, midpoint):
        """挑戰者請求下一個範圍"""
        # 假設我們選擇前半部分繼續挑戰
        # 實際實現中會根據計算複雜度和策略選擇
        print(f"  挑戰者選擇前半部分 [0, {midpoint}) 繼續挑戰")
        return (current_start, midpoint)

    def verify_trace_against_commitment(self, start, end, trace):
        """驗證追蹤與初始承諾的一致性"""
        for i in range(start, end):
            expected_commit = self.commitment["execution_trace"].commitments[i]
            actual_commit = self.hash_commit(trace[i])

            if expected_commit != actual_commit:
                return False

        return True

    def verify_computation(self, trace):
        """驗證計算的正確性"""
        # 重新執行電路並比較結果
        expected_result = self.commitment["final_output"]
        # 實際實現中需要完整電路重放
        return True  # 簡化示例

    def execute_punishment(self, guilty_party):
        """執行處罰"""
        penalty_amount = self.locked_amount * 2  # 罰款為誠信保證金的兩倍

        if guilty_party == "prover":
            # 罰款支付給挑戰者
            print(f"Prover 被處罰 {penalty_amount} BTC，支付給挑戰者")
        else:
            # 罰款支付給 Prover
            print(f"挑戰者被處罰 {penalty_amount} BTC，支付給 Prover")

        self.commitment["resolved"] = True
        self.commitment["winner"] = (
            "challenger" if guilty_party == "prover" else "prover"
        )

2.4 BitVM 2.0 的非互動式驗證革新

2024 年底發布的 BitVM 2.0 帶來了最重要的技術升級：非互動式驗證。這個創新解決了 BitVM 1.0 的一個根本性問題：Prover 必須在線並及時回應挑戰。

互動式驗證的問題：在 BitVM 1.0 中，如果 Prover 在收到挑戰後選擇「消失」（不回應），資金可能永久鎖定在合約中。這種「活躍驗證」模型雖然理論上安全，但在實際應用中難以部署——特別是當 Prover 位於不同時區、或網路連接不穩定時。

非互動式驗證的解決方案：BitVM 2.0 採用 Fiat-Shamir 啟發式轉換，將互動式協議轉換為非互動式版本：

互動式版本：
  Verifier -> Prover: 隨機挑戰（需要即時通信）
  Prover -> Verifier: 響應（需要即時通信）

非互動式版本：
  Prover: c = Hash(commitment || public_input || block_hash)
  Prover -> Blockchain: 承諾 + c + 響應（無需即時通信）

比特幣區塊哈希在此扮演「公共隨機性來源」的角色。由於區塊哈希在開採出來之前無法預測，它提供了一個可信的隨機數生成器。

預承諾軌跡結構：BitVM 2.0 要求 Prover 在初始承諾時就包含「所有可能的挑戰路徑」。這意味著，無論挑戰者何時發起挑戰，挑戰軌跡都已經被預先揭示並承諾。

3. BitVM 的安全性模型分析

3.1 安全性假設

BitVM 的安全性建立在以下假設之上：

假設一：至少一個誠實的挑戰者

在任意時間窗口內，網路中至少存在一個願意發起挑戰的誠實參與者。這個假設類似於以太坊樂觀 rollup 中的「至少一個誠實驗證者」假設。

假設二：Prover 的經濟理性

Prover 是經濟理性的代理人，不會發起一個「必然失敗」的欺詐。因為欺詐不僅會導致計算被拒絕，還會損失質押的保證金。

假設三：比特幣共識的安全性

所有最終結算都在比特幣區塊鏈上完成，因此 BitVM 的安全性不會超過比特幣本身的安全性。如果比特幣網路遭受 51% 攻擊，BitVM 的保障也會失效。

3.2 安全性量化分析

讓我們量化分析 BitVM 的安全保障。假設：

• Prover 的欺詐概率為 p
• 每次欺詐被發現後，Prover 損失保證金 M（BTC）
• 挑戰成本為 C（BTC）

欺詐的期望收益：

EV_fraud = p × (欺詐成功收益) - (1-p) × M

假設欺詐成功意味著 Prover 可以偷竊 N BTC 的資金，則：

EV_fraud = p × N - (1-p) × M

當 N > M / p 時，欺詐才有意義。

在實際部署中，通過設置足夠大的 M（相對於 N），可以確保欺詐的期望收益為負。

3.3 攻擊向量分析

延遲攻擊（Delay Attack）

攻擊者透過不斷發起「邊緣」挑戰來延遲 Prover 的結算。這種攻擊的成本是每次挑戰的手續費，而收益可能是操縱市場價格。

緩解措施：設置挑戰間隔下限（Cooldown Period），確保 Prover 有足夠時間回應。

費用攻擊（Fee Attack）

攻擊者透過提高比特幣網路費用來增加挑戰遊戲的成本，使挑戰變得不經濟。

緩解措施：在 Layer 2 層面處理挑戰遊戲，只在必要時與比特幣主鏈交互。

串通攻擊（Collusion Attack）

Prover 與 Verifier 串通，Prover 提交錯誤結果後，雙方都不發起真正的挑戰，導致欺詐成功。

緩解措施：開放挑戰權——任何人都可以發起挑戰，而非僅限於初始的 Verifier。

4. BitVM 的應用場景

4.1 去中心化預言機

BitVM 最直接的應用之一是構建去中心化預言機（Oracle）。預言機將外部世界數據（如價格資訊、天氣資料、體育比分）引入區塊鏈智慧合約。

傳統預言機（如 Chainlink）依賴於一組可信的預言機節點。BitVM 可以將預言機的信任模型從「信任節點」轉變為「信任密碼學」。

BitVM 預言機的工作流程：

1. 多個資料提供者各自計算同一外部資料的 commitment
2. 資料被「提交」到 BitVM 合約中
3. 任何人都可以挑戰錯誤的資料
4. 爭議透過挑戰遊戲解決

4.2 跨鏈橋接

基於 BitVM 的跨鏈橋是另一個重要應用。傳統的跨鏈橋（如 WBTC）依賴於中心化托管商，存在單點失敗風險。

BitVM 跨鏈橋的優勢：

• 資金由密碼學機制保障，而非中心化托管
• 任何人可以發起挑戰，提高安全性
• 不依賴於特定的受信任方

4.3 去中心化交易所（DEX）

BitVM 可以支援比特幣原生的去中心化交易所，實現比特幣与其他資產的無托管交易。

典型功能包括：

• 訂單匹配
• 價格發現
• 結算確認
• 爭議解決

4.4 借貸協議

去中心化借貸協議允許用戶無需傳統銀行即可借入或借出比特幣。BitVM 可以用於：

• 抵押品價值驗證
• 清算觸發條件驗證
• 利率計算

5. BitVM 與其他比特幣智慧合約方案的比較

5.1 方案總覽

比特幣生態中存在多種智慧合約擴展方案：

5.2 比較分析

BitVM vs Stacks

• Stacks 在比特幣區塊鏈之上運行獨立的區塊鏈，通過「轉移證明」（Proof of Transfer）與比特幣整合
• BitVM 的結算直接發生在比特幣主鏈上，不需要獨立的區塊鏈
• Stacks 的交易容量更高，但安全性依賴於 Stacks 網路本身

BitVM vs RGB

• RGB 採用「客戶端驗證」模型，合約狀態儲存在鏈下，只有承諾和轉移記錄在比特幣上
• BitVM 的爭議解決發生在比特幣鏈上
• RGB 更適合簡單的代幣轉移場景，BitVM 更適合複雜的計算場景

BitVM vs Lightning Network

• 閃電網路專注於支付場景，支援即時、低成本的比特幣轉帳
• BitVM 支援更通用的計算場景
• 兩者可以互補：閃電網路處理微支付，BitVM 處理複雜合約

6. 當前限制與未來發展

6.1 當前技術限制

電路規模限制

BitVM 的電路表示受到比特幣腳本運算能力的限制。複雜計算（如大型語言模型推理）需要巨大的電路規模，目前難以在 BitVM 上直接實現。

挑戰延遲

挑戰遊戲的每次交互都需要比特幣區塊確認。10 分鐘的平均區塊時間意味著完整的挑戰流程可能需要數小時甚至數天。

工具鏈成熟度

BitVM 的開發工具、調試環境和測試框架仍在早期階段。開發者需要較高的密碼學和比特幣專業知識才能有效使用 BitVM。

6.2 未來發展方向

BitVMX

BitVMX 是 BitVM 的輕量級實現方案，採用遞歸驗證結構，可以大幅降低驗證節點的計算負擔。

zkVM

結合零知識證明（ZKP）技術，實現無需挑戰的即時驗證。這需要更高效的 ZK 電路生成和驗證算法。

與 Layer 2 整合

BitVM 與閃電網路、Ark 等 Layer 2 方案的整合將進一步擴展其應用範圍。

7. 結論

BitVM 代表了比特幣智慧合約能力的一次重大突破。通過巧妙的「承諾-挑戰-響應」機制，BitVM 在不改變比特幣核心共識的情況下，實現了任意計算的可驗證性。這為比特幣 DeFi 生態的發展打開了的大門，使得去中心化預言機、跨鏈橋、去中心化交易所等應用成為可能。

儘管 BitVM 目前仍處於早期發展階段，存在電路規模限制、挑戰延遲等技術挑戰，但其核心設計理念已經得到了比特幣社群的廣泛認可。隨著 BitVM 2.0 的發布和後續技術優化，BitVM 有望成為比特幣生態系統的重要基礎設施。

對於比特幣開發者和投資者而言，理解 BitVM 的技術原理和應用前景對於把握比特幣未來發展方向具有重要意義。我們建議讀者持續關注 ZeroSync 團隊和更廣泛比特幣社群在 BitVM 開發方面的最新進展。

參考文獻

1. Buterin, Z., & Herzberg, A. (2023). BitVM: Compute on Bitcoin. ZeroSync.
2. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
3. Ethereum Foundation. (2024). Optimistic Rollups. Ethereum Documentation.
4. Bitcoin Optech. (2024). Taproot and BitVM. Bitcoin Optech Newsletter.
5. ZeroSync Team. (2024). BitVM 2.0 Specification. GitHub Repository.

標籤：比特幣、BitVM、智慧合約、Layer2、密碼學、預言機、跨鏈橋、DeFi、去中心化、零知識證明

相關文章：

• BitVM 2.0 非互動式驗證與主網部署深度分析
• BitVM 腳本編程實戰：從理論到部署的完整技術教學
• BitVM 預言機與比特幣結算層應用案例深度分析
• 比特幣與人工智慧整合的未來：BitVM、DePIN 與算力市場

最後更新：2026-03-22