Polygon zkEVM Spearbit审计报告解读（2022年12月版本）

mutourend2023-12-24 19:46

1. 引言

前序博客：

主要见：

Polygon zkEVM为提供（opcode层面兼容的）EVM等价zk-rollup，具有良好的用户体验并兼容现有以太坊生态和工具。

主要关注：

Spearbit研究人员分为2组：

  • 1）一组专注于状态机和PIL。
  • 2）另一组专注于指令实现和测试评估。

经过10天（共12人周）的培训，Spearbit在（2022年12月5日至2022年12月16日）审计周期中，共发现了32个问题，其中致命漏洞7个，高风险漏洞1个，中等风险漏洞1个，不兼容漏洞1个，信息提示类22个，当前已解决了其中的27个问题。

在本审计报告中，风险分级为：

风险级别 影响：高 影响：中等 影响：低
可能性：高 致命 高 中等
可能性：中等 高 中等 低
可能性：低 中等 低 低

其中：

  • 1）影响：
    • 高：会导致丢失协议中 > 10 % >10\% >10%资产，或对大多数用户有重大危害。
    • 中等：丢失 < 10 % <10\% <10%资产，或仅丢失一部分用户的资产，但仍不可接受。
    • 低：丢失很烦人但可接收。适用于可以很容易修复的网格攻击，甚至是gas不足。
  • 2）概率：
    • 高：几乎确定会发生，易于操作，或不易于操作但激励诱人。
    • 中等：仅有可行性可能或动机，但相对有可能发生。
    • 低：需要stars to align，或者几乎没有动机。
  • 3）风险级别：
    • 致命：（若已部署）必须尽快修复。
    • 高：（若未部署），需在部署前修复。
    • 中等：应该修复。
    • 低：可修复。

1.1 测试

本轮review重点关注：

除外的测试用例列表长度约为2200个entries，可分为如下类别：

  • 预编译测试
  • 交易测试（EIP-2930访问列表相关）
  • selfdestruct测试
  • 应使用 > 30 M >30M >30Mgas、OOC（out of counters）或资源耗尽，而失败的测试。

已研究了一些预编译测试，因为有些支持的预编译（如ecrecover）失败，原因在于其结合了多个预编译（通常是sha256）。实际并不对这些测试做调整。

当前专注于研究因资源限制，且与EVM指定相关限制导致失败的测试用例。其中包括MemoryTests、VMTests、StackTests，但因时间有限，未覆盖每个测试用例。

1.2 zkASM

本轮review重点关注：

该ROM中包含如下内容：

  • ecrecover
  • opcodes
  • precompiles
  • utilities
  • transaction processing

因时间有限，重点关注：

  • 交易验证
  • flow-control.zkasm中的：
    • 跳转
    • 专注于Keccak-256的CREATE2
  • comparison.zkasm中的：LT、GT、SLT、SGT、EQ、ISZERO、AND、OR、XOR、NOT、BYTE、SHR、SHL、SAR。
  • stak-operations.zkasm中的：DUPx、SWAPx、POP、PUSH。
  • utils.zkasm中：被以上组件使用的utilities。

1.3 PIL状态机

本轮review重点关注：

以PIL编写的所有zkEVM状态机有：

  • arith状态机，部分覆盖（除曲线方程式正确性之外的所有）
  • binary状态机，完全覆盖
  • mem状态机，完全覆盖
  • mem_align状态机，完全覆盖
  • keccakf状态机，部分覆盖
  • padding_kk状态机，部分覆盖
  • padding_kkbit状态机，部分覆盖
  • nine2one状态机，完全覆盖
  • padding_pg状态机，部分覆盖
  • poseidon状态机，部分覆盖
  • main/rom状态机，部分覆盖
  • global状态机，完全覆盖
  • storage状态机，未覆盖

为辅助审计，开发了PIL状态机的形式化分析工具：

该PoC工具可做：

  • 静态分析
  • 非确定性检查
  • PIL状态机正确性证明

1.3.1 arith.pil形式化分析

arith.pil状态机，形式化为，所有多项式以整数值表示。只要所有值和所有算术运算均在所用域内，则该形式化表示是正确的。

arith.pil状态机，展开为32行，初始行号为0，证明了其如下属性：

  • 第0行中的Arith.x1值，总是与第31行的值相同。可通过arith_check_x1_constant_accross_window.smt2 来证明。
  • 若选中equation 0且在第一行，则设置了如下变量：
    Arith.y1=1
    Arith.y2=0
    Arith.x2=0
    Arith.x1=0
    Arith.y3=10
    然后，第一行中的Arith.x1必须等于10。可通过arith_eq0_b1_c0_d0_e10_implies_a10.smt2 来证明。

