從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

作者:Janos Nick,Blockstream

編譯:白丁& Faust,極客Web3

摘要:這篇文章簡潔但又一針見血的指出如何讓比特幣支援ZK驗證功能,涉及的具體話題包含比特幣UTXO和腳本在功能性上的缺陷、Taproot和OP_CAT以及BitVM和Chain State Proof等概念的大致內容。文中拋出了比較鮮明的觀點:

比特幣協定引入ZK是必然趨勢,對此有兩種路線:一種是讓比特幣腳本直接支援SNARK驗證,需要藉助OP_CAT操作碼,而OP_CAT最終通過的機率很大;第二種路線是基於BitVM的,需要引入詐欺證明的方式,而ZeroSync團隊也針對性的提出了Chain State Proofs來降低節點客戶端驗證歷史資料的成本。

正文:為了更深刻的理解比特幣,我們最好把它當作一個社會系統來看待。比特幣早期啟動的時候,開發者就確定了比特幣節點需要運行的軟體程序,就像確定了一套社會系統所遵循的規則。比特幣這個社會系統之所以能夠穩定運轉,是因為大家在「比特幣的本質是什麼」、「應該是什麼「等關鍵問題上存在某種共識。當然,共識的達成並不容易,人們在面對上述問題時,仍有廣泛且不斷演化的分歧。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

這可以追溯到比特幣的歷史來源問題。當國中本聰在發布比特幣白皮書時,曾說:「我在研究一套全新的電子支付系統,這套系統完全是P2P的,不需要依賴任何第三方」。這段話發表於密碼朋克郵件列表(一個成立於1992年的電子郵件討論小組,由一群關注隱私保護和密碼學技術的密碼學家及技術愛好者組成)。

然而,比特幣在產品設計層面限制了資料吞吐量。其單位時間內能處理的交易筆數有限,如果待處理的交易數量快速上升,用戶為了快點交易成功,就會發起價格戰,迅速拉高付出的手續費。比特幣網路內手續費最高的單筆交易出現在2024年出塊獎勵減半後,一筆上鍊優先級中等的交易手續費達到150美元。可以說,比特幣網路昂貴的交易手續費已成為一個難題。

為了解決交易手續費問題,人們把許多資源投入閃電網路開發工作。但根據一篇發佈於2016年的論文,閃電網路在實務上最多只能支援數千萬用戶,無法實現其全球支付系統的願景。

除了交易手續費太昂貴外,還有一個問題,就是比特幣始終無法實現願景中想達到的匿名性。中本聰在密碼龐克郵件討論群組中指出,比特幣具有隱私保護功能,交易發起者可以是完全匿名的。然而,雖然交易發起人不需要KYC,但比特幣鏈上的交易數據洩露了許多信息,很大程度上暴露了用戶隱私。

雖然有一些附帶隱私功能的錢包客戶端一定程度解決了上述問題,但這些錢包客戶端的開發者卻面臨著大大小小的威脅。例如,Samourai CoinJoin錢包的開發者在2024年4月被FBI逮捕,而在一週後,Wasabi錢包的開發者就關閉了他們的CoinJoin協調組件。顯然,這些所謂的隱私錢包並不完全值得用戶信任。

總結下來,直到今天比特幣的許多概念還遠未實現,相關技術仍處於不斷發展中。即使這樣,比特幣社群中許多人還認為比特幣的協議設計應該保持不變,但也有很多人像我一樣,熱衷於對比特幣做出改進。那麼,比特幣該往何種方向改進呢?

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

針對上述問題,比特幣社群中有很多提案,理論效果最好的應該是和ZK及SNARKs相關的。借助ZK和SNARKs,可以實現如下特性:

1. 顯著改善隱私性:使用同態Peterson承諾對交易金額和Range Proof顯著提高用戶隱私性(如Blockstream的Element側鏈中所做的);透過可連結簽署(如Monero )隱藏交易痕跡;實現真正的私密交易(如Zcash)。

2. 提高交易吞吐量

其實有許多技術方法可以解決比特幣身上存在的問題,但為什麼直到今天,這些技術仍沒有加入比特幣協議中?這是因為比特幣協議很難被修改。比特幣生態裡沒有類似以太坊基金會的組織,對協議的任何修改都需要社區達到高度共識才行,這裡涉及到大量的博弈和權力製衡,所以不同於以太坊那樣每年都會有EVM操作碼的更新,比特幣協議自問世以來,變更就非常少。

其實,協議難以被修改在某種程度上是好事,如果修改比特幣協議很容易,那麼對其進行惡意更改和攻擊也會很容易。這就引出了一個問題:在不改變比特幣協議設計的情況下,有什麼手段可以改善比特幣的效能?

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

