在去中心化应用的历史上有一段很多人已经忘记的默认设置：只要浏览器装了钱包插件，你打开的每一个网页都能自动读到你的账户地址，甚至能弹出一笔它替你构造好的交易等你点确认。改变这个默认状态的文本是 EIP-1102，由 Paul Bouchon 与 Erik Marks 在 2018 年 5 月提交，提案页面现标 Stagnant——不是因为没被采纳，恰恰相反，它的要求早已渗入所有主流钱包，变成不需要提案背书的行为规范。
从自动摊牌到敲门询问
提案描述里的旧世界分两步：网页检测注入对象存在，然后直接读地址列表继续跑。对钓鱼站来说这是天堂——它先看清你有什么，再决定演什么戏；恶意脚本还能不打招呼就发起交易请求。EIP-1102 提出的新流程多了一次显式请求：网页必须调用一个叫 eth_requestAccounts 的方法，钱包可以在响应前插入自己的用户界面，由人决定批不批。调用返回一个承诺对象：批准时解析为账户数组，任何原因拿不到账户——包括用户点了拒绝——都必须以携带原因的异常拒绝。协议对钱包的约束写得也具体：批准时至少要返回一个账户；等待用户操作期间可以悬着不返回；没拿到授权前，网页拿不到任何地址。
对网页开发者，这意味着初始化代码要重写：先请求，再使用。提案甚至点名当时的既有实现——某个主流插件团队已经把这套流程合并进产品——把标准追认成事实。提案早期还定义过一个名为 ethereum.enable() 的方法作为入口，后来被注明废弃，由 eth_requestAccounts 取代，这个细节解释了为什么老教程里两种写法并存。
这条防线挡住了什么、挡不住什么
值得把边界说清。授权门控解决的是两点：地址不再被全网静默扫描，钓鱼页也无法在你没点连接的情况下凭空排队交易请求。但它不验证网站本身的可信度——批准连接后，网站只是看见了地址与链上公开信息，签名和转账仍需逐笔确认；它也不阻止网站用别的方式画像，比如追踪你之后发起的请求特征。所以把”拒绝连接”当成隐私开关是对的，把它当安全保险箱则不对：真正值钱的门槛在每笔签名弹窗上。后来的 EIP-2255 权限接口、CAIP 系列账户发现规范，都算是把这一刀切的是/否继续拆细的后续工程。
一条判断线
用户端可以把自己的决策压成三问。这个站需要地址做什么？展示余额与身份识别只需要读，不需要你签任何东西——凡是要你签名或授权的”读取”都是话术。拒绝连接会损失什么？多数站拒绝后仍可只读浏览，损失几乎为零。站点是钓鱼镜像吗？连接授权挡不住域名仿冒，核对域名永远排在点批准之前。
快速问答
问：为什么有的网站不弹授权框也能显示我的地址？ 答：多半是你此前已在该域名批准过，钱包按站点记住了授权，静默重放同一结果；在钱包的站点权限列表里可以逐个撤销。
问：eth_requestAccounts 和列举账户的只读方法差在哪？ 答：前者可能触发授权界面、后者按规范在未授权时返回空列表——两者配合才构成完整的 opt-in 语义。
一次钓鱼的完整旅程
用一单攻击复盘边界。钓鱼站拿到你的地址后，能做的仍然有限：它查你的持仓、拼出一封”你的代币即将过期”的页面，引导你点某个按钮。真正交出资产的时刻，永远是签名弹窗上那份人类可读的授权内容——批错了授权，后面的静默就都合法。所以防御顺序应该是：域名核对在连接前，授权范围阅读在签名前，而连接那一问只是把攻击者的侦察成本抬高，并不替你做任何金额判断。这条提案的贡献是把这一问变成协议强制，它防的是无差别扫射，不是精准社工——认清这一点，才算用好这道门。
风险提示：连接授权只是隐私边界，不构成安全保证；授权前核对域名与合约地址，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。