概述

相比於以太坊等圖靈完備的區塊鏈，比特幣腳本語言被認為是高度限制的，僅能進行基本操作，甚至缺乏乘法和除法支持。更重要的是，區塊鏈本身的數據對於腳本幾乎是不可訪問的，這導致了顯著的靈活性和可程式性缺乏。因此，長期以來一直在努力使比特幣腳本實現內省。

內省指的是比特幣腳本檢查和限制交易數據的能力。這使得腳本能夠根據特定的交易細節來控制資金的使用，從而實現更複雜的功能。目前，大多數比特幣操作碼要麼將用戶提供的數據推送到堆棧上，要麼操作堆棧上的現有數據。而內省操作碼可以將當前交易（如時間戳，金額，txid等）的數據推送到堆棧上，從而更精細地控制utxo的花費。

截至目前，比特幣腳本中僅支持檢視三種主要操作碼的內省功能：checklocktimeverify、checksequenceverify 和 checksig，以及其變體 checksigverify、checksigadd、checkmultisig 和 checkmultisigverify。

契約，簡單來說，是指對硬幣轉移方式的限制，允許用戶指定utxo的分配方式。許多契約是通過內省操作碼實現的，對於內省的討論現在已歸類為有關的契約主題。比特幣optech.

比特幣目前有兩個契約，CSV（CheckSequenceVerify）和CLTV（CheckLockTimeVerify），這兩個契約都是基於時間的契約，是閃電網路等許多擴展解決方案的基礎。這說明瞭比特幣的擴容解決方案如何嚴重依賴內省和契約。

如何在轉帳中添加條件？在加密世界中，我們最常見的方法是通過承諾來實現，通常是通過哈希實現。為了證明轉帳條件已經滿足，還需要簽名機制進行驗證。因此，在契約中存在許多對哈希和簽名的調整。

下面，我們將描述廣受討論的契約操作碼提議。

ctv (checktemplateverify) bip-119

ctv（checktemplateverify）是一項包含在bip-119中的比特幣升級提案，引起了社區的廣泛關注。ctv使輸出腳本能夠指定一個模板來花費交易中的資金，包括nversion，nlocktime，scriptsig哈希，輸入計數，序列哈希，輸出計數，輸出哈希，輸入索引等字段。這些模板限制通過哈希承諾實現，當資金被花費時，腳本會檢查在花費交易中指定字段的哈希值是否與輸入腳本中的哈希值匹配。這有效地限制了該utxo未來交易的時間、方式和金額。

值得注意的是，輸入的交易ID（txid）被排除在此哈希之外。這種排除是必要的，因為在傳統和隔離見證（SegWit）交易中，當使用默認的SIGHASH_ALL簽名類型時，交易ID取決於scriptPubKey中的值。包括交易ID將導致哈希承諾中的循環依賴，使構造變得不可能。

ctv 通過直接拉取指定交易信息進行哈希並將其與堆棧上的承諾進行比較來實現內省。這種內省方法對鏈空間的要求較小，但缺乏某些靈活性。

比特幣的第二層解決方案，如閃電網絡的基礎是預先簽名的交易。預先簽名通常是指提前生成和簽名交易，但在滿足某些條件之前不廣播它們。基本上，CTV實現了一種更嚴格的預先簽名形式，將預先簽名的承諾發布在鏈上，限制於預定的模板。

CTV最初是为了缓解比特幣的擁堵而提出的，也可以称为擁堵控制。在高擁堵时期，CTV可以在单个交易中承诺多个未来交易，避免在高峰期广播多个交易，并在拥堵缓解后完成实际交易。这在交易所银行挤兑期间可能特别有帮助。此外，该模板还可用于实施保险库以防止黑客攻击。由于资金方向是预定的，黑客无法使用CTV脚本将UTXO定向到自己的地址。

ctv 可顯著增強第二層網絡。例如，在閃電網絡中，ctv 可通過將單個 utxo 擴展為一個 ctv 樹，僅通過一筆交易和一次確認就能打開多個狀態通道，從而實現超時樹和通道工廠的創建。此外，ctv 還通過 atlc 支持 ark 協議中的原子交易。

apo (sighash_anyprevout) bip-118

bip-118引入了一種新的簽名哈希標誌，用於tapscript，旨在促進更靈活的消費邏輯，稱為sighash_anyprevout。apo和ctv有許多相似之處。在解決scriptpubkeys和txids之間的循環問題時，apo的方法是排除相關的輸入信息，僅對輸出進行簽名，從而使交易能夠動態地綁定到不同的utxos。

