文章精簡摘要：

「恢復 OP_CAT」是一個嚴重誤解，提案中有一段重要的話為證：This implementation is inspired by the original implementation of

OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c which disabled it:

比特幣亞洲大會上討論了一個技術相關話題，在比特幣的腳本語言中要不要恢復 OP_CAT 操作指令？之後在萬物島 BTC 工作室的上海閉門會議中，大山老師也討論了相關的問題，鼓勵我們工作室的學員來寫一篇系統的總結文章。

為什麼一個指令的恢復會在業內大會上討論？它有那麼大的重要性嗎？這個事情涉及到了哪些問題？相信很多人會有相關的疑問。

1.  OP_CAT的基礎知識

要了解恢復 OP_CAT 這個問題，我們先了解一些和 OP_CAT 相關的基礎知識。在開發語言中，操作碼（opcodes）也會稱為指令或函數，是構成開發語言的基本組成元素。在本文中我們都稱為指令。

1.1.  OP_CAT具有什麼功能？

在很多開發語言中，連接兩個字符串一般多用 concat，所以 OP_CAT 的縮寫也應該是來自 concat 這個單詞，形成 OP_CAT 的指令。

例 1：java 開發語言中的 concat

String str1 = "Hello";

String str2 = " world"; //注意有空格

String str3 = str1.concat(str2);

System.out.println(str3);

輸出結果就是 Hello world

例 2：mysql 中的 concat

select CONCAT（"My","SQL"）from Result；執行結果就是顯示「MySQL」這幾個字符。

在高級開發語言中，concat（即字符串拼接）的使用頻率非常高，而且在很多情況下也非常重要。例如一些場景：

數據展示與輸出：在很多場景下，我們需要將數據以字符串的形式進行展示或輸出，比如將不同的數據項連接成一個完整的句子、將數據格式化成特定的字符串形式等等，這時候就需要使用字符串拼接操作。

數據處理與操作：在數據處理與操作中，有時候需要將多個字符串進行拼接以生成新的字符串，比如將多個文件路徑拼接成一個完整的路徑、將多個 URL 參數拼接成一個完整的 URL 等等，這也是字符串拼接操作的重要應用。

如果比特幣的語言是高級語言，毋庸置疑一定會有這個字符連接功能，但比特幣的開發語言有些特殊性，所以產生了是否要包含這個指令的爭議。比特幣的語言是一種逆波蘭範式的腳本語言，它是非圖靈完備的。比特幣腳本指令常見的類型：

關鍵字：

1. 常數。如：OP_0，OP_FALSE    

2. 流程控制。如： OP_IF，OP_NOTIF，OP_ELSE，……

3. 堆棧。如：OP_TOALTSTACK（把輸入壓入輔堆棧的項部，從主堆棧刪除），……

4. 字符串。如：OP_CAT（連接兩個字符串，已禁用），OP_SIZE（把棧頂元素的字符串長度壓入堆棧（無需彈出元素））

5. 位邏輯。如：OP_AND，OP_OR，OP_XOR

6. 算術邏輯。如：OP_1ADD（輸入值加 1），OP_1SUB（輸入值減 1）

7. 加密。如：OP_SHA1（輸入用 SHA-1 算法 HASH.），OP_CHECKSIG（）

8. 偽關鍵字

9. 保留關鍵字

比特幣腳本指令常見的類型：

腳本：

1. 支付到比特幣地址的標準交易（pay-to-pubkey-hash）

2. 標準比特幣產生交易（pay-to-pubkey）

3. 可證明的無法花掉/可刪除的輸出

4. Anyone-Can-Spend 輸出

5. 猜謎交易

五個標準類型的交易腳本包括：支付到公鑰哈希（P2PKH）、支付到公鑰、多重簽名（限定最多 15 個密鑰）、支付到腳本哈希（P2SH），以及數據輸出（OP_RETURN）。

在網址：https://en.bitcoin.it/wiki/Script 中有詳細的說明。

1.2.  比特幣語言中刪除 OP_CAT與其他指令的刪減

其實在早期比特幣的腳本語言中也是有字符連接的功能的，也就是「OP_CAT」操作碼開始是存在的，後來被刪除了。在比特幣的腳本語言中，OP_CAT 可以實現多個 UTXO 解鎖腳本字節串的組合連接處理，可以提升 BTC 主網的可編程特性和計算的複雜性。但由於中本聰對於安全的考慮（也有可能是對穩定性的考慮），在 2010 年 8 月，這個操作碼被移出比特幣協議。

