你装了三个钱包扩展，打开一个 dApp 点“连接钱包”，弹出来的却是你没用过的那个——这不是 bug，是旧约定的历史包袱：所有钱包都抢着注入同一个 window.ethereum 对象，谁最后加载谁“赢”（dApp 连接的总体流程见 dApp 是什么？它和你常用的 App 差在哪）。EIP-6963 用一套标准的“自我介绍协议”替换了这场注入竞速。
旧约定：一个全局变量引发的排队
早期的网页钱包接口建立在单一全局对象上：钱包向页面注入 provider，页面调用 ethereum.request 发起连接。多钱包共存后问题浮现——对象只有一个，覆盖顺序取决于扩展加载次序，页面的“自动检测”经常连到错误钱包；钱包们不得不往事件名、全局变量别名上打补丁互相避让，形成脆弱的军备竞赛。用户侧的体验是：装了新钱包，旧站点的连接行为悄悄变了，而且没有任何报错。
发现协议怎么改写规则
2023 年进入 EIP 仓库的 EIP-6963（当年下半年起被主流钱包集中上线，以各钱包官方变更日志为准）把“谁在场”从覆盖式注册改为广播式公告：每个钱包在页面加载时派发标准的提供者公告事件，携带自己的名称、图标、 rdns 反向域名标识与支持的方法列表；页面监听事件，把发现的钱包列成菜单，由用户点选。选定后页面再与该钱包的 provider 建立会话——底层仍走 JSON-RPC 那套请求响应（连接请求的隐私与信任边界见 广播之前，你的交易经过了谁：公共 RPC 节点的隐私与信任边界，RPC 概念背景见 RPC节点是什么？钱包风险）。关键在于：注入冲突没有消失，而是被移交给了“用户显式选择”这个更合适的仲裁者。
对安全边界意味着什么
发现协议本身不鉴权：公告事件里的名称与图标由钱包自称，恶意扩展同样可以广播一个伪造名字——这延续了扩展生态的一贯现实，识别责任仍在用户核对（域名与弹窗核对方法见 WalletConnect Verify能防钓鱼吗？）。改进在于副作用可预期：旧模式下“页面连了谁”受加载顺序这种用户不可见因素影响；新模式下选择动作可见、可复核，配合钱包在签名请求中展示来源站点（EIP-1193 请求上下文与 EIP-1102 权限请求等配套约定以 EIP 仓库当期文本为准），把“错误钱包替我签了字”这类事故的路径显著收窄。
快速问答
问：怎么判断我用的钱包支持？看官网变更日志是否标注 EIP-6963 支持，或观察多扩展场景下站点是否出现钱包选择菜单。 问：旧站点还能用吗？能，钱包普遍保留旧的全局注入做兼容，6963 是加法而非替换；两种模式的差异体现在多钱包页面。 问：rdns 是什么用途？类似 com.example.wallet 的反向域名标识，给程序一个稳定的钱包身份键，避免靠显示名区分。 问：移动端有对应问题吗？移动场景走 deep link / 钱包跳转协议，选择逻辑由系统级弹窗承担，不走这套事件协议。
常见误区
一是把 6963 当安全标准：它是发现层协议，不改变签名授权模型，防不了假钱包仿冒名字。二是以为它会移除注入冲突：旧全局对象仍在，未升级的站点继续按旧规则排队。三是把“弹出选择菜单”误判为钓鱼特征：菜单本身是正常交互，核对站点域名和钱包名称才是判断依据。
小结
EIP-6963 解决的是多钱包时代的第一道 UX 裂缝：让页面先问“你想用谁”，而不是替用户决定。它把隐性的加载顺序竞争变成显性的选择动作——对协议来说是很小的一步，对“连错钱包签错字”这类事故是一层真实的护栏。
风险提示：本文解释接口协议机制，不构成投资建议；安装钱包扩展请以官方渠道为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。