ZK/Optimistic 混合Rollup 探討

作者: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故障證明被多步證明完全取代。

Total
0
Shares
Related Posts