作者：Robin Linus，BTC Study

初版 BitVM 的設計局限在兩個參與者。後續的工作結合了並行以及冗余的實例，以引入基於 1-of-n 誠實假設的多方參與。這些合約的主要局限在於所有驗證者都必須在編譯時定義好。而且，啓動开銷會隨着驗證數量的增加而增加。這暗示着，想要打破一個合約，永遠只需賄賂有限數量的參與者。

BitVM2 是一個大膽的變種：任何人都可以作爲驗證者。這依然需要帶有 1-of-n 誠實參與者假設的一次性裝置，但在運行時，任何人都可以挑战一個無效的斷言，不需要具備初始化團體成員的身份（不需要是那 n 個參與者之一）。這克服了以往方案的局限性，並優化了它們的信任假設。而且，它還簡化了整體設計，將審判的最長輪次降低到兩輪。

橋接合約（bridge）依然額外要求一些預先定義的操作員集合，並且m個操作員中至少要有一個是誠實的。不過，即使在所有操作員都不誠實的情況下，他們也無法偷走你的錢，最多只能燒掉這些錢。

引言

對於一個給定的程序 f，我們希望驗證一些斷言：輸入一些x，會輸出y，也即f（x）=y。舉個例子，f可以是一個 SNARK 驗證器，比如 Groth16 證明系統的驗證器。那么 x就是一個證據，而y 就是一些 SNARK 證明了有效性的輸出狀態（output state）。

在 SNARK 驗證器這樣的例子中，程度太大，無法用一段比特幣腳本來表示它。實現一個 Groth16 驗證器可能需要體積高達 20 MB 的腳本。但是，可允許的腳本體積的上限是比特幣區塊體積的上限：4 MB。而就算壓縮到這個體積，可能依然過於龐大了。

幼稚的解決方案

“Lamport 籤名” 提供了一種辦法，將一個程序f（x）=y分割成多個步驟。比如步驟：n=42。

這樣一來，f 的計算就可以分切成有順序的 43 筆交易， 在多個區塊中執行。每一筆交易都以上一筆交易的輸出狀態作爲自己的輸入狀態。但凡證明者在任何一個狀態z_i 上含糊其辭，每個人都可以使用相衝突的 Lamport 籤名作爲一個欺詐證據。

這確實是一種挑战證明者的免信任辦法。但是，這種解決方案的重大局限在於其密集的鏈上足跡，因爲它依然要求證明者執行整個計算。此外，同樣因爲 Lamport 籤名，它引入了轉換狀態的开銷。

平衡式解決方案

我們可以將一些重度工作從證明者一方轉移給驗證者的欺詐證據，從而顯著減少鏈上足跡。現在，證明者只需一次性承諾x和y，以及所有中間結果z1，z2……，z42。

任何驗證者都可以證否任何錯誤的斷言。在啓動階段，我們定義一棵 Taptree，包含了 43 個腳本，以證否f1，f2，f3，f43 任何一段計算。只要一個斷言

不能成立，任何人都可以從對應的腳本中花費。這就將最差情況下的計算量降低到了一步f_i ，由驗證者執行。這一步可能依然需要可觀體積的 Script 實現。理論上，只要它能塞進一個區塊，就沒有太大問題，或者更好一些，可以實現 400 KB 的標准化體積。在實踐中，對一些具體的 f  實現，我們會嘗試在證明者的承諾體積和驗證者的腳本體積之間找出一個最優的平衡。

本質上，這允許任何人毀滅證明者的輸出，只要證明者作出了任何不正確的斷言。不然的話，如果沒有人能證否任何一段計算，那么，到腳本超時的時候，誠實的證明者就能花費這個輸出。最多只需要兩輪。

這個機制可以作爲橋接合約免許可驗證的基本構築模塊。

樂觀解決方案

下列協議提升了上述設計中的皆大歡喜路徑（有希望是最常用路徑），代價是在最差情況下增加了兩輪交互：

1.證明者承諾輸出狀態y

2.如果不正確，任何人可以开啓一輪挑战

3.證明者承諾中間結果 z1,z2,……z42

4.如果不正確，任何人都可以證否斷言f _i

免許可的橋接合約設計

局限性：手續費

在上述設計中，證明者可以偷取一些手續費。在這種情況下，資金儲備依然是安全的，只不過驗證者會失去一些擔保資金。

攻擊場景如下：

• 證明者是惡意的

• 證明使用自己的 KickOff_Tx（不具備有效的 PegOut_Tx）

• 證明者等待一個挑战者執行 Challenge_TX，爲執行挑战的證明者支付

• 證明者不執行挑战，直接停止響應

下面這幅修正後的圖解決了這個問題。需要多兩筆 n-of-n 的預籤名交易。

局限性：誠實操作員

這個設計要求至少以爲操作員是誠實的，否則資金最終會變成不可花費的。在現實中，活性故障可以搭配綁票攻擊來盜竊資金（例如：除非你給我支付 50% 的贖金，否則你的資金就別想解鎖。）