Polygon zkEVM Spearbit审计报告解读（2023年1月版本）

1. 引言

前序博客：

主要见：

Polygon zkEVM Security Review: January 2023 Engagement

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

本轮审计重点关注：

1）对（PIL）状态机持续的手工和工具辅助review。
2）（跨越边界）理解并分析zkASM<>PIL结合。
3）对constant多项式的构建进行初步review。
4）Ethereum state tests除外状态的review，并验证除外原因。
5）持续对EVM指令的zkASM实现进行手工review。

Spearbit研究人员分为2组：

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

本轮审计历时11天，共发现30个漏洞，其中致命漏洞3个，不兼容漏洞4个，低危漏洞2个，信息提示类21个，当前已解决其中26个问题。
在这里插入图片描述

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

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

其中：

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

1.1 测试

本轮review重点关注：

zkevm-testvectors#v0.6.0.0-rc.1。

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

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

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

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

1.2 zkASM

本轮review重点关注：

zkevm-rom#audit.1

该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重点关注：

zkevm-proverjs#audit.1

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

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

2. 致命漏洞

2.1 致命漏洞1：当receiver和sender相同时，SENDALL会对余额清零

上下文见：

zkevm-rom:create-terminate-context.zkasm#L1040

SENDALL指令实现会更新receiver余额，然后将sender余额清零，而并不检查receiver和sender是否为同一地址。运行SENDALL时若receiver与所执行合约相同，则最终余额为0。

需注意，见后面的“SENDALL在Ethereum state tests中未测试”漏洞，即当前Ethereum state tests中并未覆盖SENDALL测试。为确认，需要一些修改来运行EIP4758 test cases #1024：

测试框架中zkevm-testvectors:gen-inputs.js#L406处的跳过SELFDESTRUCT测试，应禁用。
修改go-ethereum来激活Berlin中的SENDALL。
修复go-ethereum实现中的gas charge bug EIP-4758 Implementation #24389，修改后的内部版本见：https://github.com/spearbit-audits/go-ethereum/tree/sendall-berlin。
修改运行在Berlin上的测试用例，修改后的内部版本见：https://github.com/spearbit-audits/ethereum-state-tests/tree/eip4758-berlin。

sendallBasic通过而sendallToSelf失败：

Test name: sendallToSelf.json
AssertionError: expected '0' to equal '1000000000000000000'
at Context.<anonymous>
(/0xPolygonHermez/zkevm-testvectors/tools/ethereum-tests/gen-inputs.js:452:92)↪→
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
showDiff: true,
actual: '0',
expected: '1000000000000000000',
operator: 'strictEqual'
}

当SELFDESTRUCT用该边界情况来“burning” Ether时，根据测试结果来看，SENDALL提案看起来似乎并不想要该边界情况。

建议：

当receiver与executing合约相同时，不更新余额。

修复PR见：

Feature/fix sendall #236
add test SENDALL #172：每次ROM更新时，提供自动运行测试用例。
ethereumjs-monorepo: handle sendall to itself. increase package version，以合理处理sendall。

2.2 致命漏洞2：opCALLDATALOAD/opCALLDATACOPY读取calldata位置越界

上下文见：

检查输入calldata offset是否在calldata边界内，使用的是：
txCalldataLen < offset。

当offset == txCalldataLen时，其会加载对应calldata[txCalldataLen]位置地址的memory word——即在地址 1024 + txCalldataLen / 32 位置的memory word。

建议：

使用offset < txCalldataLen。从而排除offset == txCalldataLen边界情况。

修复PR见：

Optimize opPush and SHL #242

2.3 致命漏洞3：opJUMP/opJUMPI读取位置超过代码边界

上下文见：

zkevm-rom:flow-control.zkasm#L5

检查jump目标在代码边界内使用的是：
bytecodeLength < jumpDst

当dst == bytecodeLength时，仍会读取code[bytecodeLength]位置处的bytecode。

建议：

改为检查 dst < bytecodeLength，然后JUMPNC(invalidJump)。

修复PR见：

