ZK/Optimistic 混合 Rollup 探討

2023-07-11 16:07:14

作者：kelvinfichter；編譯：MarsBit，MK

我最近深信，以太坊 Rollup 的未來實際上是兩種主要方法（ZK 和 Optimistic）的混合體。在這篇文章中，我會嘗試解釋我所想象的基本架構，並解釋為什么我認為這是最好的前進道路。

我不打算花太多時間討論 ZK 或 Optimistic Rollups 的本質。這篇文章假設你已經對這些東西的工作原理有了不錯的理解。你不需要是專家，但你至少應該知道它們是什么，以及它們在高層次上是如何工作的。如果我試圖向你解釋 Rollups，這篇文章將會非常、非常長。總之，請享受閱讀吧！

從 Optimistic Rollup 开始

混合 ZK/Optimistic Rollup 以 Optimistic Rollup 的形式开始，這種 Rollup 與 Optimism 的 Bedrock 架構非常相似。Bedrock 旨在與以太坊（“EVM Equivalent”）達到最大程度的兼容，並通過運行幾乎與普通以太坊客戶端相同的執行客戶端來實現這一目標。Bedrock 使用以太坊即將出現的共識/執行客戶端分離模型，顯著降低了對 EVM 的差異（總是需要進行一些改變，但我們可以管理這一點）。在我寫這篇文章時，Bedrock Geth 的差異是一個+388 -30的提交。

像任何優秀的 Rollup 一樣，Optimism 從以太坊獲取區塊/交易數據，在共識客戶端內以某種確定的方式對這些數據進行排序，然後將這些數據輸入到 L2 執行客戶端以供執行。這種架構解決了“理想 Rollup”謎題的前半部分，為我們提供了一個 EVM Equivalent 的 L2。

當然，我們現在也需要解決如何以可證明的方式告訴以太坊 Optimism 內部正在發生什么的問題。如果沒有這個特性，合約就無法根據 Optimism 的狀態做出決策。這將意味着，用戶可以存入 Optimism，但永遠無法取出他們的資產。雖然在某些情況下，單向 Rollup 可能實際上是有用的，但在一般情況下，雙向 Rollup 更有用。

我們可以通過給出對該狀態的承諾以及證明該承諾正確生成的證據，告訴以太坊任何 Rollup 的狀態。另一種說法是，我們正在證明“Rollup程序”被正確執行。ZK 和 Optimistic Rollups 之間的唯一真正的區別是這個證明的形式。在 ZK Rollup 中，你需要給出明確的 ZK 證明，證明程序被正確執行。在 Optimistic Rollup 中，你對承諾提出聲明，但沒有明確的證明。其他用戶可以挑战你的聲明，並迫使你進行一場反復的遊戲，最終你會弄清楚誰是正確的。

我不會過多地詳述 Optimistic Rollup 挑战遊戲的細節。值得注意的是，這個遊戲的最新技術是將你的程序（在 Optimism 的情況下是 Geth EVM +一些邊緣部分）編譯成一些簡單的機器架構，比如 MIPS。我們這樣做是因為我們需要在鏈上為我們的程序構建一個解釋器，構建 MIPS 解釋器比構建 EVM 解釋器要容易得多。EVM 也是一個不斷變化的目標（我們有定期的升級分叉），並且並未完全包含我們想要證明的程序（裏面也有一些非 EVM 的東西）。

一旦你為你的簡單機器架構構建了一個鏈上的解釋器，並且創建了一些鏈下的工具，你應該就擁有了一個功能完全的 Optimistic Rollup。

轉化為 ZK Rollup

總的來說，我認為至少在接下來的幾年裏，Optimistic Rollups 將佔據主導地位。有些人認為 ZK Rollups 最終會超越 Optimistic Rollups，但我認為這可能是錯誤的。我認為 Optimistic Rollups 今天的相對簡單性和靈活性意味着它們可以隨着時間的推移轉變為 ZK Rollups。如果我們能夠找出一個使之實現的模型，那么當你可以簡單地部署到現有的 Optimistic 系統並稱之為一天的工作時，真的沒有強烈的動力去部署一個不太靈活、更脆弱的 ZK 系統。

因此，我的目標是創建一個架構和遷移路徑，使現有的現代 Optimistic 系統（比如 Bedrock）可以無縫地轉變為 ZK 系統。以下是我認為這不僅可以實現，而且可以以一種超越當前 zkEVM 方法的方式實現的方法。

我們從我上面描述的 Bedrock 風格的架構开始。注意，我（簡單地）解釋了 Bedrock 如何有一個挑战遊戲，可以斷言 L2 程序（運行 EVM +一些額外東將其轉化為 ZK Rollup

總的來說，我認為在未來幾年內，Optimistic Rollup將會佔主導地位。有一種觀點認為ZK Rollup最終會超越Optimistic Rollup，但我認為這可能是錯誤的。我認為Optimistic Rollup的相對簡單性和靈活性意味着它們可以隨着時間的推移轉變為ZK Rollup。如果我們能找出一種讓這種轉變發生的模型，那么在你可以簡單地部署到現有的Optimistic系統並結束一天的工作時，就真的沒有強烈的動力去部署到一個較不靈活且更易出問題的ZK系統了。

因此，我的目標是創建一種架構和遷移路徑，允許現有的現代Optimistic系統（如Bedrock）無縫轉變為ZK系統。我相信，以下是一種不僅可以使這種轉變發生，而且可以以一種超越當今的zkEVM方法的方式進行轉變的方法。

