來源:Bitlayer研究小組

作者: lynndell, mutourend.

信箱: lynndell2010@gmail.com, zouyudi@gmail.com

1.引言

比特幣是一種去中心化、安全且值得信賴的數位資產。但是,它存在重大限制,無法成為支付和其他應用程式的可擴展網路。比特幣的擴容問題自誕生以來就備受關注。比特幣UTXO模型將每筆交易視為獨立事件,導致一個無狀態的系統,缺乏執行複雜的、依賴狀態的運算能力。因此,雖然比特幣可以執行簡單腳本和多簽交易,但它難以促進在有狀態的區塊鏈平台上常見的複雜和動態的合約互動。這個問題顯著限制了在比特幣上建構的去中心化應用(dApps)和複雜金融工具的範疇,而狀態模型平台提供了一個更多樣化的環境,用於部署和執行功能豐富的智慧合約。

對於比特幣擴容,主要有狀態通道、側鏈、客戶端驗證等技術。其中,狀態通道提供了安全且多樣化的支付解決方案,但在驗證任意複雜計算的能力上有限。這種限制減少了其在需要複雜、條件性邏輯和互動的各種場景中的應用。側鏈雖然支援廣泛的應用,並提供超越比特幣功能的多樣性,但是具有較低的安全性。這種安全上的差異源自於側鏈採用的是獨立的共識機制,這些機制遠不如比特幣共識機制的健壯性。客戶端驗證,使用比特幣UTXO模型,可以處理更多複雜的交易,但是與比特幣沒有雙向校驗和約束能力,導致其安全性低於比特幣。客戶端驗證協定的鏈下設計依賴伺服器或雲端基礎設施,這可能導致集中化或透過妥協伺​​服器進行潛在審查。客戶端驗證的鏈下設計也為區塊鏈基礎設施引入了更多複雜性,可能導致可擴展性問題。

2023年12月,ZeroSync專案負責人Robin Linus發表了一篇名為《 BitVM:Compute Anything On Bitcoin 》的白皮書,引發了大家對於提升比特幣可編程性的思考。該論文提出一種在不改變比特幣網路共識的情況下可實現圖靈完備的比特幣合約解決方案,使得任何複雜計算都可以在比特幣上驗證,而無需改變比特幣基本規則。 BitVM充分利用比特幣腳本和Taproot,實現樂觀Rollup。基於Lamport簽名(又稱bit commitment),讓比特幣兩個UTXO之間建立聯繫,實現有狀態的比特幣腳本。在Taproot 位址中承諾一個大型程序,operator和驗證方進行大量的鏈下交互,在鏈上產生的足跡很小。如果雙方合作,則可以執行任意複雜的、有狀態的鏈下計算,而不在鏈上留下任何痕跡。如果雙方不合作,則發生爭議時,需要鏈上執行。因此,BitVM大大拓寬了比特幣的潛在用例,使比特幣不僅可以作為一種貨幣,還可以作為各種去中心化應用程式和複雜運算任務的驗證平台。

但是,雖然BitVM技術在比特幣擴容方面極具優勢,但仍處於早期階段,在效率和安全方面仍存在一些問題。如:(1)挑戰與回應需要多次交互,導致手續費昂貴,挑戰週期長;(2)Lamport一次性簽章資料較長,需要降低資料長度;(3)雜湊函數複雜度較高,需要Bitcoin friendly哈希函數,降低費用;(4)現有BitVM合約龐大且比特幣區塊容量有限,可藉助scriptless scripts實現Scriptless Scripts BitVM,節省比特幣區塊空間,同時提升BitVM效率;(5)現有BitVM採用的是授權模型,僅聯盟成員可發起挑戰,且限定為僅兩方之間,應擴展至permissionless 多方挑戰模式,將信任假設進一步減少。為此,本文提出一些最佳化思路,進一步提高BitVM的效率與安全性。

2.BitVM原理

BitVM定位為Bitcoin的鏈下合約,致力於推動Bitcoin合約功能。當前比特幣腳本是完全無狀態的,所以比特幣腳本執行時,其執行環境在每個腳本之後都會重置。令腳本1和腳本2擁有相同x值的原生方式是不存在的,比特幣腳本原生不支援該方式。但仍可藉助現有opcodes,透過Lamport一次性簽章讓Bitcoin腳本是有狀態的,如可強制script1和script2中的x為相同值。如果參與者簽署了相互衝突的x值,則可對其進行懲罰。 BitVM程式計算發生在鏈下,而計算結果驗證發生在鏈上。目前Bitcoin區塊有1MB限制,當驗證計算過於複雜時,可藉助OP技術,採用挑戰響應模式,支援更高複雜度的計算驗證。

