提案想解决的问题
2018 年 3 月 25 日提交的 EIP-665 提议给 EVM 加一个 Ed25519 签名验证预编译合约。预编译是写进客户端的原生函数，合约调用它就像调用一个特别便宜的内置工具。作者列的理由放在今天依然成立：Ed25519 是 IETF 推荐的算法族，约 128 位安全强度，公钥只有 32 字节、签名 64 字节，设计上便于做恒定时间、抗侧信道的实现；TLS、SSH、OpenBSD 签名工具等系统早已大量使用它。但在 EVM 字节码里用纯 Solidity 做这条曲线的验证，开销大到不实用——这正是预编译存在的意义。提案状态至今 Stagnant（停滞），从未上链。
按原文拆开它的接口
规范部分很简短。名为 ED25519VFY 的预编译放在地址 0x9，输入固定 128 字节：32 字节消息、32 字节公钥、64 字节签名；输出 4 字节，全零表示验签成功，任何非零值表示失败。Gas 定价 2000，作者的理由是 Ed25519 计算比 secp256k1 的 ecrecover（定价 3000）更便宜，所以应该更便宜。Rationale 还点出一个关键差异：Ed25519 无法从消息和签名反推公钥，所以公钥必须作为参数传入——不像 secp256k1 那样有”恢复”这一说。输入里放的是 32 字节摘要而不是任意长度原文，意味着调用方自己负责先把消息哈希成 32 字节，摘要算法一致性由合约层约定。
与相邻机制的边界
这条提案常被拿来和两类现实对比。其一是早已内置的 secp256k1：EVM 一直能从交易或签名中恢复出公钥地址，这也是以太坊账户体系的根基，验出的地址若是合约：EIP-8151 给 ecRecover 预编译加了一道代码检查 描述的正是给这类恢复预编译加合约代码检查的后续工作。其二是紧凑签名ERC 那一支（见 签名从 65 字节变成 64 字节省了什么：ERC-2098 紧凑签名格式的读写法）压缩的是签名长度，不改变曲线。EIP-665 想动的是曲线版图：让以 Ed25519 为主签名算法的系统和以太坊合约之间有一条经济的互验通道——比如把链下账户体系关联到链上地址。这条动机在文中被明确写为”关联已有的链下系统”。
为什么停在原地
提案没有获得推进，可从文本与后续历史读出几层：一是需求始终没有大到必须进协议的临界点，纯代码实现虽然昂贵但并非不可能，零知识与预言机方案也提供了绕开曲线限制的路；二是新预编译地址与 Gas 定价要进硬分叉议程，机会成本始终存在；三是 2024 年另一场讨论证明，社区先解决的是”验哪条曲线”的优先级问题——最终在 2025 年定稿并随 Fusaka 升级激活的 secp256r1 预编译（EIP-7951）瞄准的是通行密钥设备，而非 Ed25519。同一时间窗里，Ed25519 的候选顺序被排在了后面。
用户视角的版图
对不写合约的钱包用户，这张曲线版图并非抽象知识。你的资产钥匙多半在 secp256k1 上；一部分链（如 Solana 生态）的账户密钥是 Ed25519；而你手机的指纹与面容签名、FIDO2 安全密钥走的是 P-256（即 secp256r1）。“某条曲线能否被链上原生验证”决定了大量体验能不能做：例如用通行密钥直接发起链上交易的智能账户方案，可行性就建立在 EIP-7951 落地之后。反过来，宣称”用 Ed25519 设备签名直接驱动以太坊合约”的产品，要么付出高得离谱的 Gas，要么依赖链下验证器——后者的信任边界值得你单独审视。
检查手上有无此类依赖
如果你使用的钱包或产品宣传了跨曲线能力，可以做两个低成本核对：其一，看其技术文档声称的验证发生在哪一层——链上预编译调用、链下服务验证，还是零知识证明；其二，若宣传链上验证，可以在区块浏览器里打开其验证合约的”执行”页，看调用列表里是否出现预编译地址。文档吹得再响，调用轨迹不会配合演戏。对开发者身份的用户还有一条延伸：若你在合约里集成第三方验签库，留意库README声明的验证路径——是纯 Solidity 实现（Gas 极高）、调用某个预编译地址，还是依赖链下服务回传结果。三者的信任假设完全不同，前两者看链，第三种要看服务方。对普通用户则只需记住原则的另一方面：签名算法抗不抗攻击，永远抵不过私钥或恢复短语被钓鱼，这两层风险互不替代。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。