我們從我之前描述的Bedrock風格的架構开始。注意，我（簡要地）解釋了Bedrock是如何擁有一個可以斷言L2程序（運行EVM+一些額外內容的MIPS程序）執行的有效性的挑战遊戲的。這種方法的主要缺點之一是，我們需要預留一段時間讓用戶能夠檢測到並成功挑战一個錯誤的程序結果提議。這使得資產提現過程增加了相當多的時間（當前Optimism主網上為7天）。

然而，我們的L2只是在一個簡單的機器（MIPS）上運行的一個程序。完全有可能為這種簡單的機器構建一個ZK電路。然後我們可以使用這個電路來明確地證明L2程序的正確執行。而無需對當前的Bedrock代碼庫做任何改動，你就可以开始為Optimism發布有效性證明。這真的就是這么簡單。

為什么這種方法如此好

快速說明：在本節中，我提到了"zkMIPS"，但實際上我是用它來代指任何通用的"簡單"zkVM。

zkMIPS比zkEVM更簡單

構建一個zkMIPS（或者zk[插入其他機器名]）而不是zkEVM的一個巨大的好處是，目標機器的架構是簡單且靜態的。EVM的變化頻繁。Gas價格會改變，操作碼會被調整，有些東西會被添加或刪除。而MIPS-V自1996年以來一直沒有改變。通過目標zkMIPS，你在一個固定的問題空間上工作。每次EVM更新，你不需要改變並可能重新審核你的電路。

zkMIPS比zkEVM更靈活

另一個關鍵的爭論點是，zkMIPS比zkEVM更靈活。使用zkMIPS，你有更多的靈活性來隨意修改客戶端代碼，以實現各種優化或用戶體驗改進。客戶端更新不再需要隨着電路更新而來。你還可以創建一個核心組件，可以用來將任何區塊鏈轉變為ZK Rollup，而不僅僅是以太坊。

你的問題轉變為證明時間

ZK證明時間沿着兩個軸進行擴展：約束數量和電路大小。通過關注像MIPS這樣的簡單機器的電路（而不是像EVM這樣的更復雜的機器），我們能夠顯著減少電路的大小和復雜性。然而，約束的數量取決於執行的機器指令的數量。每個EVM操作碼都被分解為多個MIPS操作碼，這意味着約束的數量顯著增加，總體的證明時間也顯著增加。

但減少證明時間是一個堅固地根植於Web2空間的問題。鑑於MIPS機器架構在不久的將來不會有任何改變，我們可以高度優化我們的電路和證明程序，而不必擔心EVM在後期的變化。我非常確信，能夠優化一個明確定義的程序的硬件工程師的招聘池至少是構建和審計一個不斷變化的zkEVM目標的招聘池的10倍（如果不是100倍）。像Netflix這樣的公司可能有很多硬件工程師在優化轉碼芯片上工作，他們很樂意接受一堆風險投資的錢，來應對一個有趣的ZK挑战。

這種電路的最初證明時間可能超過7天的Optimistic Rollup提款期。隨着時間的推移，這個證明時間只會減少。通過引入ASIC和FPGA，我們可以大大加快證明時間。有了一個靜態目標，我們可以構建更優化的證明器。

最終，這個電路的證明時間將低於當前的7天Optimistic Rollup提款期，我們可以开始考慮取消Optimistic的挑战過程。運行一個證明程序7天可能仍然過於昂貴，因此我們可能還想再等一段時間，但是這個觀點依然成立。你甚至可以同時運行兩個證明系統，這樣我們就可以立即开始使用ZK證明，並且如果出於某種原因證明程序失敗，我們可以回到Optimistic證明。當准備好的時候，很容易以對應用完全透明的方式轉向ZK證明。沒有其他的系統可以提供這種靈活性和平滑的遷移路徑。

你可以關注其他重要的問題

運行一個區塊鏈是一項困難的任務，它不僅涉及編寫大量的後端代碼。我們在Optimism所做的大部分工作都集中在通過有用的客戶端工具改善用戶和开發者體驗上。我們也花費了大量的時間和精力處理"軟"性方面的事情：與項目對話，理解痛點，設計激勵。你在鏈軟件上花費的時間越多，就越少時間去考慮這些其他的事情。你總是可以嘗試僱傭更多的人，但是組織並不是线性擴展的，每增加一個新的僱員都會增加內部通信的負擔。

由於ZK電路工作可以被添加到現有的運行鏈上，你可以並行地开展核心平臺和證明軟件的構建工作。而且，由於客戶端可以在不更改電路的情況下被修改，你就可以分離你的客戶端和證明團隊。採取這種方法的Optimistic Rollup可能會在實際的鏈上活動方面領先ZK競爭者很多年。

一些結論

完全坦率地說，我無法看到這種方法在假設zkMIPS證明者可以隨着時間大幅度優化的情況下有任何顯著的缺點。我認為對應用的唯一實際影響是，可能需要調整不同操作碼的氣體費用，以反映這些操作碼添加的證明時間。如果真的無法將這個證明者優化到一個合理的水平，那么我就承認失敗。如果實際上可能優化這個證明者，那么zkMIPS/zkVM的方法似乎比當前的zkEVM的方法要好得多，以至於可能完全使後者過時。這可能看起來像是一個激進的聲明，但是不久前，單步的Optimistic故障證明被多步證明完全取代。