ERC-5453 Endorsement：把”谁批准了这个调用”塞进同一笔交易

permit 是一事一议，5453 想把批准做成通用附件

如果你用过 ERC-2612 的 permit 或 ERC-4494 的 NFT 免 Gas 授权，会注意到它们的共同限制：接口为特定行为设计——2612 管 approve、4494 管 safeTransferFrom——而且通常一签对一个人、要等一笔记在链上再执行下一笔。ERC-5453 的野心写在摘要里：为任意函数调用提供”同一笔交易内附加批准”的通用协议，支持任意多个批准人，从而在同一笔里凑出多签或阈值签署的效果。这份 EIP 创建于 2022 年 8 月 12 日，依赖 ERC-165、ERC-712、ERC-1271 与 ERC-5750，当前状态是 Last Call。

机制：目标函数本来就多了个尾巴

实现路线借力 ERC-5750——那份”Final 状态”的标准规定：函数最后一个参数若是动态长度的 bytes，实现必须容忍多余数据而不报错。5453 就沿着这个尾巴往里塞东西。合规合约的调用末尾附加一个扩展数据结构，内含魔数、类型标记、nonce、有效期上下界 validSince 与 validBy，以及背书载荷——载荷里是若干组”背书人地址加 65 字节签名”。合约执行时解析这段尾巴：对每组背书验证签名，核对被背书的操作哈希与有效期，全部条件满足才放行。规范用 ValidityBound 结构把三要素固定下来：被批准操作的参数结构哈希、生效起止时间、防重放 nonce。

与 permit 的本质区别用一句话说清：permit 是”先授权、后行动”的两步流程，背书是”行动连同授权书同一笔提交”。动机清单还列了另外几项：支持他人代付、多人协同（persons acting in concert）、票数累积与离线签名。

NFT 场景里它长什么样

组合起来最自然的画面是 DAO 金库卖藏品：传统做法要 N 个持有人分别提交或依次签名再拼交易，ERC-5453 结构下，召集人收齐各位对”这次挂单成交”的 EIP-712 签名，一笔交易里附上全部背书直接执行。另一个场景是小白用户的友好化：钱包把 Gas 交给付费方，付费方的批准作为背书塞进同一笔调用，用户只签自己那一份。

三条边界

第一，Last Call 不等于 Final：它处于征求意见收尾阶段，落地实现稀少，评估某合约是否支持时以合约自身声明与 ERC-165 探测为准，不能凭提案存在就假定功能可用。第二，签名内容与你的资产直接挂钩：背书签名授权的是”这一笔具体操作”，签之前必须确认魔数、目标操作哈希与有效期三样东西，否则一份宽松签名的杀伤力比普通授权更大——因为它能授权任意函数。第三，它扩展的是合约对调用数据的解读方式，签名体系仍由 712 与 1271 提供，你的多签钱包能不能参与 5453 流程，取决于钱包对 1271 的支持。

魔数与结构哈希：防的到底是什么

扩展数据结构开头那个魔数字段的职责是把”带背书的调用尾巴”和”普通多余数据”区分开：没有正确魔数的附加数据不应被解释为背书。而 ValidityBound 里的函数参数结构哈希，作用是把签名钉死在一次具体操作上——目标合约、目标函数、参数内容、有效期、nonce 五项共同构成被签名的内容，改任何一项签名即失效。这套设计与 ERC-712 域分隔符的思路同源：用结构化的可哈希文本，把”我签的那条消息”锚定到一个唯一的动作上。反推用户体验的要求就很清楚：钱包必须能完整展示被哈希的结构，一个只会弹”同意”按钮的界面，在这里等于签一张空白支票。确认签名前逐项核对 validSince 与 validBy 的窗口、nonce 是否首次使用，是 5453 场景下最关键的两次停顿。

底座 ERC-5750 的立场

5453 依赖的 ERC-5750 自身状态是 Final、创建于 2022 年 10 月 4 日，主张把动态 bytes 末位参数当作可扩展空间。这条”宽容尾巴”约定让大量协议可以后向挂载功能，也意味着同一笔 calldata 里可能藏着多份互不相识的附加协议——你的签名同时接受了几套解读规则，取决于目标合约认识哪个魔数。遇到复杂弹窗时优先在支持结构化预览的钱包里操作，把”尾巴里到底带了什么”看懂再签。

本文为协议机制科普，涉及授权签名的操作务必逐字段核对，不构成投资建议。