ERC-5630 加密解密新方案：钱包只做数学，别再替你做整套加密

想给某个地址发一条只有它能读的私信，或者加密一份只有自己能解的备份，在以太坊生态里一直缺一条标准路。签名有 EIP-191 与 712，加密却没有共识，两个旧提案各占一角还都有毛病。2022 年 9 月 7 日创建的 ERC-5630 想做减法之王：钱包只做一步核心数学，其余全部交给上层实现。本文按原文拆这份状态为 Draft 的提案。

旧方案的三处硬伤

抽象部分把新旧差异摊开对比。旧提案让同一把私钥在加密和签名两个场景里复用，还横跨两条不同的曲线——签名用 secp256k1，加密走 ed25519——并且把某一种 ECIES 加密混合方案的细节写死在规范里。ERC-5630 全部反着来：只用 secp256k1 一条曲线，钱包端只被要求执行 ECDH 核心运算，具体怎么把明文变成密文由实现者决定，原文只建议一种标准化做法供参考。职责切分的逻辑很清楚：私钥碰得越少、协议演进越自由。钱包固件更新慢，规范把复杂度压给更新快的库，密文格式将来要升级，不用等全网钱包发新版。

两个 RPC 方法就是一条协议线

方案只新增两个 JSON-RPC 方法。eth_getEncryptionPublicKey 返回当前账户在 secp256k1 上的加密公钥，别人拿它就能向你加密消息；eth_performECDH 是解密侧，钱包收到一个对方公钥，对内部的私钥做一次椭圆曲线密钥协商，把共享密钥交回给调用方，ECIES 的其余步骤在钱包外完成。发送侧库在本地生成临时密钥对，用对方的加密公钥做 ECDH 得到对称密钥，加密后把临时公钥随密文附上；接收方在自己的钱包上对临时公钥执行 eth_performECDH，重新汇出同一把对称密钥。数学上是教科书内容，标准的全部价值在于把公钥导出和解密授权两件事变成钱包必须提供的正式接口——在此之前，各家钱包要么不实现，要么各家用各家的小门。

一条曲线背后的选择

把“只用 secp256k1”写进抽象层，是整份提案的重心所在。双曲线方案看似各取所长，代价是钱包要维护两套密钥派生与两套安全论证，任何一套出问题都拖累整体；统一曲线让同一份密钥材料只走一条数学路径，换来实现面减半。同一密钥跨签名与加密两种用途是否引入新的理论风险，规范没有给出证明，这也是评审中绕不开的讨论。ECIES 细节交给实现者同样是一步进化速度赌注：对称加密方案需要更新时，迭代库版本即可，不必等钱包固件的漫长周期。对普通用户的实操清单收敛成三问：你的钱包支持哪个方法、加密公钥能否从自己的地址正常导出、解密弹窗有没有说明“正在和谁的公钥派生密钥”。第三问尤其值得认真对待——调用 eth_performECDH 的那一刻，你批准的是一次密钥协商授权，它和签名弹窗一样值得逐字读完。

Draft 状态下的使用边界

按 ercs 仓库记录，ERC-5630 处于 Draft，实现覆盖参差，同一功能也存在 ERC-5564 这样的竞争路线，集成方需要逐一确认目标钱包的支持情况。机制层面有条更深的注脚值得普通读者记住：让钱包执行 ECDH 本质上仍是让私钥参与解密，每次解密都是一次授权动作，钱包弹窗应当把“你在解密什么”说清楚，这和签名弹窗同样值得警惕。这条标准的真正贡献是把一个判断写进了规范文本——钱包的职责边界越窄越好，密钥该少碰的场景就少碰。这个判断同样适用于读任何加密类功能：评估的对象不是“它用了多强的算法”，而是私钥在哪台设备、哪一步被调用，密文与元数据经过谁的手，收件人身份怎么绑定。数学正确只是及格线，信任拓扑才是考卷。

本文为机制说明，不构成任何投资建议。