DAO:复刻Windows和Linux格局,Web 3时代的EVM演化史

导言

一切以技术特性为主要卖点的产品都是半成品。关于EVM和ZKEVM的炒作、争论已经延续一段时间,尤其是在Vitalik对ZKEVM的类型做出划分之后,关于字节码、虚拟机、兼容性等等拗口概念的科普文章层出不穷,但是这些词汇究竟何意,ZKEVM的普及又会把公链格局导向何方等问题并未得到清晰阐释。ZK赛道也正式火热起来,如果说之前的ZK-Rollup将其限制在L2局部领域,那么此刻已经隐约有成为整个区块链网络通用技术的趋势,R3PO认为ZKEVM某种程度上会终结多链并存格局。在这一替代的历史进程中,必然会爆发出更多的新项目,R3PO致力于发掘潜藏价值,我们将从“意会”式理解EVM入手,探索出公链的未来走向。

图片说明:不同操作系统间传递文件的解决办法图源:R3PO试想如下场景:Alice想将一份运行在Windows上的Word文档传递给Bob,但是Bob只有一台可以使用Pages的Mac,所以Bob无法打开文档,请问应该如何解决这个问题?如不考虑Bob安装Mac版本的Word和拷贝文章内文字,还剩下以下四种方式:1.Alice将文章上传至云端,比如GoogleDocs中,Bob可以在支持跨平台的浏览器上打开并编辑文档;2.Alice将Word.exe和文档一并交给对方,Bob可以使用Crossover或者虚拟机来模拟Windows环境,从而可以在Mac上运行.exe应用并打开文档;Crossover只可以单独支持Word.exe运行,而对其他.exe应用无能为力,虚拟机会在Mac内安装一个Windows子系统,在Windows子系统内可运行任意.exe应用;3.Alice将文档变为Java可以理解的文件格式并交给对方,Bob可以在Mac上安装Java环境从而打开文档;4.Alice将文档变为二进制文件并传给对方,Bob可凭借最为底层的兼容性打开文档。如果可以理解上述过程,那么试做如下概念替换:Windows和macOS等操作系统-->Ethereum和Cosmos等公链;.exe和.dmg等应用格式-->不同公链的Dapp;Word文档-->链上资产;Crossover-->跨链桥;虚拟机-->较低兼容性的EVM,比如PolygonHermez便是一种ZKVM,对照EVM实现功能,需要手动迭代保持同步更新;JVM-->EVM,语言级等效的兼容性,比如计划中的Scroll,其实现的ZKEVM跟EVM完全等效,可以理解为EVM加入ZK特性版;二进制兼容-->这就是EVM或者以太坊本体;整个VM和EVM的特性如上所述,其运作模式和跨操作系统传递文件的流程基本类似。在R3PO看来,最大的趋势是ZKEVM不仅会替代现有的EVM兼容方案,并且会最终导致以太坊成为唯一的应用层通信协议,而其他公链都会成为特定领域的特定用途链,类似Linux活跃在服务器领域,而Windows活跃在普通用户之间。至于得出这样论断的原因,我们会在下文详述。欲知人者,必先自知:生态的本质是开发者和用户方的双向奔赴

EVM促进了以太坊在公链竞争中的胜利,这种胜利并非出于以太坊的“计算能力优越性”,而主要是出于兼容性,因为EOS等老一代以太坊杀手,Solona等上一代以太坊杀手,以及Aptos等新一代以太坊杀手都标榜过自身TPS的超高速度。但是以太坊仍旧屹立不倒,以个位数的TPS保持TVL、Dapp数量的绝对领先优势,这种优势可以归纳为生态群聚效应,但是为何在其他公链纷纷兼容EVM,以及大力建设跨链桥之后,差距并未缩小,反而在熊市有进一步扩大的迹象呢?R3PO认为,可以从一个较为确定的起点出发去得出问题的解。这个起点是开发者的体验,目前的Web3仍处于极早期阶段,可以类比为2000年前的互联网,仍旧是极客和早期尝鲜者的领域,即使有代币机制,大多数用户仍沉淀在CEX、TradiFi机构构建的CeDeFi之内,真正的链上用户少的可怜,以太坊的活跃地址不过40万,但TVL却高达320亿美元,市值达2000亿美元。在用户数量和资金沉淀量的巨大反差背景下,争夺开发者力量成为维持生态的最主要途径,其中逻辑在于谁能坚持到真正亿级消费者应用的面世,哪条公链就能真正成为下一代互联网的基础设施,一如万维网和网景浏览器往事。而以太坊给予开发者的开发体验是最为完整的。某种意义上,这也是对Java语言成功的一种效仿,在Java之前,C/C++语言最大的问题是需要程序员去考虑软件和硬件的适配问题,比如32位的数值类型无法直接迁移至16位的机器运行。

