Polygon zkEVM ROM Spearbit审计报告解读（2023年6月Dragon Fruit升级版本）

news2024/11/25 13:48:59

1. 引言

前序博客有：

Polygon zkEVM Hexens审计报告解读
Polygon zkEVM Spearbit审计报告解读（2022年12月版本）
Polygon zkEVM Spearbit审计报告解读（2023年1月版本）
Polygon zkEVM Spearbit审计报告解读（2023年3月版本）
Polygon zkEVM的Dragon Fruit和Inca Berry升级

Dragon Fruit升级点有：

改进了网络
支持了最新的以太坊opcode——PUSH0

Dragon Fruit，又名ForkID5，包含了2个新特性：

1）PUSH0：最新的以太坊opcode，PUSH0已包含在以太坊Shanghai硬分叉中。一旦Dragon Fruit升级完成，Polygon zkEVM Mainnet Beta与最新版本的Solidity一致，以维护rollup的EVM等价性。更多PUSH0知识，见EIP-3855。
2）RLP解析：修复了交易解析的一个非致命错误。

主要见：

Polygon zkEVM Security Review: zkEVM ROM June Upgrade features review

本轮审计重点关注zkevm-rom的fix-RLP-push0 feature：

https://github.com/0xPolygonHermez/zkevm-rom/tree/feature/fix-RLP-push0

本轮审计历时16天。共发现8个漏洞，其中高危漏洞2个，低危漏洞1个，信息提示类5个。
在这里插入图片描述
在本审计报告中，风险分级为：

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

其中：

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

2. 高危漏洞

2.1 高危漏洞1：PUSH0中缺少ZK counters检查

上下文见：

zkevm-rom:stack-operations.zkasm#L11

PUSH0中未更新ZK couners。
建议：

像其它PUSH指令一样，检查out of counters。

修复PR见：

Effective gas implementation #290

2.2 高危漏洞2：对有效gas计算，缺少arith ZK counters检查

上下文见：

zkevm-rom: process-tx.zkasm#L88

_effGasPriceShifted会占用arith ZK counters，因其2次使用了ARITH。

建议：

添加arith counters检查。

修复PR见：

Effective gas implementation #290

3. 低危漏洞

3.1 低危漏洞1：对PUSH0缺少文档注释

上下文见：

zkevm-rom: stack-operations.zkasm#L1-L9

opPUSH0上的注释，仅适于opPUSH1及其它。

建议：

将opPUSH0实现移至现有注释之上，并添加PUSH0注释。

修复PR见：

Effective gas implementation #290

4. 信息类提示

4.1 信息类提示1：关于RLP逻辑修复缺少文档说明

上下文件：

zkevm-rom: utils.zkasm#L931

缺少文档说明，为何RLP解析中的RLP错误处理不同于其它。
建议：

添加解释注释。

修复PR见：

Effective gas implementation #290

4.2 信息类提示2：关于RLP修复方法的通用反馈

上下文见：

zkevm-rom: vars.zkasm#L51

似乎是为了解决不同上下文，ZK coutners表现不同，而引入了新的全局变量isLoadingRLP。这回增加复杂性、前缀的按时交互依赖，以及增加代码理解难度。

建议：

理论上，最好将其依赖明确，如具有额外的flag参数来表示来自RLP处理的调用，且应采用不同的方式处理counter errors。
可以理解这可能不切实际，若这些调用源自很多不同地方。
另一个不那么激进的建议是：只在所需的utils中，而不是在较低级别的handleBatchError中，基于全局isLoadingRLP进行分支。相比于现有的会影响每个batch error处理，这种修复方式，只会影响一些有限的功能范围。同时会更明确哪些utils依赖于该全局状态。。
（这种方法的缺点可能是，如果RLP处理更改为使用一些新的utils，则必须记住在每个utils中检查isLoadingRLP。）

Polygon zkEVM回复：