Audit jan fixes #226

3. 不兼容漏洞

3.1 不兼容漏洞1：缺乏对特定预编译支持，可能引起可用性和安全风险

上下文见：

selector.zkasm

Berlin协议支持9个预编译合约：

ecrecover
sha256
ripemd160
identity
modexp
ecadd
ecmul
ecpairing
blake2f

而zkEVM仅实现了其中的2个预编译合约：ecrecover和identity。
未支持的预编译合约中：

ripemd160和blake2f很少用到
modexp常用于RSA验证场景，但也用于通用bignumber库中。
ecadd/ecmul/ecpairing常用于各种ZK应用，如bridge、私人交易和游戏应用。

RSA的一个主要用例为：

ENS的dnssec-oracl：用于验证DNSSEC enabled domains（如.xyz、.tech等等）的所有权。
VDF验证。如https://github.com/kilic/evmvdf和https://github.com/0xProject/VDF。

缺乏这些主要表现在2方面：

1）可用性问题：特定项目将无法在zkEVM上部署，可能会影响大范围使用和跨链兼容性。
2）安全性问题：可能有的项目可部署，但特定特性可能会被破坏。可能会对在合约内锁定有资产的项目有影响。

建议：

注意到文档中的差异。考虑实现sha256、modexp和bn256预编译文件。

Polygon Hermez回复：

出于安全考虑，将revert任意对未支持预编译合约的调用，具体实现见：
- selector.zkasm#L16
- revert-precompiled.zkasm

3.2 不兼容漏洞2：BASEFEE指令返回固定0值

上下文件：

block.zkasm#L180

BASEFEE指令不包含在Berlin中（见Berlin Network Upgrade Specification），而是作为London（见London Network Upgrade Specification）中EIP-1559的内容首次展示。对BASEFEE并未定义明确的值范围，也未以任何形式提及BASEFEE值为0。

关注点1：

EIP-1559: Fee market change for ETH 1.0 chain 在区块头中定义了base_fee_per_gas，该值需遵循如下规则：

INITIAL_BASE_FEE = 1000000000
BASE_FEE_MAX_CHANGE_DENOMINATOR = 8
ELASTICITY_MULTIPLIER = 2
...
parent_gas_target = self.parent(block).gas_limit // ELASTICITY_MULTIPLIER
parent_gas_limit = self.parent(block).gas_limit
# on the fork block, don't account for the ELASTICITY_MULTIPLIER to avoid
# unduly halving the gas target.
if INITIAL_FORK_BLOCK_NUMBER == block.number:
parent_gas_target = self.parent(block).gas_limit
parent_gas_limit = self.parent(block).gas_limit * ELASTICITY_MULTIPLIER
parent_base_fee_per_gas = self.parent(block).base_fee_per_gas
parent_gas_used = self.parent(block).gas_used
...
# check if the base fee is correct
if INITIAL_FORK_BLOCK_NUMBER == block.number:
expected_base_fee_per_gas = INITIAL_BASE_FEE
elif parent_gas_used == parent_gas_target:
expected_base_fee_per_gas = parent_base_fee_per_gas
elif parent_gas_used > parent_gas_target:
gas_used_delta = parent_gas_used - parent_gas_target
base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_gas_target //
BASE_FEE_MAX_CHANGE_DENOMINATOR, 1)↪→
expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta
else:
gas_used_delta = parent_gas_target - parent_gas_used
base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_gas_target //
BASE_FEE_MAX_CHANGE_DENOMINATOR↪→
expected_base_fee_per_gas = parent_base_fee_per_gas - base_fee_per_gas_delta
assert expected_base_fee_per_gas == block.base_fee_per_gas, 'invalid block: base fee not correct'

通常（在生态测试和工具中），使用的最低值为7 wei。
对于以太坊主网，basefee的最低可能值为7wei。但其也依赖于fork block的初始值（INITIAL_BASE_FEE）。
证据如下。定义如下变量：

1） $b_n$ 表示block $n$ 的base-fee
2） $g_n$ 表示block $n$ 使用的总gas
3） $t_n$ 表示block $n$ 的target gas

