探索以太坊擴容的未來,zkEVM與zkWasm開啟承前啟後之勢

23-11-14 14:15
閱讀本文需 18 分鐘
总结 AI 總結
看總結 收起
原文標題:《zkEVM + zkWasm:承前啟後之勢》
原文作者:putin 學習區塊鏈、0xTodd


以太坊最終核心功能可能是DA + Settlement + Consensus 的一個分散式帳本定位,eWASM 以zkWasm 的解決方案更適合建構應用。 zkEVM 承前優化區塊鏈生態,zkWasm 啟後接受更多的開發可能。 Build Rollups with zkWasm, not just Blockchains。


前言


去年8 月份Vitalik 發布《The different types of ZK-EVMs一文,對當前主流的擴容方案從兼容性和性能兩個角度進行了整體對比(參見下圖),引發整個社區誕生了許多討論和思考直到今天。


The different types of ZK-EVMs Overview


目前zkVM 擴容的解決方案也都基本上圍繞著zkEVM 的方案,因為對既有生態的延續和支持上其他的zkVM 方案對承前有著一定not compatible 的問題,然而在啟後的問題上卻會是Web2 升級Web3 的重要組成部分。


尤其是以zkWasm 為代表的等兼容很多C++、Rust、Go、AssemblyScript、C# 等語言的解決方案出現後,Web2 應用的帳戶系統升級成為了可能;可期的zkEVM 向左承前,zkWasm 向右啟動後。


zkEVM 承前,zkWasm 啟動後


Rollup 時代不需要創造出過多的chain , 因為chain 扮演的是帳本,也即帳戶層脫離於單獨的應用,回歸到通用層,所屬權回歸用戶;chain 天然是這樣一個載體,承擔著Data Availability(DA),Settlement 和Consensus 的本質職能。


AppRollup is much more flexible than Appchain


ZKP,Zero-Knowledge Proof


密碼學中,零知識證明(英語:zero-knowledge proof)或零知識協議(zero-knowledge protocol)是一方(證明者)向另一方(檢驗者)證明某命題的方法,特徵是過程中除「該命題為真」之事外,不洩漏任何資訊。因此,可理解成「零洩密證明」。


最早由MIT 的Shafi Goldwasser、Silvio Micali 和Charles Rackoff 在1985 年一篇名為《互動式證明系統的知識複雜性([ GMR85])的論文中提出。作者在論文中提到,證明者(prover)有可能在不透露具體數據的情況下讓驗證者(verifier)相信數據的真實性。零知識證明可以是互動的,即證明者面對每個驗證者都要證明一次資料的真實性;也可以是非互動式的,即證明者創建一份證明,任何使用這份證明的人都可以進行驗證。


零知識證明發展史


zk-SNARK (Succinct Non-Interactive Arguments of Knowledge)可能是最受歡迎的零知識證明形式,最早出現在2011 年的Bit+11 論文中。到 2013 年,多虧了 Pinocchio PHGR13 論文,零知識證明可以在現實應用中使用,該論文使 zk-SNARKS 適用於一般計算,儘管速度較慢。 2016 年提出的 Groth16 演算法大大降低了計算複雜性,使 zk-SNARKS 非常高效,至今仍然是標準。


然而,「可信任設定」對於這些零知識協定的安全性至關重要。必須使用初始過程產生加密參數,以便能夠運行零知識協定。由第三方執行此操作,以確保加密參數是隨機、不可預測且安全的。


隨後在 2017 年引入了 Bulletproofs(BBBPWM17),在 2018 年引入了 zk-STARKs(BBHR18)。與前任不同,它們是不需要初始可信任設定的範圍證明類型。 2019 年的 PlonK 論文實現了通用零知識證明演算法,這意味著只需要啟動一次可信任設置,而與之相比,Groth16 需要每個電路都有單獨的可信設置。


由於領域的發展,零知識證明已經從純理論過渡到在區塊鏈、安全通訊、電子投票、存取控制和遊戲中具有有用的實際應用。隨著它們繼續投入商業應用,將會有更多令人興奮的發展來推進技術。


所以,zk-SNARKS、zk-STARKS、PLONK 以及Bulletproofs 構成了當前零知識證明主要實現方式,每種方式在證明大小、證明者時間以及驗證時間上都有自己的優缺點。在區塊鏈的擴容解決方案裡,基本上也是圍繞著 ZK-SNARK-friendly 為主的實現方式。


WASM, WebAssembly


WebAssembly(簡寫WASM)是Web 技術家族(JavaScript、HTML 、CSS)中相對較新的成員,於2019 年12 月成為W3C 官方認可的標準。 WebAssembly 在瀏覽器中引入了一個新的運行時,該運行時與 JavaScript 運行時協同工作。相比之下,它更輕量,擁有少量的指令集以及嚴格的隔離模型。


開發WebAssembly 的主要動機之一是為更多的程式語言(C++、Rust、Go 等)提供編譯目標,讓開發人員使用更廣泛的工具集開發新的Web 應用程式或移植現有的應用程式。


Wasm 版圖


不論是Web2 還是Web3,對Wasm 的支援和使用範圍也越來越廣泛。


WebAssembly 生態中主要的公司和組織


zkWasm = zkp + WASM


