一切以技術特性為主要賣點的產品都是半成品。
關於EVM和ZK EVM的炒作、爭論已經延續一段時間，尤其是在Vitalik對ZK EVM的類型做出劃分之後，關於字節碼、虛擬機、兼容性等等拗口概念的科普文章層出不窮，但是這些詞彙究竟何意，ZK EVM的普及又會把公鍊格局導向何方等問題並未得到清晰闡釋。
ZK賽道也正式火熱起來，如果說之前的ZK-Rollup將其限制在L2局部領域，那麼此刻已經隱約有成為整個區塊鍊網絡通用技術的趨勢，R3PO認為ZK EVM某種程度上會終結多鏈並存格局。
在這一替代的歷史進程中，必然會爆發出更多的新項目，R3PO致力於發掘潛藏價值，我們將從“意會”式理解EVM入手，探索出公鏈的未來走向。
圖片說明：不同操作系統間傳遞文件的解決辦法圖源：R3PO
試想如下場景：
Alice想將一份運行在Windows上的Word文檔傳遞給Bob，但是Bob只有一台可以使用Pages的Mac，所以Bob無法打開文檔，請問應該如何解決這個問題？如不考慮Bob安裝Mac版本的Word和拷貝文章內文字，還剩下以下四種方式：
1.Alice將文章上傳至雲端，比如Google Docs中，Bob可以在支持跨平台的瀏覽器上打開並編輯文檔；
2.Alice將Word.exe和文檔一併交給對方，Bob可以使用Crossover或者虛擬機（VM）來模擬Windows環境，從而可以在Mac上運行.exe應用並打開文檔；
Crossover只可以單獨支持Word.exe運行，而對其他.exe應用無能為力；
虛擬機（VM）會在Mac內安裝一個Windows子系統，在Windows子系統內可運行任意.exe應用；
3.Alice將文檔變為Java可以理解的文件格式並交給對方，Bob可以在Mac上安裝Java環境從而打開文檔；
4.Alice將文檔變為二進製文件並傳給對方，Bob可憑藉最為底層的兼容性打開文檔。
如果可以理解上述過程，那麼試做如下概念替換：
Windows和macOS等操作系統–> Ethereum和Cosmos等公鏈；
.exe和.dmg等應用格式–> 不同公鏈的Dapp；
Word文檔–> 鏈上資產；
Crossover –> 跨鏈橋；
虛擬機（VM）–> 較低兼容性的EVM，比如Polygon Hermez便是一種ZK VM，對照EVM實現功能，需要手動迭代保持同步更新；
JVM –> EVM，語言級等效的兼容性，比如計劃中的Scroll，其實現的ZK EVM跟EVM完全等效，可以理解為EVM加入ZK特性版；
二進制兼容–> 這就是EVM或者以太坊本體；
整個VM和EVM的特性如上所述，其運作模式和跨操作系統傳遞文件的流程基本類似。在R3PO看來，最大的趨勢是ZK EVM不僅會替代現有的EVM兼容方案，並且會最終導致以太坊成為唯一的應用層通信協議，而其他公鏈都會成為特定領域的特定用途鏈，類似Linux活躍在服務器領域，而Windows活躍在普通用戶之間。
至於得出這樣論斷的原因，我們會在下文詳述。
欲知人者，必先自知：生態的本質是開發者和用戶方的雙向奔赴
EVM促進了以太坊在公鏈競爭中的勝利，這種勝利並非出於以太坊的“計算能力優越性”，而主要是出於兼容性，因為EOS等老一代以太坊殺手，Solona等上一代以太坊殺手，以及Aptos等新一代以太坊殺手都標榜過自身TPS的超高速度。
但是以太坊仍舊屹立不倒，以個位數的TPS保持TVL、Dapp數量的絕對領先優勢，這種優勢可以歸納為生態群聚效應，但是為何在其他公鏈紛紛兼容EVM，以及大力建設跨鏈橋之後，差距並未縮小，反而在熊市有進一步擴大的跡象呢？
R3PO認為，可以從一個較為確定的起點出發去得出問題的解。
這個起點是開發者的體驗，目前的Web 3仍處於極早期階段，可以類比為2000年前的互聯網，仍舊是極客和早期嚐鮮者的領域，即使有代幣機制，大多數用戶仍沉澱在CEX、TradiFi機構構建的CeDeFi之內，真正的鏈上用戶少的可憐，以太坊的活躍地址不過40萬，但TVL卻高達320億美元，市值達2000億美元。
在用戶數量和資金沉澱量的巨大反差背景下，爭奪開發者力量成為維持生態的最主要途徑，其中邏輯在於誰能堅持到真正億級消費者應用的面世，哪條公鏈就能真正成為下一代互聯網的基礎設施，一如萬維網和網景瀏覽器往事。
而以太坊給予開發者的開發體驗是最為完整的。
某種意義上，這也是對Java語言成功的一種效仿，在Java之前，C/C++語言最大的問題是需要程序員去考慮軟件和硬件的適配問題，比如32位的數值類型無法直接遷移至16位的機器運行。
圖片說明：JVM架構圖源：維基百科
而Java在語言易用性做出改進之外，最大的改進之處就在於JVM的設計，一言以蔽之，其特性就在於“硬件軟化”，通過語言調度實現對不同硬件的相同適配，只要在EVM實現一次，便可在任意設備運行，真正實現跨平台開發，而無需額外考慮硬件問題。
借助JVM，Java成為世界上最主流的開發語言之一，也許並不專精某領域，但是任何領域都可適用，這就是兼容性的本質。
EVM及以太坊開發生態也是如此，開發者只需要面向EVM開發一次，便可持續跟隨以太坊生態而不斷進步，而無需考慮公鏈升級的兼容性、硬件的差異性等情況。
圖片說明：EVM架構圖源：ethereum.org
Solidity並不完美，EVM也不是沒有問題，但是最好的兼容性足以保證開發者的忠誠度，而隨著越來越多的公鏈兼容EVM，這種兼容性變獲得了被動收益，鏈間遷移工作量足夠小，其他公鏈只是以太坊Dapp的本土化版本，最終有利於以太坊生態的獨大。
圖片說明：EVM的工作示意圖源：R3PO
並且語言級的兼容性也有助於確保EVM的效率和安全。
上圖中的虛擬機（VM）是指不同操作系統間的運作模式，比如Parallels Desktop，可以保證在Mac上運行Windows子系統，但是需要先從原始系統內分配特定的軟硬件資源建立子系統，然後在子系統中安裝Windows應用，隨後該應用才能運行，但是受限於分配資源的局限性，其運行效率和原生應用無法相提並論。
而EVM類似JVM，是從Solidity語言級去進行兼容性操作，開發者利用Infura提供的API和主網交互，利用Truffle進行智能合約開發，測試和部署等等，開發套件一應俱全，完成對EVM的適配後Dapp便可在任意兼容EVM的公鏈上運行。
不僅對於開發者，EVM級別的兼容開發保證帶給任意用戶的體驗也是完全一致的，為以太坊生態保存了最起碼的種子用戶群體，僅憑開發者和少量用戶便維持了以太坊生態對其他公鏈的領先優勢。
EVM參考的是JVM，不需要考慮過多硬件和編碼問題，只需要面向應用真正需要的功能去開發，一次適配，多端通用。
生態的含義就是開發+應用+用戶，EVM在生態建設上起到了飛輪的初始化作用。
欲論人者，必先自論：兼容EVM不會促進競爭者的勝出
EVM促進了以太坊的成功，但為什麼兼容EVM的其他公鏈，吸血以太坊生態的“吸血鬼計劃”無法奏效呢？
兼容者們的邏輯：
對開發者：兼容EVM以降低以太坊開發者遷移成本，並提供更高的TPS等公鏈新特性；
對用戶：提供一定程度的代幣刺激，以鼓勵用戶遷移；
完成對以太坊的取代。
兼容者們的邏輯漏洞：
對開發者：兼容EVM終究不是原生EVM，存在隱形的遷移成本；
對用戶：以太坊的安全性是除比特幣網絡外最高的，這種安全不是打金、搶空投等短時誘惑可比的；
結果：以太坊仍舊佔據最主流位置。
實際上，其他公鏈陷入了兩難境地，兼容EVM有成為以太坊事實上的側鏈的危險，但是不兼容有成為孤島的後果，所有人都渴望流量的前提下，就成為不得已而為之的無奈之舉。
圖片說明：EVM兼容方案一覽圖源：R3PO
在此時，主要還是其他公鏈在主動出擊，而以太坊在埋頭改進自己的舊疴，比如PoW轉PoS、L2道路選擇、賬戶抽象的實現、DankSharding等，在兼容路徑上，主要有實現EVM、借助應用實現鏈間兼容和EVM兼容鏈三種。
公鏈實現EVM兼容，以BNB Chain等為代表。
BNB Chain或者OKX Chain等交易所公鏈，憑藉交易所的用戶基數，以及對項目的運營能力，其鏈上TVL和生態也不容小覷，以BNB Chain為例，據DeFi Llama數據，其上運行492種協議，TVL達60億美元，按照規模和體量而言，是僅次於以太坊的第二大公鏈。
其最主要運作模式“模仿”以太坊，比如其上的最大DEX Pancakeswap最早便是Uniswap的分叉版本，同一種Dapp可以無縫在兩條公鏈上切換，背後便是EVM兼容帶來的巨大優勢，項目方只需要專注於運營，而不必從頭開發產品。
鏈上EVM兼容，以Solona為代表。
Solona是一種PoH機制的單體區塊鏈，也長期是市值前十的公鏈項目中唯一未兼容EVM的公鏈，但並不是說其無法和EVM兼容鏈通信，其在鏈上運行的Neon項目提供了EVM兼容能力。
可以把這種兼容理解為套娃式兼容，而非直接在公鏈本體層面進行兼容。
Neon提供了高度類似於EVM本身的開發體驗，比如Solidity語言編程支持、無縫銜接的智能合約部署體驗、直接調用MetaMask,和Truffle等開發套件。
兼容EVM鏈，以EVMOS為代表。
Cosmos或者波卡等模塊化區塊鏈的可選方式更多，其上的應用本身便可單獨成為L1級別的公鏈，而EVMOS便同時是Cosmos的一條子鏈，也是提供EVM兼容性的公鏈，這意味著Evmos不僅可在Cosmos之間“傳遞”EVM兼容性，在任意其他公鏈之間都可提供EVM兼容性。
除了作為EVM兼容性提供商，其本身也可作為公鏈部署DeFi等應用，比如其上的DEX Exswap就是Uniswap的分叉版本。
本段小結：正是這種廣泛的兼容促成了整個公鏈世界的打通，而其中的紐帶就是EVM兼容性、跨鏈橋以及交易所，鑑於此，R3PO總結瞭如上的兼容性的具體流派，來為ZK EVM的終結者角色做賽前預熱。
欲勝人者，必先自勝：ZK EVM是以太坊的主動出擊
如果說其他公鏈忙於兼容EVM時以太坊自顧不暇，但是在PoS合併成功，L2技術路線確定後，ZK便成為了整個公鏈賽道的通用技術，而ZK技術和EVM的結合也會促成以太坊模塊化架構的進化完成。
ZK技術並不只局限於L2領域，在Dapp、公鍊等上下層都有其用武之地，而當下最火熱的ZK EVM賽道則稍顯魚龍混雜，R3PO對此做簡要整理，力求去蕪存菁。
圖片說明：不同EVM兼容性和性能表現圖源：vitalik.eth
Vitalik曾給出不同的EVM分類的兼容性和性能表現關係，可以發現，越底層的實現兼容性越強，但其性能表現則會越差，這個道理其實很簡單，聯想下以太坊主網那可憐的性能和極強的安全性便可明白。
越靠近底層，則越接近原生EVM的運作模式，則兼容性越強，但是性能也會遭受嚴重限制；
越靠近上層，則越考驗自有EVM兼容方案的能力，和以太坊原生EVM差異越大，則兼容性越差，但也會帶來更強的定制自由度，可大幅優化性能。
前文曾提到過Polygon Hermez，並將其歸類為ZK VM之列，但其實Hermez自稱為ZK EVM解決方案，看似是一字母之差，但其兼容性和安全性卻迥然不同。
在Polygon Hermez上實現的ZK VM/EVM，本質上是一比一“復刻”了EVM的功能，類似於WBTC和BTC的關係、影子和本體的關係，在日常運行中，只要開發團隊保持更新，其使用體驗和EVM是別無二致的，但終究不是語言級別的實現，只能說這是商業競爭下的話術粉飾。
而近日StarkNet 發布使用Cairo 語言的ZK EVM Kakarot，用於在StarkNet 上運行以太坊智能合約，則可以認為是首次進入測試環節的ZK EVM。其餘排在路上的還有Taiko、Scroll、zkSync 2.0等一眾ZK EVM選手。
為什麼ZK EVM成為如此火熱的賽道，又為什麼這是公鏈的終結者？
目前在商業競爭階段，各項目方放出的信息並不全面，R3PO嘗試給出自己的理解，權當拋磚引玉。
圖片說明：ZK EVM時代的以太坊架構圖片來源：R3PO
對於第一個問題，答案是ZK EVM其實是未來Dapp的真正容身之處。
在既有認知中，Dapp要么運行在公鏈上，要么運行在L2網絡上。但在R3PO看來，未來ZK EVM會直接承載應用層。
如上圖所示，未來的ZK EVM會成為EVM、Rollup和跨鏈橋功能的集合體，其本身是一種EVM不需解釋，來重點解釋後兩種功能。
L2 級別的Rollup過於底層，為了追求更高的性能，還是以StarkWare開發的StarkNet為例，其計劃使用ZK 遞歸證明驗證數據的有效性，遞歸可以“以後驗前”的方式無限拓展，ZK可保證數據規模的整體有限性，因此StarkNet本身又可作為其上應用、L3的驗證層。
而跨鏈橋本身更容易理解，跨鏈橋的本質是在不同的公鏈之間交易所、傳遞資產，而如果彼此都實現EVM 兼容性，則無需跨鏈橋作為中介，ZK本身相較於目前漏洞頻發的跨鏈橋方案更為安全，因此ZK EVM是更好的跨鏈橋解決方案。
對於第二個問題，答案是ZK EVM會將整個公鏈都變成EVM鏈。
即使如Solona、Aptos等本身不兼容EVM的公鏈，也可通過Evmos等實現接入，從這個角度上說，ZK EVM是以太坊的主動出擊，你不接入我，我也要兼容你，如此一來，會進一步放大以太坊的生態優勢。
而諸如Aptos、Sui等Move生態公鏈，其所宣稱的Move VM也是類似於EVM一般的開發機制，理論上而言，由Rust改造而來的Move語言確實比Solidity更優，但其最大的劣勢在於時間不等人，能否建構起獨屬於自身的流量和生態值得懷疑，而這又會陷入其他公鍊是否兼容EVM的兩難困境。
結語
一條公鏈能否取得市場成功當然要靠自己的奮鬥，但是也要考慮歷史的進程。
在ZK EVM的發展進程中，能明顯感知到背後的公鏈角力之艱難，在以太坊和一眾公鏈的拉鋸戰中，創造了無盡的浪漫故事，而此時賽點已經來到了EVMOS和Move VM等新物種和ZK EVM的生死局，R3PO認為，未來的公鍊格局必須基於EVM兼容性帶來的互通互聯爲競爭前提，用戶和開發者依然是故事的全部要義。
如果ZK EVM進展順利，很有可能會讓以太坊成為公鏈世界的Windows，運行最為豐富的應用層，保證自身作為最安全的、最穩健的結算層。
ZK技術距離大規模成熟，至少還有5年時間，在資本和市場的大規模催熟下，也許會減緩至3年左右，到那時我們就能見證今日的預判是否會成真。
資訊來源：由0x資訊採集自互聯網。版權歸作者“深潮TechFlow”所有，未經許可，不得轉載