为简化，假设block 0为EIP-1559 Hardfork block，其中 $b_0=10$ gwei。根据block $n$ ， block $n + 1$ 的basefee定义为：
在这里插入图片描述

即使basefee为固定0值，basefee为7 wei是一个好的默认值，zkEVM总是可定义EIP-1559的fork block，并设置 $b_{fork-block}$ 为大于7 wei的常量值，以快速启动合适的EIP-1559机制。
需注意的是：

一旦basefee至少为7 wei时，其永远不能低于7 wei。若交易处理遵循EIP-1559，则7个区块后 $b_n>t_n$ ，则basefee将达7 wei。
EIP-1559的一个有趣结果是，其阻止交易gasprice为0。可能值得关注下，何时sequencer会打包gasprice为0的交易。
若basefee为固定0值，则当 $b_n>t_n$ 时（即，若区块内使用的gas超过了区块gas limit的一半），EIP-1559机制将不一致。

关注点2：

Ethereum Test Suite中未包含任何currentBaseFee为0的测试用例，且与其它部分的交互也未覆盖。

关注点3：

EIP-3198: BASEFEE opcode 介绍了该指令的一些动机：
- gas futures可基于BASEFEE来实现，其将比gastokens更精确。
- 可改建state channels、plasma、optirolls以及其他欺诈证明驱动的解决方案。输入中有BASEFEE，当BASEFEE是高的，可自动延长挑战周期。
这两种情况都不支持常量0值，否则zkEVM上的类似项目将失败或锁定。

关注点4：

最近，某些工具（如hardhat: BASEFEE always returns 0 when running an eth_call with a London block #1688）正面临gas estimation子系统返回0值的问题，引起测试或部署代码失败。

建议：

文档说明Mainnet/Berlin差异，考虑非零值，或移除该指令。

Polygon Hermez回复：

基于以下2个主要原因，决定从当前zkEVM版本中移除BASEFEE opcode：
- 1）安全考虑：BASEFEE opcode并未在Berlin hardfork中实现。将实现BASEFEE opcode的合约，但由于其是硬编码的，可能会有意外情况。这回降低使用BASEFEE opcode合约的安全性。
- 2）一致性：添加或移除BASEFEE opcode并不影响zkEVM性能。由于已实现了Berlin hardfork，但未包含EIP-1559，这并无任何优势，但可能会给支持该opcode的会议带来安全问题。

3.3 不兼容漏洞3：SENDALL在Ethereum state tests中未测试

上下文见：

zkevm-rom:create-terminate-context.zkasm#L979

Ethereum state tests中并未覆盖SENDALL指令，因SENDALL指令正在开发中EIP-4758: Deactivate SELFDESTRUCT。EIP4758 test cases #1024，2022年就有相关PR，但其与EIP的一致性尚不清楚。
关联问题为：“使用SENDALL来替换SELFDESTRUCT”。

建议：

实现覆盖SENDALL的测试用例

Polygon Hermez回复：

知悉。

3.4 不兼容漏洞4：使用SENDALL来替换SELFDESTRUCT

上下文见：

zkevm-rom:create-terminate-context.zkasm#L979

SELFDESTRUCT与Berlin说明不一致。其被替换为EIP-4758: Deactivate SELFDESTRUCT
Deactivate SELFDESTRUCT by changing it to SENDALL, which does recover all funds to the caller but does not delete any code or storage，而整个账号余额仍需transfer，但该账号不被移除。此外，移除了gas refund。该EIP不清楚是否继续执行。

这有显著不同，合约开发者需留意。

同时，需注意，尽管已有相关讨论，但如何实现暂无共识。

建议：

文档说明Mainnet/Berlin差异。

Polygon Hermez回复：

当前实现会像SELFDESTRUCT那样停止。已注意到EIP-4758: Deactivate SELFDESTRUCT
Deactivate SELFDESTRUCT by changing it to SENDALL, which does recover all funds to the caller but does not delete any code or storage中并未说明。决定遵循SELFDESTRUCT，终止交易执行。
终止执行行为、移除SELFDESTRUCT和SENDALL指令，将在文档中详细说明。

