比特幣上的通用計算之路：構想 STARK 為比特幣擴容

撰文：StarkWare

編譯：Starknet 中文社區

1. 引言

本文，我們將討論在比特幣上實現通用計算的任務及其涉及的各個步驟。事實上，實現在比特幣腳本上計算任意邏輯的能力是一個吸引人的目標，因為其將比特幣帶入了非託管應用和去中心化金融的領域。

之前，由於兩個嚴重的限制 — 比特幣腳本長度和操作碼的表達能力，比特幣上的通用計算幾乎被認為是不可能的。前者禁止了除短腳本之外的任何交易，後者限制了腳本操作碼能夠計算的內容。這兩個限制共同構成了比特幣計算可行性的嚴峻局面，因為許多應用無法在這些限制條件下實現。

不過，近年來，這種狀況已經有了明顯改善。事實上，隨著 2021 年 Taproot 的升級，腳本長度的限制取消了，使得比特幣腳本可以顯著加長（事實上，Taproot 腳本甚至允許有時只對腳本的一部分進行鏈上支付，但我們不會在本文探討這一特性）。此外，為了解決操作碼錶達能力的限制，我們發現一個簡單的操作碼就足以有效地實現無限的表達能力。

上述操作碼被稱為 OP_CAT，自 2012 年起就在比特幣腳本中被禁用。這是一個非常簡單的操作碼，允許在堆棧上連接元素，只需要 13 行代碼，就可以通過軟分叉在比特幣上進行非侵入性激活。從這個看似不起眼的操作碼中衍生出如此大的能量是非常不容易的，因此，本文的核心目標就是詳細闡述這一點。

下文，我們將深入探討比特幣上的計算過程，從其實現方式以及存在的限制開始。

接下來，我們將概述兩種工具 — Covenant和 STARK 證明，並證明如果二者能在比特幣腳本中運行，將能夠實現比特幣上的通用計算。此外，我們將在本文中論證，得益於 STARK 證明，這種計算還能被賦予更多有用的屬性：

• 可擴展性— 鏈上交易處理和計算變得可行，手續費極低。

• 表達能力— 邏輯可以用不同的、比比特幣腳本更強大的編程語言進行編程。這對比特幣編程的人性化和安全性至關重要。

• 鏈上安全性— 不管是什麼樣的計算，比特幣腳本都只驗證委託計算的數學證明。

• 靈活性— 比特幣上的計算可以存儲全局狀態，從而實現大量應用。

最後，我們將討論 OP_CAT，及其如何實現上述工具。我們還將提到我們在這方面所做的一些努力，並討論未來的發展方向。

注意：本文簡化了一些技術性問題，以提供一個清晰的思維模型。當涉及實際實施所呈現的想法時，「細節決定成敗」。

2. UTXO 模型和鎖定腳本

本節，我們將簡要概述比特幣的 UTXO 模型，即每個 UTXO 都被鎖定在一個鎖定腳本後面。如果你對此很熟悉，可以跳到下一節內容。

瞭解比特幣交易的第一步是注意到它們是根據未花費的交易輸出（UTXO）模型進行安排和處理的，如圖 1 所示。比特幣交易可以有多個輸入和輸出，其中每個輸出代表了可以由另一筆交易所花費的一定數量的比特幣。相應地，一個交易的輸入則代表了另一個比特幣交易輸出的支出。當然，我們要求輸入中的比特幣總量與輸出中的比特幣總量大致相等（差額為支付給礦工的費用）。

圖 1：UTXO 模型中的交易。每個交易的輸入和輸出都與一定數量的比特幣相關聯，其中輸出中的累計金額不能超過輸入中的金額。未花費的交易輸出（UTXO）以藍色表示。

每個交易輸出都被一個鎖定腳本（scriptPubKey）鎖定，該腳本將接受或拒絕它所給定的輸入（scriptSig）（由所謂的花費者提供）。因此，如果想要從一個未花費的交易輸出（UTXO）中轉移資金，你必須能夠生成正確的 scriptSig，並將此 UTXO 作為輸入包含在你生成的交易中。

