企业官网建设流程全解析

EIP-5988 拆解:EVM 的通用 Poseidon 预编译如何服务 ZK-Rollup

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

EIP-5988 是一个 Standards Track / Core 类提案:在 EVM 中新增一个部署在地址 0xA 的预编译合约,用于计算 Poseidon 算术哈希,目标是支撑 ZK-Rollup 与主网的互操作。提案创建于 2022 年 11 月,当前状态 Stagnant,分叉块号与 Gas 成本均为待定,参考实现和基准目录还是空的。

参数分歧:一个固定参数的预编译服务不了所有 ZK-Rollup

直接促使这份提案走向"全参数化"的,是各 ZK-Rollup 在 Poseidon 实例参数上互不统一。

Poseidon 不是一套写死的常量,实例化之前要依次选定:素数域模数p、S-box 幂次alpha、状态宽度t、全轮数R_F、部分轮数R_P。提案在 Motivation 一节给出的事实是:使用 Poseidon 的各 ZK-Rollup 选择了不同的参数集,这导致"一个预编译适配所有 Rollup"无法直接实现。类比一下:中央厨房的食材相同(Poseidon),但各家分店的配方不同(参数),固定的预制产线自然不够,需要上一台可调参数的机器。

EIP 给出的解法,是构建一个支持任意参数的通用预编译,把参数选择权交还给各 Rollup。这个解法建立在路线判断之上:以太坊走 Rollup 中心化路线后,协议层必须为 L2 提供与 EVM 高效通信的基础设施,而 ZK-Rollup 对哈希函数的诉求很具体,就是让证明验证足够廉价。Poseidon 与主流证明系统(SNARKs、STARKs、Bulletproofs 等)均兼容,因此被提案列为多 Rollup 共享预编译的候选。

概念铺垫:Poseidon 是一种为证明系统定制的算术哈希

Poseidon 的运算全部发生在素数域内,这是它适配 ZK 系统的根本原因。

先打个比方:Keccak 或 SHA-256 像密封的高速搅拌机,靠位级替换与置换制造雪崩效应,信任来自数十年的密码分析积累;把它写进证明电路时,每条非线性约束都很"贵"。Poseidon 则像一套开放式齿轮传动:每一步都只是域内加法和幂运算(S-box),形式上与电路里的约束方程同构,编译器可以低成本地把它翻译成极少数的约束。这就是它的设计哲学:接受较高的代数结构,换取极低的约束数。

正式一点说,Poseidon 是定义在素数域上的置换,状态宽度记作t;轮函数分为全轮(每个状态位置都过 S-box)与部分轮(只有一个位置过 S-box)两类,轮数分别记为R_F与R_P,输入输出都是域元素序列。"算术哈希"这个名字指的就是这一点:哈希原语由算术运算而非位运算构成。

设计钥匙:参数不写死,由调用方编码传入

整份提案的理解钥匙是一句话:预编译本身不绑定任何 Poseidon 参数,每次调用都在调用数据里携带完整的实例描述。

可以类比 3D 打印机:机器固定,每个打印任务自行附带"材料、层高、层数"的完整规格;打印机只认编码格式,不关心你带来什么配方。对应到本提案,一次调用就是 40 字节固定参数头加input_rate × 32字节的输入,同一个 0xA 地址可以服务任意多组参数组合。

好处很明显:不必为每组参数新占一个预编译地址,避免地址碎片化;各 Rollup 保留参数组合在安全性与性能上的取舍自由。代价也写在明面上:每次调用多带 40 字节头部,客户端还要对参数做合法性校验。

接口规范:预编译地址、基础常量与输入编码

提案的接口部分只锁定三样东西:地址 0xA、两个待定常量,以及"7 个头部字段加变长输入"的二进制布局。文中 MUST、SHOULD、MAY 等关键词按 RFC 2119 解释。

基础常量

分叉块号与 Gas 成本均标注 TBD,提案没有给出任何具体数字,实现者不应自行补数。

七个头部字段与输入

前 7 个字段共同描述一个 Poseidon 实例,末尾紧跟待哈希输入。

二进制布局

按提案规范,调用数据的字段顺序如下:

[32B p][2B security_level][1B alpha][2B input_rate][1B t][1B full_round][1B partial_round][input_rate×32B input]

预编译应严格按 Poseidon 论文规定的算法计算并返回哈希输出。

