導語近幾個月以來，越來越多關注的目光放到了 Optimistic Rollup (OR) 這個基於錯誤性證明（Fault Proof）的拓展框架上。我們 StarkWare 則採用有效性證明（Validity Proofs ，VP），因為它比錯誤性證明更安全。本文將在安全性討論之外，列舉一些 VP 較 OR 的額外優勢，同時糾正大眾對有效性證明的常見誤解，最後介紹 StarkEx —— StarkWare 開發、基於 STARK 和有效性證明的拓展引擎。在此特別說明，和 OR 比較，VP 具有以下優勢：· 從根本上更安全· 撤款時的資本效率高 1000 倍· 可拓展性更強（鏈上）· 在計算方面，至少能達到相同的效率安全性在上一篇分析（編者注：中譯本見文末）中，我們比較了 VP 和 OR ，前者只會在某狀態轉換被嚴格證明有效的情況下執行該狀態轉換，而後者則允許任意的狀態轉換（因此是 Optimistic ，樂觀的），參與方可以針對無效的狀態轉換提交錯誤性證明。我們的上一篇文章聚焦安全性分析，明確指出了一種能在 OR 中實施、且會導致 OR 中所有資金被盜的攻擊手段（其它可行的攻擊手段也在後續不斷討論）。區塊鏈上的基礎架構解決方案必須足夠健壯，要能支撐來自金融世界、每天萬億級別的資金互動負載。VP 和 OR 分別怎樣勝任？由於在 OR 中竊取資金的成本和收益大小無關，所以一旦系統承載了足夠多的資本，使得破壞系統變得有利可圖，那理性的參與者肯定會想方設法透過攻擊牟利。與 OR 相反，VP 不會轉換到任何無效的狀態，使得無論承載多少資金都不會被盜。對於大規模的金融系統，VP 更健壯，而 OR 更脆弱。也可以站在資料集一旦遺失的角度分析系統的安全性。和 VP 相比，OR 中的資料更為敏感。一旦資料遺失，OR 中的資金就可能被盜 —— 也正因如此，目前的設計方案都集中在鏈上資料可用性挑戰（Data Availability）上。而對於 VP ，由於採用了鏈上資料（例如 ZK-Rollup），資金就跟存在 Layer-1 中一樣安全。至於 VP 的鏈下資料部分，資金最多被凍結，而不會失竊。資金效率數字貨幣世界中流動性的一大痛點在於資金取款時的延遲。在 OR 中，標準取款視窗期大約為 1 周時間——這是給提交錯誤性證明的有效視窗時間（一個安全性引數）。在 VP 中，標準取款視窗大約為 10 分鐘（利用額外的軟體和硬體提升能變得更短）—— 這是針對上一次計算結果來生成有效性證明的時間。因此 OR 的標準取款視窗時間要比 VP 長 1000 倍（1 周/10 分鐘 ~ 1000）。使用 OR 就要承受這樣 1000 倍的不便，這不僅是時間上的延遲，也是資金效率的降低。我們先前描述過一個免信任的快速提款機制：想要立刻提款的使用者需要給流動性提供商打一份鏈下資產的欠條，即簽名了的條件支付交易，然後流動性提供商從自己的 “存錢罐” 智慧合約中墊付這筆資金，在鏈上把欠條金額上的資金轉給提款使用者，整套操作需要的時間和區塊鏈網路的轉賬時間差不多。流動性提供商會定期把累積的鏈下資產轉移到鏈上的“存錢罐”中。VP 和 OR 都能應用快速取款機制。但在 OR 系統中，流動性提供商需要在 “存錢罐” 中準備 1000 倍的資金，因為他們收到鏈下資產等待的時間視窗要長 1000 倍。這個 1000 倍的比例和 “存錢罐” 流動性演算法中的各種假設都無關：無論是基於取款金額期望值，或 提款-存款差額，再或者是峰值流動性需求、平均撤款金額等等，OR 需要的儲備金數量都是 VP 的 1000 倍。然而，有時根本無法使用快速撤款。對於非同質化資產（或者是一些非主流同質化資產）就沒法使用（或者應用的成本很高）：· 非同質 Token（NFT）：正如早先由 Vitalik 介紹那樣，如果一隻名叫 Mitzi 的名貴 CryptoKitty 存在了鏈下，他的所有者沒法要求在鏈上再收到一隻 Mitzi ，因為世界上有且只有這一隻叫 Mitzi 的 CryptoKitty。· 隱蔽交易：Zerocash 風格的承諾（commitment）在某種程度上也是非同質化的。要想把隱蔽交易中的資金快速提到主鏈（主鏈上也應該保持隱蔽性），使用者必須要向流動性提供商揭露承諾中的資料，破壞隱蔽性。在這種快速撤款機制無法應用的場景下，使用者只能選擇等待標準撤款視窗結束，VP 則要比 OR 快 1000 倍。可拓展性（鏈上）在這一部分我們將對比不同的 rollup 系統，由於同類事物間的比較才有意義，因此我們只比較提供鏈上資料可用性的 rollup 系統，即：OR vs. STARK ZK-Rollup（StR）。雖然我們不想，但是所有在鏈上儲存資料的 rollup 系統都將隨著 rollup 交易的增多而線性增大消耗的資源量。鏈上資料包含一些 狀態（例如交易細節）以及 見證資料（例如用來證明交易參與各方的數字簽名）。OR 和 StR 的區別在於隨著交易量的增加，前者的見證資料線性增長，而後者把這些見證替換成了一個證明，這個證明的大小隻會多項式對數級別增長。劃重點，對於足夠大、足夠多的批次交易，StR 的鏈上資料指紋要比 OR 小很多...從細節出發：在 StR 中，見證資料能核實 rollup 運營者所進行的查驗，因此一批計算只需要一則見證（例如一份 zk-proof），而不需要在每一份交易後面都附一份證明。更優秀的是，在現代 zkp 系統中，這個證明的大小是固定的（準確點來說，正如我們前文所提到，是多項式指數級別）。因此隨著批次交易的增大，分攤到每一條交易頭上的資源消耗反而減少。在 OR 中，每一條交易都必須附上一則見證，使驗證人能核實交易的正確性。因此對於大批次的交易，並沒有均攤減少的優勢。更重要的是。OR 中的見證要比交易本身大很多：比方說 OR 見證需要包含所有使用者的簽名 1，而 VP 不需要（證明能核實它們已經在鏈下被驗證過了）。在單純的支付中，見證要比支付的資料量大 3 到 5 倍；而對於複雜的應用場景（比如說隱蔽交易），見證通常會比狀態的資料大 10 倍以上，有時甚至更多。總的來說，OR 明顯要消耗更多的鏈上資源，也因此比 StR 更快地頂到拓展性天花板。通用計算開支（STARKs 越用越好用）人們常常拿 VP 和 OR 的通用計算開支做對比：即對於一個給定的鏈下計算任務，兩種不同的系統額外需要做哪些工作？下文我們將圍繞 StarkWare 的 STARK 展開，因為這是我們目前應用的 VP 框架。OR：由於 100 個驗證者互相監督基本上能夠保證整個計算的正確性，因此當提到 OR ，驗證者的數量都數以百計。到了驗證階段，每一個驗證人都需要進行一遍計算任務，因此在 OR 中做通用計算的開支是原任務的 100 倍。有必要說明，驗證人集合越小或者越多預先指派的情況，驗證人就越容易互相勾結，或者受到外界的賄賂、攻擊。STARK：由於驗證過程的計算開支微不足道，它只需要一個實體 —— 證明者 —— 進行大量的計算。驗證的計算開支有多微不足道呢？現在我們甚至可以用一臺簡單的智慧手機對一大批計算結果做驗證，因此可以忽略驗證的計算消耗。人們常說證明者的計算開支是原有任務的 10000 倍，因為證明需要消耗大量的計算來生成。但實際上 StR 需要的計算開支僅僅是 100 倍，因此額外的計算開支和 OR 大致相當。之所以說 StR 的計算開支僅有 100 倍，是基於以下理由：· 對於算數/幾何運算操作，我們已經達到了少於 100 倍的計算開支。目前應用的 Pedersen 雜湊函式僅僅比原來的操作增加了 20 倍計算消耗：即用 STARK 來證明一個 Pedersen 雜湊值的正確性僅僅比直接計算 Pedersen 慢 20 倍。· 對於那些像 SHA-256 那樣眾所周知計算開支很大的操作，我們正試著把那些函式換成對 STARK 友好的操作。我們目前受以太坊基金會的資助來進行這些研究，而且在 2020 年第一季度，許多密碼學大牛會提交給我們他們的替代方案建議。估計對 STARK 友好的雜湊函式在證明時僅比某些高效的雜湊演算法（例如 SHA-256）的直接計算慢 100 倍。最後，很多人之所以稱道 OR 是因為它能用到通用計算中，並且將支援 EVM 程式碼，而 VP 不具備這一特性。對於將 STARK 用到通用計算中，我們持樂觀的態度。
感謝 Dan Robinson, John Adler 以及 Vitalik Buterin 對本文的反饋。
¹ BLS 通常被認為是一種高效的聚合簽名機制。我們相信 BLS 不會只應用在這個用例中，因為它是整合多個簽名到一則訊息中的最佳方式。在 OR 的用例中，許多訊息都需要由交易收/發方簽名；而 BLS 簽名的驗證耗時 10ms/簽名（每條訊息進行一對操作），這不僅是驗證人（鏈下）的負擔，主鏈在判別欺詐時也需要處理這種消耗。
