ERC-7627 链上安全消息：公钥登记、会话编号和密文事件怎么拼起一套私信

在链上给人发一条只有他能读的消息，听起来矛盾：链上数据人人可查，还谈什么私信。ERC-7627（Secure Messaging Protocol）的答案是——把密文放上链，把钥匙留在链下。按以太坊 ercs 仓库的记录，这份提案状态为 Final，创建于 2024 年 2 月 19 日，它给合约内加密消息定义了最小接口：登记公钥、发送密文、用事件留痕。

三个函数撑起整个协议

接口只有三个必需函数。updatePublicKey 让调用者更新自己某个密钥槽的公钥：每个地址可以维护多个 keyIndex 对应的公钥条目，每条记录是一个结构体，装着公钥字节 public_key、一个 valid_before 的 uint64 截止时间戳，以及算法枚举 PublicKeyAlgorithm——标准列了 ECDSA、ED25519、X25519 三种，方便不同加密体系的钱包共用一份注册表。getUserPublicKey 让任何人按地址读回对方登记的公钥列表，发送方正是用它拿到收件人的加密钥匙。sendMessage 则把消息投递出去：参数是收件地址、所用公钥的索引、一个 sessionId 和密文字节。每一次成功发送都发出 MessageSent 事件，字段包括收发双方地址、密钥索引、sessionId 和密文本身；公钥变更则发出 PublicKeyUpdated。

sessionId 这个 bytes32 字段值得单独说：它是发送方自定的会话标识，同一段对话的消息共用一个 ID，索引器或客户端按它把散落在不同区块的消息串成对话线程，不需要合约自己维护聊天记录。

谁加密、谁解密，边界在哪

标准明确要求加密发生在消息传输之前、用收件人的公钥完成——也就是说加密与解密都在客户端做，合约只负责忠实记录密文和关系。这带来一条必须讲清的隐私边界：链上密文是公开的。任何人都能看到”A 在某块高给 B 发了一段密文、用的是第几个钥匙、挂哪个会话”，看不到的只有解密后的正文（前提是加密算法本身安全、且收件人私钥没泄露）。元数据——收发关系、频率、时间——在链上是完全透明的。把它宣传成”绝对保密的私信”是对这套机制的误读。

密钥轮换与过期字段的设计意图

valid_before 和 keyIndex 组合解决的是”私钥长期不变”的风险。轮换密钥时，发送方用新索引登记新公钥，旧索引的历史密文仍可用旧私钥解出；截止时间戳则允许客户端对过期公钥给出警告，避免用一把主人早已放弃的钥匙加密新消息。对审计者来说，PublicKeyUpdated 事件序列就是一只地址的密钥演化史，谁在什么时间换过钥匙、换了哪套算法，全部可回放。

使用前值得核对的三件事

索引器与审计者的读取姿势

这套协议对第三方工具非常友好，因为它把该留痕的都留在了事件里。索引器订阅 MessageSent 就能重建任意地址的通信图谱：按 from 与 to 两个 indexed 主题过滤，按 sessionId 聚合对话，按 keyIndex 判断用的是收件人哪一期钥匙——全程不需要解密。审计报告则可以把两条事件流交叉使用：PublicKeyUpdated 序列给出每只地址的钥匙年表，用它去校验密文发送时刻所用公钥是否处于有效期，能揪出”对着已过期公钥发信”的配置错误。对普通用户，链上私信的收信姿势也由此确定：钱包扫描到收件人是自己地址的 MessageSent 事件，用本地私钥尝试解密对应 keyIndex 的那一期钥匙，解不开就提示版本或密钥不匹配，而不是静默丢弃。一个实现是否用心，看它对解密失败的处理是明确报错还是假装无事发生，就能分辨。

第一，读合约确认它是标准意义上的消息注册表，还是只是把明文写进事件的”假加密”——密文字段里放明文的项目一眼就能从事件解码看出来。第二，给对方发消息前先 getUserPublicKey 检查钥匙是否临近 valid_before。第三，理解元数据公开这一点再做合规或商业判断：链上私信适合需要留痕、可验证发送者的通信，不适合需要隐藏”谁在联系谁”的场景。本文为机制说明，不构成任何投资建议。