1.3.2 mem.pil形式化分析

1.3.2.1 mem.pil中read形式化分析

mem.pil状态机内，read，表示为 m O p ′ = 1 ∧ m W r ′ = 0 mOp'=1\land mWr'=0 mOp′=1∧mWr′=0，输出值 v a l i ′ , i ∈ [ 0 , 7 ] val_i',i\in[0,7] vali′,i∈[0,7]取决于 l a s t A c c e s s lastAccess lastAccess是否为 1 1 1。 l a s t A c c e s s lastAccess lastAccess为请求read之前的address access：

  • 1）Lemma 1： m O p ′ = 1 ∧ m W r ′ = 0 ∧ l a s t A c c e s s = 1 mOp'=1\land mWr'=0\land lastAccess=1 mOp′=1∧mWr′=0∧lastAccess=1，输出为 v a l i ′ = 0 val'_i=0 vali′=0。若 l a s t A c c e s s = 1 lastAccess=1 lastAccess=1，则表示为首次访问新读取的地址，因此 v a l i ′ = 0 val'_i=0 vali′=0。其在mem_read_last_access.smt2中证明，应返回unsat。
  • 2）Lemma 2： m O p ′ = 1 ∧ m W r ′ = 0 ∧ l a s t A c c e s s = 0 mOp'=1\land mWr'=0\land lastAccess=0 mOp′=1∧mWr′=0∧lastAccess=0，输出为 v a l i ′ = v a l i val'_i=val_i vali′=vali。若 l a s t A c c e s s = 0 lastAccess=0 lastAccess=0，则表示所读取的地址之前已被读过或写过，因此 v a l i ′ = v a l i val'_i=val_i vali′=vali。其在mem_read_not_last_access.smt2中证明，应返回unsat。
  • 3）Lemma 3： m O p ′ = 1 ∧ m W r ′ = 0 mOp'=1\land mWr'=0 mOp′=1∧mWr′=0，输出 v a l i ′ val'_i vali′为确定性的。无论 l a s t A c c e s s lastAccess lastAccess为何值。其在mem_read_are_deterministic.smt2中证明，应返回unsat。
1.3.2.2 mem.pil中write形式化分析

mem.pil状态机内，writes，可将任意值写入 v a l i ′ val_i' vali′内。这些值未在Mem状态机内约束，因此当有write时，其query是非确定性的：

  • 4）Lemma 4： m W r ′ mWr' mWr′，则 v a l i ′ val_i' vali′是诶确定性的。其在mme_writes_are_not_deterministic.smt2中证明，返回sat。

writes和内存操作之间关系的另一简单但有用的定理为：

  • 5）Lemma 5： m W r ′ mWr' mWr′，则 m O p ′ mOp' mOp′，即永远没有内存之外的write。见mem_write_implies_mem_op.smt2，返回unsat。
1.3.2.3 mem.pil中address和step形式化分析

mem.pil中，内存访问表，先按地址排序，然后按step排序。从而要求下一行的地址要么是增加的，要么地址值不变，但step是增加的。除第一行和最后一行之外，其它相邻行都需满足该要求：

  • 6）Lemma 6： I S N O T L A S T = 1 ISNOTLAST=1 ISNOTLAST=1，表示 ( a d d r ′ > a d d r ) ∨ ( a d d r ′ = a d d r ′ ∧ s t e p ′ > s t e p ) (addr'>addr)\vee (addr'=addr'\land step'>step) (addr′>addr)∨(addr′=addr′∧step′>step)。具体见mem_isnot_last_implies_inc_addr_step.smt2，返回unsat。

addr和lastAccess之间感兴趣的另一关系为，若当前行的lastAccess为0，则下一行的地址保持不变：

  • 7）Lemma 7： l a s t A c c e s s = 0 lastAccess=0 lastAccess=0，表示 a d d r ′ = a d d r addr'=addr addr′=addr。具体见mem_not_last_access_implies_same_addr.smt2，返回unsat。

2. 致命漏洞

2.1 致命漏洞1：频繁使用unchecked free变量来计算gas

具体上下文见：

这些均会影响memory expansion。

以opCALLDATACOPY为例，其未对用于计算wordsize cost的free变量进行约束：

 	GAS - 3 => GAS  :JMPN(outOfGas)
    GAS - ${3*((C+31)/32)} => GAS    :JMPN(outOfGas) ; Arith