4. 低危漏洞

4.1 低危漏洞1：

上下文见：

zkevm-proverjs:padding_pg.pil

padding_kk状态机，将blocks以136行来表示。由于136不能整除 $N$ ，在table底部会有不完整block。padding_kk状态机不支持方位最后的block，以“avoid problems”。

类似的，padding_gg状态机，将blocks以56行来表示。由于56也不能整除 $N$ ，在table底部也会有不完整block。但padding_gg状态机似乎并不是不支持方位最后的block，来“avoid problems”。

建议：

经分析，未发现具体的可利用案例。但是，出于安全考虑，建议像padding_kk状态机那样，也禁止padding_gg状态机访问最后的block。

修复PR见：

fix/padding pg crvalid #127

4.2 低危漏洞2：PC应约束为初始化为0值

上下文见：

zkevm-proverjs:main.pil

（主状态机和storage状态机内的）PC值，均只通过plookup和编码control-flow的约束来约束。并无约束来强化程序从entry point开始。

建议：

目前并不清楚该问题的影响。但建议约束Main.zkPC和Storage.pc初始化为0值：Global.L1 * Main.zkPC = 0, Global.L1 * Storage.pc = 0。

修复PR见：

add pil pc zero constraints, remove duplicated column on Rom plookup #121

5. 信息类提示

5.1 信息类提示1：croffset应唯一确定crF_i寄存器

上下文：

zkevm-rom:padding_kk.pil#L113-L116

croffset和crF_i寄存器由plookup约束。但是，在文档Table7中的描述是不正确的。croffset应唯一确定crF_i寄存器。当crLatch为1和crOffset为0时，crF_i寄存器中的值均不同。

对于plookup argument，当crOffset == 0和crF_0 == 1时，剩余的crF_i寄存器值应为0，这也与PIL中的一样。

建议：

更新文档。

Polygon Hermez回复：

已修改更新文档。offset递减和factors应逆序表示。

5.2 信息类提示2：mem_align.pil中的resultRd可能约束不够

上下文：

zkevm-proverjs:mem_align.pil#L95

当RESET为0时，3个多项式 resultWr8、resultWr256 和 resultRd 均约束为0。当wr8和wr256为0时， resultWr8 和 resultWr256 也分别被约束为0。同理对 resultRd 可能应有相同的逻辑，当wr8为1或wr256为1时，应约束resultRd为0。

建议：

添加约束 (wr8 + wr256) * resultRd = 0

Polygon Hermez回复：

从可靠性来说，无需添加这种明确的约束。因为其已通过permutation checks来保证了该约束。不过为改进代码清晰度，添加了约束 (wr8 + wr256) * resultRd = 0：
- fix/mem align audit #129

5.3 信息类提示3：mem_align.pil中多余约束

上下文：

zkevm-proverjs:mem_align.pil#L104

wr8 * wr256 = 0; 约束是多余的，因第111行代码显示 wr8’ 和 wr256’ 源自同一plookup，且相应的常量WR256和WR8可确保二者特定时期只有一个为1。

建议：

移除该约束。

修复PR：

fix/mem align audit #129

5.4 信息类提示4：Binary.lCout是多余的

上下文：

zkevm-proverjs:binary.pil#L83

binary.pil中有：

lCout' = cOut;

main.pil中有：

bin {
	binOpcode,
	A0, A1, A2, A3, A4, A5, A6, A7,
	B0, B1, B2, B3, B4, B5, B6, B7,
	op0, op1, op2, op3, op4, op5, op6, op7,
	carry
} is
Binary.resultBinOp {
	Binary.lOpcode,
	Binary.a[0], Binary.a[1], Binary.a[2], Binary.a[3], Binary.a[4], Binary.a[5], Binary.a[6], Binary.a[7],
	Binary.b[0], Binary.b[1], Binary.b[2], Binary.b[3], Binary.b[4], Binary.b[5], Binary.b[6], Binary.b[7],
	Binary.c[0], Binary.c[1], Binary.c[2], Binary.c[3], Binary.c[4], Binary.c[5], Binary.c[6], Binary.c[7],
	Binary.lCout
};

