在 EVM 中支持 MNT4 椭圆曲线循环预编译EIP-1895 技术解析【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-1895Support for an Elliptic Curve Cycle是 Ethereum 社区于 2018 年提出的 Core 类标准提案目标是在 EVM 中以预编译precompile形式引入MNT4 椭圆曲线循环的ecadd、ecmul与ecpairing三种运算从而为递归 SNARKrecursive SNARK在链上落地铺路。本文以 EIPS/eip-1895.md 为骨架结合仓库中 EIP-196、EIP-197、EIP-1108、EIP-1962 等相关文档完整还原该提案的曲线参数、预编译设计、压缩编码、gas 讨论与安全性权衡并梳理其与现有 alt_bn128 预编译体系的异同。读完本文你将理解为什么支持曲线循环是链上递归验证的关键以及该提案为何最终停留在 Stagnant 状态、其思路如何在后续 EIP 中延续。一、提案背景为什么 EVM 需要曲线循环1.1 现有状态alt_bn128 的三个预编译在 EIP-1895 提出之前EVM 已经通过三个预编译支持椭圆曲线运算全部基于alt_bn128曲线预编译地址功能gas 定价来源ECADD0x06点加法EIP-196初始 500 gasECMUL0x07标量乘法EIP-196初始 40 000 gas配对检查0x08最优 ate 配对检查EIP-19780 000 * k 100 000alt_bn128 曲线定义在 EIP-196 中Y² X³ 3基域模数p 21888242871839275222246405745257275088696311157297823662689037894645226208583254 位。这套预编译支撑了链上 zkSNARK 验证——例如 EIP-197 的配对检查即被设计为验证e(a1,b1) · … · e(ak,bk) 1这一等式恰好是 Groth16 等 SNARK 验证的核心步骤。1.2 核心痛点无法在 SNARK 内部验证 SNARKalt_bn128 虽适合配对却无法实现递归 SNARK——即在一条曲线上的 SNARK 电路内部去验证另一条曲线的证明。原因在于递归验证要求两条曲线构成循环cycle即曲线 A 的群阶与曲线 B 的基域大小相互匹配、彼此嵌入对方的标量域。EIP-1895 的 Simple Summary 明确指出EVM 当前通过预编译ecadd、ecmul、ecpairing支持 alt-bn128而MNT4 与 MNT6 曲线族包含曲线循环这类循环使得在一条曲线的 SNARK 内部执行另一条曲线上的运算反之亦然成为可能因此提案建议为 MNT4 增加预编译支持。这正是递归 SNARK在一个 SNARK 中验证另一个 SNARK的基石。1.3 动机量化链上大量 SNARK 验证的成本问题从 EIP-1895 的 Motivation 可以读到一组关键估算如果 EVM 需要处理数千次 SNARK 验证将消耗约15 亿 gas对当时的 Ethereum 而言不可实际承受。而递归 SNARK 可以将多个证明聚合为一个单一证明再像普通 SNARK 一样被验证从而大幅降低验证成本此外 SNARK 验证时间与电路规模无关常数时间从另一个维度缓解了可扩展性问题。而 alt_bn128 无法实现这一循环结构。据提案所述当时已知能产生循环的配对友好曲线族只有MNT4 与 MNT6二者之间的循环特性在On cycles of pairing-friendly elliptic curvesCCW18arxiv 1803.02067中有完整刻画循环本身最早由Scalable Zero Knowledge via Cycles of Elliptic CurvesBCTV14eprint 2014/595引入。二、MNT4 曲线定义完整参数2.1 群与域的阶EIP-1895 给出的 MNT4 曲线由两个素数阶循环群构成群G_1与G_2均为素数阶qq 475922286169261325753349249653048451545124878552823515553267735739164647307408490559963137G_1定义在素数阶域F_p上p 475922286169261325753349249653048451545124879242694725395555128576210262817955800483758081生成元PP ( 60760244141852568949126569781626075788424196370144486719385562369396875346601926534016838, 363732850702582978263902770815145784459747722357071843971107674179038674942891694705904306 )提案特别指出p 与 q 均可用 298 位bits表示——这一事实在 Rationale 中被强调为必须为更大域元素运算提供支持的直接原因详见第五节。2.2 曲线方程与 G_1G_1位于形如Y² X³ aX b的曲线上参数为a 2 b 4238945365266841782894160115338882400293181036738960028033415441240547450193407953608416852.3 扭曲群 G_2G_2是定义在二次扩域F_p² F_p / To be completed上的**扭曲twisted**群原文档此处扩域构造留待补全曲线方程形如Y² X² aX b原文档笔误应为三次项X³参数为a 34 i * 0 b 0 i * 67372828414711144619833451280373307321534573815811166723479321465776723059456513877937430G_2生成元P2的坐标为i为扩域虚部单位P2 ( 438374926219350099854919100077809681842783509163790991847867546339851681564223481322252708 i * 37620953615500480110935514360923278605464476459712393277679280819942849043649216370485641, 37437409008528968268352521034936931842973546441370663118543015118291998305624025037512482 i * 424621479598893882672393190337420680597584695892317197646113820787463109735345923009077489 )说明p、q 及坐标均精确取自 EIPS/eip-1895.md可放心用于实现对照。与 alt_bn128 相比MNT4 的域模数与群阶约 298 位明显大于后者的 254 位这直接决定了后续编码与 gas 设计的差异。三、预编译设计与 gas 成本3.1 计划新增的操作提案 Abstract 明确列出将通过预编译支持的三种操作全部作用于 MNT4操作含义与 alt_bn128 预编译的对应关系ecaddon MNT4点加法对应 EIP-196 的0x06ecmulon MNT4标量乘法对应 EIP-196 的0x07ecpairingon MNT4配对检查对应 EIP-197 的0x08其中X文档写作MNT_X_*取值为4即 MNT4。3.2 gas 定价留白To be estimated原文档在 gas 一节给出的是待估占位MNT_X_ADD To be estimated MNT_X_MUL To be estimated MNT_X_PAIRING To be estimated并在 Rationale 中说明Proper benchmarks will be done in order to make this choice and to price the operations in gas——即正确做法是先完成基准测试再据此为运算定价 gas。这与其他预编译 EIP 的做法一致例如 EIP-1108 正是依据 2018 年后 Geth 切换到 Cloudflare bn256 库、Parity 的 bn crate 优化带来的数量级性能提升将ECADD从 500 降至 150、ECMUL从 40 000 降至 6 000、配对检查从80 000 * k 100 000降至34 000 * k 45 000并详细给出了以 ecrecover 116 微秒 / 3000 gas 为基准折算 25.86 gas/微秒的定价推导过程。EIP-1895 若推进到实现阶段gas 定价大概率会走同样的先基准、后定价路径。3.3 域元素超过 256 位带来的定价复杂度由于 MNT4 的 p、q 都是 298 位整数见第二节单个域元素无法塞进一个uint256这会让预编译的输入布局与 gas 模型比 alt_bn128 复杂——原文档在 Rationale 中对此有明确论述详见第五节。这也解释了为什么提案正文把编码设计第四节放在如此重要的位置。四、压缩点编码方案4.1 压缩表示EIP-1895 规定F_p上的曲线点P(X, Y)采用压缩形式C(X, Y)表示C X | s其中s用于编码Y的奇偶信息s取值Y含义0x00无穷远点point at infinity0x02取偶数的解yeven0x03取奇数的解yodd从仿射坐标求压缩表示是平凡的s 0x02 | (s 0x01)4.2 与既有编码方案的对比这一压缩编码与 EIP-1829Precompile for Elliptic Curve Linear Combinations中的编码约定高度一致后者同样采用0x00表示无穷远点、0x02/0x03表示 y 的奇偶并注明遵循 SEC 1 v 1.9 2.3.4但不支持非压缩0x04。而 alt_bn128 的 EIP-196/EIP-197 走的是另一条路线非压缩编码点以完整的(x, y)两个域元素表示、无穷远点编码为(0, 0)——Rationale 说明这样做的好处是合约内仍可执行部分运算包含完整 y 坐标、两个编码点可直接比较相等无需第三个射影坐标。EIP-1895 选择压缩编码的动机在文中写得很直白在 EVM 中压缩形式使每个曲线点只需 2 个 uint256 而非 3 个减少存储与 calldata 开销——考虑到 MNT4 域元素为 298 位、天然占用超过一个 256 位字这种节省更为关键。4.3 边界情况原文档在 Edge cases 一节明确指出无穷远点存在多种可接受的表示Several acceptable representations for the point at infinity。结合上表可知0x00是约定的无穷远点编码但实现需要容忍其它可能出现的表示并统一处理。这与 EIP-2539BLS12-377中以(0, 0)作为无穷远点约定、以及 EIP-1829 Edge cases 中专门列出 Returning the point at infinity 的处理思路一致——不同曲线族对无穷远点的编码约定各不相同实现时必须以对应 EIP 的规范为准。五、Rationale安全性、域大小与曲线选择的深层权衡5.1 80 位安全性的取舍提案明确承认MNT4 只有80 位安全性而 MNT6 有 120 位。Rationale 的表述是80 位可能不足以支撑关键安全级别例如转移数十亿美元的场景但对其他场景足够。若证明安全性不足还有另一个选项Coda现 Mina使用的另一条循环曲线其定义在 753 位大小的域上——这可能也低得令人望而却步提案提到从 Coda 的公开资料中未找到对该曲线的引用。这一讨论与后续 EIP-1962Precompile for elliptic curve arithmetic over multiple curves形成呼应后者将 MNT4/6 cycle from the original paper 明确标注为Its not too secure, but may give some freedom for experiments不太安全但为实验留出空间并把 MNT4/6 cycle from Coda 列为待评估项。可见MNT 循环安全性不足是社区共识EIP-1895 自己也将此作为未能定稿的关键顾虑之一。5.2 大于 256 位的域元素Rationale 特别强调无论选择哪条循环曲线群元素与域元素都大于 256 位即使是 80 位安全性的 MNT4 也不例外因此可能有必要同时为更大域大小的运算增加支持。从当前仓库的后续提案看这一判断已被事实印证EIP-1962 为多曲线椭圆曲线运算预编译设计了(modulus, curve_id, ...)形式的通用输入布局域模数作为参数传入而非硬编码正是为了容纳 MNT4/6约 298 位乃至更大域如 BLS12-377 在 EIP-2539 中的 377 位模数的场景。5.3 无需支持循环中的全部曲线一个重要的设计洞察是假设找到合适的循环实现方无需为该循环包含的所有曲线都实现预编译只需要其中一条。原因在于递归 SNARK 的整体安全性不取决于验证在哪条曲线上进行因此最佳选择是速度最快的那条曲线。这一论点让 EIP-1895 可以只聚焦 MNT4而不必同时引入 MNT6。5.4 更优循环的开放性问题提案坦诚目前不知道是否存在更高效的配对友好曲线循环也不确定其是否存在。它提出一种可能的变通放宽循环中所有曲线都必须是配对友好的约束——若循环中只有一条配对友好曲线仍可通过在 SNARK 与其它通用零知识密码系统之间交替来组合证明。这为后续研究保留了方向也解释了为什么该提案在曲线选型上保持开放。六、测试用例、参考实现与现状评估6.1 测试用例与实现原文档的Test Cases一节为空未给出任何测试向量Implementation一节引用了三类参考资源[go-boojum]递归 SNARK 应用的 PoC 演示作者 Alexandre Belling即本 EIP 作者[libff]C 有限域与椭圆曲线库[coda]Coda 协议——轻量级、恒定大小区块链的新加密货币协议注以上为原文档列出的外部项目文中不再展开。从仓库内证据看与 MNT 曲线相关的实现线索主要出现在 EIP-1962 的曲线支持清单中MNT4/MNT6 的 Ate pairing、加法、标量乘法与配对运算。6.2 提案状态StagnantEIPS/eip-1895.md 的 front matter 明确标注status: Stagnant停滞、type: Standards Track、category: Core创建于 2018-03-31讨论链接指向 ethresear.ch 关于通过层级聚合降低 SNARK 验证成本的帖子。综合仓库内证据可以推断其停滞原因gas 定价未完成MNT_X_*三个常量全部是To be estimated占位缺乏可执行的定价关键参数未补全F_p² F_p / To be completed的扩域构造留白安全性顾虑80 位安全性被认为偏低且当时没有明确优于 MNT 循环的替代方案缺乏测试向量Test Cases 为空无法支撑共识层硬分叉所需的验证工作。从后续演进看社区最终选择了更通用的路线EIP-1962 通过单一预编译同时支持 BN254、BLS12-381、BLS12-377、MNT4/6 等多条曲线其中 MNT4/6 被明确标注为实验用途EIP-2539 则聚焦 BLS12-377 以获得 120 位安全性。EIP-1895 作为最早把曲线循环 递归 SNARK引入 EVM 讨论的提案之一其曲线参数、压缩编码与安全性分析为后续工作提供了重要参考。七、延伸阅读与仓库资源围绕本文主题可继续阅读当前仓库中的以下相关文档EIP-196alt_bn128 点加法与标量乘法预编译——EVM 椭圆曲线预编译的起点含完整编码与 gas 定义EIP-197alt_bn128 最优 ate 配对检查预编译——以配对等式形式定义 SNARK 验证核心步骤EIP-1108降低 alt_bn128 预编译 gas 成本——展示先基准测试、后定价的完整方法论EIP-1829通用椭圆曲线线性组合预编译——与 EIP-1895 相同的压缩编码约定0x02/0x03EIP-1962多曲线椭圆曲线运算预编译——将 MNT4/6 纳入曲线支持清单的后续方案EIP-2539BLS12-377 曲线运算预编译——面向 120 位安全性的曲线预编译设计总结EIP-1895 为在 EVM 中实现递归 SNARK这一目标提供了具体的技术蓝图以 MNT4 曲线的 298 位域参数、压缩点编码和ecadd/ecmul/ecpairing三类预编译为核心辅以对 80 位安全性、大域元素编码与 gas 定价的坦诚讨论。尽管该提案因参数未补全、gas 未定价、安全性存疑而停留在 Stagnant 状态但它揭示的曲线循环思想——让证明可以在一条曲线的电路内部验证另一条曲线——深刻影响了后续 EIP-1962 的多曲线预编译设计与递归聚合证明的探索方向。对于研究 EVM 密码学原语演进与链上可扩展性方案的开发者而言理解 EIP-1895 是理解这一技术脉络的关键一环。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考