你在陌生网站点下连接钱包的那一刻，其实发生了一次没有书面凭据的授权：钱包给了这个网站读账户地址的能力，也许还有签名请求的通道，但事后你想查这笔授权给了谁、管多大范围、怎么撤销，绝大多数钱包答不上来。EIP-2255在2019年8月提出给这件事补一张标准清单，两个RPC方法加一套数据结构，提案状态是Final。它没有改变任何链上规则，做的是给钱包和网站之间的权力关系建立可查询的账本。
两个方法各查什么
按规范，钱包提供方新增wallet_getPermissions和wallet_requestPermissions。前者无参数，返回一张权限数组，默认为空；后者让网站申报想要的能力，钱包负责弹窗确认。数组里每一条权限记录由三部分组成：invoker是发起方的来源标识，比如网站的域名；parentCapability是被授予的方法名，比如读取账户列表；caveats是一串附加限制，每条限制有类型和值，值本身是任意JSON，含义由类型决定。这个结构的野心藏在caveats里：权限不是有没有的问题，而是带什么镣铐的问题——只允许访问某一个账户、只允许在某个时间前签名，理论上都能用一条caveat表达。
权限模型的前史
这份提案不是凭空画的。网页端连接钱包的鼻祖协议是EIP-1102定义的enable方法——本质上是一次性的全有全无授权。2255把授权从一次性握手升级成持续可审计的关系记录：谁在什么时候被允许调用什么，全部落成可枚举的对象。设计血缘上它借用了浏览器权限管理的样子：网站要用摄像头先申请，授权有作用域，用户能在设置页逐条撤销。钱包行业的现实进度则是另一套叙事——主流钱包普遍实现了连接确认，但把完整权限清单开放给用户的少之又少，2255的接口在很多实现里名存实亡。
为什么标准赢了、普及慢了
从协议政治看，2255的Final状态说明接口本身没有争议；从工程看，难点全在钱包侧的权限存储：记录要活过浏览器重启、跨设备同步、用户改密码，还得提供撤销界面；从交互看，逐次弹窗询问权限会把用户弹疯，默认宽松加事后清单又要求用户真的会去翻清单。三层难度都不是规范文本能解决的，于是出现了微妙的错位：接口在纸面上已经是标准，各家钱包的用户界面仍各自为政。对普通用户的实用推论是：别依赖钱包替你做授权审计，用链上授权管理工具和交易模拟插件自查才是当下的正解。
一份权限记录长什么样
把规范里的数据结构翻译成日常语言。一条记录读作：来自某个网站的调用，被允许使用某个方法，附带若干镣铐。invoker字段锁来源，锁到源粒度，同域名不同页面共用一条记录；parentCapability锁能力，粒度精确到单个RPC方法，而不是连账号一把梭；caveats挂镣铐，每条有类型有值，比如限制这个授权只对某一组账户生效。这套形状妙在它把用户的三件心事写成了可查询对象：我给了谁、给了什么、能不能收窄。现实落差在于钱包对caveats的支持：记录一个网站读过哪些账户，多数钱包做得到；限制它只能看第二个账户，几乎家家沉默。规范给了形状，落地深度取决于产品愿不愿意把撤销做成主界面而非彩蛋。
快速问答
问：这和更早的账户暴露提案是什么关系？ 答：早期提案解决的是连接瞬间一次性给不给账户的确认问题；2255把授权升级成可持续查询的记录，两者互补，也都未完全改变各家钱包的私有实现。 问：caveats现在有人实现吗？ 答：规范允许类型自由注册，部分钱包实现了限制账户范围这类单点功能，没有形成通用生态。 问：这跟钓鱼防护什么关系？ 答：权限清单让授权可见，但防钓鱼靠的是可见之后的行动，两者不可互相替代。
风险提示：本文描述接口标准与钱包机制，不构成任何投资建议，也不构成对任何钱包产品的安全背书。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。