EIP-5988 拆解:EVM 的通用 Poseidon 预编译如何服务 ZK-Rollup【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-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 解释。基础常量常量取值FORK_BLKNUM待定(TBD)GAS_COST待定(TBD)POSEIDON_PRECOMPILE_ADDRESS0xA分叉块号与 Gas 成本均标注 TBD,提案没有给出任何具体数字,实现者不应自行补数。七个头部字段与输入字段含义编码大小(字节)论文记号p素数域模数32security_level安全级别(比特数)2MalphaS-box 幂次1input_rate输入长度(域元素个数)2t状态宽度1full_round全轮数1R_Fpartial_round部分轮数1R_Pinput待哈希输入,每元素 32 字节input_rate × 32前 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 组现成向量,可直接作为预编译的单元测试基准。向量名素数域位长状态宽度 t备注poseidonperm_x5_255_32553输入 0、1、2poseidonperm_x5_255_52555输入 0 至 4poseidonperm_x5_254_32543输入 0、1、2poseidonperm_x5_254_52545输入 0 至 4starkadperm_x5_256_32563额外给出拼接(input/output concat)形式覆盖价值有三点。其一,素数域覆盖 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 论文的建议,矩阵生成流程是:生成一个随机矩阵;用上述论文的 Algorithm 1、2、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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
