Polygon zkEVM Spearbit审计报告解读(2022年12月版本)

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系列博客