zkevm-docs/14-comparisons.markdown

@@ -2,59 +2,59 @@
 
 ---
 
-## 从对以太坊的兼容性、零知识证明的生成性能角度来对比下各常见的虚拟机：  
+## ChainWeaver zkEVM对比各常见的虚拟机：  
 
-| 虚拟机 | 兼容性 | 性能 | 实现 |   
+| 虚拟机 | 兼容性 |  实现方案 | 技术路线  |
 | :--: | :--: | :--: | :--: | 
-| [zkSync](https://zksync.io/) | 与高级语言兼容 | 最高 | 自定义中间字节码、自定义基于寄存器的虚拟机、证明自定义虚拟机上执行字节码的正确性 |  
-| [Polygon Hermez](https://hermez.io/) | 与EVM几乎兼容 | 较高 |  自定义汇编代码、自定义虚拟机、证明自定义汇编代码执行的正确性 |
-| [Scroll](https://scroll.io/) | 与EVM完全兼容 | 较低 | 针对EVM[大部分操作码](https://docs.scroll.io/zh/technology/chain/differences/)的计算步骤以及状态改变设计通用证明电路来证明交易执行Trace的正确性 |  
-| [长安链zkEVM](https://git.chainweaver.org.cn/zkp/zkevm-circuits) | 与EVM完全兼容 | 较低 | 针对EVM操作码的计算步骤以及状态改变设计通用证明电路来证明交易执行Trace的正确性 |  
-| [Zeth](https://github.com/risc0/zeth) | 与以太坊完全兼容 | 最低 | 将EVM编译为RISC-V机器操作码、使用RISC Zero zkVM来证明RISC-V操作码执行的正确性 |   
+| [zkSync](https://zksync.io/) | 与高级语言兼容 |  自定义中间字节码、自定义基于寄存器的虚拟机、证明自定义虚拟机上执行字节码的正确性 | ? | 
+| [Polygon Hermez](https://hermez.io/) | 与EVM几乎兼容 |   自定义汇编代码、自定义虚拟机、证明自定义汇编代码执行的正确性 | ? |
+| [Scroll](https://scroll.io/) | 与EVM兼容 |  针对EVM[大部分操作码](https://docs.scroll.io/zh/technology/chain/differences/)的计算步骤以及状态改变设计通用证明电路来证明交易执行轨迹的正确性 |  zkSNARK, Halo2, Plonkish |
+| [Zeth](https://github.com/risc0/zeth) | 与以太坊兼容 |  将EVM编译为RISC-V机器操作码、使用RISC Zero zkVM来证明RISC-V操作码执行的正确性 |   ? |
+| **[ChainWeaver](https://git.chainweaver.org.cn/zkp/zkevm-circuits)** | 与EVM兼容 |  针对EVM大部分操作码的计算步骤以及状态改变设计通用证明电路来证明交易执行轨迹的正确性 |   zkSNARK, Halo2, Plonkish |
 
 ---
 
-## 长安链zkEVM与Zeth对比
+## ChainWeaver与Zeth对比
 
-长安链[zkEVM](https://git.chainweaver.org.cn/zkp/zkevm-circuits)与[Zeth](https://github.com/risc0/zeth)，二者实现的原理不同，相应的性能也有差异。
+ChainWeaver与[Zeth](https://github.com/risc0/zeth)，二者实现的原理不同，相应的性能也有差异。
 
-| 虚拟机 | 机器 | 聚合度 |  生成proof耗时 | 验证proof gas消耗 | 
+| 虚拟机 | 机器 | 聚合度 |  生成证明耗时 | 验证证明gas消耗 | 
 | :--: | :--: | :--: | :--: | :--: |
-| 长安链zkEVM | 64核CPU、256GB内存 | 1 | 4025(second) | 432692 |
+| ChainWeaver zkEVM | 64核CPU、256GB内存 | 1 | 4025(second) | 432692 |
 | Zeth | 64 × (4核CPU、16GB内存 + 1核GPU、24GiB内存) | 12 | 2963(second) | 245129 |   
  
 
-当前表格中Zeth采用数据[来源自Zeth官网](https://www.risczero.com/blog/zeth-release)。长安链zkEVM运算使用的是单机CPU，优点是部署简单，硬件成本较低。如何使用GPU的加速能力、如何使用较低配置的硬件集群进行运算也是我们的未来的工作方向。随着项目的迭代,相信两种虚拟机性能都会有提升。  
+当前表格中Zeth采用数据[来源自Zeth官网](https://www.risczero.com/blog/zeth-release)。ChainWeaver zkEVM运算使用的是单机CPU，优点是部署简单，硬件成本较低。如何使用GPU的加速能力、如何使用较低配置的硬件集群进行运算也是我们的未来的工作方向。随着项目的迭代，相信两种虚拟机性能都会有提升。  
 
 --- 
 
-## 长安链zkEVM和Scroll zkEVM对比
+## ChainWeaver和Scroll对比
 
-长安链zkEVM和Scroll的zkEVM都是针对EVM操作码的计算步骤以及状态改变，设计通用证明电路，证明交易执行Trace的正确性。二者整体思路相似，但具体到电路设计有所不同，由此也带来了相应的性能差别。以下表格为在同一机器上(64核CPU、256GB内存)，运行相同的Trace的结果列举。  
+ChainWeaver和Scroll都是针对EVM操作码的计算步骤以及状态改变，设计通用证明电路，证明交易执行轨迹的正确性。二者整体思路相似，但具体到电路设计有所不同，由此也带来了相应的性能差别。以下表格为在同一机器上(64核CPU、256GB内存)，运行相同的交易执行轨迹的结果列举。  
 
-| 虚拟机 | 度数(反映电路的行数规模) | 生成proof耗时 | 验证proof耗时 |  
+| 虚拟机 | 度数(反映电路的行数规模) | 生成证明耗时 | 验证证明耗时 |  
 | :--: | :--: | :--: | :--: |  
 | Scroll zkEVM | 19 | 1906.934(second) | 355.071(millisecond) |  
-| 长安链 zkEVM | 19 | 1603.769(second) | 470.817(millisecond) |  
+| ChainWeaver  zkEVM | 19 | 1603.769(second) | 470.817(millisecond) |  
 
 
-比较下来，长安链生成proof的时间大约提升15%，验证时长较Scroll多耗费了大约34%(但仍然在0.5秒以内,并未形成量级上的延迟)。之所以有如此表现，在于长安链zkEVM针对具体电路的[精心设计](https://git.chainweaver.org.cn/zkp/zkevm-circuits/-/wikis/home)。  
+比较下来，ChainWeaver 生成证明的时间大约提升15%，验证时长较Scroll多耗费了大约34%(但仍然在0.5秒以内,并未形成量级上的延迟)。之所以有如此表现，在于ChainWeaver zkEVM针对具体电路的设计。  
 
-### 长安链zkEVM设计亮点  
+### ChainWeaver zkEVM设计亮点  
 
 为处理智能合约执行的每一步，设计了[Core子电路](https://git.chainweaver.org.cn/zkp/zkevm-circuits/-/wikis/zkevm-docs/4-core)。 
 
-- 定义了执行状态，针对复杂的OpCode将其拆分为多种执行状态的组合来对应多个执行步骤。这样设计的好处是可以让每一个执行状态尽量的简单化，便于处理和复用。举个例子，比如对`Log0`、`Log1`这两个相似的OpCode，我们可以将其分别拆分为以下执行状态序列：`[LOG_BYTES, MEMORY_GAS, LOG_GAS, LOG_TOPIC_NUM_ADDR]`和`[LOG_BYTES, MEMORY_GAS, LOG_GAS, LOG_TOPIC_NUM_ADDR, LOG_TOPIC]`。前四个状态依次处理Log数据的拷贝，memory相关的gas计算，Log操作最终的gas花费，Log数据地址的计算；`LOG_TOPIC`则负责处理TopicHash的计算。这样二个相似的OpCode共享了大多数状态，做到了状态的复用，而每一个执行状态又足够的简单有效。
+- 定义了执行状态，针对复杂的操作码将其拆分为多种执行状态的组合来对应多个执行步骤。这样设计的好处是可以让每一个执行状态尽量的简单化，便于处理和复用。举个例子，比如对`Log0`、`Log1`这两个相似的操作码，我们可以将其分别拆分为以下执行状态序列：`[LOG_BYTES, MEMORY_GAS, LOG_GAS, LOG_TOPIC_NUM_ADDR]`和`[LOG_BYTES, MEMORY_GAS, LOG_GAS, LOG_TOPIC_NUM_ADDR, LOG_TOPIC]`。前四个状态依次处理Log数据的拷贝，memory相关的gas计算，Log操作最终的gas花费，Log数据地址的计算；`LOG_TOPIC`则负责处理TopicHash的计算。这样二个相似的操作码共享了大多数状态，做到了状态的复用，而每一个执行状态又足够的简单有效。
 
-- 动态选择器(Dynamic Selector)的设计。针对不同的执行状态，需要不同的约束。因此需要设计一个电路组件能根据若干advice列来控制N中执行状态的约束。按当前设计,我们可以做到仅使用2sqrt(N)个输入变量完成N种执行状态的约束。  
+- 动态选择器(Dynamic Selector)的设计。针对不同的执行状态，需要不同的约束。因此需要设计一个电路组件能根据若干advice列来控制N中执行状态的约束。按当前设计,我们可以做到仅使用`2\sqrt(N)`个输入变量完成N种执行状态的约束。  
 
 - 每个执行状态使用了多行、多功能列的设计来减小电路的列数，缩减电路规模。计算中所需的状态、变量等都存放到多功能列中以重复利用列。每个执行状态可能会使用多个行来处理更多的数据。比如我们的动态选择器就位于每个执行状态的第0行的多功能列中的0-17列来标识当前的执行状态。我们的aux辅助变量则位于每个执行状态的第0行的18-24列。又比如第1行通常用于存储操作数及其属性，继而可以作为来源到state子电路去做lookup。对每一个执行状态的每一行的每一个格子都做到了按需使用布局，在满足运算需求的同时尽量节约行数。
 
-- 在core电路中汇总所有执行状态的lookup，而不是每个执行状态分别去做lookup。从而减少lookup的开销；且容易做控制，比如我们有个feature叫no_fixed_lookup，开启以后所有执行状态产生的fixed lookup都不用在去查表了，这样就避免了在每一个产生fixed lookup的执行状态中做控制了。
+- 在Core电路中汇总所有执行状态的lookup，而不是每个执行状态分别去做lookup了，从而减少lookup的开销。设置了一个feature叫`no_lookup_merge`，不开启时，所有执行状态产生的lookup将会被汇总、分类、合并，最终产生少量的lookup，这样就减少了lookup的开销。
 
-[Arithmetic子电路](https://git.chainweaver.org.cn/zkp/zkevm-circuits/-/wikis/zkevm-docs/8-arithmetic)用来处理(模)加法、减法、(模)乘法、(模)除法、有符号数比较、有符号除法取余运算，也支持长度判断(Length)、内存拓展(memory expansion)、以及是否u64越界的运算。 
+[Arithmetic子电路](https://git.chainweaver.org.cn/zkp/zkevm-circuits/-/wikis/zkevm-docs/8-arithmetic)用来处理(模)加法、减法、(模)乘法、(模)除法、有符号数比较、有符号除法取余运算，也支持长度判断(length)、内存拓展(memory expansion)、以及是否u64越界的运算。 
 
-- 当然我们可以在core电路中执行数学运算的Opcode所对应的执行状态中来做数学计算，但是那样的话就需要每个执行状态都要去做大量的u16的lookup。这样做是不经济的。统一在arithmetic算术子电路中进行处理能大量减少lookup的开销。同时可以保持core电路中处理数学运算的执行状态的简洁。举个例子，比如evm有个`ADD`的Opcode，其对应的core电路中的执行状态为`ADD_SUB_MUL_DIV_MOD`。这个执行状态中只需要关注操作数、计算结果、gas消耗等的正确性，而整个加法计算过程的正确性则交给了arithmetic电路，仅需要根据(tag,[operand_hi_0,operand_lo_0,operand_hi_1,operand_lo_1,operand_hi_2,operand_lo_2,operand_hi_3,operand_lo_3])到arithmetic电路中lookup验证查询即可。Exp计算幂指数电路也是同样的逻辑，相关数学计算的正确性都交给了arithmetic子电路，仅在需要的时候通过lookup确认正确性即可。
+- 当然我们可以在Core电路中执行数学运算的操作码所对应的执行状态中来做数学计算，但是那样的话就需要每个执行状态都要去做大量的u16的lookup。这样做是不经济的。统一在Arithmetic算术子电路中进行处理能大量减少lookup的开销。同时可以保持Core电路中处理数学运算的执行状态的简洁。举个例子，比如EVM有个`ADD`的操作码，其对应的Core电路中的执行状态为`ADD_SUB_MUL_DIV_MOD`。这个执行状态中只需要关注操作数、计算结果、gas消耗等的正确性，而整个加法计算过程的正确性则交给了Arithmetic电路，仅需要根据(tag,[operand_hi_0,operand_lo_0,operand_hi_1,operand_lo_1,operand_hi_2,operand_lo_2,operand_hi_3,operand_lo_3])到Arithmetic电路中lookup验证查询即可。Exp计算幂指数电路也是同样的逻辑，相关数学计算的正确性都交给了Arithmetic子电路，仅在需要的时候通过lookup确认正确性即可。
 
 # 附录(各常见的零知识虚拟机简介)