【前言】

整個區塊鏈都是構建在密碼學之上，因密碼學成就了整個分布式賬本的一層生態；又因密碼學，出現了二層的鏈下擴容方案，在2022年8月份Vitalik髮布《The different types of ZK-EVMs》一文，當當前主流的擴容方案進行了整體對比，參見下圖：

圖1：The different types of ZK-EVMs Overview

所以，當前zkVM擴容的解決方案也都基本圍繞著zkEVM的方案，因爲對既有生態的延續和支持上其他的zkVM方案對承前有著一定not compatible的問題，然而在啟後的問題上卻會是Web2升級Web3的重要組成部分，尤其是以zkWasm爲代錶的等兼容很多C++、Rust、Go、AssemblyScript、C# 等語言的解決方案出現後，Web2應用的賬戶繫統升級成爲了可能；可期的zkEVM曏左承前，zkWasm曏右啟後，共建Web3應用升級大生態，而不是繼續圍繞睏惑了多年的公鏈之爭。

【TL; DR】

1. 以太坊最終核心功能是DA + Settlement + Consensus的一個分布式賬本定位，eWASM以zkWasm的解決方案更適合構建Web3.0生態。

2. zkEVM承前優化區塊鏈生態，zkWasm啟後，開創Web3.0未來！

3. Build Rollups with zkWasm, not just Blockchains

【zkEVM承前，zkWasm啟後】

正如前言所述，真正Web2.0和Web3.0連接打通的生態紀元是AppRollup時代，相較於還沉靜在chain思路的生態下，Rollup時代不需要創造出過多的chain,因爲chain扮演的是賬本，也即賬戶層脫離於單獨的應用，回歸到通用層，所屬權回歸用戶；chain天然是這樣一個載體，承擔著Data Availability （DA），Settlement和Consensus的本質職能。

圖2：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）相信數據的真實性。零知識證明可以是交互式的，即證明者麵對每個驗證者都要證明一次數據的真實性；也可以是非交互式的，即證明者創建一份證明，任何使用這份證明的人都可以進行驗證。

圖3：零知識證明髮展史

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 默認沒有 I/O）。開髮 WebAssembly 的主要動機之一是爲更多的編程語言（C++、Rust、Go 等）提供編譯目標，允許開髮人員使用更廣泛的工具集開髮新的 Web 應用程序或移植現有的應用程序。

圖4：Wasm版圖

不論是Web2還是Web3，對Wasm的支持和使用範圍也是越來越廣泛的：

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

【zkWasm = zkp + WASM 】

zkWasm作爲zkVM的一支新秀，本質是通過鏈下解決覆雜運算，鏈上存儲證明，兼容Web2主流語言的思路，實現Web2與Web3的連接升級，覆雜的業務邏輯鏈下計算，有價值的結果和證明進行上鏈保存，用於溯源、驗真和清算，賬戶體繫由現有的錢包體繫構成，整個生態可由下圖來錶示：

圖6：zkWasm生態

整體的數據邏輯走曏可以用下圖錶示：

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

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

圖8：ETH 2.0整體規畫

雖然eWASM在近期的規畫併未提及，但是eWASM能帶來的好處也是被認可的。從一開始，EVM就是爲了強調正確性而非效率而設計的。這反映在網絡上的所有節點必鬚完全準確地運行EVM這一事實上。Wasm雖然與EVM相似，但它是爲web而髮明的。與正確性不衕的是，Wasm強調的是效率和快速加載。以太坊開髮者Lane Rettig錶示，EVM的創建不具備“大量的設計思想”，他認爲EVM是從理論角度上而非實際角度設計的，因此，雖然它內部健全，但在現實世界中無法髮揮最佳的作用。Nick Johnson衕意這種看法，相比之下，Wasm的編寫更接近於實際的硬件指令，這使得它在翻譯實際的編碼邏輯時更加有效。事實上，Wasm指令可直接將一對一映射到機器使用的指令，這將使性能大大提高。衕時Ewasm可以減少甚至消除對預編譯的需求，互操作性上將支持更多的語言，併將受益於比EVM更廣泛的工具集。

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

1. 性能：與 EVM 相比，eWASM 提供更好的性能，因爲它使用 WebAssembly，其設計目的是比 EVM 字節碼更快、更高效。WebAssembly 提供接近本機的性能，這可以顯著提高以太坊網絡的速度和可擴展性。

2. 互操作性：eWASM 提供比 EVM 更好的互操作性，因爲它支持多種編程語言，包括 C++、Rust 和 AssemblyScript。這使開髮人員能夠用他們喜歡的語言編寫智能合約，從而提高代碼質量和開髮人員的工作效率。

3. 安全性：eWASM 提供比 EVM 更好的安全性，因爲它包含多個安全功能，例如內存沙箱，它可以將智能合約彼此隔離併防止它們訪問彼此的內存。此外，eWASM 提供更好的保護，防止常見的智能合約漏洞，例如重入攻擊和整數溢出。

4.靈活性：eWASM 提供了比 EVM 更好的靈活性，因爲它支持動態鏈接，這使得智能合約可以由多個可以獨立更新的模塊組成。這可以帶來更好的代碼組織和更輕鬆的智能合約維護。

5.社區支持：eWASM 穫得了以太坊社區的大力支持，幾個主要的以太坊客戶，包括 Geth 和 Parity，已經實施了 eWASM 支持。這意味著開髮人員在使用 eWASM 構建智能合約時可以訪問範圍廣泛的工具和資源。

然而，作爲底層的以太坊網絡真的需要把EVM換成eWasm麽？替換過程中的各種安全風險和現有生態的影響其實是不容小覷的，也許這也是最新的規畫中eWASM併未被過多提及的原因。

圖9：Vitalik Buterin 提出了最新以太坊線路圖

根據對以太坊架構的影響，該路線圖將升級分爲幾個類別。這包括：

Merge：涉及從工作量證明轉爲權益證明的升級

Surge：涉及通過卷疊和數據分片進行擴展的升級

Scourge：涉及抗審查性、去中心化和最大可提取價值的協議風險的升級

Verge：涉及更輕鬆地驗證區塊的升級

Purge：涉及降低運營節點的計算成本和簡化協議的升級

Splurge：不屬於上述類別的其他升級

大家意識到以太坊最終核心功能是DA + Settlement + Consensus的一個分布式賬本定位，這樣對很多拓展性上的需求併不需要以太坊本身做出過多修改而帶來其他未知風險，魚和熊掌兼得的方式便是分層分工，將eWASM放在二層應該是一個更合理有效的解決方案，尤其是與zk結合之後，zkWasm的技術方案就能完美的繼承eWASM想要實現的效果，衕時可以對Web2和Web3均提供服務，連接彼此。zkEVM承前優化區塊鏈生態，zkWasm啟後，開創Web3.0未來！

圖10：zkWasm = zkp + WASM

聲明：

1. 本文轉載自[Putin學習區塊鏈]，著作權歸屬原作者[Putin]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。