验证方法:用仓库中的 Poseidon 测试向量做基准

仓库内附带的 test_vectors.txt 提供 5 组现成向量,可直接作为预编译的单元测试基准。

覆盖价值有三点。其一,素数域覆盖 255 / 254 / 256 位三档,其中 254 位与主流 ZK 曲线标量域一致,这一点属于社区通行认知,仓库正文未展开。其二,状态宽度同时覆盖 3 与 5,五组向量全部为 S-box 幂 5。其三,starkadperm_x5_256_3组额外给出整体拼接的输入输出串,便于按字节流整体比对,而非逐元素比对。以第一组为例:

# poseidonperm_x5_255_3 Input: [0x00..00, 0x00..01, 0x00..02] Output: [0x28ce1942..d2a78a, 0x51f3e312..1ddc4, 0x3b2b6913..0f79a]

客户端实现拿到这 5 组输入输出,即可做单元测试、集成测试与跨客户端一致性比对。

安全边界:成熟度争议、MDS 矩阵筛选与风险隔离

提案的安全论证分三层:承认算术哈希的成熟度差距、把参数空间约束在可审计范围内、把潜在漏洞的影响范围限定在单个 Rollup 内。

第一层是成熟度。EIP 的 Security Considerations 一节引用了 Vitalik Buterin 在 EthResearch 相关讨论帖中的观点(转述):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 仪式风险限定于使用方"的处理逻辑同构。向后兼容风险在此一并带过:风险极低,唯一前提是某合约依赖 0xA 为空地址,概率很小,若真出现可将地址改为任意其他值,碰撞风险可忽略。

第三层是参数本身的安全性,关键在于 MDS 矩阵的选择。

MDS 矩阵:MixLayer 的"洗牌器"

MDS 矩阵是t × t的方阵,在 Poseidon 每轮的 MixLayer 阶段负责对状态做混合。类比:它是洗码机,职责是让每一轮的扰动彻底摊开,不让任何信息"抄近道"存活。混合是否到位有可判定标准:不能存在跨越超过t - 1轮、利用非活跃/活跃 S-box 位置的 subspace trail(子空间迹,可理解为代数上绕过大部分 S-box 的捷径)。

检测弱 MDS 矩阵的高效算法,出自 Proving Resistance Against Infinitely Long Subspace Trails: How to Choose the Linear Layer 一文,其 Algorithm 1、2、3 提供了检查手段。按 Poseidon 论文的建议,矩阵生成流程是:

1. 生成一个随机矩阵;
2. 用上述论文的 Algorithm 1、2、3 检查其是否安全;
3. 不安全则回到第 1 步重新生成。

仓库的 papers 目录 还收录了四篇核心文献:Poseidon: A New Hash Function for Zero-Knowledge Proof Systems(原始论文)、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。

缺口清单与后续演进

这份提案的缺口是明确可数的:两处 TBD、三处 TODO、两个只有占位文件的目录。

• FORK_BLKNUM、GAS_COST均 TBD,提案未给出任何基准数据;
• Gas 成本章节、Solidity 示例章节是 HTML 注释中的 TODO;
• Reference Implementation 章节是 HTML 注释里的 Geth 实现 TODO;
• Rationale 章节只有两条 "TODO: Add rationale" 占位;
• reference-implementation 与 benchmarks 目录当前各含一个.gitkeep,无实际内容。

这些与 Stagnant 状态互相印证:它是一份"规范先行、实现未动"的早期文档,不宜直接当作生产级实现规格使用。

不过 Poseidon 话题在 EIP 生态并未停更:EIP-7864、EIP-8182、EIP-8222、EIP-8297、EIP-8289、EIP-8310 均在其正文或讨论中引用 Poseidon,其中 EIP-8182 的资产目录 已包含 poseidon2_vectors.json 与 poseidon2_bn254_t4_rf8_rp56.json 两组 Poseidon2 测试向量。"为 EVM 引入高效算术哈希"的方向仍在推进,而 5988 提出的通用参数化编码与 MDS 检测框架,是后续讨论可直接复用的底座。

适合谁:如果你的工作是客户端预编译实现、ZK-Rollup 哈希选型,或追踪算术哈希安全性,提案正文、papers 目录 与 测试向量 构成一份结构完整的一手材料;如果你期待的是可落地的实现与 Gas 基准,这份提案目前还交不出答案。文档版权经 CC0 放弃,可自由引用与改写。

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