與Optimistic Rollup和MATT提案(Merkelize All The Things)類似,BitVM系統基於詐欺證明和挑戰-回應協議,但不需要修改比特幣的共識規則。 BitVM底層原語簡單,主要基於雜湊鎖、時間鎖和大型Taproot 樹。

證明者逐字節承諾,但在鏈上驗證所有計算將過於昂貴。所以,驗證者執行一系列精心設計的挑戰,以簡潔地駁斥證明者的虛假主張。證明者和驗證者共同預簽一系列挑戰和回應交易,用於解決爭議,從而允許在比特幣上進行通用計算驗證。

BitVM關鍵組件有:

  • 電路承諾:證明者和驗證者將程式編譯為大型二進位電路。證明者在一個Taproot地址中承諾該電路,該地址下的每個葉子腳本,對應該電路中的每個邏輯閘。核心是基於bit commitment來實現logic gate commitment,從實作電路承諾。

  • 挑戰與回應:證明者和驗證者預簽一系列交易來實現挑戰-反應遊戲。理想情況下,這種互動是在鏈下進行的,當證明者不配合時,也可在鏈上執行。

  • 模糊懲罰:如果證明者提出任何不正確的聲明,則驗證者挑戰成功後可拿走證明者存款,挫敗證明者的作惡行為。

3.BitVM優化

3.1 基於ZK降低OP交互次數

目前有2大主流Rollups:ZK Rollups和OP Rollups。其中,ZK Rollups依賴ZK Proof的有效性驗證,即正確執行的密碼學證明,其安全性依賴於計算複雜度假設;OP Rollups依賴Fraud Proof,假設所提交的狀態均是正確的,設定挑戰週期通常為7天,其安全性假定係統內至少有一個誠實方能偵測到不正確的狀態,並提交詐欺證明。假設BitVM挑戰程式最大步數為2^{32},需要記憶體為2^{32}*4位元組,約17GB。在最壞情況下,需要約40輪挑戰和回應,約半年時間,總腳本約150KB。該情況下激勵嚴重不足,但實際情況下幾乎不發生。

考慮使用零知識證明降低BitVM的挑戰次數,進而提高BitVM的效率。根據零知識證明理論,如果資料Data滿足演算法F,則證明proof滿足驗證演算法Verify,即驗證演算法輸出True;如果資料Data不滿足演算法F,則證明proof也不滿足驗證演算法Verify,即驗證演算法輸出False 。在BitVM系統中,如果挑戰者不認可證明方提交的數據,則發起挑戰。

對於演算法F,使用二分法拆開,假設需要2^n次,則能找到錯誤點;如果演算法複雜度太高,則n較大,需要很久才能完成。但是,零知識證明的驗證演算法Verify的複雜度是固定的,公開證明proof和驗證演算法Verify全過程,發現輸出為False。零知識證明的優點在於開啟驗證演算法Verify所需的計算複雜度,比起二分法開啟原始演算法F,要低得多。因此,借助零知識證明,讓BitVM挑戰的不再是原始演算法F,而是驗證演算法Verify,降低挑戰輪數,縮短挑戰週期。

最後,雖然零知識證明有效性和詐欺證明依賴不同的安全假設,但可將二者結合,可建構ZK Fraud Proof,實現On-Demand ZK Proof。不同於full ZK Rollup,不再需要為每個單一狀態變換產生ZK proof,On-Demand模型使得,僅在有挑戰時才需要ZK Proof,而整個Rollup設計仍是樂觀的。因此,仍預設所產生的狀態是有效的,直到有人挑戰該狀態。如果某個狀態無挑戰,則無需產生任何ZK Proof。但是,如果參與者發起挑戰,則需為挑戰區塊內所有交易的正確性產生ZK Proof。未來,可探索為單一有爭議指令產生ZK Fraud Proof,避免一直產生ZK Proof的運算成本。

3.2 比特幣友善的一次性簽名

在比特幣網路中,遵循共識規則的交易是有效交易,但除共識規則之外,還額外引入了standardness規則。比特幣節點僅轉發廣播標準交易,有效但非標準的交易被打包的唯一方法直接是與礦工合作。

根據共識規則,legacy(即non-Segwit)交易的最大size為1MB,即佔滿整個區塊。但legacy交易的standardness上限為100kB。根據共識規則,Segwit交易的最大size為4MB,即weight limit。但Segwit交易的standardness上限為400kB。