要回答這個問題,我們要先回顧關於比特幣的知識。如果我們要將比特幣轉移給別人,我們需要先創建一筆交易,將其廣播到比特幣網路中。交易的輸出資料會說明轉帳的BTC金額,BTC接收者可以再建立一筆新的交易,來花費收到的BTC。此後,這筆新的交易又會產生新的輸出數據,並將BTC發送給其他人。

這裡要注意的是,比特幣沒有以太坊那樣的全局狀態,特別是沒有帳戶的狀態,只有交易輸出資料。每筆交易的輸出有兩種狀態:已被接收者花費或未花費。未被花費的交易輸出就是我們熟悉的UTXO。

當然,除了關聯的BTC數額外,每個交易輸出都有一段附加程序,用一種叫做比特幣腳本的語言來編寫。誰能向這段程式出示正確的證明Witness,誰就能花費這筆交易輸出(UTXO)。比特幣腳本本身是一種基於堆疊的程式語言,包含一系列操作碼,前述UTXO的附加程式往往由多個操作碼組成,它們基於堆疊完成計算並將結果再放回堆疊。

常見的比特幣腳本有很多種類型,從比特幣啟動之初就已經存在了。舉個例子,比特幣中最常見的腳本程式由公鑰+檢查數位簽章的操作碼組成。此操作碼規定,要花費/解鎖某個UTXO,必須出示對應公鑰的數位簽章。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

這裡我們來總結一下比特幣腳本的功能。先比特幣腳本能做什麼?

  • 可以重排堆疊,等式檢查(使用等式檢查來驗證特定條件是否滿足,從而確保交易的安全性和有效性),可以進行類似if-else的分支操作。
  • 可以對32位數字進行有限的算術運算,即加法和減法。
  • 資料可以哈希化,並且可以檢查ECDSA和Schnorr簽章。

比特幣腳本不能做什麼?

  • 沒有循環、跳轉、遞歸,即非圖靈完備,程式設計能力非常有限。
  • 不能進行位元操作。
  • 缺乏進行乘除法的操作碼。
  • 不能連接堆疊上的元素。
  • 幾乎沒有讀取並檢查鏈上交易資料的能力。比特幣腳本不能直接存取每筆交易的金額,也沒有辦法傳遞狀態(UTXO都是一次性使用的,每次轉帳都會銷毀舊的生成新的)。

在比特幣早期版本中,上述腳本中」不能做「的事情,有些其實可以做,但部分功能後來被中本聰禁用了,原因是中本聰發現這些操作碼存在漏洞。例如,可以把堆疊中2個元素合併的操作碼OP_CAT可以被用於遠端攻擊比特幣節點致其崩潰,中本聰出於謹慎,禁用了OP_CAT,其他的一些操作碼也遭到了禁用。

那麼,比特幣腳本是否可以驗證SNARK?理論上雖然比特幣腳本非圖靈完備,但它的基本操作足以驗證任何計算,可在實踐中SNARK驗證還是無法實現,因為驗證步驟所需的程式尺寸超過比特幣的最大區塊限制——4MB 。

也許我們可以盡量在大型有限域中進行算術運算,但這樣的成本非常高,例如BitVM實現的兩個254位元整數的乘法,相關的比特幣腳本尺寸達到近8KB。

而且,在沒有OP_CAT的情況下驗證Merkle證明的成本也很高,因為這需要類似for迴圈的操作。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

那麼再回到前面的問題:為什麼我們不能簡單地改變比特幣協議,增加功能更強大的操作碼?

如同先前所提到的,要在新的協議規則上達成多數共識非常困難,因為比特幣生態沒有中心化決策者,任何對比特幣腳本的改進提案都有很多反對意見,大家的立場、角度都是不同的。在比特幣網路中,沒有很好的辦法來衡量社群是否達成了多數共識,在這種情況下強行推動更新,會導致鏈分叉。

當然,比特幣也不是完全一成不變的,最近的更新是2017年的SegWit和2021年的Taproot。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

Taproot升級改變了許多規則,從理論發佈到真正被啟動落地,花了三年半。 Taproot被啟用的關鍵因素是:它沒有改變現有安全假設,並對比特幣協議做出了明顯改進。例如,它允許使用Schnorr簽章來取代ECDSA,二者都是基於離散對數假設,並使用相同的橢圓曲線,但前者比後者更有效率、計算量更少。

進一步說,Taproot對比特幣的改進主要分為以下三個部分:

第一,Taproot降低了有大量選擇性分支的腳本的驗證成本,可以讓比特幣支援更複雜的程式;

第二,Taproot縮減了需要在鏈上揭示的腳本數據,你可以將多段腳本程式組裝為一棵Merkle樹,每段腳本位於不同的葉子上,如果你要觸發某段腳本,只需揭示出示其所在的葉子及Merkle證明;

