不花 gas 设定操作人:ERC-7741 用一份 EIP-712 签名授权或撤销 operator 图 1
不花 gas 设定操作人:ERC-7741 用一份 EIP-712 签名授权或撤销 operator · 图 1

不花 gas 设定操作人:ERC-7741 用一份 EIP-712 签名授权或撤销 operator

有些协议把”替我动手的人”叫 operator:它可以代你提交申购、赎回这类请求,而资产仍记在你名下。麻烦在于,每设一次 operator 都要自己发交易、付 gas,跨链用的时候更是每链都要来一遍。ERC-7741 给出了一条省事的路:把授权动作本身变成一份链下签名,谁想落地这份授权,谁就替你把交易提交了。标准文档记录的状态为 Draft,创建于 2024 年 6 月 3 日,最新状态以标准仓库为准。

适用对象与四个部件

这套签名方案适用于实现了 operator 模型的合约,也就是暴露 setOperatorisOperator、并发出 OperatorSet 事件的那类接口,ERC-6909 与 ERC-7540 型金库已经天然符合。在此之上,ERC-7741 要求合约提供 authorizeOperator:参数依次是 owner(资产归属人)、operator(被授权地址)、approved(授权还是撤销)、nonce(32 字节随机数)、deadline(截止时间)和 signature(EIP-712 签名)。调用成功必须发出 OperatorSet 事件并返回真;deadline 过期、签名无效、nonce 用过,任何一种情况都要整体回滚。另有三个辅助件:invalidateNonce 让本人提前作废某个签名里写的 nonce;authorizations 查询某个 nonce 是否已用;DOMAIN_SEPARATOR 按 EIP-712 生成,用合约与链的信息把签名钉死在本协议本链上,防止跨场景重放。合约还必须实现 ERC-165 探测,接口标识为 0xa9e50872

对不熟悉金库类协议的场景,可以这样理解 operator:把它想成你在家门口给保洁公司留的临时门禁码——进门权限是你主动给的,何时给、给哪扇门、给到几点,都应该由你控制。ERC-7741 把”给门禁码”这个动作从”你亲自跑一趟物业(发交易付 gas)“改成”你在家写好纸条(链下签名),快递公司顺路送去(服务方代提交)“,控制权和撤销通道仍然在你手里。

不花 gas 设定操作人:ERC-7741 用一份 EIP-712 签名授权或撤销 operator 图 2
不花 gas 设定操作人:ERC-7741 用一份 EIP-712 签名授权或撤销 operator · 图 2

与 ERC-2612 相像,但 nonce 换了逻辑

设计说明里坦承这套规范刻意贴近 ERC-2612 的 permit,方便熟悉的人直接迁移。关键差别在 nonce 的形态:2612 用递增计数,一次只能推进一份签名;7741 用 32 字节随机值,理论上你可以同时准备许多份互不干扰的授权签名,各自带不同的有效期,谁先用、用哪份都互不影响。这对需要频繁切换 operator、或在多条链并行维护授权的协议很友好。参数命名上也留了余地:同样的模型在 ERC-6909 里对应的是 spender 而非 operator,含义可互换。

签之前要想清楚的三件事

第一,operator 的权力不小,它能代替你触发金库的请求流程。签名前确认被授权地址是官方合约或你完全理解的服务方。第二,deadline 要设得尽可能短。标准的安全考量写得很明白:签名一旦在不该出现的地方出现,剩余有效期就是风险敞口,过期时间越短,泄露的后果越小。第三,用完即废。已经落地的授权对应 nonce 会自动标记为已用;没落地却可能泄露的,主动调用 invalidateNonce 作废,别指望”没提交就没事”。

落到日常操作:怎么查、怎么撤

普通用户可以用三步管理这类授权。第一步,授权前读签名弹窗:EIP-712 规范的签名会把 owner、operator、approved、deadline 拆成字段展示,任何一个字段显示为看不懂的原始哈希或被折叠,先停手。第二步,授权后留一个自查动作:在区块浏览器里对协议合约调用 isOperator(你的地址, 被授权地址) 确认状态与预期一致;再调用 authorizations 确认 nonce 已标记为已用,说明这份签名不能被二次提交。第三步,定期清理:更换钱包或停止使用某个金库服务时,用 authorizeOperator 把 approved 设为 false 撤销授权,再把可能残留的旧签名对应 nonce 用 invalidateNonce 作废。

日常排查也有一条实用经验:如果某次操作免 gas 却失败了,先查签名窗口是否已过、nonce 是否被用过,再怀疑服务本身。跨链场景下还要注意 DOMAIN_SEPARATOR 与链绑定,把 A 链上签好的授权拿到 B 链提交会因域不匹配而失败,这是防重放设计生效的表现,不是漏洞。

本文只讲协议机制与安全实践,不构成任何投资或买卖建议;对任何要求先转账、先授权才可”激活操作人”的客服话术,一律先按钓鱼处理。

最后补一个容易被忽略的问题:授权与资产是两层记录。operator 只能触发请求流程,不拥有你的资产,也不因为一次授权就获得取款路径;反过来说,若某个协议声称”设了 operator 就能替你领取 NFT 奖励”,那描述的是它自己的业务接口而非本标准的设定,看到这种话术先回到协议文档核对函数签名,再决定要不要签。