在某些地方，如opRETURNDATACOPY中使用arith状态机来计算：

	;${3*((C+31)/32)}
    C+31 => A
    ;(C+31)/32
    A               :MSTORE(arithA)
    32              :MSTORE(arithB)
                    :CALL(divARITH)
    $ => A          :MLOAD(arithRes1)
    ; Mul operation with Arith
    ; 3*((C+31)/32)
    3               :MSTORE(arithA)
    A               :MSTORE(arithB)
                    :CALL(mulARITH)
    $ => A          :MLOAD(arithRes1)
    GAS - A => GAS  :JMPN(outOfGas)

具体修复PR见：

2.2 致命漏洞2：内存对齐延展性

上下文见：

常量多项式BYTE_C4096，未对255之后的值做wrap around，支持inV值大于一个字节，从而可能carry over，并引起MSTORE8在写入指定byte到内存之前，写入一个 1 1 1。

背景知识为：

  • Solidity代码生成器通常会试图对齐内存便宜，通过word-boundaries来分配，且许多其它项目也鼓励写内联汇编来实现对齐。但是，某些人为优化gas，可不做对齐，而且也不能确定Solidity的代码生成器中不存在未对齐的情况。
    想象下，若可能在未对齐的MLOADS中插入"fake value"，则意味着恶意产块者可让某用户在某AMM交易或其它类型的swaps中损失钱或赚钱。这些交易可被三明治以提取价值。未对齐读取情况下，可很容易地通过交易追踪来map out，且"searchers"可搭建proof样式的数据库来修改自动执行类似交易。

推荐修复策略：

  • 对大于255的值做wrap around。

    @@ -11,7 +11,7 @@ const CONST_F = {
    BYTE2B: (i) => (i & 0xFF), // [0..255]
    // 0 (x4096), 1 (x4096), ..., 255 (x4096), 0 (x4096), ...

    • BYTE_C4096: (i) => (i >> 12), // [0:4096..255:4096]
    • BYTE_C4096: (i) => (i >> 12) & 0xFF, // [0:4096..255:4096]
      // 0 - 1023 WR256 = 0 WR8 = 0 i & 0xC00 = 0x000
      // 1024 - 2047 WR256 = 0 WR8 = 0 i & 0xC00 = 0x400

修复PR见：

2.3 致命漏洞3：不正确的BYTE实现

上下文见：

在opBYTE中，范围检查 31 - B => D :JMPN(opBYTE0) 是不正确的，因为其仅检查了B0，若任意的B1-B7为非零值，则opBYTE应为0值时，可能为其它值。

如：

  • A=0xa0a1a2a3a4a5a6a7a8a9b0b1b2b3b4b5b6b7b8b9c0c1c2c3c4c5c6c7c8c9d0d1
  • B=0x100000001，即B0=1，B1=1
  • 则结果应为0值，但现在为0xa0值。

类似用例未在Ethereum State Tests中覆盖，但多种不同版本的实现通过单元测试（如evmone）进行了覆盖。

推荐修复措施为：

  • 使用 :SUB

修复PR见：

2.4 致命漏洞4：VMTests/vmPerformance/loopExp中的测试失败（可能问题在于EXP）

上下文：

  • zkevm-testvectors

VMTests/vmPerformance/loopExp.json中的某些以太坊测试用例有如下错误：

Input: /0xPolygonHermez/zkevm-testvectors/tools/ethereum-tests/eth-inputs/GeneralStateTests/VMTests/loo c
pExp_1.json↪→
Start executor JS...
Error
Error: Program terminated with registers A, D, E, SR, CTX, PC, MAXMEM, zkPC not set to zero

失败的测试用例列表为：

loopExp_1
loopExp_2
loopExp_3

具体测试用例见：

相比于Ethereum tests，其修改为具有更低交易gas limit，并降低了loop迭代次数，以满足3000万 gas limit的限制。

很难诊断具体原因，因测试框架并不保存类似错误情况下的trace log文件，具体见后面的"Trace log is not saved in case of "register not set to zero" error"信息类漏洞。

可能是EXP实现中存在bug。

建议：

  • 确保可执行这些loopExp测试，并验证EXP表现正确。

修复PR见：

2.5 致命漏洞5：不正确的SAR实现

上下文见：

该opSAR实现是不正确的。当A为"negative"（符号位为1）时，SHRarithBit错误为(0-A)。

如：sar(0x80...01, 1)，结果为0xc0...01，而不是c0...00：

sign(A) == 1
abs(A) == 0x7f..ff
abs(A) >> 1 == 0x3f..ff
0 - (abs(A) >> 1) == 0xc0..01

如下测试用例应可发现该bug，但其被禁用了：

[ FAILED ] stShift.shiftCombinations
[ FAILED ] stShift.shiftSignedCombinations

建议：

  • 当A为负数时，SAR的正确实现可为：NOT(SHR(NOT(A), D))，其中A为shift数，D为要移动的位数，当前实现中，NOT为bit wise negation，而不是算术negation。

  • 可使用XOR和符号位，来做有条件negate。若E包含了符号位，则可为：

    MASK = SUB(0, E)
    RESULT = XOR(SHR(XOR(A, MASK), D), MASK)

修复PR见：

2.6 致命漏洞6：对division余数的check不足

上下文见：

divARITH子程序中，使用arith状态机来做除法。使用的为A * B + C = D * 2**256 +E 方程式，所有变量均为256位无符号数字，但该方程式是整数运算方程式。

该子程序会同时计算 E/A 和 E%A，E和A为该子程序的输入，并按状态机变量的方式赋值。

在调用arith状态机之前，该子程序会做如下2个checks：

  • 1）除0，若A==0，则直接返回(0, 0)。
  • 2）若E<A，则直接返回(0, E)。

然后当其调用arith状态机时，会设置：D=0, B=(E/A)（free input）, C=(E%A)（free input）。选择这些free inputs，会让该状态机成功。

问题在于：

  • 仅当余数{E%A}值小于A时，其才是正确的余数。当以B={E/A-1}, C=${(E%A)+A}来触发arith状态机时，其仍然满足该方程式------只要E/A>=1且无算术溢出。

在第469行，其注释声称在调用完arith状态机后，会检查"remainder < divisor"，但实际代码做的是不同的检查：

  • 其调用LT状态机来检查C<E，而不是C<A。

这就意味着，恶意prover可伪造无效的除法和模运算。

注意，由于在调用arith状态机之前检查了E<A，仅在A<=E的情况下才调用arith状态机，从而使得C<E的无效检查，永远不会比正确的C<A检查更严格，从而导致在测试中未发现该问题。

推荐：

  • 修改469行代码：

     - ; check divisor > reminder
 - C => A ; reminder
 -  E => B ; divisor
 + ; check divisor > reminder
 +  C => A ; reminder
 +  E => B ; divisor

修复PR见：

2.7 致命漏洞7：binary状态机内未约束的carry值

上下文见：

当RESET为1时，prover可任意设置cIn中的值。这样，prover可设置cIn为1，来证明0+0==1。

如对于binary状态机的收割运算，该漏洞可被利用为：

// sm_binary.js:337
+ pols.cIn[0] = 1n;

建议：

  • 修改对cIn的PIL约束为：【这样当RESET==1时，有cIn==0。】

    // binary.pil:82

    • cIn' * (1 - RESET) = cOut * ( 1 - RESET' )
    • cIn' = cOut * ( 1 - RESET' )