從邏輯上講，簽名驗證操作op_checksig（及其變體）執行三個功能：

1. 組裝消費交易的部分。
2. 對它們進行雜湊。
3. 驗證哈希是否已由給定的金鑰簽署。

簽名的具體內容非常靈活，對於要簽署哪些交易字段的決定由 sighash 標誌確定。根據 BIP 342 中的簽名操作碼的定義，sighash 標誌分為 sighash_all、sighash_none、sighash_single 和 sighash_anyonecanpay。sighash_anyonecanpay 控制輸入，而其他標誌則控制輸出。

sighash_all 是默認的 sighash 標誌，簽署所有輸出；sighash_none 不簽署任何輸出；sighash_single 簽署特定的輸出。如果設置了 sighash_anyonecanpay，則僅簽署指定的輸入；否則，必須簽署所有輸入。

顯然，這些sighash標誌並不能消除輸入的影響，即使是需要承諾一個輸入的sighash_anyonecanpay標誌也是如此。

因此，BIP 118提出了Sighash_AnyPrevout。APO簽名不需要承諾已花費的輸入UTXO（稱為prevout），而只需要對輸出進行簽名，從而在比特幣控制方面提供了更大的靈活性。通過預先構建交易並創建相應的一次性使用的簽名和公鑰，資產發送到該公鑰地址必須通過預先構建的交易來花費，從而實現契約。APO的靈活性還可以用於交易修復；如果一筆交易由於低手續費而卡在鏈上，可以輕鬆創建另一筆交易來增加手續費，而無需新的簽名。此外，對於多簽錢包，不依賴於已花費的輸入使操作更加便捷。

由於它消除了腳本公鑰和輸入交易ID之間的循環，apo 可以通過在見證中添加輸出數據來進行內省，儘管這仍然需要額外的見證空間消耗。

對於像閃電網絡和金庫這樣的離線協議，apo減少了保存中間狀態的需求，大大減少了存儲要求和複雜性。apo的最直接用例是eltoo，它簡化了通道工廠，建立了輕量級和廉價的監視塔，並允許單方面退出而不留下錯誤的狀態，從多個方面增強了閃電網絡的性能。apo也可以用於模擬ctv功能，但需要個人存儲簽名和預簽名交易，這比ctv更昂貴且效率更低。

apo的主要批評集中在其需要新的密鑰版本上，這不能僅通過向後兼容實現。此外，新的簽名哈希類型可能引入雙重支付的潛在風險。在廣泛的社區討論後，apo在原始簽名機制上添加了常規簽名，以緩解安全問題，從而獲得了bip-118代碼。

op_vault bip-345

bip-345 提議增加兩個新的操作碼，op_vault 和 op_vault_recover，在與 ctv 結合使用時，實現一個專門的契約，允許用戶對特定幣種的花費施加延遲。在此延遲期間，可以通過恢復路徑“撤銷”先前進行的交易。

用戶可以通過創建一個特定的Taproot地址來創建一個金庫，該地址必須至少包含兩個腳本：一個包含op_vault操作碼以促進預期的提款過程，另一個包含op_vault_recover操作碼以確保在提款完成之前隨時可以恢復貨幣。

op_vault如何實現可中斷的時間鎖定提款？ op_vault通過用指定的腳本替換已花費的op_vault腳本來實現這一點，從而有效地更新了樹根葉子中的單個葉子，同時保持其餘的taproot葉子節點不變。這種設計類似於tluv，不過op_vault不支持對內部密鑰的更新。

透過在腳本更新過程中引入模板，可以限制支付。時間鎖定參數由op_vault指定，ctv操作碼的模板限制了可以通過此腳本路徑花費的輸出集。

bip-345 專為金庫設計，利用 op_vault 和 op_vault_recover，為用戶提供一種安全的保管方法，該方法使用高度安全的密鑰（例如紙錢包或分佈式多簽）作為恢復路徑，同時為常規支付配置一定的延遲。用戶的設備不斷監視從金庫的花費，如果發生意外轉移，用戶可以啟動恢復。

通過BIP-345實現保險庫需要考慮成本問題，特別是恢復交易。可能的解決方案包括CPFP（子支付父親），臨時錨點和新的SIGHASH_GROUP簽名哈希標誌。

tluv (tapleafupdateverify)