图片说明:JVM架构图源:维基百科而Java在语言易用性做出改进之外,最大的改进之处就在于JVM的设计,一言以蔽之,其特性就在于“硬件软化”,通过语言调度实现对不同硬件的相同适配,只要在EVM实现一次,便可在任意设备运行,真正实现跨平台开发,而无需额外考虑硬件问题。借助JVM,Java成为世界上最主流的开发语言之一,也许并不专精某领域,但是任何领域都可适用,这就是兼容性的本质。EVM及以太坊开发生态也是如此,开发者只需要面向EVM开发一次,便可持续跟随以太坊生态而不断进步,而无需考虑公链升级的兼容性、硬件的差异性等情况。

图片说明:EVM架构图源:ethereum.orgSolidity并不完美,EVM也不是没有问题,但是最好的兼容性足以保证开发者的忠诚度,而随着越来越多的公链兼容EVM,这种兼容性变获得了被动收益,链间迁移工作量足够小,其他公链只是以太坊Dapp的本土化版本,最终有利于以太坊生态的独大。

图片说明:EVM的工作示意图源:R3PO并且语言级的兼容性也有助于确保EVM的效率和安全。上图中的虚拟机是指不同操作系统间的运作模式,比如ParallelsDesktop,可以保证在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兼容,以BNBChain等为代表。BNBChain或者OKXChain等交易所公链,凭借交易所的用户基数,以及对项目的运营能力,其链上TVL和生态也不容小觑,以BNBChain为例,据DeFiLlama数据,其上运行492种协议,TVL达60亿美元,按照规模和体量而言,是仅次于以太坊的第二大公链。其最主要运作模式“模仿”以太坊,比如其上的最大DEXPancakeswap最早便是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等应用,比如其上的DEXExswap就是Uniswap的分叉版本。本段小结:正是这种广泛的兼容促成了整个公链世界的打通,而其中的纽带就是EVM兼容性、跨链桥以及交易所,鉴于此,R3PO总结了如上的兼容性的具体流派,来为ZKEVM的终结者角色做赛前预热。欲胜人者,必先自胜:ZKEVM是以太坊的主动出击

如果说其他公链忙于兼容EVM时以太坊自顾不暇,但是在PoS合并成功,L2技术路线确定后,ZK便成为了整个公链赛道的通用技术,而ZK技术和EVM的结合也会促成以太坊模块化架构的进化完成。ZK技术并不只局限于L2领域,在Dapp、公链等上下层都有其用武之地,而当下最火热的ZKEVM赛道则稍显鱼龙混杂,R3PO对此做简要整理,力求去芜存菁。

