ZK-Rollup 的哈希参数各不相同，EVM 凭什么一个预编译接住？拆解 EIP-5988 Poseidon 预编译

ZK-Rollup 的哈希参数各不相同，EVM 凭什么一个预编译接住？拆解 EIP-5988 Poseidon 预编译

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

EIP-5988 是 EIPs 仓库里的一个 Standards Track / Core 类提案，为 EVM 新增一个参数化的 Poseidon 算术哈希预编译，让各 ZK-Rollup 能在链上按自选参数完成哈希计算。这个提案 2022 年 11 月创建，当前状态为Stagnant。本文从输入编码、测试向量验证、MDS 矩阵安全判据三个切面拆解它的完整设计。

哈希不能一个尺寸通吃：Rollup 的参数分歧

以太坊走向 Rollup 中心化路线后，协议层需要为 L2 与 EVM 之间的高效通信提供基础设施，而 ZK-Rollup 对哈希函数有专门要求：它必须是证明系统能够高效处理的类型，否则链上验证证明的成本会失控。

Poseidon 就是为这个场景造的。它是一种算术哈希函数——由一组素数域上的置换构成，运算几乎全是域内乘加。正因为代数结构强，它在证明电路里产生的约束数量远少于 SHA-256、Keccak 这类传统哈希，并且与 SNARKs、STARKs、Bulletproofs 等主流证明系统都兼容。

障碍在于参数不统一：各 ZK-Rollup 落地 Poseidon 时各自挑选了不同的素数域、轮数与状态宽度。给每种组合各部署一个固定参数预编译，会立刻碎片化；而提案给出的路线是反过来的——

we can still build a generic precompile that supports arbitrary parameters, and allow the ZK rollups to choose the parameters they want to use.

即参数由调用方编码传入，而不是预编译写死。这是理解 EIP-5988 全部后续设计的支点。

参数跟着调用方走：预编译的输入编码布局

规范部分先给出三个常量：

分叉块号与 Gas 成本都还是 TBD，说明提案停留在早期。预编译地址规划为0xA，文中 MUST / SHOULD / MAY 等关键词按 RFC 2119 解释。

每次调用需要随输入一起指定的 Poseidon 参数如下：

完整的输入布局为：

[32 bytes for p][2 bytes for security_level][1 byte for alpha][2 bytes for input_rate][1 byte for t][1 byte for full_round][1 byte for partial_round][input_rate * 32 bytes for input]

人话版本：40 字节的参数头 + 变长输入尾部。头部 7 个字段共同钉死一次 Poseidon 置换实例（哪个域、多少轮、多宽状态），尾部按序排列待哈希的域元素；预编译按 Poseidon 论文 定义的算法计算并返回输出。

配套内容目前基本是空壳：Solidity 封装示例、Gas 成本、Rationale 三处均为 TODO 占位；assets/eip-5988/ 下的reference-implementation/与benchmarks/目录只放了.gitkeep，没有公开的 Geth 实现与基准数据——与 Stagnant 状态相符。

向后兼容的风险极低，唯一要防的是某个合约恰好依赖0xA地址为空。概率不高，真出现时把地址换成任意其他值即可，碰撞风险可忽略。

拿什么验证实现：参考实现的测试向量族

验证材料来自 Poseidon 参考实现的测试向量，存放在 assets/eip-5988/test/poseidon/test_vectors.txt。文件覆盖 5 组参数组合：

命名中的x5即 S-box 幂次为 5。向量整体覆盖了254 / 255 / 256 位三种素数域宽度与 3、5 两种状态宽度，并且同时提供逐元素与整段拼接两种表示——实现者做单元测试、集成测试和跨客户端一致性对比时，两种形式各有用武之地。

算术哈希的风险边界：生产记录与 MDS 矩阵判据

生产足迹与影响半径

提案引用了 Vitalik Buterin 在 EthResearch「Arithmetic hash based alternatives to KZG for proto-danksharding」讨论帖中的评估，要点有三：Poseidon 2019 年才正式提出，靠高代数结构换低约束数的路线相比 SHA-256、Keccak 的数十年检验仍然年轻；链上 L2 与多个系统已依赖它，至今未出现相关漏洞，但生产使用仍需"掂量"；这份风险应与备选方案（如带可信设置的配对方案）的风险、以及依赖能证明 SHA-256 的强大证明者所带来的中心化风险放在一起权衡。

提案同时列出了生产使用方：StarkWare 计划把 Poseidon 用作 StarkNet 主哈希并内置进 Cairo；Filecoin 用于不同阶数的 Merkle 树证明与两值承诺；Dusk Network 用于类 Zcash 的证券交易协议；Sovrin 用于基于 Merkle 树的撤销；Loopring 用于以太坊隐私交易；Polygon 用于 Hermez ZK-EVM。

关键的定性判断是：即便 Poseidon 将来被证实存在漏洞，影响被限定在使用该哈希的 Rollup 之内。这与 EIP-4844 为 KZG 仪式风险做的论证同构。

MDS 矩阵的安全判据与生成流程

参数化设计把安全压力转嫁到了参数选择上，其中最敏感的是 MDS 矩阵——一个t × t方阵，在 Poseidon 的 MixLayer 阶段负责把状态各元素互相混合。判据只有一条：不活跃/活跃 S-box 子空间迹不得超过t − 1轮（子空间迹可以理解为大部分 S-box 被"跳过"、只沿线性部分传播的攻击路径；能搭的轮数越长，置换暴露的结构越多）。检测弱矩阵的高效算法见 Proving Resistance Against Infinitely Long Subspace Trails: How to Choose the Linear Layer。按 Poseidon 论文建议，矩阵生成是一个循环：生成随机矩阵 → 用上述论文的 Algorithm 1、2、3 校验 → 不过关就重新生成。

assets/eip-5988/papers/ 目录收录了提案引用的全部原始文献：Poseidon 论文、Security of the Poseidon Hash Function Against Non-Binary Differential and Linear Attacks、Report on the Security of STARK-friendly Hash Functions、Practical Algebraic Attacks against some Arithmetization-oriented Hash Functions。

虽然 EIP-5988 本身停滞，"给 EVM 引入高效算术哈希"的方向在仓库里仍在推进：EIP-7864、EIP-8182、EIP-8222、EIP-8297、EIP-8289、EIP-8310 的讨论中均提及 Poseidon，EIP-8182 的资产目录里甚至已有新一代置换 Poseidon2 的测试向量（poseidon2_vectors.json与poseidon2_bn254_t4_rf8_rp56.json）。5988 定下的"参数头 + 变长输入"编码范式和 MDS 安全检测流程，仍是这批后续工作的参照系。EIP-5988 文档版权已通过 CC0 放弃。

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs