Bitcoin Script 實戰教學（六）：進階應用與未來展望

系列導言

這是「Bitcoin Script 實戰教學」系列的最後一篇。經過前五篇的學習，你已經掌握了比特幣腳本的基礎知識、各種標準腳本類型、SegWit 和 Taproot 的技術細節、多重簽名實現，以及時間鎖機制。在這一篇中，我們將探索比特幣腳本的前沿應用，包括 DLC（Discreet Log Contracts）、Vault 設計模式、Covenant 提案，以及未來可能的發展方向。

系列文章：

一、Discreet Log Contracts（DLC）

1.1 什麼是 DLC？

DLC（謹慎日誌合約）是一種創新的比特幣智能合約形式，允許兩方基於現實世界的事件結果進行條件支付。它由 Tadge Dryja（閃電網路的共同發明者）在 2018 年提出，解決了一個長期存在的問題：如何在不信任任何中心化實體的情況下，在比特幣上執行依賴外部數據的合約。

考慮這樣的場景：Alice 和 Bob 想要對 2025 年底比特幣的價格進行賭注。Alice 賭價格會超過 10 萬美元，Bob 賭不會。在傳統系統中，他們需要一個可信的第三方來判定結果並執行支付。DLC 則允許他們創建一個合約，由一個獨立的「神諭」（Oracle）來證明結果，但這個神諭甚至不需要知道合約的存在。

這裡的「謹慎」（Discreet）有雙重含義。首先，神諭發布的是通用數據（如「2025-12-31 BTC/USD = 102,345」），而不是針對特定合約的裁決，這意味著神諭不知道誰在使用它的數據。其次，DLC 交易在鏈上看起來就像普通的多簽名交易，觀察者無法判斷這是一個 DLC 結算。

1.2 Adaptor Signatures：DLC 的密碼學基礎

DLC 的核心技術是 Adaptor Signatures（適配器簽名），這是一種密碼學構造，允許創建「不完整」的簽名，只有在獲得某個秘密值後才能變成有效簽名。

在標準的 Schnorr 簽名中，簽名者用私鑰 d、隨機數 k、和訊息 m 計算簽名 (R, s)，其中 R = k × G，s = k + H(R, P, m) × d。驗證者可以用公式 s × G = R + H(R, P, m) × P 來驗證。

適配器簽名引入了一個「適配點」T = t × G，其中 t 是適配秘密。簽名者創建一個「不完整」簽名 (R’, s’)，其中 R’ = R + T。這個簽名單獨無法通過驗證，但如果有人知道 t，他們可以計算 s = s’ + t，得到相對於 R’ 的有效簽名。

這個機制的妙處在於：給定 (R’, s’) 和完成的簽名 (R’, s)，任何人都可以計算出 t = s - s’。這意味著使用適配器簽名會「揭示」適配秘密。

1.3 DLC 的工作流程

讓我們詳細看看 DLC 是如何工作的。

首先是設置階段。Alice 和 Bob 協商合約條款，包括：事件（如「2025-12-31 的 BTC/USD 價格」）、可能的結果（如價格區間）、每種結果對應的支付分配。然後他們找到一個或多個可信的神諭，獲取神諭的公鑰和對這個事件的「承諾點」。承諾點代表神諭將為每個可能結果發布的簽名對應的公鑰。

接下來是資金鎖定。雙方創建一筆「Funding Transaction」，將各自的資金鎖定到一個 2-of-2 多簽輸出。這筆交易上鏈後，資金就無法被任何一方單獨移動。

然後是預簽 CET（Contract Execution Transaction）。這是 DLC 的核心。對於每個可能的結果，雙方創建一筆 CET，表示該結果發生時的資金分配。例如，如果有 100 個可能的價格區間，就會有 100 筆不同的 CET。

關鍵在於：這些 CET 不是用普通簽名，而是用適配器簽名。每筆 CET 的適配點是神諭對該結果的簽名對應的公鑰。這意味著只有當神諭發布特定結果的簽名時，對應的 CET 才能被完成並廣播。

最後是結算。當事件發生時，神諭發布結果和對應的簽名 s。獲勝方使用這個簽名作為適配秘密，完成對應 CET 的適配器簽名，得到有效簽名，然後廣播 CET 獲取資金。