在比特幣的腳本語言中，開始和字符操作相關的指令有很多，在之後大部分都被刪除了，刪除了 OP_CAT、OP_SUBSTR、OP_LEFT、OP_RIGHT，只保留了 OP_SIZE。如下圖所示。

不僅刪除了字符串操作指令，還刪除了不少其他指令。

（1）位操作相關指令

（2）算術操作

為什麼要刪減這麼多指令？關於比特幣技術發展變化的詳細內容，讀者可以閱讀《導致比特幣再次爆發的新技術發展總結》。

2.  為什麼有人要「恢復 OP_CAT」

網上很多人都在說比特幣要「恢復 OP_CAT」，這是眾人對這個事情的一個嚴重的誤解。但確實需要 OP_CAT 那樣的字符連接功能，是要在 Tapscript 中增加這個類似功能，於是要產生「恢復 OP_CAT」這件事情。

2.1. 「恢復 OP_CAT」的提案與眾人的誤解

在介紹相關內容前，我們需要先對 BIP 有所了解。BIP 是 Bitcoin Improvement Proposal 的縮寫，直接翻譯為：比特幣改進提案。包含以下幾種狀態，他們之間的狀態轉換如下圖所示：

2023 年 10 月，Bitcoin Core 開發者 Ethan Heilman 和 Botanix Labs 首席軟體工程師 Armin Sabouri 聯合推出了一份比特幣改進提案（BIP）草案，名為「OP_CAT」，讓這個討論到了一個新的高度。詳細提案內容查看網址：https://github.com/bip420/bip420

Tapscript 提案的新腳本（12 行）如下

提案中還有一段重要的話：This implementation is inspired by the original implementation of OP_CAT as it existed in the Bitcoin codebase prior to the commit "misc changes" 4bd188c which disabled it:

參考的原有比特幣腳本代碼（13 行）如下：

BIP420 這份草案，僅包含簡潔的 12 行程序代碼（與原來的 BTCscript 很相似），卻攜帶了明確直觀的功能性質，定義了一個新的 Tapscript 操作碼，允許在堆棧上連接兩個值。此操作碼實現的靈感明顯來自原始被刪除的 OP_CAT。這段文字被我用不同的顏色來標識，在強調不是在比特幣的原始指令中恢復相關指令，而是在 Taproot 的擴展中 Tapscript 中重新實現一個類似指令。

在比特幣的指令中恢復某些指令和在 Tapscript 中產生新指令是不同的概念，有不同的影響範圍。

2.2.  哪些功能或應用需要恢復 OP_CAT

完全理解這個問題需要兩部分知識：

（1）在 1.1 節中，我們已經知道在編程語言中字符連接 concat 是一個非常常見與重要的功能，在高級開發語言或者功能豐富一些的編程語言中都需要這個功能。有了這個共識，再了解到比特幣的變化，就會理解恢復 OP_CAT 的根本原因。

當前一些想在比特幣主網上面開發功能的團隊與項目方很希望恢復這個指令。有了這個指令，可以實現功能更強大的智能合約（比特幣上有智能合約，只是不是圖靈完備的）。這個功能的添加，會支持許多其他依賴於智能合約的創新方法，還可以把比特幣從僅為支付服務的網路，發展成一個更多功能、可擴展的計算平台。

（2）比特幣已經通過 Taproot 為擴展功能做好了準備。在這裡我們需要詳細的了解一些知識：Taproot、MAST、Taproot Scripts。最好閱讀《導致比特幣再次爆發的新技術發展總結》，了解比特幣技術爆發的底層變化。

比特幣技術通過隔離見證 Segwit 擴充了比特幣的 OP_RETURN 的功能，使得比特幣可儲存的實際空間直接擴大，區塊最大可以到達 4M。這些擴大出來的空間，當前被人們大量的使用在儲存文本或圖片等場景，但設計者的目的是用於擴展比特幣的功能。因為為了擴展功能產生的幾個 BIP 協議 BIP340、BIP341 和 BIP342，其中 BIP340 引入了可以同時驗證多個交易的 Schnorr 簽名，取代了橢圓曲線數字簽名算法（ECDSA），再一次擴大了網路容量並加快了批量交易的處理速度，為部署複雜的智能合約提供了可能性；BIP341 實現了默克爾化抽象語法樹（MAST）來優化區塊鏈上的交易數據儲存；BIP342（Tapscript）採用比特幣的腳本編碼語言擴充的比特幣原生腳本能力的不足。