第三,Taproot也加入了其他的機制設計。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

話說回來,既然比特幣有Tarpoot這樣添加較強大功能的先例,為什麼不添加一個專用的操作碼來驗證SNARK呢?這是因為添加一個所謂的OP_SNARK操作碼與Taproot升級有很大不同。

首先,OP_SNARK的設計思路有很多,很難讓大多數人都支援某種單一方案;其次,如果這類提案通過了,所有比特幣節點都要支援該特定的OP_SNARK方案,這將增加龐大的技術負擔。

此外,OP_SNARK本身的複雜性也是不小的挑戰。如果不包括測試的話,Taproot只添加了約1600行程式碼,這是人們可以接受的,而相較之下,OP_SNARK包含的程式碼要複雜得多。

再有,誰來審核OP_SNARK操作碼該不該被啟動?如何在沒有幾個人理解其細節的情況下在比特幣生態內獲得共識?這些都是問題。因此綜合來看,OP_SNARK升級是不會在短時間內發生的。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

但是,還有其他途徑可以在比特幣腳本中驗證SNARK。我們可以添加較簡單的操作碼使比特幣腳本功能性更強大,讓人們可以在腳本中實現SNARK驗證器程式。但事實上用比特幣腳本語言來寫SNARK驗證程式的難度很高。

因此,Blockstream研究團隊正在開發Simplicity,這是一種旨在取代比特幣腳本的程式語言。 Simplicity專為區塊鏈共識系統設計,刻意設計成不圖靈完備的,易於靜態分析和形式化驗證。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

下面我們要談一個非常簡單但又很重量級的提案,它可以讓比特幣腳本變得更強大,也就是OP_CAT操作碼。前面我們提到,OP_CAT存在於比特幣的最初版本中,但這個操作碼可以在特定條件下讓比特幣節點被DOS攻擊,所以被中本聰禁用,現在比特幣社群中有一些人想重新啟用它。

OP_CAT的功能是彈出堆疊頂部的兩個元素,將它們連接起來,然後放回堆疊。這聽起來非常簡單,但卻能為比特幣腳本帶來龐大的功能改進。

例如,比特幣腳本程式本來無法存取鏈上交易的金額等狀態訊息,但有了OP_CAT這將成為可能;OP_CAT還可以用於驗證Merkle證明。總之OP_CAT是屬於底層操作碼等級的升級,會衍生出非常多的新功能,很多人都提出使用OP_CAT能達成的效果。

而OP_CAT是否有助於在腳本中驗證SNARK呢?答案是有幫助,因為支持驗證Merkle證明就有助於驗證基於FRI的SNARK,而OP_CAT可以支持這一點。在過去,涉及SNARK驗證的腳本程式可能尺寸太大而無法放入比特幣區塊,有了OP_CAT可以壓縮程式大小。

過去OP_CAT已經被討論很多年,越來越多的人認識到它在交易檢查(introspection)中的作用。與其他提案相比,OP_CAT的優勢在於它以前在比特幣腳本中存在過,因此更容易在社區中達成共識。然而,OP_CAT啟用後也可能導致某些人的MEV收益受損,所以比特幣社群對其尚未達成共識。

綜上,比特幣可能會有一個潛在路徑,透過啟用如OP_CAT這樣的簡單操作碼,讓大家可以用比特幣腳本中驗證SNARK。另外值得一提的是,最近有一個名為「Great Script Restoration」的提案,啟用了乘法操作碼,允許所有算術操作碼以任意精度操作。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

此外,當我們考慮OP_CAT對比特幣網路的影響時,可以檢視它通過後對比特幣節點運行者的影響。為了使比特幣具有抗審查性和去中心化,比特幣社群希望盡可能多的人運行節點驗證數據。如果比特幣支援了SNARK驗證操作,運行比特幣節點的成本仍不會顯著增加,這對於比特幣的安全性和抗審查性並無太多危害。

目前,一個比特幣區塊可以包含最多4MB的數據,預計每10分鐘挖出一個區塊,幾乎所有的區塊都可以填滿比特幣腳本和Witness見證(類似於數位簽章)。折算下來,每個區塊目前最多可以包含80K次簽名驗證,平均每個區塊支援7K到10K次簽名驗證,我的2020年版英特爾CPU驗證一個比特幣區塊平均耗時3.2 秒。當然,影響區塊驗證速度的不只簽章驗證的耗時。

此外,如果比特幣交易日後支援ZK化,就算因此延長交易生成時間似乎也無傷大雅。對於用於長期儲存資產的硬體錢包而言,它們往往帶有螢幕且體積並不大,功能是儲存金鑰並產生簽名。硬體錢包的CPU一般比較弱,如240MHz雙核CPU,並帶有一定內存,在簽署比特幣交易時響應非常迅速。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

