属性搬上链：ERC-7496 动态属性如何堵住挂单欺诈

“挂单时写着金色款，成交后属性变灰”是 NFT 市场里一种经典纠纷：属性存在元数据 JSON 里，卖家改一次文件、重新广播一次 IPFS，市场展示的与被交易的已经是两个东西。ERC-7496 的对策是把属性做成合约存储里的 bytes32 值——属性不再是一段可以随时改写的网页，而是只能在链上改、改了必留事件痕迹的状态。2026 年 9 月 9 日在 ethereum/ERCs 仓库核对，该标准状态为 Draft，2023 年 7 月 28 日创建，依赖 ERC-165、ERC-721 与 ERC-1155，接口标识 0xaf332f3e。

接口：两个读、一个写、一串事件

读取端有 getTraitValue（一枚代币一个属性键）、getTraitValues（一次批量读多个键）和 getTraitMetadataURI（属性说明书在哪）。写入端只有 setTrait，一枚一枚地改。事件面很讲究：单枚修改发 TraitUpdated，连续区间批量改有 TraitUpdatedRange 和统一值版本，任意列表批量改有 TraitUpdatedList 及统一值版本，说明书本身更新则发 TraitMetadataURIUpdated。事件的设计动机是索引器友好：一个合约改了十万枚的属性，不该刷出十万条单枚事件。

键、默认值与两条报错

属性键 traitKey 必须唯一，推荐使用人可读名字的 keccak256 哈希。说明书 JSON 里有个防碰撞规定：键名如果是 0x 开头的 32 字节十六进制串，就直接当键用，否则一律哈希；字面键不允许和任何哈希值相撞，展示名也不允许互相重复。两条报错的分工值得记：查一个合约根本没定义的属性键，必须回滚并抛 TraitDoesNotExist，让应用明确知道“你问错了”；键存在但这枚代币还没设过值，则必须返回 bytes32(0) 而不是报错——这是为了让批量扫描不被零星空值打断。

validateOnSale：市场该在成交瞬间核对什么

说明书里每个属性可以声明一个 validateOnSale 信号，告诉市场合约成交那一刻怎么验证属性。七种取值：none 不校验；requireEq 要求与下单时相等；requireNeq 要求不相等；剩下四种 requireUintLt、requireUintLte、requireUintGt、requireUintGte 把值按 uint256 比较，例如“分数不得低于下单时”。不满足条件时市场合约必须拒绝成交。这条机制的靶子就是属性抢跑：下单后把分数改走再等你成交。

标准自己泼的冷水

一个具体场景走完流程

设想一个带“战斗力”属性的游戏卡集合。合约侧登记 points 键，displayName 为“Total Score”，数据类型声明为无符号整数、小数位为零，并声明 validateOnSale 为 requireUintGte。挂单侧：卖家在 12:00 挂出卡牌，市场合约快照当时的属性值为 880。买家 12:05 签单支付，成交函数在转移代币前先调 getTraitValue 复取当前值——若有人在报价期内把分数改到 879，比较失败，交易按标准语义应当被市场合约拒绝，买家资金原路退回。攻击窗口从“改个 JSON 再广播”的几分钟，缩短为“抢在成交块内改链上值”的一口气。这就是它对付挂单欺诈的全部魔法：把属性变动从无声的链下换文件，变成一次要付 Gas、要进区块、要发 TraitUpdated 的显式动作，验证函数在成交那一刻有据可依。剩下的功课在参数：键名哈希算法、validateOnSale 声明是否存在、市场实现是否真的执行校验——三环缺一，纸面防线归零。顺带一句实操口径：属性上链后，行情站做“全集合属性分布图”从抽样估算变成一次批量 getTraitValues 即可成图，稀有度统计第一次有了不依赖索引员手工核对的公开底账，这也是它对数据侧最实在的贡献。

规范文本特意写明：即使市场侧有校验义务，买卖双方也不能完全依赖市场，交易发起前自己要再去链上读一次当前属性值。这句话翻译给持有人就是三步——先用 supportsInterface 确认 0xaf332f3e；再取 getTraitMetadataURI 弄明白每个键显示成什么、能不能被代币持有人自改（说明书里有 tokenOwnerCanUpdateValue 开关）；最后在签单前用 getTraitValues 现场对账。属性上链不等于属性永久不变，setTrait 的调用权在谁手里、按什么节奏改，仍然要从合约源码读起。本文为协议机制科普，不构成任何投资建议；标准状态以 ethereum/ERCs 仓库文本为准（核验时间 2026 年 9 月 9 日）。