ARC-72 的合约 NFT 接口：ownerOf 与 tokenURI 两个方法，256 字节的返回值

Algorand 上的藏品大多用网络原生的 ASA 发，可 ASA 的字段是固定的，做不了复杂逻辑。ARC-72 因此为”用智能合约实现的 NFT”立了一份最小接口：只规定两个方法，其余交给扩展。文档在 2023 年 1 月创建，状态标为 Living。

接口探测先行

合规的第一步不是实现方法，而是让别人能问出来。ARC-72 要求符合核心规范的合约必须实现 ARC-73 定义的接口检测标准——这套机制的角色相当于以太坊上的 ERC-165：解析器先问”你支持什么”，再决定怎么调用。跳过这一步的合约，市场端只能靠硬编码地址名单来认。

核心接口本身是两个方法。arc72_ownerOf 声明为只读，输入 uint256 的 tokenId，返回当前持有者地址。合约必须实现这个基线接口，才算符合核心规范。

元数据扩展与 256 字节的返回值

再加一层，是元数据扩展。arc72_tokenURI 同样只读，输入 tokenId，返回一个 byte[256]——注意返回类型是定长字节数组，文档规定：短于返回长度的 URI 必须在末尾用零字节填充。这一条是 Algorand 应用调用约定的直接后果：跨合约的返回值形状要在 ABI 层面定死，不足部分用零补齐由调用方剔除。

URI 该怎么选，ARC-72 给了明确倾向：应当使用 ipfs://... 形式的 URI，理由是元数据不会因为某个 DNS 注册的到期或被接管而过期、被改动；出于安全考虑不应当使用 http://。所指内容也定了下游：应当指向符合 ARC-3 的 JSON 元数据文件规范、并按 ARC-16 的特质声明方式来写属性。

零填充不是小事

byte[256] 加零填充的组合，会让逐字比较 URI 的实现翻车：同一个 ipfs:// 地址，填充后是 256 字节，未填充是不定长，解析器若不剥尾部零，哈希比对、白名单匹配、跨工具联动都会错。规范写 MUST 的正是这一点——短 URI 必须在末尾补零。把它翻译成审计动作：取 arc72_tokenURI 的原始返回，剔除尾部零字节，再判断它是否 ipfs:// 开头、能否解析成符合 ARC-3 的 JSON、traits 段是否按 ARC-16。

规范顺带给出选 ipfs 的理由本身也值得记住：一次 DNS 注册的到期或被接管，足以让 http 域名上的元数据悄悄换脸；ipfs 方案把这扇门关上，代价是取件更依赖客户端与网关，可用性从域名问题变成网络副本问题。两种取舍没有免费的选项。

放回生态位置看

ARC-72 的动机段写得平实：当前 Algorand 生态的多数 NFT 以 ASA 实现，但需要丰富功能时智能合约是另一条路，立接口标准是为了让这条路长出可互操作的工具。这与 ERC-165 加 ERC-721 在以太坊的历史角色同构——先让解析器问得出，市场才调得动。规范里的方法以 JSON 形式直接内嵌：名称、描述、只读标记、参数类型、返回类型齐全，审合约 ABI 时可以逐字对照，不需要猜。

还有一条不写在接口里、却决定信任结构的事实：ARC-72 只规定怎么读，没有规定谁能改。合约型 NFT 的元数据可变与否完全取决于实现方自己，ASA 那套”参数写在资产配置里、改动即新交易”的不可变直觉在这里不成立——链上没有统一的更新事件约定，也没有市场必须监听的广播义务。把”符合 ARC-72”读成”元数据安全”，方向就偏了；正确的读法是：接口让工具通用，实现者决定你买到的到底是哪一种合约。

三条链上的自查动作

给一件 Algorand 合约 NFT 做体检，可以按文档结构逐层验证：能不能通过 ARC-73 探测到 ARC-72；调用 arc72_ownerOf 是否返回与账面一致的地址；arc72_tokenURI 的原始返回是否带零填充、剥掉填充后是不是 ipfs 方案而非 http，解析出的 JSON 是否符合 ARC-3、traits 段是否符合 ARC-16。四段里任何一段含糊，问题都在解析层而不是市场页面。

ARC-72 自己也承认这只是起点：文档说后续标准可以定义新的 URI 或文件格式推荐。接口让工具可通用，不改变作品本身的价值，本文不涉及价格判断，也不构成投资建议。