這個機制的優美之處在於：神諭只發布一次數據，完全不知道誰在使用它；雙方在設置階段就交換了所有需要的信息，結算時不需要額外互動；整個過程在鏈上看起來只是普通的多簽名操作。

1.4 DLC 的應用場景

DLC 開啟了比特幣上許多之前不可能實現的應用。

金融衍生品是最直接的應用。期貨、期權、差價合約都可以用 DLC 實現。例如，一個比特幣礦工可以使用 DLC 對沖未來的價格風險，而不需要依賴任何中心化交易所。

合成資產允許用戶獲得對其他資產（如股票、黃金、其他加密貨幣）的價格敞口，而只使用比特幣作為抵押品。這在傳統金融受限或不信任中心化服務的地區特別有價值。

保險合約也可以用 DLC 實現。航班延誤保險可以基於航班數據神諭自動結算；農業保險可以基於天氣數據；甚至健康保險的某些類型也可以這樣設計。

預測市場讓用戶可以對任何有明確結果的事件進行預測和投注。體育賽事、選舉結果、科學發現——只要有可靠的神諭能證明結果，就可以建立 DLC。

二、Vault 設計模式

2.1 為什麼需要 Vault？

比特幣的安全模型建立在私鑰控制上：誰擁有私鑰，誰就能花費對應的比特幣。這種模型簡單直接，但也意味著一旦私鑰洩露，資金立即面臨風險，而且通常無法追回。

Vault（金庫）是一種設計模式，旨在為這個問題提供一層額外的保護。它的核心思想是：即使熱密鑰（用於日常操作的密鑰）被盜，攻擊者也無法立即獲得資金。相反，任何提款嘗試都需要經過一段等待期，在此期間，真正的擁有者可以發現攻擊並採取行動——使用一個更安全的「恢復密鑰」將資金轉移到安全地址。

這個概念類似於傳統銀行的大額轉帳延遲或企業的多級審批流程。它創造了一個時間窗口，讓安全監控和人為干預成為可能。

2.2 使用預簽交易實現 Vault

在目前的比特幣腳本限制下，實現 Vault 的主要方法是使用預簽交易。這種方法有其局限性，但已經可以提供有價值的保護。

Vault 的結構包含兩種密鑰。熱密鑰用於發起提款，可能存儲在連接網路的設備上，面臨被盜的風險。恢復密鑰是高安全級別的密鑰，可能是多簽、分散在多個地理位置、或存儲在硬體錢包中，用於在緊急情況下恢復資金。

Vault 輸出的腳本設計有兩條路徑。第一條是正常提款路徑：使用熱密鑰簽名，將資金轉移到一個「Unvault」狀態，這個狀態有 CSV 時間鎖（例如一週）。第二條是緊急恢復路徑：使用恢復密鑰簽名，可以立即將資金轉移到預設的冷存儲地址。

Unvault 狀態同樣有兩條路徑。第一條是完成提款：等待 CSV 延遲期結束後，用熱密鑰簽名提取資金到目標地址。第二條是取消提款：使用恢復密鑰，立即將資金轉回冷存儲。

2.3 預簽交易的工作流程

設置 Vault 時，用戶需要預先簽署一系列交易。

首先是 Unvault 交易：從 Vault 輸出到 Unvault 狀態的轉換。然後是 Withdrawal 交易：從 Unvault 狀態到最終目的地的轉換，帶有 CSV 延遲。接著是 Recovery 交易：從 Vault 直接到冷存儲的緊急轉移。最後是 Cancel 交易：從 Unvault 狀態回到冷存儲的取消操作。

這些交易需要在存入資金之前就簽署好，而且必須安全存儲。特別是 Withdrawal 交易需要為每個可能的目的地預先準備，這限制了靈活性。

正常提款流程是：廣播 Unvault 交易，等待 CSV 延遲（例如 1008 個區塊，約一週），然後廣播 Withdrawal 交易。

緊急恢復流程是：發現異常活動（例如收到 Unvault 交易被廣播的警報），在延遲期結束之前，使用恢復密鑰廣播 Cancel 或 Recovery 交易。

2.4 當前 Vault 的限制

預簽交易方式的 Vault 有幾個顯著限制。

目的地必須預先確定：由於需要預先簽署 Withdrawal 交易，你必須在設置時就知道所有可能的提款目的地。這對於想要靈活提款的用戶來說很不方便。