由隔離見證 Segwit 與 Taproot 的空間擴大，導致了 Schnorr、MAST 樹和 TapScripts 的產生，他們要完成的使命是比特幣主網的功能擴大。4M 的儲存空間可以儲存大量的程序代碼，只要 Tapscript 的功能足夠強大，就能開發出非常多的應用。但當前 Tapscript 剛剛誕生，很多指令還不夠完善，會出現逐步擴大 Tapscript 指令功能的情況。

3.  比特幣協議在 Web3.0中的地位與作用

即使通過第 2 節我們了解到了恢復 OP_CAT 的提案內容與原因，那我們怎麼評判這類事件？因為不光要增加 OP_CAT，Tapscript 還會增加其他指令，那掌握這個增加的基本原則有哪些呢？我們還需要從更宏觀的角度來看待比特幣。

3.1.  Web3.0的應用架構與分層協議設計思想

在《從狀態機的角度觀察比特幣二層，可以看到未來 Web3.0 應用的架構和建設路徑》文章中，我們已經大致勾畫出 Web3.0 的應用架構，如下圖所示：

我們可以看到區塊鏈是 Web3.0 中重要的基礎設施，並且只有比特幣網路適合作為分層結構中的最底層基礎設施。這就是為什麼說區塊鏈是「以比特幣為開局，以比特幣生態為終局」，所有的其他區塊鏈系統都是比特幣的廣義二層或測試技術。

了解了 Web3.0 的應用架構，我們還需要理解一些分層設計思想（尤其是底層應該具有的特徵）。分層設計是一種人類處理複雜系統的手段和方法論，通過將系統劃分為多個層次結構並定義各層之間的關係和功能，以實現系統的模塊化、可維護性和可擴展性，從而提高系統的設計效率和可靠性。我們使用已有的案例來說明，如下圖的 TCP/IP 協議：

在協議的底層，TCP 協議與 IP 協議只需要實現最簡單，最基礎的功能，那些應用層的協議，如 FTP、SMTP、IMAP、HTTP 等協議都在高層來實現，會封裝在 TCP 協議和 IP 協議中。

如果比特幣是類似 TCP/IP 協議的最底層協議，那麼比特幣主網原則上也要保持最簡單，最基礎的功能。那些豐富的功能，尤其是應用層的功能都需要在比特幣的二層或三層協議上來實現。有了這個原則，我們會對明確的底層協議與上層協議有準確的判斷，那麼像 Tapscript 這樣在比特幣主網上實現的擴展功能，我們該怎麼判斷呢？

3.2.  過度設計與夠用即可的兩種做事哲學思想

為了增加我們的判斷準確性，我們先了解兩種做事的哲學思想：過度設計和夠用即可。（也許我們知道了也沒有用，因為比特幣的發展決策是很多因素決定的，比特幣的去中心化文化使得它的發展會由很多因素決定，或者是由人類的群體思想決定。）

過度設計和夠用即可是兩種不同的做事哲學思想，它們各自有不同的優缺點。以下是它們的優缺點和一些例子：

（1）過度設計

過度設計的優點：

可擴展性強：過度設計通常考慮了未來的需求變化，能夠應對各種擴展和改變。

更具靈活性：過度設計的系統能夠適應各種不同的情況和需求，具備更高的靈活性。

提高長期效率：很多功能可以在後期之間調用底層來開發，長期上看效率是提高的。

過度設計的缺點：

耗時：過度設計需要更多的時間和資源來完成，可能會導致項目延期。

資源浪費：過度設計可能會引入冗餘的功能或複雜的結構，浪費了資源。

可能過於複雜：過度設計可能導致系統結構過於複雜，增加了系統維護和理解的難度。

過度設計適用場景（我個人的一些經驗總結和參考 ChatGPT 的部分內容）：

過度設計通常適用於非全新的項目，有可以參考的例子，並且全新案例的初始需求比較少或不夠明確，但預計需求變化可能會比較頻繁，就可以借鑑已有的經驗，在一定程度上使用過度設計的原則。例如，大型軟體系統或平台的底層可以考慮過度設計。

（2）夠用即可

夠用即可的優點：

簡單明了：夠用即可的思想注重解決當前需求，使系統保持簡單和易於理解。

資源節約：夠用即可的思想避免了過度設計和不必要的功能，節約了時間和資源。

快速交付：夠用即可的思想可以快速交付可用的產品或系統，滿足用戶的基本需求。

夠用即可的缺點：

無法適應變化：夠用即可的思想可能無法適應未來的需求變化，需要進行較大的修改和調整。

