私钥和地址长得一模一样：Aptos AIP-80 把 ed25519-priv- 写进前缀

AIP-80 的标题极其朴素，Standardize Private Keys，但它要救的是一种极其常见的自伤：用户把私钥当地址用了。这份提案状态为 Accepted，类型标注为生态标准，起草于 2024 年 4 月 19 日，意见征集截止日记在同年 4 月 30 日。

问题的根源是三个东西长得一样

在 Aptos 上，私钥、公钥和账户地址都表现为 32 字节，写成十六进制就是 64 个字符（前面带不带 0x 都一样）。对机器来说它们是不同的字段，对人来说它们是一串同形状的字符。提案描述的事故路径很具体：用户在钱包里给自己转账时，把私钥复制进了地址栏；这笔交易上了链之后，任何人都能看到那 32 字节；于是有人拿它去轮换这个账户的密钥，账户就易主了。核心问题不在于用户犯错的概率，而在于格式本身没有给出任何提示。

解法是在链下的表示上加前缀

方案没有动链，只动“软件怎么把私钥呈现出来”。钱包、命令行工具和各类应用输出的私钥会带上前缀，提案给的样例是 ed25519-priv- 加上原来的十六进制串。输入侧则两种都接受：带前缀的和不带前缀的都能导入，这样已经存下来的旧私钥不会被判废。前缀本身由两段组成，第一段是密钥方案，ed25519 对应 Ed25519、secp256k1 对应 Secp256k1；第二段是密钥类型，目前列了 priv 表示私钥、pub 表示公钥。提案把它带来的好处归为四条：能把签名方案连同密钥一起携带，便于跨钱包和应用移植；能让参数校验拒收那些看起来像账户地址的新私钥输出；旧私钥仍然可以导入，向后兼容；改动面被压在输入输出这一层，不扩散到别处。

它明确不做的事

范围切割写得很清楚：静态加密不在本提案范围内，理由是“密钥在存储时是否加密”与“密钥被当成地址”是两个正交问题。被排除的还有另三条路。改地址格式（换成 Bech32 之类）会连应用、索引器、链上表示、交易所和用户一起改动，同时还得保留对旧地址的兼容，等于没根治问题。把私钥改用 Base64 之类编码，虽然方便做格式检查，却可能造成用户把私钥贴进十六进制与 Base64 互转的网站，而私钥本就不该被贴进任何网站。只依赖助记词加派生路径的做法，则不支持自定义私钥，也让已存下来的私钥失去兼容路径。

用户一侧该怎么用这条约定

先接受它的性质：前缀是链下表示的约定，不是链上校验算法，它不会替你判断这串字符是否真是一把有效私钥，也不会在你手敲掉一个字符时报错。它的实际价值是让“这串是什么角色”变得可见：看到 ed25519-priv- 就该知道这是能签名、能轮换成密钥的秘密，不该出现在给别人的地址栏里。导入钱包时如果工具接受带前缀的输入，优先用带前缀的形式；反过来，一个能接受 64 位十六进制的输入框并不证明它期待的就是私钥。复制粘贴环节的两道自查，可以按剪贴板劫持与地址替换：复制地址时最容易被坑的一瞬间里的思路做，地址本身有没有校验能力则另有一篇讲地址校验和是什么？为什么粘错一个字符会报错。

落地程度不要替它吹

提案文本里参考实现那一栏写的是 TBD，也就是说这份文档自身并没有附上一份可查的实现在册。它的定位是影响钱包和应用如何显示与接收私钥，而不是让链上出现一种新的字节表示，也不要求谁在某天之前换掉手里的旧格式。判断某个具体钱包是不是已经按前缀输出、能不能接受带前缀导入，只能看该钱包当前的行为，不能从“提案已通过”直接推出来。同一类问题在比特币生态里有完全不同的答案，那套用首字符区分私钥外皮的机制在同一把私钥的几种外皮：WIF、十六进制与导入导出的格式边界里拆过，两者可以对照着读，但不要互相套用结论。本文只讲格式与误用面，不构成投资建议。