ERC-5050：让 NFT 互相发消息的 sendAction 协议

你的一枚 NFT 能“触碰”另一枚 NFT 吗？比如一只链上宠物走到另一件藏品面前打个招呼、一把钥匙试着开一扇藏品门。普通合约时代这没有标准写法。ERC-5050（ethereum/ERCs 仓库，状态 Stagnant，2021 年 4 月创建）定义了一种代币之间的消息协议：动作从一个代币发往另一个代币，中间可以站一个仲裁的“环境”。

三种角色与一条消息链

协议里最多有三方：发送方代币、接收方代币、可选的环境合约（controller/environment）。发起端调用 sendAction，把动作名称、双方坐标、双方主人等参数打包；接收合约实现 onActionReceived，带着类型标识与双方地址逐一核对“这个动作我接不接”；动作完成后广播 ActionReceived 事件。双方还能声明能力清单：sendableActions 与 receivableActions 返回各自允许的动作字符串数组，配合 interfaceURI 指向说明文档。整条链上，代币本身可以不持久化任何状态——状态寄存在环境合约里，这就是提案说的“模块化有状态”。

授权链别跳着签

交互类协议最怕“被动作”，提案为此配了三层授权：approveForAction 针对某个具体动作放行、ApprovalForAllActions 放开某方全部动作、setApprovalForAll 走传统代理授权；接收侧还有控制器维度的 ControllerApproval。安全部分把话说死：任何合约在没有收到持有人事先授权的情况下执行动作，都视为被劫持。对使用者意味着：给互动 NFT 签名前，先想清楚放行的是“一次打招呼”还是“随便调用我的全部动作”。

它停在哪，又留下了什么

一次互动的完整调用栈

把 5050 的一次典型动作从点击追到事件，看清它为什么叫“协议”。用户 A 的宠物币 42 对雕塑币 7 发出动作 pet，钱包端调用宠物合约的 sendAction，参数里带上双方代币合约地址、双方编号、双方主人、动作类型与目标环境地址；宠物合约先查 sendableActions 确认 pet 在发送方的允许清单，再查 A 对该动作的授权状态，通过后向环境合约转发；环境合约若有规则（冷却时间、距离条件、次数上限）在此裁决，随后调用雕塑合约的 onActionReceived，传入动作类型、双方合约与主人地址；雕塑合约查 receivableActions 决定是否响应，改不改状态取决于其自身实现；最后 ActionReceived 事件入账，索引器拼出完整互动史。整个链条五跳，Gas 也按这个规模计——这解释了提案为什么更适合低频高意义的互动（赠礼、解锁、结盟），而非高频小动作。对使用者，链条给了三个检查点：自己的 approveForAction 记录里有没有陌生账号、目标环境的 interfaceURI 文档是否可读、事件流里的动作统计是否与界面宣称一致。

互动协议的安全常识两条

第一条：动作接口的攻击面在展示层。用户看到的“打招呼”按钮背后可能是任意 bytes4 动作类型，钱包若不解析 sendAction 的参数，就永远无法区分问候与攻击，使用互动功能前确认钱包是否显示动作标识与目标合约。第二条：环境合约是规则的心脏，冷却、上限、解锁条件都在它里面，它的升级机制决定规则会不会半夜改姓——可升级环境等于项目方保留随时重写物理定律的权力，看到此类合约应把信任预算调低一档。两条常识放进任何互动类藏品的评估流程都通用。

Stagnant 状态背后是现实成本：每个动作一笔交易、费率劝退轻交互、互动场景多被游戏内账本消化。但它留下的问题意识越来越常被重提：钱包和浏览器能不能像读邮件一样读到“你的藏品最近对谁做了什么”？答案就藏在有没有实现这套事件与查询函数上。看到标榜“链上互动”的项目，可以照清单核对：有没有 sendableActions 声明？动作事件是否上链？仲裁环境是否可被项目方随时改规则？它说明代币间的交互可以被消息化、审计化，不能说明轻交互在经济上已经可行。本文仅解释标准，不构成投资建议。