图片说明:不同EVM兼容性和性能表现图源:vitalik.ethVitalik曾给出不同的EVM分类的兼容性和性能表现关系,可以发现,越底层的实现兼容性越强,但其性能表现则会越差,这个道理其实很简单,联想下以太坊主网那可怜的性能和极强的安全性便可明白。越靠近底层,则越接近原生EVM的运作模式,则兼容性越强,但是性能也会遭受严重限制;越靠近上层,则越考验自有EVM兼容方案的能力,和以太坊原生EVM差异越大,则兼容性越差,但也会带来更强的定制自由度,可大幅优化性能。前文曾提到过PolygonHermez,并将其归类为ZKVM之列,但其实Hermez自称为ZKEVM解决方案,看似是一字母之差,但其兼容性和安全性却迥然不同。在PolygonHermez上实现的ZKVM/EVM,本质上是一比一“复刻”了EVM的功能,类似于WBTC和BTC的关系、影子和本体的关系,在日常运行中,只要开发团队保持更新,其使用体验和EVM是别无二致的,但终究不是语言级别的实现,只能说这是商业竞争下的话术粉饰。而近日StarkNet发布使用Cairo语言的ZKEVMKakarot,用于在StarkNet上运行以太坊智能合约,则可以认为是首次进入测试环节的ZKEVM。其余排在路上的还有Taiko、Scroll、zkSync2.0等一众ZKEVM选手。为什么ZKEVM成为如此火热的赛道,又为什么这是公链的终结者?目前在商业竞争阶段,各项目方放出的信息并不全面,R3PO尝试给出自己的理解,权当抛砖引玉。

图片说明ZKEVM时代的以太坊架构图片来源R3PO对于第一个问题,答案是ZKEVM其实是未来Dapp的真正容身之处。在既有认知中,Dapp要么运行在公链上,要么运行在L2网络上。但在R3PO看来,未来ZKEVM会直接承载应用层。如上图所示,未来的ZKEVM会成为EVM、Rollup和跨链桥功能的集合体,其本身是一种EVM不需解释,来重点解释后两种功能。L2级别的Rollup过于底层,为了追求更高的性能,还是以StarkWare开发的StarkNet为例,其计划使用ZK递归证明验证数据的有效性,递归可以“以后验前”的方式无限拓展,ZK可保证数据规模的整体有限性,因此StarkNet本身又可作为其上应用、L3的验证层。而跨链桥本身更容易理解,跨链桥的本质是在不同的公链之间交换、传递资产,而如果彼此都实现EVM兼容性,则无需跨链桥作为中介,ZK本身相较于目前漏洞频发的跨链桥方案更为安全,因此ZKEVM是更好的跨链桥解决方案。对于第二个问题,答案是ZKEVM会将整个公链都变成EVM链。即使如Solona、Aptos等本身不兼容EVM的公链,也可通过Evmos等实现接入,从这个角度上说,ZKEVM是以太坊的主动出击,你不接入我,我也要兼容你,如此一来,会进一步放大以太坊的生态优势。而诸如Aptos、Sui等Move生态公链,其所宣称的MoveVM也是类似于EVM一般的开发机制,理论上而言,由Rust改造而来的Move语言确实比Solidity更优,但其最大的劣势在于时间不等人,能否建构起独属于自身的流量和生态值得怀疑,而这又会陷入其他公链是否兼容EVM的两难困境。结语

一条公链能否取得市场成功当然要靠自己的奋斗,但是也要考虑历史的进程。在ZKEVM的发展进程中,能明显感知到背后的公链角力之艰难,在以太坊和一众公链的拉锯战中,创造了无尽的浪漫故事,而此时赛点已经来到了EVMOS和MoveVM等新物种和ZKEVM的生死局,R3PO认为,未来的公链格局必须基于EVM兼容性带来的互通互联为竞争前提,用户和开发者依然是故事的全部要义。如果ZKEVM进展顺利,很有可能会让以太坊成为公链世界的Windows,运行最为丰富的应用层,保证自身作为最安全的、最稳健的结算层。ZK技术距离大规模成熟,至少还有5年时间,在资本和市场的大规模催熟下,也许会减缓至3年左右,到那时我们就能见证今日的预判是否会成真。版权声明:如需转载欢迎加小助理微信沟通,未经允许转载、洗稿、我方将保留追究法律责任的权利。免责声明:市场有风险,投资需谨慎。请读者在考虑本文中的任何意见、观点或结论时严格遵守所在地法律法规,以上内容不构成任何投资建议。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

链链资讯

[0:0ms0-10:581ms