有关zkEVM,你需要知道的一切(三)_DEF:99DEFI币

TL;DR

zkEVM与zkVM差异主要在于对EVM的兼容以及对零知识证明的支持。在开发者与开发资源方面,以太坊拥有最多的开发者、最完整丰富的开发资源与基础设施,以太坊的开发者与开发资源更方便转移到zkEVM上。而StarkNet与zkSync等zkVM的开发者与开发资源远远落后于以太坊。在应用生态方面,以太坊拥有最多的DApp数量与高达58%的DeFi份额,以太坊上的既有应用都将是zkEVM的发展红利,zkVM由于EVM兼容性差将难以移植这些既有应用;但zkVM更兼容零知识证明使得zkVM更有可能涌现出应用创新。在技术上,1)在算法方面,STARKs有更高的安全性和扩展性,但STARKs的证明规模更大,验证时间更长,且STARKs仍处于初始阶段,基础设施和代码库不如SNARKs完善;2)在语言方面,zkEVM可能由于短期内兼容技术不成熟使得Solidity语言在编写过程中可能产生未知漏洞,zkVM的语言更加适配零知识证明;3)在架构方面,EVM串行状态机的架构天然不适配零知识证明,zkVM则是为零知识证明量身定制的虚拟机。本文属于《一文看懂zkEVM》系列文章的第三篇,第一篇介绍了zkEVM的基本原理和细分层次,第二篇盘点了行业中主流的zkEVM项目,本篇文章将说明zkEVM和zkVM两种不同ZKR项目的基本差异。为什么要了解zkEVM和zkVM的差异

Terra Luna Classic社区通过“直接销毁8亿USTC”提案:金色财经报道,Vegas提交的“直接销毁8亿USTC”提案11710被Terra Luna Classic社区正式通过。根据该提案,Ozone 储备钱包的签署者应启动 8 亿个 USTC 的销毁过程。这可以通过直接将资金转移到 Terra Luna Classic 销毁地址来完成。

提案11710获得了近85%的赞成票,8%的人投弃权票,7%的人投反对票。在参与提案的40个验证者中,Allnodes、Interstellar Lounge、HappyCattyCrypto、StakeBinfavor、1maxfee等35个验证者赞成烧掉8亿USTC。[2023/8/21 18:13:29]

zkEVM和zkVM是ZKR项目的两种不同发展方案,二者没有绝对的优劣,只是在生态兼容和技术性能上有不同的权衡,把握二者的差异,有助于把握不同ZKR项目的优劣以及长期发展的基本面。

需要注意,zkVMZKR常特指那些专门设计了zkVM的ZKR,但有时一定程度的兼容EVM也被归到zkEVM的类别中。基本介绍

zkEVM是通过零知识证明验证程序正确性的以太坊虚拟机,旨在以支持零知识技术的方式执行智能合约,优点是兼容EVM。而zkVM,是用于零知识证明系统电路实现的虚拟机,优点在于更加兼容ZK。

zkEVM相对遵循EVM操作码和字节码规范,zkVM则设计新的虚拟机,因此zkEVM也被叫做原生EVM,zkVM也被叫做自定义EVM。对比

zkEVM和zkVM两种方案,代表着ZKR发展的两个方向。在前文zkEVM和zkVM定义下,严格来看,ZKR中的zkEVM包括Scroll、PolygonHermez、PolygonNightfall、PolygonZero,zkVM包括StarkNet、zkSync、PolygonMiden。我们将在开发者与开发资源、应用生态、技术前景等方面对比zkEVM和zkVM两种ZKR方案的差异。开发者与开发资源

zkEVM可以继承以太坊开发者与开发资源,而zkVM则难以继承。在开发者方面,ElectricCapital编撰的《DeveloperReport2021》中的数据显示以太坊月活开发者于2021年达到4011,在所有区块链中排名第一且并遥遥领先其他区块链。

《《DeveloperReport2021》》报告根据Github上以太坊,与StarkNet、zkSync等zkVM项目热门代码仓库的数据,可以看出以太坊有非常庞大的开发者群体以及代码资源,StarkNet与zkSync远远落后于以太坊。

StarkNet的开发资源尽管比较完善,但数量较少,也不如以太坊成熟。

zkSync的开发资源相比以太坊与StarkNet一样匮乏,但相比Starknet,zkSync的教程不够系统与完善,对开发者不够友好。

总结,以太坊的开发者最多,开发资源最丰富,将是zkEVM未来的发展红利,StarkNet和zkSync等zkVMZKR面临巨大的后发劣势。应用生态

在应用生态方面我们将从应用移植与应用创新两个角度对比zkEVM和zkVM。以太坊DApp总数达到2970,日活用户达到5.2万,遥遥领先所有其他区块链。