默認情況下，鎖定腳本將簡單地根據硬編碼的公鑰驗證數字簽名，這定義了被鎖定比特幣的所有權。更籠統地說，每當存在一個 UTXO 時，我們就可以說，能夠提供正確 scriptSig 的人就是對應鎖定腳本背後鎖定的比特幣的所有者。因此，每個比特幣所有者的總餘額由與該所有者相關的所有 UTXO累積決定（例如，由同一人進行數字簽名的所有 UTXO）。

3. 比特幣腳本的侷限性

上一節概述了鎖定腳本的一般情況，以及它們如何與比特幣交易和比特幣本身互動。本節，我們將重點介紹鎖定腳本本身及其組成內容。

比特幣上的鎖定腳本是用一種類似於 Forth的基於堆棧的語言編寫，這種語言被稱為「比特幣腳本」。由於比特幣腳本沒有循環，我們通過腳本所需的操作碼數量來衡量腳本的成本，因為腳本的長度與其運行時間成正比。在圖 2 中，我們可以看到一個簡單程序的示意圖，該程序將檢查兩個輸入的和是否為 12。

圖 2*：一個檢查兩個輸入值之和是否為 12 的簡單程序。程序的執行是通過將 scriptSig 與鎖定腳本本身連接起來，然後從左到右處理操作碼。scriptSig 只將元素推入堆棧。(a) 計算的第一步。(b)* 計算過程中。(c) 計算的最後一步（鎖定腳本接受輸入）。

我們必須指出，比特幣腳本有很多侷限性，這使得為它開發簡單的邏輯變得非常困難，甚至根本不可能。這些侷限性包括：

• 堆棧大小限制為最多 1000 個元素。

• 沒有乘法操作碼（事實上，即使是 31 字節整數乘法也需要用約 1.4 萬個操作碼來模擬）。

• 對於 Pay2Taproot輸出類型（Taproot 升級後）來說，單個交易中可容納的操作碼總數最多約為 400 萬個，佔滿整個區塊，而對於其他輸出類型，操作碼總數僅為 1 萬個。

• 算術操作（加法、減法）僅限於 4 字節元素。

在最後一點提到的 4 字節限制尤其成問題。實際上，這意味著你無法修改長元素，例如，加密操作所需的 20 字節或更長的元素。

例如，將數據連接在一起並應用加密操作這種非常常見的操作是不可能完成的，除非忽略加密操作碼，並將其模擬為對由 4 字節元素數組表示的數據進行的操作。後者的成本極高，因為單一的哈希操作可能需要數十萬個操作碼來模擬。

最後，我們要指出的是，由於比特幣腳本的開發難度很大，代碼自然更容易出現錯誤和漏洞。

4. 在比特幣腳本中保存狀態的挑戰

雖然上一節已經證明比特幣腳本還有很多不足之處，但我們認為，比特幣鎖定腳本的最大限制在於其只能讀取花費者的輸入。這意味著兩個嚴重的限制：

• 比特幣腳本不具備狀態性。也就是說，它們不能讀取 / 寫入存儲單元數據。類比以太坊虛擬機，沒有類似於 SLOAD/SSTORE的操作碼，而這是進行通用計算的一個基本功能。

• 比特幣腳本無法強制規定比特幣的花費方式（少數例外除外）。這可以通過 Covenant來解決，Covenant 賦予鎖定腳本這種能力。（你可以想象這樣一個簡單的應用：鏈上金庫，它通過限制允許花費的地址來運作。更通俗地說，Covenant 是一個功能極其強大的工具，具有廣泛的應用範圍。）

然後，我們將看到，通過構建 Covenant ，我們已經可以獲得狀態性。直觀地說，這是因為你可以使用 Covenant 在交易數據本身中模擬存儲的讀取和寫入。

事實上，以上所述還不足以概括比特幣腳本及其複雜性的全部內容。但至少，我們可以肯定的是，編寫比特幣腳本並非易事。比特幣腳本有非常嚴格的限制：

• 堆棧大小不得超過 1000 個元素的限制。

• 必須使用許多操作碼來模擬乘法等簡單操作。一般來說，你必須使用繁瑣的比特幣腳本語言編寫邏輯。

• 必須以 4 字節形式編碼的元素進行操作。特別是，你不能對加密操作碼的輸入進行操作和更改。

• 你的邏輯不能保存狀態，必須適應單個交易。

• 一旦進行身份驗證，你的邏輯不能控制比特幣的花費方式。

此外，根據上述限制編寫代碼容易出現錯誤和漏洞。