可等价为，移除lCout并修改permutation check为：

bin' {
	binOpcode',
	A0', A1', A2', A3', A4', A5', A6', A7',
	B0‘, B1‘, B2', B3', B4', B5', B6', B7',
	op0', op1', op2', op3', op4', op5', op6', op7',
	carry'
} is
Binary.resultBinOp' {
	Binary.lOpcode',
	Binary.a[0]', Binary.a[1], Binary.a[2]', Binary.a[3]', Binary.a[4]', Binary.a[5]', Binary.a[6]', Binary.a[7]',
	Binary.b[0]', Binary.b[1]', Binary.b[2]', Binary.b[3]', Binary.b[4]', Binary.b[5]', Binary.b[6]', Binary.b[7]',
	Binary.c[0]', Binary.c[1]', Binary.c[2]', Binary.c[3]', Binary.c[4]', Binary.c[5]', Binary.c[6]', Binary.c[7]',
	Binary.cOut
}

建议：

从代码清晰的角度来说，无需做相应修改。

Polygon Hermez回复：

认可，不做修改。

5.5 信息类提示5：ModExp预编译合约已禁用，但源码仍在

上下文见：

ModExp预编译合约当前仅部分实现，其中包含了TODOS，看起来是不完整的。当前所review的tag中，已在selectorPrecompiled jump-table中将其禁用。

建议：

移除不完成的源码，避免混淆。

修复PR：

Boundaries check fixes #228

5.6 信息类提示6：testing报告

总结当前试图运行的ethereum state test 格式的所有测试用例。

Ethereum State Tests：

启用了一些当前在Polygon zkEVM test suite中禁用的状态测试。为启用，要么需降低交易gas limit，使其小于30M gas，要么需启用测试中的Berlin hard fork。
- 完整“Ethereum Tests”报告见：zkEVM Testing Report
- 所有测试修改见内部库：https://github.com/spearbit-audits/ethereum-state-tests/tree/reduce-gas-limit

ECRecover tests：

某些ECRecover预编译合约测试用例未针对Berlin fork运行。启用所有丢失的测试用例后，均测试通过。
- 完整“ECRecover tests”报告见：zkEVM Testing Report
- 修改项见内部库：https://github.com/spearbit-audits/ethereum-state-tests/tree/ecrecover-all-forks

evm-benchmarks：

lpsilon的EVM benchmark suite 已是Ethereum State test格式。需以Blockchain test format生成，并启用Berlin fork来测试zkEVM。
大多数benchmarks都有正确结果。一些有OOC错误或在测试机上提示内存不足。
- 完整“evm-benchmarks”报告见：zkEVM Testing Report
- 完整日志见：evm-benchmarks-logs.tar.xz
- 所生成的blockchain tests和filters见内部库：https://github.com/ipsilon/evm-benchmarks/tree/blockchain_tests

New arithmetic test：

源自Tests for arithmetic opcodes #1144，修改为Berlin hardfork之后，测试通过。
- 相应修改见内部库：https://github.com/spearbit-audits/ethereum-state-tests/tree/20230114-arith-tests-berlin

5.7 信息类提示7：mem_align常量定义的注释不正确

上下文：

FACTOR常量被描述为具有64行周期，后32行为0。但在executor中，后32行为0是不存在的，FACTOR简单做常规对角移动，每32行重复一次。

建议：

若constant生成是正确的，则应修改mem_align.pil中的注释

修复PR：

fix factor constant comment on mem_align.pil #124

5.8 信息类提示8：可内联一些中间多项式

上下文：

zkevm-proverjs:pil

一组中间变量是线性的。基于静态分析：