修复PR见：

3. 不兼容性漏洞

3.1 不兼容性漏洞1：可跳转进push-data，与以太坊主网背离

上下文见：

其仅检查目标是0x5b（JUMPDEST）byte，但不检查0x5b是否为之前PUSH指令的一部分。

以太坊jumpdest-analysis规定，不应跳转到push-data，这是执行过程中代码和数据的有力分离。

虽然JUMPDEST opcode初始需求是为了让EVM代码更容易转换到机器代码（通过启用基本执行块探测），但后来开发人员和工具都期望使用此功能，以避免（恶意）错误隐藏在代码的数据部分。

如果zkEVM允许此类代码有效，则分析部署的代码将需要改进的工具，安全研究人员社区必须意识到这一差异。

如下字节码0x6001600055600A56615B5B5B应fail：

# Bytes Opcode
# Location
# -------- ----------
# 00-01 PUSH1 0x01
# 02-03 PUSH1 0x00
# 04 SSTORE
# 05-06 PUSH1 0x0A (End of PUSH data location)
# 07 JUMP
# 08-0A PUSH2 0x5B5B
# 0B JUMPDEST

建议：

  • 若跳转目标为push-data内的0x5b byte，则异常终止。

当前Polygon-Hermez认为：

  • 这是EVM和zkEVM实现的一个已知的不同之处。在runtime是做code JUMPDEST分析，意味着zkEVM的高开销，因此决定不做该check。

4. 高风险漏洞

4.1 高风险漏洞1：交易处理未拒绝可延展签名

上下文见：

在EIP-2: Homestead Hard-fork Changes中，限制了高S值的签名。

当前，s值大于secp256k1n/2的所有交易签名，都认为是无效的。该ECDSA recover预编译合约保持不变，且将仍保持接受高s值，这样做的好处有------在合约内恢复old Bitcoin签名。