可擴展性差：夠用即可的思想可能導致系統缺乏可擴展性，難以添加新功能和組件。

夠用即可的適用場景：要實施的項目沒有可以參考的樣例，或可參考的樣例很少，不知道發展的方向和目的地，可以採用夠用即可的方式。還有那些小型項目完全適用夠用即可的思想。對於創新性項目，很多時候也會採用這種原則，因為未來完全不明確。

過度設計和夠用即可並不是對立的概念，而是一種思維方式的不同取向。在比特幣的原生腳本 BTCscript 上多數採用夠用即可原則，但 Tapscript 是一種原生腳步的擴展，可以參考一些編程場景，稍微過度設計一些。在 Taproot 和 Tapscript 的使用上也需要考慮，它們只是一層與二層之間的連接技術，不應該過度使用，甚至要限制在 Tapscript 上面的功能。這樣我們就找到了設計 Tapscript 的下限與上限。

3.3.  Web3.0（下一代網路）的輝煌未來

在 3.2 節中我們表達了在 Tapscript 的指令設計上可以適當的過度設計，但上限是滿足連接比特幣一層和二層的需求即可。但在早期，尤其是比特幣價格還不過高的情況下（每次簡單交易執行不超過 100 美元，都被認為不過高）和分布式系統的二層或三層還不成熟的情況下，很多人還是會開發過多的功能，這導致 Tapscript 也可能會包含過多的指令。

從另一方面，區塊鏈技術與相關的分層建設作為整個 Web3.0 的基礎設施來看，比特幣的 Tapscript 技術也不應該開發過多的功能。參考 3.1 節中的 Web3.0 的應用架構圖。

在《從狀態機的角度觀察比特幣二層，可以看到未來 Web3.0 應用的架構和建設路徑》我們通過中國互聯⽹絡發展狀況統計報告了解 Web2.0 的豐富應用。在統計報告中，可以看到 Web2.0 中的應用已經非常豐富，並且擁有巨大的用戶群體。這些應用包括：即時通訊、網路影音、短影音、網路支付、網路購物、搜尋引擎、網路新聞、網路音樂、網路直播、網路遊戲、網上外賣、網路文學、網約車、在線辦公、在線旅行預定、在線教育、在線醫療、……，幾乎覆蓋了人們生活的全部領域。除了這些消費網路的內容，在產業網路中也有很多的應用。

這些主流應用都還沒有進入到 Web3.0 的世界。當這些應用進入 Web3.0 時代後，用戶的規模和性能要求更高。所以比特幣主網承擔的任務在未來是非常重，使得一定要用分層結構才能建立起來真正的 Web3.0 世界。那麼在比特幣主網上面的功能就以簡單穩定為主，以服務一層與二層的連接技術為主。我個人主張不要過度使用比特幣一層與二層的連接技術，給 Tapscript 一個擴展空間，但不要有太多的功能。

4.  是否恢復 OP_CAT誰有決定權

通過前面的內容，我們知道了這個提案的真實內容，是在 Tapscript 中產生一個類似 OP_CAT 的指令功能，而不是恢複比特幣腳本中原來的 OP_CAT。對於這個提案誰有決策權呢？比特幣 Core 的開發團隊？礦工？生態開發者？社區？

如果我們從利益的角度分析，Tapscript 中產生 OP_CAT 指令會增加比特幣主網的可編程性，會產生更多的比特幣主網程序和應用，這樣就會增加主網上面的手續費。礦工會是最積極的支持者，生態開發者因為增加了開發的可能性也會支持。

比特幣 Core 團隊怎麼考慮？一直以來 Core 團隊秉持一種保守風格，會不會同意呢？有很大的不確定性。其實這個事件還牽扯出一個較大問題，對於 Tapscript 的發展，需要制定一套規則，它不同於比特幣主網的 BTCScript，決策上是否也要適當寬鬆一些？比特幣的 BIP 協議參考以太坊的 EIP 協議，作一下提案的分級也許是個不錯的方法。對每種提案採用不同的審核標準。

通過整理這篇文章，我個人判斷這個提案最終會獲得通過，不然 Tapscript 的功能就太弱了，也許過程會有些曲折。

在比特幣的世界，因為沒有權威機構，權利在比特幣的世界不是直接影響因素，只有經濟因素才會是決定性的影響因素，什麼會獲得通過最終是由大多數人的利益驅動的。即使 Tapscript 被過度設計了，在使用中也會被經濟因素矯正過來。

原文連結