雖然支付等非常簡單的應用可以滿足上述限制，但任何稍微複雜的應用都會遇到障礙。下文，我們將瞭解 Covenant和 STARK 證明如何使我們打破這些侷限性。此外，我們還將討論 OP_CAT 如何幫助比特幣腳本實現上述功能。

5. 通過 Covenant 實現比特幣上的智能合約

本節，我們將瞭解比特幣中的 Covenant 是如何保存邏輯狀態的，並將更通俗地解釋，比特幣上的「智能合約」是什麼樣的。這裡的智能合約指的是某種有狀態的邏輯，它包含一系列函數，可以根據預定義的規則調用這些函數，將狀態轉換為不同的有效狀態。

更具體地說，比特幣合約需要以下功能：

• 持久的邏輯和狀態

• 控制邏輯 / 狀態變化的能力

如前所述，上述功能可以通過 Covenant來實現。回想一下，默認情況下，鎖定腳本只能讀取直接輸入的數據（scriptSig）。然而，通過 Covenant，鎖定腳本可以讀取花費者交易的所有數據字段，以及鎖定腳本所在的交易數據字段，甚至其他交易的數據。圖 3 展示了使用 Covenant 時鎖定腳本可以訪問的不同部分。

圖 3：鎖定腳本（可視化為一個鎖）可以訪問的一些數據字段（紅色箭頭所示）。除了訪問花費者交易的數據字段外，鎖定腳本還可以訪問鎖定腳本所在的交易（tx1）的數據字段，以及由花費者交易同時花費的另一筆交易（tx2）的數據字段。

我們認為，上述描述的 Covenant 足以在比特幣上構建通用智能合約。實際上，通用的方法是在交易數據本身中編碼狀態，並檢查其向新值轉換的有效性。為此，我們的交易將有兩個輸出：

• 第一個輸出保存合約的邏輯（通過鎖定腳本）以及合約中鎖定的資金。

• 第二個輸出保存智能合約的當前狀態。這個 UTXO 的鎖定腳本只保存狀態，永遠不會被花費（它鎖定的比特幣實際上為 0）。

鎖定腳本邏輯將執行以下規則：

• 花費者的交易必須具有完全相同的形式（只有兩個輸出，並且所有資金都鎖定在第一個輸出中）；

• 第一個輸出必須具有相同的鎖定腳本邏輯；

• 第二個輸出必須是有效狀態；

• 提供給當前鎖定腳本的輸入必須使該鎖定腳本相信從當前狀態到新狀態的轉換是有效的（有效性由邏輯設計者定義）

圖 4 是這種結構的示意圖。正如 Weikeng Chen 所寫的那樣，已有許多人建議為這種結構起一個正式的名稱，而「狀態守車（state caboose）」作為一個候選名字脫穎而出。守車（caboos）指的是連接在貨運列車尾部的鐵路車廂，是指乘務員的專用車廂及其工作空間。

圖 4：通過 Covenant 在比特幣上實現的智能合約，遵循「狀態守車」設計模式。鎖定腳本確保花費者交易具有相同的形式和鎖定腳本，並且具備有效的新狀態 S’，其從上一個狀態 S 的轉換也是有效的。

舉個簡單的例子，你可以想象一個簡單的計數智能合約。該合約的狀態總是按花費者提供的值遞增，這實際上調用了一個「累計」函數。這個計數智能合約如圖 5 所示。

圖 5：一個簡單的智能合約，通過將輸入（scriptSig）相加而將輸入累加到其狀態中。

最後要指出的是，為了「調用合約」並將合約轉換到新的有效狀態，用戶需要為每次調用創建一個新的花費者交易。與以太坊智能合約不同，比特幣智能合約本質上是按順序的，要求交易同時承諾當前狀態和新狀態。在比特幣上構建智能合約時，必須考慮到這種順序屬性。儘管也存在一些可能緩和該限制的方案，但本文將不對此展開討論。

總的來說，我們瞭解到 Covenant 使比特幣上實現了智能合約，理論上來說，當計算被分割到足夠多的交易中時，可以在比特幣上進行任意長度的計算。然而，僅僅使用 Covenant 仍然受到比特幣腳本的大部分限制，即堆棧大小限制、操作碼數量有限，以及一般情況下必須根據比特幣腳本語言的約束進行編程。