processTx中的交易处理代码，会将raw签名细节传递给ecrecover，其仅验证r值在[1, secp256k1n-1]范围内，且s值在[1, secp256k1n-1]范围内。由于ecrecover代码用于预编译，其是合理的。但用于交易处理时，有效的范围应为[1, secp256k1n/2]。

详情也可参看以太坊黄皮书附录F。

建议：

  • 拒绝类似交易。

修复PR见：

5. 中等风险漏洞

5.1 中等风险漏洞1：Ethereum Test Suite设计运行多个版本而不是单个版本

上下文：

Ethereum Test Suite设计为支持多个协议版本（称为Network），可自genesis（称为Frontier）递增至最新release。

某些测试用例启用于：

  • 某特定老版本，如今Frontier，因无人更新它们。
  • 自某特定新版本开始，如London，因其依赖于某些新的EVM feature来让测试更简单，但该feature实际设计为自更早的upgrades启用测试。

Polygon zkEVM仅与Berlin release紧密关联，可能会错过某些测试用例。https://github.com/spearbit-audits/ethereum-state-tests/tree/ecrecover-all-forks中更新了一些Berlin中启用的测试用例，但需要更深入地review该test suite。

建议：

  • 确保所有测试用例均运行于Berlin版本

修复的PR有：【Polygon zkEVM团队将review整个Ethereum test suite来识别与Berlin版本想过的missing test，以提升测试覆盖率】

6. 信息类风险

6.1 信息类风险1：源码中仍有TODO和question注释

在源码中，仍有不少TODO和question注释。这些可能导致行为是否是故意的不确定性。再加上许多以太坊状态测试案例被禁用，它们很可能掩盖了真正的问题。

建议：

  • review所有注释，标识并移除。

相关修复PR：

6.2 信息类风险2："register not set to zero"错误时，未保存trace log

当Ethereum测试执行结束有错误：Error: Program terminated with registers A, D, E, SR, CTX, PC, MAXMEM, zkPC not set to zero时，在zkevm-proverjs/src/sm/sm_main/logs-full-trace 目录下并未创建trace文件，使得难于deug该错误。类似loopExp错误也存在没有trace文件，难于debug的问题。

建议：

  • 若test执行以错误结束，总是创建trace log文件。

修复PR见：

6.3 信息类风险3：identity预编译内部循环检查了未使用变量

上下文见：

identity内部循环------名为IDENTITYreturnLoop，会做STEPS、BINARY、POSEIDON_G counters减法，但这些并未在该loop内使用，因为没有发生任何arithmetic计算或哈希计算。

这些减法是浪费的，同时会导致区块内包含更少的交易数。

建议：

  • 不要调整这些counters

修复PR见：【将在更底层的函数做zk-counters检查】

6.4 信息类风险4：可能的opPUSH优化

上下文见：

在opPUSH实现中，检查了push data是否在code boundaries：

$ => B :MLOAD(bytecodeLength)
PC + D => A
$ :LT,JMPC(opAuxPUSHA2)
PC => A
B - A => D

无需做256位精度的比较，因为这些值均在32位范围内。因此，可将LT替换为常规减法：

$ => B :MLOAD(bytecodeLength)
B - PC - D :JMPN(opAuxPUSHA2)
B - PC => D

此外，对于push data仅部分位于code boundaries内的病态情况，将D调整为B-PC。特别是，D可以为0，因此请检查readPush是否能正确处理。

最后，可以注意到，在病态情况下，推送到stack的值永远不会被访问（因为PUSH是最后一条指令）。因此，在这种情况下，可始终设置0=>D。

相关修复PR：

6.5 信息类风险5：应有选项来运行独立测试

上下文见：

eth-tests-folder.sh脚本总是重新生成输入，甚至没有update选项。这与eth-tests.sh脚本逻辑不一致，eth-tests.sh脚本支持不重新生成，仅运行测试用例。

建议：

  • 修改eth-tests-folder.sh脚本，使其与eth-tests.sh类似：

    if [ -f "eth-inputs/group/folder/info.txt" ] && [ "$1" != "update" ]
    then
    echo "Exist"
    else
    npx mocha --max-old-space-size=12000 gen-inputs.js --group $group --folder $folder --output
    eth-inputs↪→
    fi

同时，建议有可选项，来运行指定folder内的单个测试。

相关修复PR：

6.6 信息类风险6：test运行时不易于使用debug选项

上下文：

  • zkevm-testvectors

README中提及了一些额外的选项，但如何激活这些选项并不清晰：

如，可能想要对gen-inputs.js运行添加--evm-debug选项。

同时，生成的traces置于未说明的难以发现的路径，如：

  • 当激活--evm-debug选项时，ethereumjs traces存储在zkevm-testvectors/tools/ethereum-tests/evm-stack-logs目录下。
  • 无需任何flags，zkevm traces存储在zkevm-proverjs/src/sm/sm_main/logs-full-trace 目录下。

