给 NFT 点赞要花 Gas 吗：ERC-6381 表情仓库的免签与防回放设计

“给这枚 NFT 点个赞”在社交平台是零成本动作，放到链上却一直是空白：每点一次赞都要发一笔交易，几乎没人会真的这么做。ERC-6381（Public Non-Fungible Token Emote Repository，公共非同质化代币表情仓库）给出的解法，是把回应数据放进一个独立的公共合约，而不是每套藏品自己的合约。规范文本记录其状态为 Final（最终），创建于 2023 年 1 月 22 日，覆盖 ERC-721 与 ERC-1155 两类资产。

仓库与藏品合约分家

这个仓库合约的设计点是“所有部署它的链上使用同一个地址”，规范文本特意让它以 0x311073 开头，用来呼应 EMOTE 的抽象形态。仓库不校验被回应的代币是否真实存在——你可以对一枚还不存在的代币“点赞”，仓库只记录“某地址对某合约某编号使用了某表情若干值”。表情本身直接用 Unicode 码点表示，不需要向任何机构注册一个表情编号。

正因为仓库不验证代币存在性，规范才建议：如果要在另一条链上回应某藏品，把藏品合约地址按那条链上的地址填写即可，同一地址恰好撞上别的系列的概率极低。

三种表态路径

第一是直接回应：emote(collection, tokenId, emojiId, emojiValue)，自己发交易，自己付 Gas，批量版本是 bulkEmote。第二是预签名回应：先调用 prepareMessageToPresignEmote 拿到一份待签名的 EIP-712 结构，签好名之后交给任何人代为提交 presignedEmote——点赞助的人不出网费，交易由代发方付。第三是查询：emoteCountOf 数某枚代币收到的某表情总量，hasEmoterUsedEmote 查某人对某枚代币是否用过某表情。

防重放靠链号

预签名带来一个经典风险：同一份签名被拿到别的链上重放。仓库的防护办法是把链编号写进 DOMAIN_SEPARATOR——每条链上的仓库合约生成的签名域都不同，A 链上签好的表情消息拿到 B 链提交会直接失效，仓库应当拒绝这种调用。换句话说，“免 Gas 点赞”的安全前提不是代发方可信，而是签名结构本身跨链不可复用。

后来者 ERC-7409

需要说明的是，表情回应这条路线后来由 ERC-7409 继续推进，把回应数据同样放进独立的“表情合约”，并把单枚资产的回应做成更细的接口。ERC-6381 文本中的很多设计——仓库不分藏品、不验证代币存在、依赖 Unicode 表情——都被延续了下来。读老资料时把两份提案当作同一条技术路线的前后两站，不容易混淆。

对普通用户意味着什么

不写解析器能核对什么

仓库设计留出了三个可以随手自查的查询面。emoteCountOf 数某枚代币收到的某表情总量，批量版本 bulkEmoteCountOf 把多枚代币拼进一次调用，省去挨个查询；hasEmoterUsedEmote 回答某地址对某枚代币用过某个表情没有——空投方用这个函数做“一人一票”式的互动核验时，你至少能自己先查一遍结果。所有回应记录都写入公共仓库而非藏品合约，意味着同一份数据可被任意市场引用，市场页面之间不应再造出互相矛盾的点赞数。如果你看到两个平台给出的回应总量不一致，先确认它们查的是否同一个仓库地址、是否同一份签名域下的记录，再判断哪边在缓存旧数据。

仓库模式的取舍

把回应放进公共仓库而不是藏品合约，是一种刻意的取舍：好处是任何集合零改造就能接入，坏处是藏品合约本身读不到这些回应——想把“被点赞数”写进自己的链上逻辑，项目方得主动去仓库查询，或者接受互动数据与资产合约彼此独立。理解这层分工，也就理解了为什么市场页面显示的点赞数依赖第三方统计，而不是藏品合约的出厂配置。

如果在市场里看到“链上点赞”“表情回应”功能，值得先弄清三件事：数据记在藏品合约还是公共仓库；预签名模式下你签的那份 EIP-712 消息里有没有写清过期时间与目标合约；以及这些回应数字只是互动记录，不代表任何所有权、份额或空投资格。回应写进链并不让它变成资产，这一点和点赞不会变成转账是同一个常识。本文为机制说明，不构成任何投资建议。