zkWasm 作為zkVM 的新秀,本質是透過鏈下解決複雜運算,鏈上儲存證明,相容於Web2 主流語言的思路,實現Web2 與Web3 的連接升級,複雜的業務邏輯鏈下計算,有價值的結果和證明進行上鍊保存,用於溯源、驗真和清算,帳戶體係由現有的錢包體系構成,整個生態可由下圖來表示:


zkWasm 生態


整體的資料邏輯走向可以用下圖表示:


On-Chain Contracts + Off-Chain Virtual Machine (VM) + WASM Composability


在最初以太坊2.0 更新的一個重要核心,也包括從EVM 過渡到eWASM;但是實際2.0 的進展並不如預期,所以在最新的規劃計劃裡,eWASM 並未有過多的提及。


ETH 2.0 整體規劃


雖然eWASM 在近期的規劃並未提及,但是eWASM 能帶來的好處也是被認可的。從一開始,EVM 就是為了強調正確性而非效率而設計的。這反映在網路上的所有節點必須完全準確地運行 EVM 這一事實上。


Wasm 雖然與 EVM 相似,但它是為 web 而發明的。與正確性不同的是,Wasm 強調的是效率和快速加載。以太坊開發者Lane Rettig 表示,EVM 的創建不具備「大量的設計思想」,他認為EVM 是從理論角度而非實際角度設計的,因此,雖然它內部健全,但在現實世界中無法發揮最佳的作用。


Nick Johnson 同意這種看法,相較之下,Wasm 的編寫更接近實際的硬體指令,這使得它在翻譯實際的編碼邏輯時更加有效。事實上,Wasm 指令可直接將一對一對應到機器使用的指令,這將使效能大大提高。同時 Ewasm 可以減少甚至消除對預編譯的需求,互通性上將支援更多的語言,並將受益於比 EVM 更廣泛的工具集。


主流認可使用eWASM 優於EVM 的優勢主要有以下幾點:


效能:與EVM 相比,eWASM 提供更好的效能,因為它使用WebAssembly,其設計目的是比EVM 字節碼更快、更有效率。 WebAssembly 提供接近本機的效能,可顯著提高以太坊網路的速度和可擴充性。


互通性:eWASM 提供比 EVM 更好的互通性,因為它支援多種程式語言,包括 C++、Rust 和 AssemblyScript。這使開發人員能夠用他們喜歡的語言編寫智慧合約,從而提高程式碼品質和開發人員的工作效率。


安全性:eWASM 提供比EVM 更好的安全性,因為它包含多個安全功能,例如記憶體沙箱,它可以將智慧合約彼此隔離並防止它們存取彼此的記憶體。此外,eWASM 提供更好的保護,防止常見的智慧合約漏洞,例如重入攻擊和整數溢位。


靈活性:eWASM 提供了比EVM 更好的靈活性,因為它支援動態鏈接,這使得智能合約可以由多個可以獨立更新的模組組成。這可以帶來更好的程式碼組織和更輕鬆的智慧合約維護。


然而,對於以太坊來說,這可能是個超長遠期的規劃,而且替換過程中的各種安全風險和現有生態的影響也不容小覷。也許這也是最新的規劃中 eWASM 並未被過多提及的原因。


許多社群成員意識到以太坊最終核心功能是DA + Settlement + Consensus 的一個分散式帳本定位,這樣對許多拓展性上的需求並不需要以太坊本身做出過多修改而帶來其他未知風險。魚和熊掌兼得的方式便是分層分工,將 eWASM 放在二層應該是一個更合理有效的解決方案。


尤其是與zk 結合之後,zkWasm 的技術方案就能很好繼承eWASM 想要實現的效果,這樣,透過zkEVM+zkWasm 兩套方案左右配合,向前可以繼承傳統的EVM Dapp,向後可以拓展用更多語言編寫的應用,進而實現真正的「承前啟後」。


zkWasm = zkp + WASM


【參考文獻】
https://jhc.sjtu.edu.cn/~hongfeifu/manuscriptb.pdf
https://delphinuslab.com/wp-content/uploads/2023/04/zksummit-presentation-zkwasm- game-1.pdf
https://vitalik.ca/general/2021/01/05/rollup.html
https://vitalik.ca/general/2021/01/26/snarks.html
https://vitalik.ca/general/2022/08 /04/zkevm.html
https: //twitter.com/VitalikButerin/status/1588669782471368704
https://github.com/DelphinusLab/zkWasm
https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/
https://almanac.httparchive.org/en/2022 /webassembly
https://www.circularise.com/blogs/zero-knowledge-proofs-explained-in-3-examples
https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Put-WebAssembly-on-the-front-end-and-back-end -in-2023
https://github.com/privacy-scaling-explorations/zkevm-specs/blob/master/specs/introduction.md
https://academy .moralis.io/blog/breaking-down-eth-2-0-ewasm-and-evm-explained


本文來自投稿,不代表BlockBeats的觀點



欢迎加入律动 BlockBeats 官方社群:

Telegram 订阅群:https://t.me/theblockbeats

Telegram 交流群:https://t.me/BlockBeats_App

Twitter 官方账号:https://twitter.com/BlockBeatsAsia

举报 糾錯/舉報
本平台現已全面集成Farcaster協議, 如果您已有Farcaster帳戶, 可以登錄 後發表評論
選擇文庫
新增文庫
取消
完成
新增文庫
僅自己可見
公開
保存
糾錯/舉報
提交