下文，我們將探討 STARK 證明系統如何通過減少比特幣上計算的區塊鏈佔用以及允許使用完全不同的語言進行腳本編寫，從而緩解上述限制。這種方法顯著提高了編程效率和安全性。

6. 比特幣 STARK 驗證器

本節的目的是探討如何在比特幣上進行計算，同時把通過比特幣腳本進行的實際計算量降至最低水平。我們的一般方法是通過計算委託，即將計算轉移至鏈下進行（多個實體都有可能參與），只有驗證步驟在鏈上的比特幣腳本中進行。

這就引出了一個問題：我們如何確保鏈下計算是正確執行的？實際上，解決這個問題的一個很自然的候選方案就是證明系統。簡單來說，證明系統允許 Alice（證明者）通過提供一個「證明」，來說服 Bob（驗證者）某個語句的正確性，關鍵在於：

• 與沒有證明者的幫助相比，驗證者只需完成更少的工作就能驗證這個語句。

• 此外，驗證者得到了保護，即證明者無法欺騙驗證者並使其相信一個錯誤的語句。

被證明的語句幾乎可以是任何語句，從難題的解法，到更相關的計算委託例子。更具體地說，Alice 將向 Bob 證明 f(x)=y，而不需要 Bob 自己進行 f(x) 的計算，如圖 6 所示。

圖 6：計算委託的證明系統。證明者計算 y=f(x) ，並讓驗證者相信這個語句的正確性。關鍵點在於，如果 y≠f(x)，證明者則無法說服驗證者相信這個事實。

因此，我們減少計算在區塊鏈上的佔用的方法將是在比特幣腳本中實現一個證明系統的驗證器。因此，為了調用智能合約，調用者將提供一個正確狀態轉換的證明，比特幣智能合約將驗證這個狀態轉換的證明的正確性，而不是直接檢查狀態轉換（見圖 7）。

此外，這種方法還有一個至關重要的好處，那就是比特幣腳本的邏輯可以保持固定不變，而不受應用的影響，這就大大降低了出現錯誤的幾率，並簡化了審計工作。這源於一個簡單的事實：同一個驗證算法可以驗證 y=f(x) 語句或 y=g(x) 語句，而無需事先知道要計算的函數。

圖 7：通過 Covenant 在比特幣上實現的智能合約，遵循圖 4 中的「狀態守車」設計模式，但增加了一個驗證器。這一次，鎖定腳本不再直接檢查從 S 到 S’ 的轉換是否有效，而是驗證轉換是否正確的證明。

雖然存在許多證明系統，但我們選擇使用 STARK 證明系統（STARK），因為其具有許多吸引人的特點：

• 後量子安全

• 無需可信設置

• 不增加比特幣新的加密假設

• 擴展速度最快

• 經過實戰檢驗，在超過一萬億美元的結算中得到信任

最後，與其他證明系統相比⬇️

STARK 對比特幣友好，即其驗證器組件更容易在比特幣腳本中實現。從本質上講，這是因為 STARK 主要基於哈希，與基於配對的證明相比，涉及的代數運算非常少。

在比特幣腳本中代數運算的成本很高，這就解釋了為什麼 STARK 是比特幣友好的。此外，Circle-STARK變體由於字段很小，對比特幣尤其友好。

因此，由於比特幣驗證器可以相對容易地驗證任何計算，我們可以選擇驗證哪種類型的計算。值得注意的是，這甚至可以是某種類型的 CPU 執行。此外，我們還可以在 CPU 的基礎上設計高級編程語言。為此，我們在 StarkWare 開發了 Cairo，這是一種類 Rust、人性化且安全的編程語言，專為高效證明和驗證而設計。在比特幣上證明 Cairo 的執行可以帶來很大的優勢。

總的來說，通過使用 STARK 驗證器以及 Covenant ，我們能夠在比特幣上實現通用計算。此外，這種計算還具有以下吸引人的附加特性：

• 可擴展性— 鏈上交易處理和計算變得可行，手續費極低。

• 表達能力— 邏輯可以用不同的、比比特幣腳本更強大的編程語言進行編程。這對比特幣編程的人性化和安全性至關重要。

• 鏈上安全性— 不管是什麼樣的計算，比特幣腳本都只驗證委託計算的數學證明。