我做了一個小調查,詢問用戶能接受的簽名設備產生證明的最長延時,許多人可以接受較長的等待時間,特別是能獲得顯著收益的時候。所以如果我們將ZK引入比特幣交易中,似乎也沒有太多麻煩。

上面我們花了很多篇幅來討論應如何變更比特幣的底層設計,但其實還有不少無需變更比特幣就可以實現的應用場景。這裡我想強調一個與BitVM相關的應用—Chain State Proofs,它結合了ZK,可以證明區塊雜湊的有效性。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

這項技術為比特幣帶來了什麼變化?首先,有了Chain State Proofs,就可以壓縮比特幣曆資料的同步與驗證工作量,大幅降低運行節點的成本。目前在一台硬體好的設備上從創世區塊同步並驗證到最新的比特幣區塊,需要5小時30分鐘,而在樹莓派級別的設備上則需要幾天,如果引入狀態證明則可以大幅壓縮這個耗時。其次,鏈狀態證明是與BitVM可以用到的重要部分,會對BitVM的實作有推動作用。

ZeroSync團隊對Chain State Proofs進行了深入研究,並創建了一種更輕量的“header chain Proofs”,這種方案結合ZK,只證明比特幣區塊頭的有效性,以此構成一條”header chain“ ,包含比特幣歷史上全部的85萬個區塊頭,並針對每個區塊頭產生80位元組的哈希。

這種方案需要對每個比特幣區塊頭進行雙重SHA-256計算以驗證對應的PoW證明。 ZeroSync的使用STARKs來產生比特幣的header chain Proof,產生證明的成本約為4000美元,用我的瀏覽器驗證證明則只需要3秒鐘。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

但由於不包含區塊中交易內容的驗證過程,header chain proof只能假設擁有最多POW證明的區塊鏈是有效的,並默認讓比特幣客戶端同步這條鏈上的最新區塊。在這種場景下,雖然攻擊者可以創建包含無效交易的區塊,並在該區塊之後添加更多區塊,並產生header chain proof來蒙蔽同步歷史資料的比特幣客戶端,但這樣做的話攻擊成本極為昂貴,並且會被現有的比特幣全節點客戶端直接揭穿。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

然而,儘管這種攻擊場景的成功率很低,但如果可以讓攻擊者竊取巨大金額的BTC,那麼header chain proof就無法被認作是萬無一失的方案。如果我們想證明完整的鏈狀態,就需要直接證明比特幣區塊中所有的內容都有效,包括基於secp256k1橢圓曲線的ECDSA和Schnorr簽名驗證。

比特幣每個月的歷史區塊中都可以包含3000萬個簽名,歷史上總計包含25億次簽名運算,以及大量的SHA-256運算。這樣下來比特幣網路每個月產生的區塊資料約7GB,所有歷史資料總計超過650GB。而實際情況中這個數字可能是2到3倍。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

現在我們再來看BitVM。 BitVM使得比特幣可以驗證任何計算任務,是無需變更協議來實現SNARK驗證的最佳路徑。 BitVM使用兩種技術繞過了比特幣區塊對腳本大小的限制。首先,它使用了Taproot MerkleTree的腳本結構;

其次,它啟用了可以跨單一腳本存取的KV儲存方案,允許連接到超級多的腳本程式。不過,比特幣協議不強制保證上述KV存儲方案的完整性,BitVM需要通過欺詐證明來檢查惡意Prover,如果Prover發布無效聲明或有問題的KV存儲,其他人可以在比特幣鏈上發起一筆交易,顯示Prover行為不當,並取走其事先質押的資產。

從OP_CAT到狀態證明和BitVM,如何讓比特幣支援ZK?

總結一下,比特幣正面臨重大挑戰,大家提出了各種方案解決這些問題,然而,這些提案不會很快被比特幣社群採納,對協議的改變也非短期內能完成的,這既是好事也是壞事,這也意味著比特幣是去中心化的、較安全的。

比特幣社群許多人對SNARK/STARK的潛力感到興奮。在中長期內實現SNARK驗證的最可行方法,很大機率是BitVM,但它需要更多的研發投入才能在實踐中發揮作用;

重新啟用OP_CAT操作碼也是一種思路,但需要證明重啟該操作碼的收益遠大於風險,並調查哪些簡單的操作碼可以允許在比特幣腳本中驗證SNARK,或者探究類似OP_CAT的功能可以實現什麼場景。無論選擇哪種方案,比特幣社群的最終宗旨一定是讓產品變得實用,支援更多可落地的場景。

Total
0
Shares
Related Posts