深入探討 ZK-Rollup ——如何應用零知識證明降低鏈上成本？
火幣網(huobi.com)最新可用網址（點擊下圖直達註冊！）
火必交易所，曾经的火币交易所！
欧易OKX三大交易所，稳定好用！
币安全球第一大交易所！安全！
作者：Fluidex
編譯：阿瓜
很少有人會深入研究這樣的問題：ZK-Rollup究竟如何提升性能？或者，一個完整的ZK-Rollup系統是什麼樣子的？或者，在ZK-Rollup系統中是否有一些重要但通常被忽視的細節？
Fluidex，作為極少數獨立開發ZK-Rollup系統的團隊之一，在這裡想要分享一些從ZK-Rollup系統開發中獲得的經驗。我們將談論一些重要但很少被提及的話題，如ZK-Rollup系統的性能瓶頸在哪裡，經濟成本在哪裡等等。
目前，對區塊鏈技術的主要期望是進一步擴大使用規模，提高性能和降低成本。在這篇文章中，我們將深入研究ZK-Rollup，它是以太坊第二層的擴展解決方案之一。它巧妙地應用瞭零知識證明技術（被稱為ZK-SNARK），以減少鏈上成本，因此，能夠大大改善以太坊的TPS（約10倍-100倍）。ZK-Rollup被許多人認為是長期內最重要的以太坊第二層擴展解決方案，包括以太坊的創始人Vitalik。
總的來說，我自己的觀點是，在短期內，optimistic rollups可能在通用的EVM計算中勝出，而ZK-rollups可能在簡單的支付、交易和其他特定應用案例中勝出，但從中長期來看，隨著 ZK-rollups技術的改進， ZK-rollups將在所有案例中勝出。——V神
ZK-SNARK和ZK-Rollup概述
同樣，我們不會專註於ZK-SNARK證明的密碼學細節，因為如前所述，有足夠多的高質量資源來解釋它。在本章中，我們將簡要地回答以下問題。ZK-SNARK能做什麼？為什麼它能成為ZK-Rollup的核心，並與 “rollup ”一起幫助提升以太坊的性能？“rollup” 到底是什麼意思？
ZK-SNARK的特性
一般來說，在區塊鏈生態系統中，每個節點會對區塊中的每筆交易執行相同的計算，然後驗證他們的結果與其他節點的結果是否相同。換句話說，對於每筆交易的上鏈，它將被每個節點執行。這就是區塊鏈的性能相對較低的一個主要原因。
然而，“再次計算”是驗證交易的唯一方法嗎？換句話說：驗證的成本是否有必要和計算的成本一樣高？
答案是否定的。驗證的成本可能比計算的成本更低。讓我們以數獨為例。解決一個數獨問題的復雜性與驗證一個數獨解決方案的復雜性是完全不同的。”再次計算 “是效率最低的驗證方法。如果你碰巧有計算機科學背景，隻需考慮計算復雜性理論中的P與NP問題。
因此，在區塊鏈中，即使增加計算成本，也值得有一個可以降低驗證成本的技術方案。原因是，對於每筆交易，計算隻會發生一次，而驗證會在每個節點上發生。ZK-SNARK本質上就是這樣一種技術，可以大大降低驗證成本。一般來說，ZK-SNARK可以使驗證成本比計算成本低幾個數量級。準確地說，將驗證復雜性從線性降低到常數（或對數），這就是 “簡潔”，即 “SNARK “中的 “S”，所代表的含義。
讓我們看看ZK-SNARK是如何工作的。
對於一個特定的程序，它首先會被預處理。在一次性預處理之後，對於每個輸入，驗證者需要計算與輸入相對應的結果，以及生成一個成本相對較大的“證明”（通常以大整數的形式）。任何驗證者都可以使用這個 “證明 “和輸入來快速驗證結果的正確性，而無需實際運行程序。
用模擬代碼進行更詳細的描述：
Rollup系統的現實世界設計
在一個正常的Rollup系統中，我們將維護一個全局默克爾樹。Rollup系統中的所有狀態（包括賬戶中每個代幣的餘額，賬戶的隨機數等）將成為樹上的一個葉子節點。
ZK-SNARK將在數學上保證對默克爾樹的每一次更新都滿足一些 “預定的規則”。這些規則是由ZK-Rollup開發者的設置決定的。例如，對於ZK-Rollup轉賬系統，開發者可以要求：
轉賬金額小於發件人賬戶的餘額。
發送人賬戶的簽名是有效的，並且隨機數是正確的。
發送方賬戶中減少的金額等於接收方賬戶中增加的金額。
此外，默克爾樹根的哈希值將從新的葉子中計算出來。
為瞭保證最壞情況下的安全性（也就是說，即使Rollup系統的開發者跑瞭，用戶仍然可以完整地提取他們的資產），系統應該確保用戶能夠從頭開始重建樹（稱為 “數據可用性”），並且能夠通過默克爾樹證明做出類似“Alice實際上有3個ETH ”的斷言。為瞭實現這一點，系統應該將每筆交易的數據公開，並存儲在鏈上。
對於一批成百上千的交易，在我們按照特定的順序執行並更新默克爾樹後，我們將使用ZK-SNARK來證明結果的正確性（即默克爾樹的新根）。請註意，這裡的交易數量是由一個預定義的配置決定的，這個配置在運行時是固定的。這批交易將被一起證明和驗證，被稱為“L2塊”。
同樣，讓我們用模擬代碼來演示真實世界的ZK-Rollup系統中的數據流：
自己的專門業務模塊。例如，Fluidex有一個訂單匹配引擎，它從用戶的訂單中生成匹配的交易，然後將其發送到狀態管理器中。
ZK-Rollup的TPS限制
ZK-Rollup系統的TPS的主要制約因素是什麼？
證明的速度
證明是ZK-Rollup系統中最耗費資源的部分。那些剛接觸ZK-Rollup的人通常錯誤地認為證明速度是對TPS的主要限制。實際上，由於每個L2塊的證明可以完全並行完成，使用數百人規模的證明者集群是一種常見的做法。因此，盡管ZK-SNARK證明確實需要很長時間，但它主要會導致從L2撤回到L1的延遲更長，以及運營商的服務器成本更高，但不會對TPS造成限制。
鏈上存儲數據和ETH GAS的限制
這是對TPS的一個真正的限制。讓我們回顧一下ZK-Rollup的整體設計。為瞭確保安全/數據的可用性，每個交易都應該存儲在鏈上。這部分數據將作為CALLDATA存儲在ETH交易歷史中，平均成本為16gas/byte。對於一個正常的交易/匹配訂單，每筆交易估計為40字節。
讓我們嘗試通過GAS限制來估計TPS的限制。
每個ETH區塊的開采需要大約13s，最大GAS量為1250萬。假設一個ZK-SNARK驗證需要花費30-50萬GAS，那麼每個ETH區塊最多可以包含12,000,000 / (40*16) = 20,000個交易。所以這樣一來，ZK-Rollup的TPS上限將是1500-2000。這也是許多Rollup系統在白皮書中聲稱的性能上限值。
默克爾樹上的全局狀態更新
這是一個很少討論但很關鍵的觀點。一個現實世界的ZK-Rollup系統的TPS實際上更多的是受到這個模塊的限制，而不是上面討論的證明速度或GAS限制。
為瞭支持大量的用戶和資產，我們需要默克爾樹有一定的深度。假設我們使用的是二進制密集梅克爾樹，我們打算支持100萬用戶和1000種資產，那麼默克爾樹的深度就需要達到30。假設每個事務會引起5-10個葉子節點的更新，那麼總共會有大約200次哈希計算。
出於性能考慮，我們不會在ZK-Rollup的默克爾樹中使用像SHA3這樣的普通哈希值。相反，我們將使用與ZK-SNARK更兼容的，如poseidon或save。根據Fluidex的測試結果，每個poseidon的哈希值大約需要30us（每個測試的樹深度是20，因此，每個哈希值將是57ms / 100 / 20 = 30us）。因此，從默克爾樹的角度估計，ZK-Rollup系統的極限是1 / 0.00003 / 200 = 160 TPS。
因此，默克爾樹的並行更新對於突破100-300TPS的水平至關重要。與計算ZK-SNARK證明不同的是，ZK-SNARK證明可以完全並行化，而要並行化默克爾樹的更新則需要更多的斟酌，並且很難在其上應用分佈式計算。這也是一個技術挑戰。
上面計算的100-300TPS接近許多現實世界中ZK-Rollup系統的實際性能上限值。
雜項開發經驗
為什麼ZK-SNARK的邏輯描述被稱為 “電路”？
對於有軟件工程師經驗的人來說，在下面的代碼中，if-分支和else-分支中隻有一個會被執行，而不是兩個都執行，隻選擇一個。
這種 “隻有一個條件分支會被執行 “的概念對於軟件開發來說似乎很自然，但對於硬件芯片電路的設計來說卻不是這樣的。在硬件順序邏輯電路的開發中，所有 “分支”（如果仍然稱為 “分支”）的邏輯都將在序列被觸發時執行。開發者需要從不同的 “分支 “中選擇並保持正確的全局狀態。
ZK證明的代碼最終將被轉換為一些巨大的多項式（可能有數億項），這樣，程序的證明將被轉換為多項式的證明。然後，這些多項式將以門電路的形式被約束。這也是為什麼我們把ZK證明程序稱為電路的原因之一。因此，代碼具有與硬件電路相同的屬性：所有分支的代碼將被一起執行。這就是為什麼ZK證明代碼被稱為 “電路”。此外，與硬件電路類似，ZK證明電路中沒有遞歸和復雜的循環，循環的數量隻能是恒定的。
因此，在開發ZK證明電路時，開發者需要重新考慮他們軟件開發的習慣。例如，在優化軟件時，我們可以把重點放在最常執行的分支上。但是在ZK證明電路中，由於所有的分支都會被執行，所以不經常執行的分支也需要被考慮。
關於DSL的意見
ZK證明電路的開發有幾種選擇，比如低級計算庫，如ethsnarks / bellman，或者DSL，如ZoKrates / Circom / Zinc。
我們選擇瞭Circom，它提供瞭一個恰到好處的抽象水平。一方面，它提高瞭讀/寫代碼的效率，另一方面，它不會歪曲底層電路的細節。
相比之下，用ethsnarks和bellman開發的效率就比較低。另外，當代碼被審查時，不管是內部還是外部，太多的 “語法噪音 “使審查者不能專註於核心邏輯。此外，ZoKrates和Zinc過於抽象。例如，ZoKrates中python風格的控制流語法掩蓋瞭底層電路，不利於低級別的優化（如C/Rust的內聯匯編）。
打個比方，ethsnarks / bellman就像傳統開發中的匯編語言，而cirom就像C，而ZoKrates就像Python。然而，ZoKrates的工具鏈並不像Python解釋器那樣成熟。這就是為什麼我們寧願使用“C”（這裡是cirom）作為我們的開發語言，而不是同時維護“Python”（這裡是ZoKrates）代碼和 “CPython解釋器”（這裡是ZoKrates解釋器）代碼。
然而，Circom本質上仍然是一個R1CS DSL。Fluidex實際上使用PLONK證明系統。我們可能會在Circom上做重大改變，以更好地利用PLONK，包括支持自定義門、plookup、聚合與遞歸等。
來源：https://www.tuoluocaijing.cn/technology/detail-10051111.html