pol Arith.eq0_31 = Arith.y2[15]
pol Arith.eq1_31 = -262140
pol Arith.eq2_31 = -262140
pol Arith.eq3_31 = -262140
pol Arith.eq4_31 = -262140
pol Binary.RESET = (Global.CLK32[0] + Global.CLK32[16])
pol Mem.INCS = (Global.STEP + 1)
pol Mem.ISNOTLAST = (1 - Global.LLAST)
pol MemAlign.RESET = Global.CLK32[0]
pol PoseidonG.a0 = (PoseidonG.in0 + PoseidonG.C[0])
pol PoseidonG.a1 = (PoseidonG.in1 + PoseidonG.C[1])
pol PoseidonG.a10 = (PoseidonG.cap2 + PoseidonG.C[10])
pol PoseidonG.a11 = (PoseidonG.cap3 + PoseidonG.C[11])
pol PoseidonG.a2 = (PoseidonG.in2 + PoseidonG.C[2])
pol PoseidonG.a3 = (PoseidonG.in3 + PoseidonG.C[3])
pol PoseidonG.a4 = (PoseidonG.in4 + PoseidonG.C[4])
pol PoseidonG.a5 = (PoseidonG.in5 + PoseidonG.C[5])
pol PoseidonG.a6 = (PoseidonG.in6 + PoseidonG.C[6])
pol PoseidonG.a7 = (PoseidonG.in7 + PoseidonG.C[7])
pol PoseidonG.a8 = (PoseidonG.hashType + PoseidonG.C[8])
pol PoseidonG.a9 = (PoseidonG.cap1 + PoseidonG.C[9])

建议：

引入一种方式将它们定义为aliases，或在PIL编译时内联它们。

5.9 信息类提示9：应改进语言和工具

上下文：

到处

与zkEVM的一个方面有关的信息/代码通常分布在多个文件中，这使得审查代码变得非常困难。还有其他基于语言的功能可以提供帮助，例如，常量定义可以直接成为PIL文件的一部分，多项式可以被键入（代码历史表明，这可能在过去部分实现）。

执行语义和验证语义可以同时存在。目前，执行者以与通过PIL文件中的约束验证多项式的方式非常相似的方式填充所承诺的多项式。

建议：

这是一个信息性的建议，因为在发布之前考虑和完成这样的重大更改是不现实的。

Polygon Hermez回复：

与多项式类型相关，移除是因为多项式内部是有限域（goldilocks）。要定义一种特定类型或范围，必须定义特定约束或plookup。

5.10 信息类提示10：移除padding_kk中的firstHash

上下文：

zkevm-proverjs:padding_kk.pil#L38

中间多项式firstHash使用承诺多项式lastHash来表示。
firstHash仅在如下场景中使用：

pol commit firstHash;
firstHash' = lastHash;
[...]
len * firstHash = rem * firstHash;

其等价为：

len' * lastHash = rem' * lastHash;

建议：

当前的实现通过引入firstHash，会更清晰一点。但是，可令fristHash为alias lastHash’，具有相同的清晰度，且不用额外引入一个中间多项式。可在PIL中拥有alias syntax，或使用内联中间多项式来优化。总之，二者等价。

修复PR：

first hash optimization #123：移除firstHash，并修改为len’ * lastHash = rem’ * lastHash;。

5.11 信息类提示11：优化opAuxPUSHB

上下文：

zkevm-rom:stack-operations.zkasm#L169

可将2个步骤，合并为一个：【其它地方也有类似代码】

$ => A :MLOAD(isCreate)
0 - A :JMPN(opAuxPUSHBcreate)
; set bytes length to read to C
D - 1 => C
0 => A

合并为：

$ => A :MLOAD(isCreate), JMPNZ(opAuxPUSHBcreate)
; set bytes length to read to C
D - 1 => C

建议：

考虑如上优化

修复PR:

Boundaries check fixes #228

5.12 信息类提示12：Memory expansion gas check 被切分为2个检查

上下文：

zkevm-rom:utils.zkasm#L451

