作者：R3PO
导言
一切以技术特性为主要卖点的产品都是半成品。
关于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年左右，到那时我们就能见证今日的预判是否会成真。
