1. 引言
前序博客:
- Polygon zkEVM Hexens审计报告解读(2022年12月至2023年2月版本)
主要见:
Polygon zkEVM为提供(opcode层面兼容的)EVM等价zk-rollup,具有良好的用户体验并兼容现有以太坊生态和工具。
主要关注:
- 1)检查Ethereum state tests和evm-benchmarks测试覆盖率。
- 2)手工和工具辅助review一些(PIL)状态机。为辅助审计,开发了PIL状态机的形式化分析工具:
- 3)手工review EVM指令的zkASM实现。
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
具体上下文见:
- zkevm-rom:calldata-returndata-code.zkasm#L73
- zkevm-rom:calldata-returndata-code.zkasm#L225
- zkevm-rom:calldata-returndata-code.zkasm#L329
- zkevm-rom:utils.zkasm#L395
- 等等
这些均会影响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见:
- fixes opSAR, opBYTE & remove check poseidon counters #211
- add test comparison: byte & sar #165 为针对性的测试用例
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见:
- fixes opSAR, opBYTE & remove check poseidon counters #211
- update tmpvars & expAD counters #212 改进了zk-counters check。
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见:
- fixes opSAR, opBYTE & remove check poseidon counters #211
- add test comparison: byte & sar #165 为针对性的测试用例
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值
上下文见:
cIn' * ( 1 - RESET' ) = cOut * ( 1 - RESET' );
当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,与以太坊主网背离
上下文见:
; check if is a jumpDest (0x5B)
0x5B => B
$ :EQ, JMPC(readCode, invalidJump)
其仅检查目标是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检查】
- Feature/counter tests #223 改进了zk-counters处理。
- Feature/counters and comments #227 添加了一个安全的zk-counter band,以避免不受控的out-of-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:
- update README, add test gasPrice*gasLimit #161,改进了README.md来解释每个脚本的目的,并可运行单个测试。
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:
- reduce duplicated constant pols #107,仅使用单个多项式r8Valid,并更新了相关文档。
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回复:
- 某些测试需要高端指定硬件来运行。具体为,Return50000_2_0.json文件被标记为忽略,因其在大型机器上运行后会触发zkevm-rom out-of-counters。当前,将所有会触发out-of-counters错误的测试,都已知,不做zk-counters限制而passed。
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内运行。
- gasUsed > 30M gas
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:
- fix ethereum/tests version & update package.json and no-exec #164,冻结了以太坊测试套件的某commit
- update README, add test gasPrice*gasLimit #161,改进了tests解析。
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兼容性修改,可回滚多个网络,实际支持是有用的。
建议:
- 支持EIP-3541
修复PR:
- comments & eip-3541 #210,添加了EIP-3541
- add test eip-3541 #163,添加了定制测试
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' = SET*freeIn + (1 - SET)*(out + freeIn);
附录:Polygon Hermez 2.0 zkEVM系列博客
- ZK-Rollups工作原理
- Polygon zkEVM——Hermez 2.0简介
- Polygon zkEVM网络节点
- Polygon zkEVM 基本概念
- Polygon zkEVM Prover
- Polygon zkEVM工具——PIL和CIRCOM
- Polygon zkEVM节点代码解析
- Polygon zkEVM的pil-stark Fibonacci状态机初体验
- Polygon zkEVM的pil-stark Fibonacci状态机代码解析
- Polygon zkEVM PIL编译器——pilcom 代码解析
- Polygon zkEVM Arithmetic状态机
- Polygon zkEVM中的常量多项式
- Polygon zkEVM Binary状态机
- Polygon zkEVM Memory状态机
- Polygon zkEVM Memory Align状态机
- Polygon zkEVM zkASM编译器——zkasmcom
- Polygon zkEVM哈希状态机——Keccak-256和Poseidon
- Polygon zkEVM zkASM语法
- Polygon zkEVM可验证计算简单状态机示例
- Polygon zkEVM zkASM 与 以太坊虚拟机opcode 对应集合
- Polygon zkEVM zkROM代码解析(1)
- Polygon zkEVM zkASM中的函数集合
- Polygon zkEVM zkROM代码解析(2)
- Polygon zkEVM zkROM代码解析(3)
- Polygon zkEVM公式梳理
- Polygon zkEVM中的Merkle tree
- Polygon zkEVM中Goldilocks域元素circom约束
- Polygon zkEVM Merkle tree的circom约束
- Polygon zkEVM FFT和多项式evaluate计算的circom约束
- Polygon zkEVM R1CS与Plonk电路转换
- Polygon zkEVM中的子约束系统
- Polygon zkEVM交易解析
- Polygon zkEVM 审计及递归证明
- Polygon zkEVM发布公开测试网2.0
- Polygon zkEVM测试集——创建合约交易
- Polygon zkEVM中的Recursive STARKs
- Polygon zkEVM的gas定价
- Polygon zkEVM zkProver基本设计原则 以及 Storage状态机
- Polygon zkEVM bridge技术文档
- Polygon zkEVM Trustless L2 State Management 技术文档
- Polygon zkEVM中的自定义errors
- Polygon zkEVM RPC服务
- Polygon zkEVM Prover的 RPC功能
- Polygon zkEVM PIL技术文档
- Polygon zkEVM递归证明技术文档(1)【主要描述了相关工具 和 证明的组合、递归以及聚合】
- Polygon zkEVM递归证明技术文档(2)—— Polygon zkEVM架构设计
- Polygon zkEVM递归证明技术文档(3)——代码编译及运行
- Polygon zkEVM递归证明技术文档(4)—— C12 PIL Description
- Polygon zkEVM递归证明技术文档(5)——附录:借助SNARKjs和PIL-STARK实现proof composition
- eSTARK:Polygon zkEVM的扩展STARK协议——支持lookup、permutation、copy等arguments(1)
- eSTARK:Polygon zkEVM的扩展STARK协议——支持lookup、permutation、copy等arguments(2)
- eSTARK:Polygon zkEVM的扩展STARK协议——支持lookup、permutation、copy等arguments(3)
- Polygon zkEVM的Dragon Fruit和Inca Berry升级
- Polygon zkEVM协议治理、升级及其流程
- Polygon zkEVM 节点软件release日志
- Polygon zkEVM bridge服务 release日志
- Polygon zkEVM DataStreamer
- Polygon zkEVM Goldilocks域各项运算性能
- Polygon zkEVM Hexens审计报告解读