金額不可分割：預簽交易鎖定了整個 Vault 的金額，無法只提取部分資金。

安全刪除問題：如果攻擊者獲得了預簽的交易副本，他們可以嘗試使用它。確保舊的預簽交易被完全銷毀是困難的。

手續費固定：預簽交易的手續費率在簽署時就確定了，無法適應未來的網路條件。

這些限制的根本原因是比特幣腳本目前無法「內省」交易本身——腳本無法檢查「這筆花費交易必須發送到特定地址」或「必須保持特定金額」。這正是 Covenant 提案試圖解決的問題。

三、Covenant：限制未來的花費方式

3.1 什麼是 Covenant？

Covenant（契約/公約）是一個密碼學和智能合約術語，指的是對 UTXO 未來如何被花費的限制。在目前的比特幣腳本中，你可以限制「誰」可以花費（透過簽名要求）和「何時」可以花費（透過時間鎖）。但你無法限制花費交易的其他屬性，如輸出的目的地、金額，或結構。

Covenant 填補了這個空白。有了 Covenant，你可以創建這樣的腳本：「這筆資金只能被轉移到以下三個地址之一」，或「提款必須分批進行，每次最多 10%」，或「這筆交易的找零必須回到同樣的 Covenant 保護下」。

這個能力看似簡單，但影響深遠。它使得許多目前不可能或需要信任的應用成為可能，同時也引發了關於審查和可替代性的擔憂。

3.2 主要的 Covenant 提案

比特幣社區正在討論幾個不同的 Covenant 實現方案，每個都有不同的功能範圍和權衡。

OP_CHECKTEMPLATEVERIFY（CTV，BIP 119）是最保守的提案。它允許腳本承諾一個精確的未來交易「模板」——包括輸出的數量、腳本、金額，以及鎖定時間。花費交易必須精確匹配這個模板。CTV 是功能最有限的 Covenant，但也因此最容易分析其安全性和影響。它已經經過多年審查，可能是最接近被激活的提案。

OP_VAULT（BIP 345）是專門為 Vault 用例設計的。它引入兩個新操作碼：OP_VAULT 和 OP_VAULT_RECOVER。OP_VAULT 創建一個可以被「觸發」進入等待狀態的輸出，然後在延遲後完成提款。OP_VAULT_RECOVER 允許在等待期間將資金恢復到安全地址。這個提案解決了預簽 Vault 的許多限制，允許靈活的目的地和部分提款。

OP_CAT（BIP 347）是一個被「復活」的提案。OP_CAT 在比特幣早期存在，但因為擔心記憶體攻擊而被禁用。現在提議在 Tapscript 中重新啟用它，並設置 520 位元組的輸出限制。OP_CAT 本身只是串接兩個堆疊元素，但它可以與其他現有操作碼組合，實現相當強大的 Covenant。透過在腳本中重建交易結構並驗證其雜湊，可以間接檢查交易的屬性。

更激進的提案如 OP_TXHASH 允許將交易的任何欄位的雜湊推入堆疊，提供完全的交易內省能力。這功能最強但也最有爭議，因為它可能對比特幣的審查抵抗性和可替代性產生影響。

3.3 CTV 的具體應用

讓我們看看 CTV 可以實現的一些具體應用。

擁塞控制（Congestion Control）是 CTV 最引人注目的用例。想像一個交易所需要同時處理 10,000 個用戶提款。在目前的系統中，這需要一筆巨大的交易（或多筆較大的交易），在網路擁塞時成本極高。

使用 CTV，交易所可以創建一棵「展開樹」。根交易只有一個輸出，承諾到特定的展開結構。這個輸出可以被展開成 100 個子輸出，每個子輸出又承諾到進一步的展開。最終，10,000 個用戶中的每一個都可以領取自己的資金。

優雅的是，這個展開可以是「惰性的」。根交易可以在費用便宜時上鏈，承諾了所有用戶的餘額。之後，每個用戶可以在任何時候展開自己的路徑來領取資金，而不需要其他用戶的配合。如果費用降低，可以一次展開更大的部分；如果費用上升，可以只展開自己關心的路徑。

