作者|付少慶,SatoshiLab,萬物島BTC 工作室

正文

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

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

一、OP_CAT 的基礎知識

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

1.1OP_CAT 具有什麼功能?

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

範例1:java 開發語言中的concatString str1 = "Hello";String str2 = " world"; //注意有空格String str3 = str1.concat(str2);System.out.println(str3);輸出結果就是Hello world

例2:mysql 中的concatselect 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。如下圖所示。

曾被中本聰刪除的OP_CAT,為何現在要恢復?

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

1.位元操作相關指令

曾被中本聰刪除的OP_CAT,為何現在要恢復?

2.算術操作

曾被中本聰刪除的OP_CAT,為何現在要恢復?

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

2為什麼有人要“恢復OP_CAT”

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

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

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

曾被中本聰刪除的OP_CAT,為何現在要恢復?

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

Tapscript 提案的新腳本(12行)如下

曾被中本聰刪除的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:

參考的原有比特幣腳本程式碼(13 行)如下:

曾被中本聰刪除的OP_CAT,為何現在要恢復?

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

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

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

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

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

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

比特幣已經透過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.1Web3.0 的應用架構與分層協定設計思想

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

曾被中本聰刪除的OP_CAT,為何現在要恢復?

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

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

曾被中本聰刪除的OP_CAT,為何現在要恢復?

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

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

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

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

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

1.過度設計

過度設計的優點:

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

更具彈性:過度設計的系統能夠適應各種不同的情況和需求,並具備更高的彈性。

提高長期效率:許多功能可以在後期之間呼叫底層來開發,長期上看效率是提高的。

過度設計的缺點:

耗時:過度設計需要更多的時間和資源來完成,可能會導致專案延期。

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

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

過度設計適用場景(我個人的一些經驗總結和參考ChatGPT的部分內容):過度設計通常適用於非全新的項目,有可以參考的例子,並且全新案例的初始需求比較少或不夠明確,但預計需求變化可能比較頻繁,就可以藉鏡已有的經驗,在一定程度上使用過度設計的原則。例如,大型軟體系統或平台的底層可以考慮過度設計。

2.夠用即可

夠用即可的優點:

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

資源節約:夠用即可的想法避免了過度設計和不必要的功能,節省了時間和資源。

快速交付:足夠的想法可以快速交付可用的產品或系統,滿足使用者的基本需求。

夠用即可的缺點:

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

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

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

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

3.3Web3.0(下一代網路)的輝煌未來

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

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

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

曾被中本聰刪除的OP_CAT,為何現在要恢復?

 2020.12 - 2021.6 各類網路應用使用者規模及網友使用率

這些主流應用程式都還沒有進入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 過度設計了,在使用上也會被經濟因素矯正過來。