tluv方案建立在Taproot之上，旨在有效地解决从共享utxo退出的问题。其指导原则是，当Taproot输出被花费时，可以通过密码学变换和Taproot地址的内部结构（由tluv脚本描述）部分更新内部密钥和Mast（Tapscript Trie）。这使得契约功能的实现成为可能。

tluv計劃的概念是基於當前的支出輸入創建一個新的taproot地址，通過引入一個新的操作碼tapleaf_update_verify來實現。這可以通過執行一個或多個以下操作來實現:

1. 更新內部公鑰
2. 修剪默克爾路徑
3. 移除目前正在執行的腳本
4. 在默克爾路径的末尾添加一個新步驟

具體來說，tluv接受三個輸入：

1. 指定如何更新内部公钥的一個。
2. 指定默克爾路徑的新步驟之一。
3. 一個指定是否刪除當前腳本和/或修剪默克爾路徑的步驟數。

tluv opcode計算更新的scriptpubkey並驗證與當前輸入對應的輸出是否花費到該scriptpubkey。

tluv受coinpool概念啟發。如今，只需使用預先簽署的交易即可創建聯合池，但如果要實現非許可退出，就需要創建指數增長的簽名數量。然而，tluv允許無需任何預先簽署的非許可退出。例如，一組合作夥伴可以使用taproot來建立共享的utxo，將他們的資金集中在一起。他們可以使用taproot金鑰內部轉移資金，或者共同簽署以啟動外部付款。個人可以隨時退出共享基金池，刪除他們的支付路徑，而其他人仍然可以通過原始路徑完成付款，個人的退出不會暴露有關內部其他人的額外信息。與非集中式交易相比，這種模式更有效和私密。

tluv操作確保部分消費限制，通過更新原始taproot trie，但它不實現對輸出金額的內省。因此，還需要一個新的操作碼in_out_amount。該操作碼將兩個項目壓入堆疊：該輸入的utxo金額和相應輸出的金額，然後使用tluv的人預計使用數學運算符來驗證資金是否適當地保留在更新的scriptpubkey中。

對輸出金額的內省增加了複雜性，因為以聰為單位的金額需要使用最多51位來表示，但腳本只允許32位的數學操作。這需要重新定義操作碼的行為，以升級腳本中的運算符，或使用sighash_group來替換in_out_amount。

tluv 在分散式第二層資金池的解決方案中具有潛力，但在調整 taproot trie 的可靠性仍然需要確認。

馬特

Matt（對所有事物進行 Merkle 化）旨在實現三個目標：對狀態進行 Merkle 化，對腳本進行 Merkle 化，並對執行進行 Merkle 化，從而實現通用智能合約。

1. 默克尔化状态：这涉及构建一个默克尔树，其中每个叶节点表示状态的哈希，而默克尔根代表合约的整体状态。
2. merkleizing the script: 這指的是使用 tapscript 形成一個 mast，其中每個葉子節點代表一個可能的狀態轉換路徑。
3. 默克尔化執行：執行通過加密承諾和欺騙挑戰機制進行默克爾化。對於任何計算功能，參與者可以在鏈下計算，然後發佈一個承諾，f(x)=y。如果其他參與者發現了錯誤的結果，f(x)=z，他們可以發起挑戰。仲裁通過二分搜索進行，類似樂觀 Rollup 的原則。

將執行merkle化

要實現matt，比特幣腳本語言需要具備以下功能：

1. 強制輸出具有特定腳本（及其金額）
2. 將一個數據附加到一個輸出
3. 從當前輸入（或其他輸入）讀取數據

第二點非常重要：動態數據意味著狀態可以通過支付者提供的輸入數據進行計算，這使得可以模擬狀態機，能夠確定下一個狀態和額外的數據。matt方案通過op_checkcontractverify（op_ccv）操作碼來實現這一點，它是先前提出的op_checkoutputcontractverify和op_checkinputcontractverify操作碼的合併，使用額外的標誌參數來指定操作的目標。

對輸出金額的控制：最直接的方法是直接檢查；但是，輸出金額是64位元數字，需要64位元算術，這在比特幣腳本中呈現出顯著的複雜性。op_ccv採用了一種延遲檢查的方法，就像op_vault一樣，具有ccv的所有輸入總和，作為該輸出金額的下限。延遲是因為這個檢查發生在交易過程中，而不是在輸入的腳本評估期間。

鑑於欺詐證明的普遍性，某些 Matt 合約的變體應能夠實現所有類型的智能合約或第2層結構，儘管還需準確評估額外要求（如資本鎖定和挑戰期延遲）；需要進一步研究以評估哪些應用可用於交易。例如，使用加密承諾和欺詐挑戰機制來模擬 op_zk_verify 函數，實現比特幣上的無信任 rollups。