另一個應用是改進的 Vault。有了 CTV，Vault 可以不需要預簽所有可能的提款交易。相反，Vault 輸出可以承諾一個模板，這個模板指定必須有一個回到同類型 Vault 的找零輸出，而提款金額可以是任意的。這解決了預簽 Vault 的金額不可分割問題。

3.4 Covenant 的擔憂

Covenant 的引入不是沒有爭議的。主要擔憂包括以下幾個方面。

審查向量：如果可以創建「只能轉移到特定地址」的比特幣，監管機構可能會要求交易所只接受「合規」的 Covenant 代幣。這可能導致不同等級的比特幣，損害可替代性。

複雜性增加：更強大的腳本功能意味著更多的攻擊面和更難審計的合約。已經有一些簡單的 bug 導致了資金損失，更複雜的系統可能會有更多這類問題。

遞迴 Covenant：某些 Covenant 設計（不包括 CTV）允許創建「永久」的限制，資金可能被永久困在某種結構中。這引發了關於比特幣長期可用性的擔憂。

支持者認為這些擔憂被誇大了。Covenant 是選擇加入的——如果你不想使用有限制的比特幣，你可以不接受它們。而其提供的功能——更好的自我託管安全、更高效的交易——對生態系統的價值超過了假設的風險。這個辯論仍在進行中。

四、BitVM：在比特幣上驗證任意計算

4.1 突破腳本限制的思路

比特幣腳本是有意設計為受限的——它不是圖靈完備的，沒有循環，操作碼有限。這是為了安全和可預測性。但如果我們想在比特幣上執行更複雜的邏輯怎麼辦？

BitVM 是 2023 年提出的一個突破性想法：不在鏈上執行計算，而是在鏈上驗證計算。這種模式稱為「樂觀執行」（Optimistic Execution），借鑑了以太坊 Optimistic Rollup 的概念。

核心思想是：如果雙方對計算結果有共識，就不需要任何鏈上驗證。只有當有人聲稱錯誤結果時，才需要在鏈上證明誰對誰錯。而且這個證明可以被設計得非常小，即使原始計算非常複雜。

4.2 挑戰-回應協議

BitVM 使用二分搜尋的挑戰-回應協議來定位錯誤。

假設 Operator 聲稱 f(x) = y，但 Verifier 認為正確答案應該是 y’。雙方的資金鎖定在一個需要正確結算的合約中。

協議開始時，Operator 發布整個計算軌跡的 Merkle 樹根。這個軌跡記錄了從輸入 x 到輸出 y 的每一步中間狀態。

然後進入二分搜尋。Verifier 選擇軌跡的前半部分或後半部分，要求 Operator 打開。Operator 提供所選部分的 Merkle 證明。如果這部分是正確的，Verifier 將搜尋範圍縮小到另一半；如果這部分已經有錯誤，繼續在這半部分搜尋。

經過 log(N) 輪互動（N 是計算步驟數），雙方定位到單個錯誤步驟。這一步可以在鏈上驗證——執行單個 NAND 門或類似的基本操作是比特幣腳本可以做到的。

如果 Operator 在這一步無法提供有效證明，Verifier 獲得 Operator 的質押金。如果 Operator 是誠實的，Verifier 無法找到錯誤步驟，Operator 保留資金。

4.3 BitVM 的應用

BitVM 最引人注目的應用是去信任的跨鏈橋。

目前的比特幣跨鏈橋大多依賴聯邦多簽：一組操作者控制比特幣端的資金，用戶需要信任他們不會共謀盜取資金。歷史上確實發生過多起橋被攻擊或內部作弊的事件。

使用 BitVM，橋可以這樣運作：用戶在比特幣上鎖定資金，在目標鏈（如以太坊）上收到等值代幣。當用戶想要贖回時，在目標鏈上銷毀代幣，然後 Operator 在比特幣上釋放資金給用戶。

如果 Operator 誠實，流程順利進行。如果 Operator 不釋放資金或嘗試欺詐，用戶（或任何觀察者）可以發起 BitVM 挑戰，證明 Operator 的聲明是錯誤的，從而獲得 Operator 的質押金並恢復資金。

這創造了一個「1-of-N」的信任模型：只要有一個誠實的 Verifier 在監控，欺詐就會被發現和懲罰。這比「M-of-N」的多簽模型安全得多，因為後者需要大多數參與者誠實。