Lamport簽名是BitVM的基礎元件,降低簽章和公鑰長度,有助於降低交易數據,進而降低手續費。 Lamport一次性簽章需使用雜湊函數(如one way permutation函數f)。 Lamport一次性簽章方案中,訊息長度為v比特,公鑰長度為2v比特,簽章長度也為2v比特。簽章和公鑰較長,需要消耗大量的儲存gas。因此,需要尋找類似功能的簽章方案,以降低簽章和公鑰長度。相較於Lamport一次性簽名,Winternitz一次性簽名的簽章和公鑰長度大幅降低,但增加了簽章和驗籤的運算複雜度。

在Winternitz一次性簽章方案中,使用特殊函數P將v位元的訊息對應為長度為n的向量s。 s中各元素的值為{0,...,d}。 Lamport一次性簽章方案是d=1特殊情況下的Winternitz一次性簽章方案。在Winternitz一次性簽章方案中,n,d,v之間的關係滿足:n≈v/log2(d+1)。當d=15時,有n≈(v/4)+1。對於包含n個元素的Winternitz簽章而言,比Lamport一次性簽章方案中的公鑰長度和簽章長度短4倍。但是,驗簽的複雜度提高了4倍。在BitVM中使用d=15,v=160,f=ripemd160(x)實作Winternitz一次性簽名,可將bit commitment size降低50%,從而將BitVM的交易費降低至少50%。未來,在對現有Winternitz比特幣腳本實作進行最佳化的同時,可探索以比特幣腳本表達的更緊湊的一次性簽名方案。

3.3 比特幣友善的哈希函數

根據共識規則,P2TR script的最大size為10kB,P2TR script witness的最大size與最大Segwit交易size一樣,為4MB。但P2TR script witness的standradness上限為400kB。

目前比特幣網路還不支援OP_CAT,無法拼接字串做Merkle path驗證。因此,需用現有比特幣腳本,以script size和script witness size最優的方式,實作一種比特幣友善的雜湊函數,從而支援merkle inclusion proof驗證功能。

BLAKE3為BLAKE2雜湊函數的最佳化版,並引入了Bao tree模式。相較於BLAKE2s-based,其壓縮函數的輪數由10降至7。 BLAKE3雜湊函數會將其輸入切分為1024位元組大小的連續chunks,最後一個chunk可能更短但不為空。當只有一個chunk時,則該chunk為root node,且為該樹的唯一節點。將這些chunks排佈為二元樹的葉子節點,然後對每個chunk獨立壓縮。

當BitVM用於驗證Merkle inclusion proof場景時,雜湊運算的輸入由2個256-bit雜湊值拼接而成,即雜湊運算的輸入為64位元組。使用BLAKE3雜湊函數時,這64位元組可分配於單一chunk內,整個BLAKE3雜湊運算只需要對單一chunk應用一次壓縮函數。在BLAKE3的壓縮函數中,需要運行7次輪函數和6次置換函數。

目前BitVM中已完成基於u32值的XOR、模加、位元右移等基礎運算,可以輕易組裝出比特幣腳本實現的BLAKE3雜湊函數。使用stack中4個分開的位元組來表示u32 words,來實作BLAKE3所需的u32 addition、u32 bitwise XOR 和u32 bitwise rotations。目前BLAKE3雜湊函數比特幣腳本共約100kB,足以用於建構一個toy版本的BitVM。

此外,可分割這些BLAKE3程式碼,使得Verifier和Prover可透過將挑戰-回應遊戲中的執行一分為二而不是完全執行來顯著降低所需的鏈上資料。最後,使用比特幣腳本實現Keccak-256、Grøstl等哈希函數,從中選出最比特幣友好的哈希函數,並探索其它新的比特幣友好哈希函數。

3.4 Scriptless Scripts BitVM

Scriptless Scripts是一種透過使用Schnorr簽名,在鏈下執行智能合約的方法。 Scripless Scripts概念誕生自Mimblewimble,除了kernel及其簽章之外,不儲存永久資料。

Scriptless Scripts的優點是功能、隱私和效率。

  • 功能:Scriptless Scripts可增加智能合約的範圍和複雜度。比特幣腳本能力受限於網路中已啟用的OP_CODES數量,而Scriptless Scripts將智能合約的規範和執行從鏈上轉移到僅設計合約參與方的討論,無需等待比特幣網路的分叉來啟用新的操作碼。

  • 隱私:將智能合約的規範和執行從鏈上轉移到鏈下,可增加隱私。在鏈上,合約的許多細節都會分享到整個網絡,這些詳細資訊包括參與者的數量和地址以及轉帳金額等。透過將智慧合約移至鏈下,網路只知道參與者同意其合約條款已滿足且相關交易有效。

  • 效率:Scriptless Scripts最大限度地降低鏈上驗證和儲存的資料量。透過將智能合約移至鏈下,全節點的管理費用會減少,用戶的交易費用也會降低。