建议：

  • 更好的说明如何从test execution中收集EVM traces。

相关修复PR：

6.7 信息类风险7：可能的SHL简化

上下文：

左移操作分为2种情况：

  • 1）zero overflow
  • 2）nonzero overflow

这2种情况，都以完全相同的值来调用ARITH状态机，唯一的区别仅在于其中一种情况使用D=0（ARITH状态机内D为overflow），而另一种情况，D为包含该overflow的free input。

根据该overflow是否为0，会多次调用BINARY和exponentiation机制。最后，2种情况均可将D用作free input。

建议：

  • 仅使用SHLarithBig：
    • 若D（shift amount）小于256，则返回0
    • 计算B=2**D
    • 使用ARITH，验证A*B=* 2**256+<result>是否成立。

相关PR见：

6.8 信息类风险8：同一文件内的测试索引号是随机的

上下文：

当单个Ethereum test文件内有多个测试时，gen-inputs.js 生成不同的具有<testFileName_index>样式的输入，其中index看起来是"随机"的。该index为Javascript引擎对object内部keys排序，见zkevm-testvectors:gen-inputs.js#L174。这样就难于找到所生成的input对应的原始test。

建议：

  • 根据原始测试文件中的key名称，来对所生成的test input文件命名，如sha3_dllg0v0_Berlin.json，而不是sha3_4.json。dll是指test filler文件transaction.data数组内的index。

Polygon-Hermez回复：

  • 将添加更好的文件命名，以易于表示为zkevm-rom生成的inputs。

6.9 信息类风险9：PaddingKK中重复constant多项式

上下文：

PaddingKK.crValid和PaddingKK.r8Valid具有相同的值。这不同于"Binary/MemAlign中的重复constant多项式"，因为这不是2个不相关状态机的偶然情况，而是在同一状态机内。2个多项式均在哈希相关状态机paper内被引用。

引入crValid：

  • 将可创建常量列crValid，当且仅当不在最后一个block时，其值为1

r8Valid：

  • 仅在lookup page 16中被提及。

建议：

  • 首先先区分这2个多项式是否应有相同的值：
    • 若是，则使用单个多项式，并据此更新paper
    • 若不是，则在paper内定义r8Valid，并修复相应的值

相关修复PR：

6.10 信息类风险10：当state root不匹配时，测试框架报OOC execution错误

上下文：

当运行evm_benchmarks中某些计算量重的测试用例时，观察到的结果输出是state root不匹配：

Input: 0xPolygonHermez2/zkevm-testvectors/tools/ethereum-tests/eth-inputs/GeneralStateTests/evm_benchma c
rks/JUMPDEST_n0.json↪→
Start executor JS...
Error
Error: Assert Error: newStateRoot does not match

但是启用tracer output显示实际的 execution error 为 OOCS (out of counters)：