實際上，事情已經在發生。約翰·托拉斯·哈爾塞特（Johan Torås Halseth）利用了Matt軟分叉提案中的op_checkcontractverify操作碼來實現。elftrace，它允許任何支持RISC-V編譯的程式在比特幣區塊鏈上進行驗證，從而使合約協議中的一方能夠通過合約驗證獲取資金，從而實現比特幣本地驗證的橋接。

csfs (op_checksigfromstack)

從apo操作碼的介紹中，我們了解到op_checksig（及其相關操作）負責組裝交易、哈希化和驗證簽名。然而，這些操作驗證的訊息來自使用操作碼對交易序列化的衍生物，並且不允許指定任何其他訊息。簡單來說，op_checksig（及其相關操作）用於通過簽名機制驗證UTXO作為交易輸入是否已被簽名持有者授權支出，從而保護比特幣的安全。

csfs，正如其名所示，檢查堆疊中的簽名。csfs操作碼從堆疊中接收三個參數：簽名、消息和公鑰，並驗證簽名的有效性。這意味著人們可以通過見證向堆疊傳遞任何消息，並通過csfs驗證它，從而在比特幣上實現一些創新。

CSFS 的靈活性使其能夠實施支付簽名、授權委託、預言機合同、雙花保護債券等機制，更重要的是，交易自省。使用 CSFS 進行事務自檢的原理非常簡單：如果將 op_checksig 使用的事務內容通過見證推送到堆疊，並使用相同的公鑰和簽名使用 op_csfs 和 op_checksig進行驗證，並且如果兩次驗證都成功通過，則傳遞給 op_csfs 的任意消息內容與 op_隱式使用的序列化 SPEND 事務（和其他數據）相同檢查。然後，我們在堆疊上獲取經過驗證的交易數據，這些數據可用於對與其他操作碼的支出交易應用限制。

csfs經常與op_cat一起出現，因為op_cat可以連接交易的不同字段以完成序列化，從而允許更精確地選擇用於內省的交易字段。沒有op_cat，腳本無法從可以單獨檢查的數據中重新計算哈希，因此它實際上能做的就是檢查哈希是否對應特定值，這意味著硬幣只能通過單個特定交易花費。

csfs可以實現像cltv，csv，ctv，apo等操作碼，使其成為一個多功能的內省操作碼。因此，它還有助於比特幣第2層的可擴展性解決方案。缺點是它需要在堆棧上添加已簽署交易的完整副本，這可能會顯著增加用於使用csfs進行內省的交易的大小。相比之下，像cltv和csv這樣的單一用途的內省操作碼的開銷很小，但添加每個新的特殊內省操作碼都需要共識變更。

txhash（op_txhash）

op_txhash是一個直觀啟用內省的操作碼，允許運營商選擇並將特定字段的哈希推送到堆棧上。具體而言，op_txhash從堆棧中彈出一個txhash標誌，並根據該標誌計算（標記的）txhash，然後將結果哈希推送回堆棧。

由於txhash和ctv之間的相似之處，社區內出現了大量關於這兩者的討論。

txhash 可以被認為是 ctv 的通用升級，提供一個更先進的交易模板，允許用戶明確指定花費交易的部分，解決了與交易費用相關的許多問題。與其他盟約操作碼不同，txhash 不需要在見證中複製必要的數據，進一步減少了存儲要求；與 ctv 不同，txhash 不是 nop-compatible，只能在 tapscript 中實現；txhash 和 csfs 的結合可以作為 ctv 和 apo 的替代方案。

從構建契約的角度來看，txhash更有利於創建“附加契約”，其中您希望固定的交易數據的所有部分被推送到堆棧上，一起進行哈希運算，並驗證生成的哈希值是否與固定值匹配；ctv更適合創建“減法契約”，其中您希望保持自由的交易數據的所有部分被推送到堆棧上。然後，使用滾動sha256操作碼，從一個固定的中間狀態開始進行哈希運算，該中間狀態對交易哈希數據的前綴進行了承諾。自由部分被哈希到這個中間狀態。

在txhash規範中定義的txfieldselector字段預計會擴展到其他操作碼，比如op_tx。

與txhash相關的bip目前在github上處於草稿狀態，尚未被指定編號。

op_cat

