把权限当代币管：ERC-6366 与 ERC-6617 的位掩码权限模型

链上系统最常见的安全对象其实不是钱，而是“谁有权对钱做动作”：Owner、Operator、Validator、Manager……传统写法是在合约里塞一串映射表和角色字符串，改权限要逐个调用专用函数，多系统之间的权限关系难以统一审计。ERC-6366（Permission Token）给出的思路是把权限本身做成一类代币：每个地址在一个“生态”里持有一个 uint256 数字，数字里哪些位是 1，就代表拥有哪些权限。它依赖底层的 ERC-6617（Bit Based Permission）定义“一个比特位代表一项权限”的表示法。两个提案目前都处于 Review（评审）状态，属于仍在演进中的应用层设计，使用前必须确认目标合约的真实支持情况。

一个数字装下一套权限

按 ERC-6617 的表示法，每项权限对应一个 2 的幂，也就是 uint256 中的一个比特位；一组权限的集合就是这个数字的按位或结果。ERC-6366 的接口建议实现者把每项权限定义为 2 的幂，这样判断“某地址是否同时具备 A、B、C 三项权限”就退化为一次位与运算，比逐个比较字符串或哈希又便宜又直接。

核心接口定义了几个关键成员：

• hasPermission(address _owner, address _actor, uint256 _required)：查询某地址在某所有者授权下是否覆盖所需权限集合。
• transfer：把一组权限移交给别的地址；权限变化通过 Transfer 事件记录。
• approve：授权给委托方，触发 Approval 事件。
• 元数据接口可选实现，用字符串命名各项权限，方便前端展示。

与 ACL、RBAC 的区别

在访问控制列表（ACL）模型里，权限记录散落在每个合约内部；在角色模型里，角色名是自由字符串。位掩码模型的价值是把“权限集合”变成一个可以被数学比较的对象：两个地址的权限交集、包含关系都能用位运算当场算出，跨合约审计时也能把一整套系统的授权状态浓缩成一组数字来核对。规范文档强调这种设计“比字符串或 keccak256 比较更高效灵活”，并把可跨生态互操作作为主要动机。

这套模型的新风险面

把权限做成“可 transfer 的代币”是一柄双刃剑。第一，可转移意味着可被盗：一旦地址沦陷，攻击者转走的不只是某个合约的一次性授权，而是一整张权限画像。第二，位掩码的抽象容易越权误配——把 _required 参数多设一个比特位，语义上就可能从“要求同时有 A 和 B”变成检查一组从未想过要授予的组合权限。第三，提案仍在 Review，不同实现的函数签名与权限编号分配尚未收敛，跨项目复用同一套编号体系并不安全。

使用与核验建议

看到项目宣称“基于 ERC-6366”时：确认它引用的 ERC-6617 权限编号表是否公开；用 hasPermission 对关键管理地址做一次实际查询，把返回值与团队公开承诺的权限矩阵对照；关注 Transfer 事件历史，权限代币的异动就是管理权的地震仪。对普通用户，最实用的一条是：这类系统里“持有权限代币”与“持有资产”是两种风险敞口，钱包隔离策略应当把它们分开对待。

把模型放进真实系统里看

设想一个 DAO 管理着一组协议合约：旧办法里，国库合约、保险池合约、预言机合约各自维护一套角色映射，审计时要翻三个合约的管理函数清单；如果各合约统一接入 ERC-6366，可以把“谁是审计员、谁能暂停、谁能升级”映射到同一棵权限代币树上，一次 hasPermission 查询胜过跨合约拼装。这也是提案强调“不同生态间的互操作性”的语境——权限的表达方式统一后，跨系统的授权图谱第一次成为可计算对象。但同一件事的反面是：一次签名失误或一个权限位分配错误，可能被多个系统同时“正确地”执行，标准消除了表达歧义，也消除了旧式系统中各合约独立设防带来的缓冲层。

与钱包权限请求生态的衔接

位掩码权限与近年兴起的钱包侧权限协商思路天然契合：把“请求某应用在一定期限内执行某类调用”翻译成一段权限子集，用户在钱包里确认的不再是一串看不懂的 calldata，而是一次明确的权限授予。ERC-6366 规范文本本身没有规定 UI，但位掩码这种“可枚举、可集合比较”的表示天然适合渲染成清单。对用户的实际提醒是：任何以“权限代币”形式出现的授权，都请像对待资产一样对待它的转移记录——它转移时不会经过你的转账页面，却同样改变风险敞口。

权限模型属于系统安全设计，本文只做机制科普，不构成投资建议，也不构成对任何合约安全性的评价。