数据来源:https://www.stateofthedapps.com/zh/stats在DeFi市场方面,根据defillama收录的数据,截至8月11日,以太坊上部署的531个DeFi协议拥有约406亿美元的TVL,占整个DeFi市场份额的58.37%。

数据来源:https://defillama.com/chains以太坊的DApp和DeFi具有非常庞大的市场,zkEVM在应用移植方面具有非常良好的发展前景。应用创新

在应用创新方面,zkVM相对于zkEVM缺失了大量EVM兼容性,导致zkVM难以承接以太坊的应用红利。但zkVM项目由于为零知识证明量身定制了虚拟机,使得zkVM涌现出许多zkEVMZKR不能实现的创新。比如StarkNet的团队Topology宣称实现了全链游戏Issac。

Issac的资产交易、状态存储、逻辑执行全部在链上。

全链也意味着游戏符合区块链的基本属性,去中心、免许可、可组合。没有实体可以更改游戏基本规则,玩家和可以免许可地参与游戏并在其中创造,开发者可以根据合约自行创建出游戏前端以及游戏内的设施和资产。Topology团队的一篇文章集中阐述了Issac的设计哲学。技术前景

在技术前景方面,我们将在算法、语言、架构方面来对比zkEVM和zkVM的优劣。在算法上,大多zkEVMZKR使用SNARKs算法,而StarkNet作为最极端的zkVM主义者使用STARKS算法,需要说明的是,SNARKs是包括Groth16、Halo、Fractal、Sonic在内的系列算法的统称,STARKs是一种新兴的特定SNARKs算法,我们将比较二者之间的优劣。

需要说明的是,可信设置意味着是否需要受信任的设置即可工作,如果不需要信任设置,会具备更高的安全性,量子安全意味着能否防止量子计算机暴力破解私钥;递归意味着是否能证明自己,简单来讲就是可在L2上再实现一个L2,实现L3的效果,性能前景近乎无限。STARKs与SNARKs相比,有更高的安全性和扩展性,性能潜力更好,但目前STARKs的证明规模更大,验证时间更长,且处于初始阶段,基础设施和代码库不如SNARKs完善。在语言方面,由于zkEVM的兼容EVM的方式是在字节码、操作码上对EVM预编译。这会出现两个问题。一方面,由于目前操作码和字节码兼容不完善,会造成Solidity代码在移植、转换电路的过程中出现未知漏洞,如PolygonHermez将EVM字节码直接转换为虚拟机的字节码。

图片来自:https://blog.hermez.io/introducing-hermez-zkevm/另一方面,随着零知识证明技术的成熟,zkEVM必然出现为定制电路的需求,而Solidity等语言对零知识证明不友好,这将造成巨大的技术障碍。而StarkNet和zkSync这类zkVM设计了兼容零知识证明的语言如Cairo和Zinc。开发者可通过这些语言直接为自己的程序生成零知识证明,而不需要学习专业的零知识证明知识编写一组多项式方程并转化为电路。总结,zkEVM可能由于短期内兼容技术不成熟使得Solidity语言在编写过程中可能产生未知漏洞,zkVM的编程语言相对于zkEVM更加适配零知识证明。在架构方面,按照以太坊黄皮书的规范,EVM是一个基于堆栈的、串行状态机,简单来讲就是EVM天然与零知识证明不兼容。而zkVM则是为零知识证明量身定制的虚拟机,在底层架构更加适合零知识证明。zkVM极端主义者StarkNet发明的Cairo语言,是对CPU友好的适配零知识证明的高级语言,使得StarkNet在CPU层级上更加适配零知识证明,甚至可以为此定制零知识证明硬件。投资机构Paradium也注意到了零知识证明中的硬件机会,并为此撰写了论文《HardwareAccelerationforZeroKnowledgeProofs》推荐下载Cairo白皮书以掌握更多设计细节《Cairo–aTuring-completeSTARK-friendlyCPUarchitecture》。综合来看,zkVM相比zkEVM在算法、语言、架构上更加适配零知识证明,拥有更高的扩展性和安全性。未来展望

Scroll创始人YeZhang在推特上建议StarkWare通过zkEVM验证StarkNet上用Cairo语言编写的证明程序,简单讲就是在一个L2上建立另一个L2。这样的提议在技术上是可行的,并且这一提议无疑也描述了一个更有想象力、包容性的L2世界。

各个zkEVM、zkEVM方案的ZKR都将在下半年开启主网与测试网,可以预见,在明年我们就会见证多个ZKR网络迎来大规模应用,以太坊生态逐渐向ZKR网络迁移,区块链可能迎来3G换4G的时代浪潮,网络扩容增速将会为应用创新奠定基础并开启下一轮牛市,2022年的冬天可能是Crypto最后一个冬天。

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

金智博客

[0:15ms0-3:920ms