授权失控的主流形态：无限期、无函数边界
用户在钱包里点下 approve 之后，常见的结果是一串额度加上一个不见到期日的记录：被授权方能动用多少额度写在链上，什么时候能停却没有默认答案，全靠用户想起来去撤销。ERC-1207 提出的 DAuth 是 2018 年的一份提案，想解决的不是「给多少额度」而是另一个维度：授权给哪些函数、活到哪个时间点。它把 Web 里 OAuth 的授权委托模式搬进智能合约，只是去掉中心化的授权服务器，改由资源合约自己记账。这份提案状态是 Stagnant，几乎没有生产部署，但「函数级白名单加过期时间戳」这套结构，恰好反衬出主流授权模型缺了哪两块。
AuthInfo：一份带截止时间的通行证
标准的记账核心是一个叫 AuthInfo 的结构，只有两个字段。funcNames 是函数名列表，写明被授权的合约能调用资源合约的哪些方法；expireAt 是秒级时间戳，过了这个点授权自动失去效力。资源合约用 userAuth 这个两层映射存它们：键是「授权者地址与被授权合约地址」这一对，值是 AuthInfo。也就是说 DAuth 的授权粒度从一开始就不是额度，而是「谁能动我的哪个函数、到什么时候」。用户视角的对应物是：签名确认页上看到的应当是函数清单和一个到期时刻，而不是一个数字额度。
生命周期：grant、regrant、revoke，每一步都有事件
授予用 grant，传入被授权合约地址、可调函数名清单（空格分隔的字符串）和到期时间戳，成功必须触发 Grant 事件。续期用 regrant，同样触发 Grant 事件。撤销用 revoke，直接删除这条授权并触发 Revoke 事件，提案把 revoke 与 grant 一并列为必需项，regrant 则用于在不换对象的前提下刷新函数清单和到期时间。事件字段把授权者、被授权者、函数清单和到期时间都写全。这套设计的实用价值在于可审计性：任何工具扫一遍事件日志就能列出「我在何时给了谁什么权限、何时过期」，不需要反查合约内部存储。被授权方每次调用前，资源合约的 verify 函数检查函数名在不在清单里、时间过没过期。
与 approve 模型的分歧在哪
ERC-20 的 approve 授权的是额度（allowance 数字），被授权合约在额度内做这笔代币允许的操作，且记录不过期；DAuth 授权的是行为（函数名）并且必然过期。两者不是替代关系而是不同象限：一个管最多能动多少钱，一个管最多能动哪些门。这也是读这类旧提案时最该带走的认知——评估授权风险时，额度、函数面、有效期是三个独立开关，现实中大部分代币只装了第一个。检查手上授权时，先把无限额 approve 归零或收紧，再核对连接过哪些合约，这条纪律对现有标准完全成立。
为什么值得知道它存在
DAuth 要求资源合约对被授权可调的函数提供两种重载：用户直接调的标准版，和带一个授权者地址参数的代理版，由合约校验授权链后代替用户执行。这个形状后来在 ERC-2771 一类元交易标准、各类委托执行框架里反复变形出现。读懂 grant 时定函数清单、到期自动失效、事件全程留痕这三件套，再看任何新型委托授权产品的文档，都能快速定位它把哪个开关装上了、哪个还空着。对普通用户，结论不变：授权页面上没有显示的边界，就等于没有边界；能选带有效期的授权就不选永久的。
用这份旧提案做授权体检的三个问题
把 DAuth 的三个字段反过来当检查清单用，比记住接口名有用得多。第一问函数面：这份授权在链上有没有写清我能调用你哪些函数？绝大多数代币授权的答案是否定的，这时你要评估的不是额度数字，而是被授权合约代码本身的权限面。第二问有效期：链上记录里有没有时间戳？没有，就自己设一个日历提醒，把「三个月后回来检查一次」当作流程而不是可选项。第三问事件留痕：授权与撤销会不会发出可检索的事件？会，你就多了一条免费的自查通道，扫一遍自己地址的日志即可复盘授权历史；不会，就靠截图与工具快照建立台账。三个问题问完，一份 Stagnant 提案就算完成了它的使命。授权相关操作只作防御性指导，不构成投资建议。 生成以太坊地址为什么免费？地址创建与链上激活的区别 连接钱包和撤销授权有何区别？
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。