Aptos 地址为什么能短成 0x1：AIP-40 的长短形态与显示规矩

一个地址，好几种”都对”的写法

Aptos 上每个账户或对象由一个 32 字节的地址标识；链上内部就用这 32 字节本身，但对外传输与显示时常见的是十六进制文本。问题在于同一地址存在多种技术上都不算错的写法：0x 加 64 个十六进制字符的完整形式、去掉前导零的短形式、再不带 0x 前缀的形式。AIP-40 的动机部分说得很直白：各 API、工具、产品各挑一种，生态就碎了——查询链上数据、提交交易时都可能因此对不上号。这份标准（状态 Accepted，2023-06-18 创建）不改编码本身，只做一件事：规定哪种场合该用哪种写法。

LONG、SHORT 与”特殊地址”的划线

标准给两种形态定了名：LONG 是 0x 加 64 个十六进制字符；SHORT 是同串去掉前导零。关键的划线在”特殊地址”：十六进制串前 63 个字符都是零、最后一个字符落在 0 到 f 之间（即末字节小于 16）的地址算特殊，写成短形就是 0x0 到 0xf 这一小把—— Aptos 的框架核心地址 0x1 就在其中。显示规则据此分两半：特殊地址应当用 SHORT；其余所有地址必须用 LONG。为什么值得为这十几个地址单开规矩？AIP 在替代方案里给了理由：统一只显示 LONG 虽然更简单，但体验差，而且允许特殊地址用短形其实有防伪作用——一个 0x0 后面 62 个零再加个 1 的地址，长得像特殊地址但不是，按规则它必须显示成 LONG，冒充”看着像 0x1”就没了便利。

钱包和 API 该接受哪种、拒绝哪种

输入侧，标准用规范语言划了层次：解析账户地址的函数必须接受 LONG 与特殊地址的 SHORT 两种（0x 前缀必需）；可以额外接受不带 0x 的 LONG、以及任何地址的 SHORT 形态——后者是为兼容存量工具留的口子。官方参考实现照这个层次做了两个函数：严格版只认前两种，宽松版四种全收。标准同时提醒建 API、钱包、工具的人：能不接受宽松形态就别接受。对照 Aptos 把私钥文本也统一了前缀的 AIP-80（同一链上的另一次”外皮”标准化，见 私钥和地址长得一模一样：Aptos AIP-80 把 ed25519-priv- 写进前缀），AIP-40 管的是地址这半边的门面。

用户核对地址时该看什么

把规则翻译成操作习惯：第一，收到非特殊地址，先数长度——0x 后应为 64 个十六进制字符，短了一截就说明对方工具在乱用 SHORT；第二，看到 0x1 这类短地址不必惊讶，那是特殊地址的正常形态，但要意识到它只有特殊身份才配这么短；第三，跨工具复制粘贴、导入导出时，同一地址出现长短两种写法属正常，若某个平台把完整地址的前导零也吃掉或大小写混乱，就按”不符合标准”对待，优先换官方渠道核对；第四，长短形态之争在 EVM 生态有平行剧情——前导零太多导致的显示投毒问题，Aptos 用”必须显示全形”来防，EVM 侧的教训是别把任何”看起来像”当成证据。

一次导入引发的格式审判

把规则放进真实故障里更好记：用户从接口文档里复制了一个不带 0x 的地址去填钱包，钱包按”必须接受”的清单只认带前缀的写法，报错是合规行为而非 bug；反过来，一个工具把完整地址的后段截掉显示，那不是标准允许的 SHORT——SHORT 只允许削前导零，从不允许动结尾。程序比对两个地址是否相同，正确做法是各自解析回 32 字节再比，而不是比字符串：长短、前缀、大小写三个维度都能让肉眼比出错。对特殊地址的短写法保持敏感还有另一层含义：0x1 这类地址背后是链的框架协议资源，转账说明里看到它们，通常代表合约层面的操作而不是普通用户收款。

边界与风险提示

这是一份收敛现状的 v1 标准：更紧凑的新编码被明确留给”v2”讨论，本文不构成对未来的预测；具体产品是否完全合规，以其文档与实测为准。转账前请务必用收款方多渠道确认的完整地址为准。本文为机制说明，不构成投资建议。