作者：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
