Algorand 上的资产（ASA）是网络原语，字段是固定的那几种：名称、单位名、总量、小数位，外加一个可选的 URL。发图、发视频的人很快发现，光有这些字段不够用，于是社区写下了一系列”约定”文档，ARC-69 是其中专门针对含数字媒体资产的一份。它不修改协议，只规定同样几个字段应该怎么写，好让钱包和市场能用同一套规则去读。
au：媒体地址该怎么写
ARC-69 对资产 URL 字段（缩写 au）提出了分级要求。它应当指向数字媒体文件本身，应当足够持久，应当小到能在画廊视图里快速抓取；同时必须遵循 RFC-3986 的 URI 语法，不得包含空白字符。最有辨识度的一条是把媒体类型写进片段标识符：在 URL 末尾加 #，用 #i 表示图片、#v 表示视频、#a 表示音频、#p 表示 PDF、#h 表示 HTML 或交互式媒体；什么都不写时按图片处理。
方案选择上有明确倾向。文档建议用 https 与 ipfs 两种 URI 方案；文件存放在 IPFS 时应当直接写 ipfs://...，而不应当写成 https://ipfs.io/ipfs/... 这样的网关形式；出于安全考虑，不建议使用 http。区别在于：网关形式的地址有效性取决于某个第三方节点的在线状态，而 ipfs:// 只包含内容标识，读取路径交给客户端自己决定。
am：把校验和留在账上
ARC-69 要求的第二个关键字段是资产元数据哈希（缩写 am）：整幅全分辨率媒体文件的 SHA-256 摘要，以 32 字节的字符串形式写入。它的作用是做完整性核对——展示端可以拿低清副本工作，但任何时候想确认”这就是原始那一张”，就用文件重算一遍摘要跟链上字段比对。
网关地址为什么不算合格
ARC-69 特意点名两种看似等价的写法：网关链接与 ipfs:// 直写，内容相同、生命周期完全不同。写 https://ipfs.io/ipfs/... 时，资产指向的不是那串内容哈希，而是”某家公司还在运营、那个域名还解析到它”这个条件；换成 ipfs:// 加内容标识，条件就只剩网络里还有副本。同理，http:// 被判不安全也不只是加密问题：明文请求可被中间方改写，媒体内容在传输层就可能被替换，而内容寻址本来的卖点恰恰是”取到的东西可以被哈希验证”。把这些写成 SHOULD 而不是 MUST，是社区约定的常态——它承认历史上已经存在大量不合规的资产，规范要引导新增，而不是把存量一次性判死。对买家，这意味着合规字段是加分项与解析提示，不是准入开关；字段不合规的藏品照样流转，只是解析要多一层人工兜底。
从链上把说明书写完
这三条字段不是给市场后台看的。要亲眼确认一件资产的 ARC-69 合规度，得回到链上：找到最近一笔带有效元数据的资产配置交易，从它的 note 字段里剥出 JSON；把 au 与展示端实际加载的地址逐字对照；用原图重算一次 SHA-256，与 am 的 32 字节比对。摘要锚定的是全分辨率原件，市场页面加载的通常是压缩副本——两份哈希不同是正常分工，只有原图摘要对不上时才是真正的问题。
约定类标准的通病也在这里：违约没有成本。au 写成网关链接、am 干脆不填、note 里没有合法 JSON，这样的资产照样创建、照样转让、照样挂单。所以成熟的读法是把字段当作解析提示，把哈希核对当作事实判定，两者混不得。ARC-69 用 SHOULD 与 MUST 分了级，实现方对 SHOULD 的取舍因此可以各不相同——同一份规范喂出两种解析结果，并不奇怪。
说明书放哪儿
除了参数，ARC-69 还规定资产附带一份 JSON 格式的元数据文件，存放在最近一次含有效 ARC-69 JSON 的资产配置交易的 note 字段里。也就是说，描述、创作者这些字段不进 URL，而是跟在参数更新的那笔交易上。
ARC-69 的正文用 RFC-2119 的强制语气词区分”必须”和”建议”：au 的语法约束是 MUST 级，媒体类型片段、URI 方案、大小控制是 SHOULD 级。读一件 Algorand 藏品时，可以把这套约定当作解析器的输入规范：字段合规不代表东西值钱，但不合规至少说明解析要靠猜。链上字段与作品真实性是两件事，任何标准都不承诺价格表现，也不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。