其他應用包括 ZK 證明驗證（在比特幣上驗證零知識證明的正確性）、複雜的 DeFi 邏輯（借貸、自動做市商等，雖然互動性有限制）、以及計算密集型的合約（任何可以編譯成電路的程式）。

4.4 BitVM 的限制

BitVM 不是萬能的，它有顯著的限制。

互動性要求：挑戰協議需要雙方多輪互動。如果一方離線，協議可能超時。這使得 BitVM 更適合有明確交易對手的場景，而不是開放式的智能合約。

延遲：挑戰期（通常一到兩週）是必要的，以確保有足夠時間發現和證明欺詐。這意味著 BitVM 不適合需要即時結算的應用。

複雜性：實現一個安全的 BitVM 系統需要大量的工程努力。預簽交易的數量可能非常龐大，存儲和管理是挑戰。

有限的表達能力：雖然理論上可以驗證任意計算，但實際上受到電路大小和挑戰輪數的限制。

儘管有這些限制，BitVM 代表了在比特幣上實現更複雜邏輯的重要一步，而且不需要任何協議變更。

五、腳本優化實踐

5.1 大小與費用的關係

在比特幣中，交易費用主要由交易的「虛擬大小」（vbytes）決定。虛擬大小的計算考慮了 SegWit 的權重折扣：非 witness 數據每位元組計 4 個權重單位，witness 數據每位元組計 1 個權重單位。虛擬大小 = (總權重 + 3) / 4。

這意味著優化腳本大小可以直接節省費用。對於多簽名、複雜條件等場景，精心設計的腳本可能比樸素實現節省 20-30% 的費用。

5.2 實用優化技巧

利用隱式操作碼。OP_CHECKSIG 在失敗時會使整個腳本失敗，所以不需要額外的 OP_VERIFY。類似地，OP_EQUALVERIFY、OP_CHECKSIGVERIFY 等合併操作碼比分開的操作更緊湊。

重用堆疊元素。如果同一個值需要使用多次，用 OP_DUP 複製比再次推入堆疊更節省空間。

使用最短編碼。OP_1 到 OP_16 各只需 1 個位元組，而推入對應的數字需要 2 個位元組。負數和大數字的編碼也要注意使用最小表示。

優化 Taproot 腳本樹。將最可能使用的腳本放在樹的淺層（接近根部），這樣花費時需要揭示的 Merkle 路徑更短。對於多條件腳本，仔細分析每條路徑的使用概率。

考慮聚合。對於 n-of-n 多簽，使用 MuSig2 將所有簽名聚合成一個，這比 n 個獨立簽名節省大量空間。即使對於 m-of-n，有時候也可以設計備用的聚合路徑。

5.3 安全與效率的權衡

優化不能以犧牲安全為代價。一些需要注意的陷阱包括以下幾點。

不要跳過必要的驗證。例如，確保所有分支都正確終止，即使看起來「不可達」的分支也可能因為意外輸入而被執行。

注意簽名雜湊類型。SIGHASH_NONE 和 SIGHASH_SINGLE 可能意外地允許修改輸出，只有在完全理解其影響時才使用。

時間鎖需要安全邊際。區塊時間有波動，MTP 與實際時間可能有偏差。設計時間鎖時要留有餘裕。

測試所有路徑。使用腳本調試工具（如 btcdeb）測試腳本的每條可能執行路徑，包括失敗情況。

六、未來展望

6.1 當前腳本能力總結

讓我們總結一下比特幣腳本目前能做什麼和不能做什麼。

可以做到的包括：各種簽名驗證（單簽、多簽、聚合簽名）、絕對和相對時間鎖、雜湊鎖和 HTLC、複雜的條件邏輯、Taproot 的隱藏腳本樹、預簽交易實現的 Vault、依賴神諭的 DLC、透過樂觀執行的任意計算驗證（BitVM）。

無法直接做到（需要協議升級）的包括：檢查花費交易的輸出目的地、檢查花費交易的輸出金額、循環和遞迴計算、原生的零知識證明驗證、完全靈活的 Covenant。

6.2 可能的協議升級

比特幣的升級過程謹慎而緩慢，但社區正在積極討論幾個可能的改進。