第一个out-of-gas check为：
GAS + 3 * old_size + old_size * old_size / 512 < 3 * new_size => GAS < 3 * new_size - 3*old_size - old_size * old_size / 512
第二个check为：
GAS + 3 * old_size + old_size * old_size / 512 - 3 * new_size < new_size *
new_size / 512 => GAS < 3 * new_size + new_size * new_size / 512 - 3 * old_size - old_size *
old_size / 512

建议：

尽管结果正确，但仅需要第二个check就够了。

修复PR：

Fix computeGasSendCall #221：重构了saveMem函数。

5.13 信息类提示13：当前内存size存储为最后一次请求最大size，而未取整为32的倍数

上下文：

zkevm-rom:utils.zkasm#L440

memLength变量中存储了expansion时所需的准确size，未被取整为word size的倍数。若在当前醉倒word中访问更高的地址，其仍可计算memory expansion cost（结果为0，因words数未变）。同时MSIZE实现需根据memLength来取整为word size。

建议：

可能的优化为：在memLength中存储已取整为word size倍数的size（即存储的即为MSIZE将返回的值）。然后memory expansion将直接与MSIZE对比该exact requested size，并仅当分配的words数增加时，才计算expansion cost。
换句话说，可认为memory expansion总是以32的倍数扩大，而不是所请求的exact size。

修复PR：

Feature/memalign optimization #238

5.14 信息类提示14：JMP to a helper used instead of CALL

上下文：

建议：

将很多类似zkPC+1 => RR :JMP(helper)，改为 CALL(helper)。

修复PR：

Audit jan fixes #226

5.15 信息类提示15：MSTORE潜在优化

上下文：

zkevm-rom:utils.zkasm#L220

MSTOREX2使用SHLArith和SHRArith组合来存储在2个相邻的memory slots。
建议：

像memAlignOptionMSTORE那样，使用MEM_ALIGN_WR来优化。

Polygon zkEVM回复：

未来将考虑做类似优化。

5.16 信息类提示16：lookup argument中的重复key value

上下文：

zkevm-proverjs:main.pil#L526

inHASHPOS列在lookup argument中出现了2次，相关联的目标列Rom.inHASHPOS也在value中出现了2次：

(x in y) => ({x, x} in {y, y})

建议：

移除重复的列。

修复PR：

add pil pc zero constraints, remove duplicated column on Rom plookup #121

5.17 信息类提示17：MSTORE32中存储了没必要的寄存器值

上下文：

zkevm-rom:utils.zkasm#L182

MSTORE32无需存储寄存器E之前值，因其用作输入、输出寄存器。

建议：

移除E :MSTORE(tmpVarE)

修复PR：

Audit jan fixes #226
update tmpvars & expAD counters #212，改进了utils函数中的tmpVars处理。

5.18 信息类提示18：可优化Jump目标有效性检查

上下文：

zkevm-rom:flow-control.zkasm#L91

initcode中jump目标有效性检查包括：

用MLOADX加载1个字节
使用SHRarith右移32个字节
将其与0x5b进行比对。

建议：

潜在的优化为，可跳过右移，直接与32字节0x5b00…00进行比较。这样就不会在SHARarith上浪费算术计数器。

修复PR：

Audit jan fixes #226

5.19 信息类提示19：@zk-counters注释与代码不符

上下文见：

注释中提及的counter数，与实际代码中的检查不一致。

建议：

要么更新代码，要么更新注释。

Polygon zkEVM回复：

关于zk-counters的注释更新见：Feature/counters and comments #227
Feature/counter tests #223：构建了特定的工具，来自动检查每个函数的zk-counters变化，因此若有代码改变引起counters增减，都能自动发现。

5.20 信息类提示20：main_executor.js中的typo

上下文：

zkevm-proverjs:main_executor.js#L60

建议：

permited，应修改为，permitted

修复PR：

minor audit fixes #119

5.21 信息类提示21：padding_kkbit.pil和sm-hash论文中的typo

上下文：

zkevm-proverjs:padding_kkbit.pil#L21

建议：

应为9*136 = 1224，同理sm-hash论文中也应修改。

修复PR：

minor audit fixes #119