Scriptless scripts是一種在比特幣上設計密碼學協議的方法,可避免執行顯式智能合約。核心思想是使用密碼演算法實現期望功能,而不是使用腳本實現功能。適配器簽名和多重簽名,是Scriptless scripts的原始建造基石。使用Scriptless scripts,可實現比常規交易更小的交易,降低交易手續費。

可藉助Scriptless Scripts,使用Schnorr多重簽章和適配器簽名,不再像BitVM方案那樣提供哈希值和哈希原像,也可實現BitVM電路中的邏輯閘承諾,從而可節省BitVM腳本空間,提高BitVM效率。雖然現有的Scriptless Scripts方案能降低BitVM腳本空間,但需要證明者和挑戰者有大量互動來組合公鑰。未來將對此方案進行改進,同時嘗試將Scripless Scripts引入到具體BitVM功能模組內。

3.5 無需許可的多方挑戰

目前BitVM挑戰預設需要許可的原因在於:Bitcoin的UTXO只能執行一次,導致惡意的verifier可透過挑戰誠實prover來「浪費」該合約。目前BitVM限定為兩方挑戰模式。試圖作惡的prover,可同時用自己控制的verifier發起挑戰,從而「浪費」該合約,使得作惡成功,而其它verifier無法阻止該行為。因此,在Bitcoin基礎之上,需要研究無需許可的多方OP挑戰協議,可將BitVM的現有1-of-n信任模型,擴展至1-of-N。其中,N遠大於n。此外,需要研究解決挑戰者與prover串謀或惡意挑戰「浪費」合約的問題。最終實現信任更小的BitVM協定。

無需許可的多方挑戰,允許任何人在沒有許可名單的情況下參與。這就意味著,用戶可在沒有任何可信任第三方參與的情況下,從L2提幣。此外,任何想要參與OP挑戰協議的用戶均可質疑並刪除無效提款。

將BitVM擴展為無需許可多方挑戰模型,需解決以下攻擊:

  • 女巫攻擊:即使攻擊者偽造多個身分參與爭議挑戰,單一誠實參與者仍能贏得爭議。如果誠實參與者捍衛正確結果的成本,與對攻擊者的數量呈線性關係時,則當涉及大量攻擊者時,誠實參與方為贏得爭議所需付出的成本將變得不切實際,且容易受到女巫攻擊。論文Permissionless Refereed Tournaments中,提出一種改變遊戲規則的爭議解決演算法,單一誠實參與者贏得爭議的成本隨著對手的數量呈對數增長,而不是線性增長。

  • 延遲攻擊:某個或一群惡意方,遵循某種策略來阻止或延遲正確結果(如將資產提取到L1)在L1上的確認,並迫使誠實的prover花費L1手續費。可要求挑戰者需事先質押以緩解此問題。如果挑戰者發動延遲攻擊,則沒收其質押。但是,如果攻擊者願意在一定限度內犧牲質押來追求延遲攻擊,則應該有應對策略來降低延遲攻擊的影響。論文BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol提出的演算法,使得無論攻擊者願意失去多少質押,最壞情況下的攻擊只能導致一定上限的延遲。

未來,將探索適用於比特幣特性的,可抵抗以上攻擊問題的BitVM無需許可多方挑戰模型。

4.結論

BitVM技術探索才剛開始,未來將探索並實踐更多的最佳化方向,以實現對比特幣的擴容,繁榮比特幣生態。

參考文獻

  1. BitVM: Compute Anything on Bitcoin

  2. BitVM:Off-chain Bitcoin Contracts

  3. Robin Linus on BitVM

  4. [bitcoin-dev] BitVM: Compute Anything on Bitcoin

  5. The Odd Couple: ZK and Optimistic Rollups on a Scalability Date

  6. What are Bitcoin's transaction and script limits?

  7. BIP-342: Validation of Taproot Scripts

  8. https://twitter.com/robin_linus/status/1765337186​​222686347

  9. A Graduate Course in Applied Cryptography

  10. BLAKE3: one function, fast everywhere

  11. [bitcoin-dev] Implementing Blake3 in Bitcoin Script

  12. https://github.com/BlockstreamResearch/scriptless-scripts

  13. Introduction to Scriptless Scripts

  14. BitVM using Scriptless Scripts

  15. Solutions to Delay Attacks on Rollups

  16. Introducing DAVE. Cartesi's Permissionless Fault-Proof System.

  17. Delay Attacks on Rollups

  18. Solutions to Delay Attacks on Rollups - Arbitrum Research

  19. Multiplayer Interactive Computation Games Notes

  20. BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol

  21. Permissionless Refereed Tournaments