op_cat是一個被神秘籠罩的操作碼，最初被中本聰因安全問題而放棄，最近卻在核心比特幣開發人員之間引起了激烈討論，甚至在互聯網上引發了迷因文化。最終，op_cat在BIP-347下獲得批准，被稱為最有可能通過的BIP提案。

事实上，op_cat的行为非常简单：它将堆栈中的两个元素连接在一起。它如何启用契约功能呢？

事實上，將兩個元素連接起來的能力對應到一個強大的加密數據結構：默克爾樹。要建立一個默克爾樹，只需要連接和哈希操作，而哈希函數在比特幣腳本中是可用的。因此，理論上我們可以通過op_cat在比特幣腳本中驗證默克爾證明，這是區塊鏈技術中最常見的輕量級驗證方法之一。

如前所述，借助op_cat，csfs能夠實現一個通用的契約方案。事實上，即使沒有csfs，單獨使用op_cat結構也能實現交易自我檢查，並利用Schnorr簽名的結構。

在Schnorr簽名中，需要簽名的訊息由以下字段組成:

這些字段包含交易的主要元素。通過將它們放置在scriptpubkey或witness中，並使用op_cat結合op_sha256，我們可以構建一個schnorr簽名並使用op_checksig進行驗證。如果驗證通過，堆棧將保留驗證的交易數據，實現交易內省。這允許我們提取和“檢查”交易的各個部分，例如其輸入、輸出、目標地址或涉及的比特幣金額。

對於特定的加密原則，可以參考安德魯·普爾斯特拉的文章《貓和施諾爾技巧》。

總的來說，op_cat 的多功能性使其能夠模擬幾乎任何契約操作碼。眾多契約操作碼依賴 op_cat 的功能，這顯著提升了其在合併清單上的地位。理論上，僅依賴 op_cat 和現有的比特幣操作碼，我們希望能夠建立一個信任最小化的 BTC zk rollup。StarkNet、Chakra 和其他生態系合作夥伴正在積極推動這一目標的實現。

結論

當我們探索多樣化的比特幣擴展策略並增強其可編程性時，很明顯前進的道路涉及本地改進、鏈外計算和複雜的腳本能力的結合。

沒有一個靈活的基礎層，就不可能建立一個更靈活的第二層。

離鏈計算擴展是未來，但比特幣的可程式化需要突破，以更好地支持這種可擴展性，並成為一種真正的全球貨幣。

然而，比特幣上的計算性質與以太坊上的計算性質基本上不同。比特幣僅支持“驗證”作為一種計算形式，無法執行一般計算，而以太坊從本質上就是計算的，驗證只是計算的副產物。這一差異從一點就是顯而易見的：以太坊對於無法執行的交易收取燃氣費，而比特幣則不收取。

契約代表了一種基於驗證而不是計算的智能合約形式。除了少數中本聰原教旨主義，似乎每個人都認為契約是改善比特幣的好選擇。然而，社區繼續激烈辯論應採用哪種方法來執行公約。

APO、op_vault 和 TLUV 傾向於直接應用程式，選擇它們可以以更便宜、更高效的方式實現特定應用程式。閃電網路愛好者更喜歡APO來實現LN對稱性;那些希望實施保險庫的人最好由op_vault服務;對於構建Coinpool，TLUV提供了更多的隱私和效率。op_cat 和 txhash 更通用，安全漏洞的可能性更小，與其他操作碼結合使用時可以實現更多用例，可能以腳本複雜性為代價。CTV和CSFS調整了區塊鏈處理，CTV實現了延遲輸出，CSFS實現了延遲簽名。Matt 以其樂觀的執行和欺詐證明策略脫穎而出，利用 Merkle Trie 的結構來實現通用智能合約，儘管它仍然需要新的操作碼來實現內省功能。

我們看到比特幣社區正在積極討論通過軟分叉獲取契約的可能性。Starknet已正式宣布加入比特幣生態系統，計劃在op_cat合併後的六個月內在比特幣網絡上實施結算。Chakra將繼續監視比特幣生態系統的最新發展，推動op_cat軟分叉的合併，並利用契約帶來的可編程性建立更安全高效的比特幣結算層。

免責聲明：

1. 本文是從 [ 轉載的鏡子]. 所有版權屬於原作者 [chakra].如果對此轉載有任何異議，請聯繫Gate 學習團隊，他們會迅速處理它。
2. 免責聲明：本文中表達的觀點和意見僅代表作者的觀點和意見，不構成任何投資建議。
3. 本文的翻譯工作由Gate.io學習團隊負責。未經許可，禁止複製、分發或抄襲已翻譯的文章。