{
tx_hash: '0xdb9be29bc49dd4615aae90d141869d51b320fb938e896bd3be9c240bd1fa18be',
rlp_tx: '0xf8638001843000000094be7c43a58000000000000000000000000000000180808207f3a0c77643128f488ea15b c
0d6ed338b8f99ad155a0f5a2eb8d5f3efc4c0ac1782a39a043f032bde2bd2b5fbdc154d32886bae6fd6664f↪→
f5f307d9adbf843b60dcd451f',
type: 0,
return_value: '',
gas_left: '29453541',
gas_used: '546459',
gas_refunded: '0',
error: 'OOCS',
create_address: '',
state_root: '0x786576b88c34f7812afdb7eb7a9a188948843e8361dd53deb376b895f21927aa',
logs: [],
call_trace: {
context: {
to: '0xbe7c43a580000000000000000000000000000001',
type: 'CALL',
data: '0x',
gas: '30000000',
value: '0',
batch: '0x00',
output: '',
gas_used: '546459',
execution_time: '',
old_state_root: '0x786576b88c34f7812afdb7eb7a9a188948843e8361dd53deb376b895f21927aa',
nonce: 0,
gasPrice: '1',
chainId: 1000,
from: '0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b',
return_value: ''
},
steps: [
...

建议：

  • 对于OOC情况，测试应不比对state roots，因执行已失败。输出错误应更好地反应实际原因。

相关修复PR：【更好的终端和详细输出】

6.11 信息类风险11：测试框架onboarding指南不清晰

上下文：

ethereum/tests测试套件的设置很容易出错，尤其是考虑到不清楚要使用哪些分支，以及最近对其中一些分支的更改会中断运行，否则直到最近才能正常运行。

updated readme 有帮助，至少在验证所运行的测试套件是否正确时，是有帮助的，虽然偶尔有错误的分支。

当前的setup总结为：

  • zkevm-testvectors：71926534（当前develop）
  • zkevm-rom: v0.5.2.0
  • zkevm-proverjs: 1252c73（在新的readme中说明）

主要障碍在于，zkevm-proverjs在其root目录下生成文件cache-main-pil.json。当切换该repo分支时，需手工删除该文件，或其有与新分支不兼容的风险。

但首次clone代码库时，不容易注意到该行为，但在现有setup中切换分支时，应说明该问题。

修复PR：

6.12 信息类风险12：opSDIV仅需调用binary状态机内的XOR一次而不是2次

上下文：

opSDIV可实现为对binary状态机更少的调用次数。

opSDIV调用abs来分别获取绝对值和符号位。若符号位相同，则使用绝对值的unsigned除法。若符号位不同，则取绝对值的unsigned除法的负值。

其使用XOR(XOR(sgnA, sgnB), 1)这种复杂的方式来计算"2个符号位是否不同"。实际上可使用EQ(sgnA, sgnB)来实现相同的效果。

或者有其它更简单的方式来计算，从而压根不需要调用binary状态机。

建议：

  • 将2次XOR调用，替换为1次EQ调用。

修复PR：

6.13 信息类风险13：opNOT的无效注释

上下文：

opNOT中注释说2226，实际应为2256

建议：

  • 将注释修改为2**256

修复PR：

6.14 信息类风险14：若某测试文件的input生产内存不足，则跳过该测试文件夹

上下文：

当测试执行结束出现如下错误：

./eth-tests-get-info.sh: line 36: let: err_gen_perc=(100*0+0/2)/0: division by 0 (error token is "0")
./eth-tests-get-info.sh: line 37: let: err_exec_perc=(100*0+0/2)/0: division by 0 (error token is "0")
./eth-tests-get-info.sh: line 38: let: ok_perc=(100*0+0/2)/0: division by 0 (error token is "0")

看起来似乎是某个input generatiosn内存不足。如下日志指出：

Test name: Return50000_2_0.json
WRITE: /0xPolygonHermez/zkevm-testvectors/tools/ethereum-tests/eth-inputs/GeneralStateTests/stQuadratic c
ComplexityTest/Return50000_2_0.json↪→
Test name: Return50000_2_1.json
Killed

最后，stQuadraticComplexity文件夹没有info.txt总结文件，且eth-tests-get-info.sh无法找到该test。

这可能会影响passed/failed/generation错误的统计分析。OOM错误掩埋在log中，当其实际被跳过时，很难注意到这些测试。

建议：

  • 考虑将文件夹内缺失info.txt文件，标记为test generation错误，这样便于注意。

Polygon-Hermez回复：

6.15 信息类风险15：未说明测试框架要求

上下文：

以eth-tests.sh脚本来运行ethereum tests，要求clone zkevm-rom库，并构建rom.json文件，当首次设置tests时，这些并不明确。同时，还需要zkevm-proverjs repo。

建议：

  • 修改文档，说明运行测试需复制zkevm-proverjs、zkevm-rom、npm install、npm run build，或在setup脚本中包含这些。

修复PR：

6.16 信息类风险16：若交易 gaslimit > 30M，则跳过或忽略该测试

上下文：

当gas limit超过30M时，则不做尝试，甚至其实际可能花费更少的gas。测试中的交易gas limit可为人一直，且并不代表其实际要花费的gas量。

建议：

  • 考虑修改测试执行工具，要么以更大的limit（如80M为一个常见的gas limit），或者尝试执行large limit test看其是否可行。可选择使用真实的limit来改进独立测试用例。

Polygon-Hermez回复：

  • Tests considered ignored regarding two topics has been addressed and are executed in the zkevm-rom to increase test coverage. Those tests are the following ones：
    • gasUsed > 30M gas
      • 最大gas limit可增加至2**32-1，因zkevm-rom可处理GAS寄存器。
      • 将检查测试大于2**32-1 gas Limit，以及在以太坊测试套件内交易生成定制filler modifying。
    • out of counters：
      • zero-knowledge资源被浪费了。因此，test无法在zkevm-rom内运行。
      • 添加不考虑zk资源的模式，然后test可在zkevm-rom内运行。

6.17 信息类风险17：Binary/MemAlign中的重复常量多项式

上下文：

Binary.P_A和MemAlign.BYTE2A是相同的，Binary.P_B和MemAlign.BYTE2B是相同的。

建议：

  • 通过将其提取到Global中，可节约2个常量多项式，并在Binary和MemAlign中使用相同的常量多项式。

修复：

6.18 信息类风险18：test生成器解析stEOF tests（以及其他过于嵌套路径）失败

上下文：

该框架循环从以太坊测试套件中读取各个目录树下的每个JSON tests，以生成eth-inputs。但是，其遍历代码默认最大深度为3，而新的stEOF/stEIP3540文件深度超过了3。

在提取test suit时，由于eth-test.sh不强化指定的commit hash，当首次尝试setup tests时，可创建随机的新的失败。

建议：

  • 强化明确所支持的以太坊测试套件版本，通过更新eth-tests.sh中的clone逻辑，或使用git submodule来表示该依赖。

相关PR：

6.19 信息类风险19：很多opcodes中不必要的stack overflow检查

上下文：

EVM中的很多指令不会引起stack overflow。zkEVM中的某些指令实现，具有不必要的stack overflow检查，如opNOT和opDUPx中的%CALLDATA_OFFSET - SP :JMPN(stackOverflow)。

建议：

  • 移除所列指令中的stack overflow检查

修复PR：

6.20 信息类风险20：应支持EIP-3541

上下文：

  • zkevm-rom

调用FirstByte的测试用例 被禁用，具体见develop分支中的execption列表和main分支中的execption列表。这些会检查新合约的创建code不能以0xEF字节开头。

缺少EIP-3541的支持可以理解，因zkEVM支持Berlin，且该修改是在London upgrade中引入。但是，这是一个future兼容性修改，可回滚多个网络，实际支持是有用的。

建议：

修复PR：

6.21 信息类风险21：package.json库中npm/yarn使用不兼容Semver版本

上下文：

无需手工干预的情况下，当前无法复制和安装zkevm-testvectors。如，checkout v0.4.0.0，和运行npm install 或 yarn install，有：

% yarn install
yarn install v1.22.11
warning package.json: License should be a valid SPDX license expression
warning package.json: "dependencies" has dependency "chai" with range "^4.3.6" that collides with a
dependency in "devDependencies" of the same name with version "^4.3.4"↪→
info No lockfile found.
warning @0xpolygonhermez/test-vectors@0.4.0.0: License should be a valid SPDX license expression
warning @0xpolygonhermez/test-vectors@0.4.0.0: "dependencies" has dependency "chai" with range "^4.3.6"
that collides with a dependency in "devDependencies" of the same name with version "^4.3.4"↪→
[1/4] Resolving packages...
error Can't add "@0xpolygonhermez/zkevm-commonjs": invalid package version "0.4.0.1".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

在zkevm-commonjs/package.json中引用了无效的package版本：

"version": "0.4.0.1",

该问题的原因在于，最新的npm/yarn期待version版本是Semver兼容的，相关问题见：Private github repository returns invalid package version #6195。

当前的解决方案是，创建所有依赖的赋值版本，并替换其版本号为仅包含3个点（如0.4.0、0.4.1、0.4.0-patch1）。此外，需同时在testvectors和修改后的commonjs中运行install命令。

注意：

  • 将该问题定性为低，是因为版本问题阻止了building，和某些npm/yarn版本使用zkevm。这不构成安全问题。

建议：

  • 使用Semver兼容版本

修复：

  • 在README.md中明确了版本和所用软件。

6.22 信息类风险22：PIL hello world multiplier不可编译

上下文：

以pilcom编译该文件返回错误，显然该约束degree太高（3）。

namespace Multiplier(%N);
pol constant SET;
pol commit freeIn;
pol commit out;
out' = SET*freeIn + (1 - SET)*(out * freeIn);

node src/pil.js multiplier.pil
Error: ERROR multiplier.pil:undefined: Degre too high

建议：

  • 要么引入中间多项式，要么修改该例子为adder：

    namespace Adder(%N);
    pol constant SET;
    pol commit freeIn;
    pol commit out;
    out' = SETfreeIn + (1 - SET)(out + freeIn);

附录：Polygon Hermez 2.0 zkEVM系列博客

热门推荐
01Docker 夺命连环 15 问02PyTorch机器学习实现液态神经网络03【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总04【音视频 | opus】opus编解码库(opus-1.4)详细介绍以及使用——附带解码示例代码05Coze扣子平台完整体验和实践（附国内和国际版对比）06(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明07〔AI 绘画〕Stable Diffusion 之 解决绘制多人或面部很小的人物时面部崩坏问题 篇08玄机平台应急响应—webshell查杀09RAG 实践- Ollama+RagFlow 部署本地知识库10ICLR24大模型提示(1/11) | BadChain：大型语言模型的后门思维链提示