• 靈活性— 比特幣上的計算可以存儲全局狀態，從而實現大量應用。

7. 使用 OP_CAT 進行連接以及其它功能

如上所述，OP_CAT 是一個簡單的、目前已被禁用的操作碼，其可以讓比特幣腳本連接堆棧上的元素。這個簡單操作的重要性不可低估，因為它可以同時在比特幣上實現 Covenant和 STARK。具體操作如下：

• STARK— 實際上，這並不奇怪。這是因為，STARK 實際上只是將數據連接在一起，然後進行哈希計算，由於哈希計算是比特幣腳本的原生計算，與代數運算不同，因此可以大大節省成本。STARK 中的主要哈希計算是 Merkle 路徑驗證（見圖 8）和 Fiat-Shamir 變換。( 此外，Circle-STARK 變體的字段大小隻有 31 字節，因此符合比特幣腳本的 4 字節限制，使其成為一種比特幣友好算法）。

• Covenant— 在 2021 年，Andrew Poelstra 提出了一個非同小可的觀點，即 OP_CAT 可以通過所謂的 Schnorr 技巧在比特幣上實現 Covenant，其中 Schnorr 的算法是 Pay2Taproot輸出類型的數字簽名（對於其他輸出類型，可以使用 Robin Linus 觀察到的類似的 ECDSA 技巧）。簡而言之，要實現 Covenant，我們需要使用 OP_CHECKSIG，這是唯一能夠將與花費者交易相關的數據放入堆棧的操作碼。這樣的操作過程並不簡單，但通過一些操作，你可以訪問所有必要的數據。

關於最後一點，在 Pay2Taproot輸出中保存狀態涉及一些技術難題。不過，可以使用其他輸出類型來存儲狀態，如 Pay2WitnessScriptHash。這就產生了前面提到的圖 4 和圖 5 中的「狀態守車」技術，交易中有兩個輸出。

圖 8：*Merkle 路徑驗證，涉及哈希和字符串連接操作。Merkle 路徑各部分（藍色字符串）被連接起來，並進行相應的哈希處理。然後，與 Merkle 根進行相等性檢查。OP_CAT操作被寫成 ||。*

8. 現狀與未來

在由 Weikeng Chen 和 Pinghzou Yuan 領導的開源項目中，我們正在共同努力建設 Bitcoin Wildlife Sanctuary。其中的兩個主要項目包括：

• Circle-STARK 驗證器，其工作演示可以驗證比特幣符號上一個簡單語句（與斐波納契數有關）的 STARK 證明。你可以通過此地址跟蹤其進展。

• Covenant 框架，已經通過一個簡單的計數 Covenant得以應用。驗證器也使用了該框架。

通過這一努力，我們的目標是為比特幣帶來高效、安全、對開發者友好的 OP_CAT 智能合約。我們認為，這對比特幣計算領域來說是一個充滿希望且令人興奮的前景。

9. 結語

總的來說，通過本文，我們瞭解到：

• Covenant是比特幣腳本的一個強大工具，允許在比特幣上創建智能合約。Covenant 擴展了比特幣的功能，不僅僅是簡單的價值轉移。

• 然而，即使有了 Covenant ，比特幣腳本仍有許多限制，包括堆棧大小的限制以及可使用的操作碼類型的限制。這限制了僅使用 Covenant 就能實現的智能合約的複雜性和表達能力。

• STARK可以有效驗證鏈下計算的執行情況，因此為緩解這些限制提供了一個很有前景的解決方案。通過利用 STARK，可以在比特幣智能合約中執行更復雜的計算，並最小化其在鏈上的計算佔用。

• Cairo是一種專為使用 STARK 進行高效證明和驗證而設計的編程語言，非常適合用於比特幣智能合約。它能夠創建更復雜的智能合約，提升了人性化程度、功能性和安全性。

• OP_CAT是一種比特幣腳本操作碼，用於連接元素。OP_CAT 在比特幣上實現 Covenant 和 STARK 方面起著至關重要的作用，進而為比特幣帶來了強大的通用計算能力。

下一篇文章，我們將深入探討比特幣上的 Circle-STARK 驗證器。

感謝 Weikeng Chen、Pingzhou Yuan 以及 StarkWare 團隊對本文提出的寶貴意見。

Victor Kolobov