Vitalik新文:未來的「ZK-EVM」會是什麼樣子?
BlockBeats 律動財經 2023-12-14 12:00
以太坊上的 Layer-2 EVM 協議,包括 op rollup 和 ZK rollup,依賴於 EVM 驗證。然而,這要求它們信任一個龐大的代碼庫,如果該代碼庫存在漏洞,這些虛擬機面臨被駭客攻擊的風險。此外,即使是希望與 L1 EVM 完全等同的 ZK-EVM,也需要一定形式的治理,以將 L1 EVM 的更改複製到它們自己的 EVM 實現中。
這種情況並不理想,因為這些項目正在複製以太坊協議中已經存在的功能,而以太坊治理已經負責升級和修復錯誤:ZK-EVM 基本上執行與驗證 L1 以太坊區塊相同的工作!此外,未來幾年內,我們預計輕客戶端將變得越來越強大,很快就會使用 ZK-SNARKs 完全驗證 L1 以太坊執行。此時,以太坊網路將有效地擁有一個內置的 ZK-EVM。因此,問題出現了:為什麼不將該 ZK-EVM 本地化提供給 rollup 項目呢?
本文將描述幾個可能實現的「被奉為圭臬的 ZK-EVM」版本,並探討權衡和設計挑戰,以及不選擇特定方向的原因。這些實現協議特性的優勢應該與留給生態系統的好處和保持基礎協議簡單的利益相權衡。
我們對被奉為圭臬的 ZK-EVM 有哪些關鍵屬性的期望?
基本功能:驗證以太坊區塊。該協議特性(目前仍未確定是操作碼、預編譯還是其他機制)應至少接受預狀態根、區塊和後狀態根作為輸入,並驗證後狀態根是否確實是在預狀態根的基礎上執行區塊的結果。
與以太坊多客戶端理念的兼容性。這意味著我們希望避免奉行單一的證明系統,而是允許不同的客戶端使用不同的證明系統。這反過來又意味著一些要點:
· 數據可用性要求:對於使用被奉為圭臬的 ZK-EVM 證明的任何 EVM 執行,我們希望能夠保證底層數據是可用的,以便使用不同證明系統的證明者可以重新證明執行,依賴該證明系統的客戶端可以驗證這些新生成的證明。
· 證明存在於 EVM 和區塊數據結構之外:ZK-EVM 特性不會直接將 SNARK 作為 EVM 內輸入,因為不同的客戶端期望不同類型的 SNARK。相反,它可能類似於 blob 驗證:交易可以包含需要證明的(預狀態、區塊主體、後狀態)語句,操作碼或預編譯可以訪問這些語句的內容,客戶端共識規則將分別檢查每個在區塊中提出的聲明的數據可用性和證明的存在。
可審計性。如果任何執行都得到證明,我們希望底層數據是可用的,以便在發生任何問題時,用戶和開發者可以檢查。在實踐中,這增加了數據可用性要求重要性的另一個原因。
可升級性。如果發現特定的 ZK-EVM 方案存在漏洞,我們希望能夠快速修復。這意味著不需要硬分叉來進行修復。這增加了證明存在於 EVM 和區塊數據結構之外的重要性的另一個原因。
支持 almost-EVM 的網路。L2 的吸引力之一在於創新執行層的能力,並對 EVM 進行擴展。如果某個給定的 L2 的虛擬機(VM)與 EVM 僅有細微差異,那麼如果 L2 仍然可以使用與 EVM 相同的原生協議內 ZK-EVM,僅對與 EVM 相同的部分依賴其自身代碼,對於不同的部分則依賴於他們自己的代碼,那將是很好的。這可以通過設計 ZK-EVM 特性的方式來實現,該特性允許調用者指定由外部提供的表處理的一些操作碼、地址或位域,而不是由 EVM 本身處理。我們還可以在有限的範圍內使燃氣成本開放定製。
「開放」與「封閉」的多客戶端系統
「多客戶端理念」可能是這個列表中最有主張的要求。有放棄這一理念的選擇,集中精力研究一個 ZK-SNARK 方案,這將簡化設計,但代價是對以太坊的一個更大的「哲學轉變」(因為實際上這將是對以太坊長期多客戶端理念的放棄)和引入更大的風險。在長期未來,例如形式化驗證技術變得更好的情況下,可能更好地選擇這條道路,但目前來看,風險似乎太大。
另一種選擇是封閉的多客戶端系統,在協議內已知一組固定的證明系統。例如,我們可能決定使用三個 ZK-EVMs:PSE ZK-EVM、Polygon ZK-EVM 和 Kakarot。一個區塊需要攜帶這三個中的兩個的證明才能被視為有效。這比單一的證明系統要好,但它使系統變得不太適應性,因為用戶必須為每個已知的證明系統維護驗證器,必然會存在政治性的治理過程來納入新的證明系統等等。
這促使我更傾向於採用開放的多客戶端系統,其中證明被放置在「區塊之外」,並由客戶端分別驗證。個別用戶可以使用他們想要的客戶端來驗證區塊,只要至少有一個生成該證明系統證明的證明者。證明系統將通過說服用戶運行它們而獲得影響力,而不是通過說服協議治理過程。然而,這種方法確實具有更多的複雜性成本,我們將會看到。
我們希望 ZK-EVM 實現具備哪些關鍵特性?
除了基本的正確功能和安全性保證之外,最重要的特性是速度。雖然可以設計一個協議內的 ZK-EVM 特性,其是異步的,僅在經過 N 個時隙的延遲後為每個聲明返回一個答案,但如果我們可以可靠地保證在幾秒內生成證明,那麼每個區塊中發生的一切都是自包含的問題將變得更容易。
儘管今天生成以太坊區塊的證明需要很多分鐘或小時,但我們知道沒有理論上的阻止大規模並行化的原因:我們總是可以組合足夠多的 GPU,分別證明區塊執行的不同部分,然後使用遞歸 SNARKs 將這些證明組合在一起。此外,通過 FPGAs 和 ASICs 的硬體加速可能有助於進一步優化證明。然而,實際達到這一點是一個重要的工程挑戰,不應該被低估。
協議內的 ZK-EVM 特性可能具體是什麼樣子?
類似於 EIP-4844 Blob 交易,我們引入了一種包含 ZK-EVM 聲明的新交易類型:
與 EIP-4844 類似,在內存池中傳遞的對象將是交易的修改版本:
後者可以轉換為前者,但反之則不行。我們還擴展了區塊邊車對象(在 EIP-4844 中引入)以包含在區塊中所做聲明的證明列表。
請注意,在實際操作中,我們可能會希望將邊車分成兩個獨立的邊車,一個用於 blob,一個用於證明,並為每種證明類型設置一個單獨的子網(還有一個額外的子網用於 blob)。
在共識層上,我們添加了一個驗證規則,即僅當客戶端看到了區塊中每個聲明的有效證明後,該區塊才會被接受。證明必須是 ZK-SNARK 證明聲明,即 transaction_and_witness_blobs 的串聯是(Block,Witness)對的序列化,執行塊在 pre_state_root 上使用 Witness (i) 是有效的,並且 (ii) 輸出正確的 post_state_root。潛在地,客戶端可以選擇等待多種證明類型的 M-of-N。
在這裡有一個哲學性的註記,即區塊執行本身可以被視為僅是需要與 ZKEVMClaimTransaction 對象中提供的(σpre,σpost,Proof)三元組之一一起檢查的。因此,用戶的 ZK-EVM 實現可以替換其執行客戶端;執行客戶端仍將被(i)證明者和區塊構建者使用,以及(ii)關心索引和儲存數據供本地使用的節點使用。
驗證和重新證明
假設有兩個以太坊客戶端,其中一個使用 PSE ZK-EVM,另一個使用 Polygon ZK-EVM。假設到達這一點時,兩個實現都已發展到可以在 5 秒內證明以太坊塊執行的程度,並且對於每個證明系統,存在足夠多獨立的志願者運行硬體以生成證明。
不幸的是,由於個別證明系統未被正式確立,它們無法在協議中獲得激勵;然而,我們預計運行證明節點的成本將較低,相比於研究和開發的成本,因此我們可以簡單地通過通用機構為公共物品資助來資助證明節點。
假設有人發布了一個 ZKEvmClaimNetworkTransaction,除非他們只發布了 PSE ZK-EVM 版本的證明。Polygon ZK-EVM 的證明節點看到這一情況,計算並重新發布該對象,附帶 Polygon ZK-EVM 的證明。
這將最早的誠實節點接受區塊和最晚的誠實節點接受相同區塊之間的總最大延遲從δ增加到 2δ+Tprove(在這裡假設 Tprove
暢行幣圈交易全攻略,專家駐群實戰交流
▌立即加入鉅亨買幣實戰交流 LINE 社群(點此入群)
不管是新手發問,還是老手交流,只要你想參與虛擬貨幣現貨交易、合約跟單、合約網格、量化交易、理財產品的投資,都歡迎入群討論學習!
- 從零開始學合約系列講座熱烈報名中
- 掌握全球財經資訊點我下載APP
文章標籤
上一篇
下一篇