短期可能實現的包括：OP_CTV 已經過多年審查，有可能在未來幾年內透過軟分叉激活。它將啟用擁塞控制和改進的 Vault，同時風險相對較低。

OP_CAT 的復活也在討論中。雖然它單獨功能有限，但與現有操作碼組合可以實現許多 Covenant 用例。由於 Tapscript 有堆疊元素大小限制，早期的安全擔憂已大大減輕。

中期可能探索的包括：OP_VAULT 提供了專門的 Vault 功能，比通用 Covenant 更容易分析影響。SIGHASH_ANYPREVOUT 允許更好的閃電網路協議（如 Eltoo），可能與其他升級一起打包。

長期研究方向包括：原生 ZK 驗證將允許在比特幣上直接驗證零知識證明，這對可擴展性和隱私有深遠影響。更強大的 Covenant 和腳本能力也在研究中，但需要在功能和風險之間找到平衡。

6.3 生態系統的發展

除了協議層面的變化，比特幣腳本的應用生態也在快速發展。

工具鏈在改進。Miniscript 提供了一種更安全的方式來編寫和分析腳本，許多錢包和服務正在採用。腳本調試、形式驗證、自動測試工具都在進步。

標準化在推進。描述符（Descriptors）成為錢包備份和恢復的標準格式。PSBT 使多方協作更加容易。MuSig2 的廣泛採用提升了多簽的效率和隱私。

應用在擴展。閃電網路持續增長，DLC 平台開始上線，Vault 解決方案進入生產環境。這些應用驗證了比特幣腳本的實用性，也推動了進一步的創新。

七、實作練習

練習 1：設計 DLC 結構

選擇一個簡單的二元事件（如「明天會下雨嗎？」），設計完整的 DLC 結構。考慮：如何找到可靠的神諭？如何處理神諭不發布結果的情況？計算需要多少個 CET。

練習 2：預簽 Vault 實現

使用你熟悉的比特幣程式庫，實現一個簡化的預簽 Vault。包括：創建 Vault 輸出、預簽 Unvault 和 Withdrawal 交易、模擬正常提款和緊急恢復流程。思考在生產環境中需要解決的額外問題。

練習 3：CTV 擁塞控制模擬

假設 CTV 已經激活，設計一個擁塞控制樹來處理 1000 個接收者的批量支付。計算不同樹結構（深度、分支因子）的權衡，比較與傳統大交易的費用差異。

八、總結

這一系列文章帶你從比特幣腳本的基礎走到了最前沿的應用。讓我們回顧關鍵要點。

比特幣腳本是一個有意設計為受限的系統，它不是為了與以太坊競爭「智能合約平台」的地位，而是為了提供安全、可驗證、可預測的價值轉移能力。在這個設計空間內，我們仍然可以構建令人印象深刻的應用。

多簽和時間鎖是兩個最基本的構建塊。多簽將控制權從單點分散到多點，時間鎖在時間維度上增加條件。這兩者的組合（加上哈希鎖）使得 HTLC 成為可能，而 HTLC 是閃電網路和原子交換的基礎。

Taproot 是腳本能力的一次重大飛躍。透過 MAST 結構，複雜的條件邏輯可以保持隱藏；透過 Schnorr 簽名，多方協作可以看起來像單方操作。這對隱私和效率都有深遠影響。

DLC、Vault、BitVM 代表了在現有能力下的極限探索。它們展示了創意和密碼學如何突破表面的限制，實現之前認為不可能的功能。

Covenant 的討論反映了比特幣社區在功能擴展和風險控制之間的持續權衡。這不是一個簡單的技術問題，而是涉及經濟激勵、審查抵抗、長期可持續性的複雜考量。

無論未來如何發展，理解比特幣腳本的當前能力和限制對於任何比特幣開發者都是必要的。希望這個系列給你提供了一個堅實的基礎。

參考資料

DLC 規範 - DLC 的正式規格
BIP 119: OP_CHECKTEMPLATEVERIFY - CTV 提案
BIP 345: OP_VAULT - Vault 專用操作碼提案
BIP 347: OP_CAT - OP_CAT 復活提案
BitVM 白皮書 - BitVM 的原始論文
Covenant 資訊集合 - 各種 Covenant 提案的比較
Bitcoin Optech - 比特幣技術的最新發展
Miniscript - 更安全的腳本編寫方式