Starknet的EVM兼容之路:Kakarot zkEVM
Kakarot是使用Cairo语言在Starknet上实现的zkEVM。
![CYNIC](/wp-content/themes/zhtcw/assets/images/logo-icon.png)
原文作者:CYNIC
原文来源:mirror
TL;DR
- 虚拟机是一个软件仿真的计算机系统,为程序提供执行环境。它可以模拟各种硬件设备,使程序在受控且兼容的环境中运行。以太坊虚拟机(EVM)是一种基于栈的虚拟机,用于执行以太坊智能合约。
- zkEVM是一种集成了零知识证明/有效性证明技术的EVM。它允许使用零知识证明验证EVM的执行过程,而无需所有验证者重新执行EVM。市场上有各种zkEVM产品,每个产品都有自己的方法和设计。
- 需要zkEVM的原因在于对在Layer 2上支持智能合约执行的虚拟机的需求。此外,一些项目选择使用zkEVM来利用EVM的广泛用户生态系统,并设计更友好于零知识证明的指令集。
- Kakarot是使用Cairo语言在Starknet上实现的zkEVM。它以Cairo智能合约的形式模拟了EVM的堆栈、内存、执行和其他方面。Kakarot面临与Starknet帐户系统的兼容性、成本优化和稳定性等挑战,因为Cairo语言尚处于实验阶段。
- Warp是将Solidity代码转换为Cairo代码的转换器,在高级语言级别提供兼容性。另一方面,Kakarot通过实现EVM的操作码和预编译,提供了在EVM级别的兼容性。
什么是虚拟机?
要讲清楚什么是虚拟机,必须先讲当今主流的冯诺依曼架构下的计算机执行流程。运行在计算机上的种种程序,通常是由高级语言经过层层转化,最终生成机器可理解的机器码完成执行的。根据转化为机器码的方式不同,高级语言可以大致分为编译型语言与解释型语言。
编译型语言是指在代码的编写完成后,需要经过编译器的处理,将高级语言代码转换成机器码,生成可执行文件。一次编译就可以多次以较高效率执行。编译型语言的优点是因为在编译时已经将代码转换为机器码,因此执行速度快,并且可以在没有编译器的环境下运行程序,便于用户使用,不需要安装额外的软件。常见的编译型语言包括C,C++,Go等。
与编译型语言相对应的是解释型语言。解释型语言是指代码通过解释器逐行解释执行,直接运行在计算机上,每次运行都要重新进行翻译过程。解释型语言的优点是开发效率高,代码易于调试,但执行速度相对较慢。常见的解释型语言包括Python,JavaScript,Ruby等。
需要强调,语言从本质上并不区分编译型和解释型,只是在最初设计时会有一些倾向。C/C++绝大多数情况下是编译执行,但是也可以解释执行(Cint、Cling)。很多传统意义上的解释型语言,现在是编译成中间代码在虚拟机上执行(Python、Lua)。
知道了物理机的执行流程,现在来讲虚拟机。
虚拟机通常通过模拟不同的硬件设备来提供一个虚拟的计算机环境。不同的虚拟机可以模拟的硬件设备有所不同,但通常包括CPU、内存、硬盘、网络接口等。
以以太坊虚拟机EVM为例,EVM是一种基于堆栈的虚拟机,它被用于执行以太坊智能合约。EVM通过模拟CPU、内存、存储器和栈等硬件设备来提供一个虚拟的计算机环境。
具体来说,EVM是一种基于堆栈的虚拟机,它使用堆栈来存储数据和执行指令。EVM的指令集包括各种操作码,例如算术操作、逻辑操作、存储操作、跳转操作等,这些指令可以在EVM的堆栈上执行,从而完成智能合约的执行。
EVM模拟的内存和存储器是用于存储智能合约的状态和数据的设备。EVM将内存和存储器视为两个不同的区域,它可以通过读取和写入内存和存储器来访问智能合约的状态和数据。
EVM模拟的栈用于存储指令的操作数和结果。EVM的指令集中的大多数指令都是基于堆栈的,它们从栈中读取操作数并将结果推回栈中。
总之,EVM通过模拟CPU、内存、存储器和栈等硬件设备来提供一个虚拟的计算机环境,它可以执行智能合约的指令并存储智能合约的状态和数据。在实际运行中,EVM会将智能合约的字节码加载到内存中,并通过执行指令集来执行智能合约的逻辑。EVM实际取代的是上图中操作系统+硬件的部分。
EVM的设计过程,显然是自下而上的,先敲定了模拟的硬件环境(堆栈、内存),再根据对应的环境设计了自己的一套汇编指令集(Opcode)与字节码(Bytecode)。尽管汇编指令集是给人看的,但是涉及到很多底层知识,对开发者的要求较高,开发起来也较繁琐,所以需要高级语言,屏蔽晦涩繁琐的底层调用,为开发者提供更好的体验。EVM由于其汇编指令集的的定制化设计,很难直接利用传统的高级语言,索性重新一个新的高级语言以适配该虚拟机。以太坊社区为了EVM执行效率设计了两种编译型的高级语言——Solidity和Vyper。Solidity自不必强调,Vyper是Vitalik针对Solidity中存在的部分缺陷进行改进后设计的EVM高级语言,但是在社区没有获得很高的采用度,于是渐渐淡出历史舞台。
什么是zkEVM
简单来讲,zkEVM就是运用零知识证明/有效性证明技术的EVM,让EVM的执行过程,可以通过零知识证明/有效性证明来更高效、低成本地验证,而不需要所有验证者都重新进行EVM的执行过程。
市场上的zkEVM产品众多,赛道火热,主要玩家包括Starknet, zkSync, Scroll, Taiko, Linea, Polygon zkEVM(原Polygon Hermez) 等,被vitalik分为了5类(1、2、2.5、3、4)。具体的内容可以查看Vitalik的博客。
https://vitalik.ca/general/2022/08/04/zkevm.html
为什么需要zkEVM
这个问题需要从两方面来看。
最初的zk Rollup尝试,都只能实现较为简单的转账、交易功能,例如zkSync Lite, Loopring等。但是曾经沧海难为水,用惯了以太坊上图灵完备的EVM,当无法通过编程创造多样的应用时,人们便开始唿唤L2上的虚拟机。撰写智能合约的需求,是为一。
关于【Starknet的EVM兼容之路:Kakarot zkEVM】的延伸阅读
Cairo 1.0 的内部机制:探索 Sierra
Sierra 的主要目标是确保生成的 CASM 代码不会失败。
Kakarot路线图:从将EVM带入Starknet,至成为type 1 zkEVM
首先,Kakarot将作为一个EVM存在于Starknet L2中。
由于EVM中部分设计对于生成零知识证明/有效性证明不友好,部分玩家选择了在底层使用对于零知识证明/有效性证明友好的指令集,例如Starknet的Cairo Assembly和zkSync的Zinc Instruction。但是大家同时也都不愿放弃EVM庞大的用户生态,于是选择在上层兼容EVM,是3、4类zkEVM。还有部分玩家仍然坚持EVM传统指令集Opcode,将精力放在为Opcode生成更高效的证明上,是1、2类zkEVM。EVM的庞大生态,是为二。
Kakarot:虚拟机上的虚拟机?
为什么能够在虚拟机上再做一个虚拟机?这个事情对于计算机从业者而言是司空见惯的,但是对于不了解计算机的用户可能没那么显然。其实很好理解,这就好像搭积木,只要下层足够牢固(有图灵完备的执行环境),就可以无上限地往上层叠加积木。但是不论搭了多少层,最后的执行还是要交给最底层的物理硬件去处理,所以层数增高会导致效率的降低。同时,由于不同积木的设计不同(虚拟机设计不同),随着积木越搭越高,积木倒塌的可能性就越大(运行出错),也就需要更高的技术水平支撑。
Kakarot是在Starknet上用Cairo语言实现的一个EVM,以Cairo智能合约形式去模拟EVM中堆栈、内存、执行等内容。相对而言,实现EVM并不是什么难事,除了使用率最高的Go-Ethereum中用Golang编写的EVM,现存的还有使用Python, Java, JavaScript, Rust编写的EVM。
Kakarot zkEVM的技术难点在于,协议是作为Starknet链上合约存在的,这就带来了两个关键的问题。
- 兼容性 Starknet使用的是和以太坊完全不同的账户体系,以太坊中账户分为EOA(外部拥有账户)和CA(合约账户),然而Starknet中支持原生的账户抽象,所有账户都是合约账户。同时,由于使用的密码学算法不同,用户无法使用同一个熵在Starknet中生成与以太坊相同的地址。
- 成本 由于kakarot zkEVM是作为合约存在于链上的,所以对于代码实现有着较高的要求,需要尽可能地面向Gas进行优化,降低交互成本。
- 稳定性 与使用Golang, Rust, Python等传统高级语言不同,Cairo语言仍然处于试验阶段,从Cairo 0到Cairo 1再到Cairo 2(或者如果你喜欢的话,Cairo 1 version 2),官方团队仍然在不断修改语言特性。同时,Cairo VM还未得到足够的测试,不排除后续大规模重写的可能。
kakarot协议由五个主要的组件组成(GitHub文档中写的是四个,未包含EOA,本文为了便于读者理解做了调整):
- Kakarot (Core):负责执行以太坊形式的交易,同时为以太坊用户提供对应的Starknet账户
- Contract Accounts:以太坊意义上的CA,负责存储合约的字节码、合约中变量状态
- Externally Owned Accounts:以太坊意义上的EOA,负责将以太坊交易转发给Kakarot Core
- Account Registry: 存储以太坊账户和Starknet账户的对应关系。
- Blockhash Registry:Blockhash作为一个特殊的Opcode,需要过去的区块数据,而Kakarot无法在链上直接获取到数据。该组件存储block_number -> block_hash的映射关系,由管理员写入,提供给Kakarot Core。
据kakarot CEOElias Tazartes反馈,在团队的最新版本中,放弃了Account Resister的设计,改为直接使用一个31bytes的Starknet地址到20位EVM地址的mapping来保存对应关系。在未来,为了提高互操作性以及允许Starknet合约注册自己的EVM地址,可能会重新使用Account Register的设计。
Starknet上兼容EVM:Warp与kakarot有什么差异
按照Vitalik定义的zkEVM类型而言,Warp属于Type-4,而kakarot当前属于Type-2.5。
Warp是一个将Solidity代码转化为Cairo代码的转译器,之所以不叫编译器,大概是因为输出的Cairo仍是高级语言。通过Warp,Solidity开发者可以维持原先的开发状态,而不需要学习新的Cairo语言。对于很多项目方而言,Warp降低了进入Starknet生态的门槛,不需要使用Cairo重写大量的工程代码。
转译的思想虽然简单,但是兼容性也是最差的,有部分Solidity代码无法很好地翻译为Cairo,涉及到账户体系、密码算法等代码逻辑需要修改源代码才能完成迁移,具体的不支持特征可见Warp文档。例如,许多项目会对EOA账户与合约账户的执行逻辑进行区分,但是Starknet中所有账户都是合约账户,这部分的代码就需要修改后才能进行转译。
Warp是在高级语言层面的兼容,kakarot是在EVM层面的兼容。
EVM的全部重写,Opcode与Pre-compile的逐条实现,让kakarot拥有了更高原生的兼容性。毕竟,在相同的虚拟机(EVM)中执行,总是要比在不同的虚拟机(Cairo VM)中执行来得更兼容一些。Account Registry、Blockhash Registry更是巧妙地屏蔽了不同体系下的差异,把对用户的迁移摩擦降到最小。
Kakarot 团队
感谢kakarot团队对本文提出的宝贵意见,特别是Elias Tazartes。Thank you, sir!
免责声明:本文仅代表作者个人观点,不代表链观CHAINLOOK立场,不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险,以及遵守所在国家和地区的相关法律法规。
图文来源:CYNIC,如有侵权请联系删除。转载或引用请注明文章出处!