EIP-5749 深度解读用window.evmproviders取代window.ethereum的多钱包互操作标准【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs导读EIP-5749 是 Ethereum Improvement Proposals 仓库README中一条状态为Final的 Standards Track / Interface 类提案由 Kosala Hemachandrakvhnuke于 2022 年 10 月提出。它定义了一个全新的浏览器全局对象window.evmproviders用于同时注入并发现多个 EVM 兼容钱包并建议最终取代长期占据统治地位的window.ethereum。读完本文你将掌握该标准的核心动机、ProviderInfo与ProviderWithInfo的完整 TypeScript 类型定义、钱包注入与读取的参考实现以及它与 EIP-1193Ethereum Provider JavaScript API和后续 EIP-6963Multi Injected Provider Discovery之间的继承关系与安全边界。背景window.ethereum单注入模型的困境在 Ethereum 的 web 应用DApp生态中浏览器钱包通过向网页注入一个 JavaScript 对象来暴露其 API这个对象被称为 Provider。这一惯例可以追溯到 2015 年的 Mist Wallet此后window.ethereum逐渐成为事实标准EIP-1193 将其 API 形态request方法、connect/disconnect/chainChanged/accountsChanged/message事件、ProviderRpcError错误码体系正式规范化。需要特别注意的是正如 EIP-1193 明确指出的Historically, Providers have been made available aswindow.ethereumin web browsers, but this convention is not part of the specification——window.ethereum仅仅是历史惯例并非 EIP-1193 规范的一部分。EIP-5749 正是抓住了这一缝隙主张用一个标准化、可容纳多个钱包的全局对象来替代这个惯例。window.ethereum的核心问题在于它同一时刻只允许一个钱包被注入。当用户安装了多个浏览器钱包扩展时扩展的注入顺序不可预测且不稳定后加载的钱包通常会覆盖先加载的钱包形成竞争条件race condition。EIP-5749 原文列举了截至 2022 年 8 月使用window.ethereum的主流钱包MetaMask、Coinbase Wallet、Enkrypt、Trust Wallet、Rainbow并指出在同一浏览器中安装多个此类钱包时用户会遭遇不一致的连接行为。这种单注入模型引发了一系列连锁负面效应竞争条件与不一致行为多钱包并存时连接行为不可预测导致安装和使用多个浏览器钱包变得不可靠、不切实际。虽然部分钱包选择注入自己的独立命名空间如window.ethereum之外的自定义对象但这要求每个 DApp 都要感知所有可能被使用的钱包不可行。赢家通吃的钱包市场竞争条件抑制了用户尝试新钱包的意愿在 EVM 链上形成了赢家通吃的钱包市场格局迫使应用开发者只为特定钱包体验做优化。抑制创新用户最多只能有一个注入钱包新进入者难以与老牌玩家竞争而老牌钱包也缺乏创新压力。拖累整个生态的 UX 演进钱包是与区块链交互最基础的工具同质化的钱包体验会阻碍整个生态系统的用户体验改进让其他更鼓励竞争与创新的生态后来居上。核心方案window.evmproviders对象EIP-5749 的解决方案非常简洁新增一个名为window.evmproviders的全局对象作为多个钱包 Provider 的注册表registry。每个钱包将自己的 Provider 注册到该对象的独立键名下从而彻底消除覆盖与竞争。该提案依赖 EIP-1193 定义的EIP1193Provider类型即实现了request(args: RequestArguments): Promiseunknown方法以及on/removeListener事件方法的最小化 Provider 接口。在此基础上EIP-5749 定义了三个核心 TypeScript 类型。ProviderInfo钱包展示信息/** * Represents the assets needed to display a wallet */ interface ProviderInfo { /** * A UUIDv4 unique to the wallet provider. * * This must remain the same across versions but must be different across channels. For example, MetaMask, Trust wallet and Enkrypt should each have different UUIDs, but MetaMask 10.22.2 and MetaMask 9.8.1 should have the same UUID. * * readonly */ uuid: string; /** * The name of the wallet provider (e.g. MetaMask or Enkrypt) * * readonly */ name: string; /** * A base64 encoded SVG image. * * Base64 is defined in RFC 4648. * * readonly */ icon: data:image/svgxml;base64,${string}; /** * A description of the wallet provider. * * readonly */ description: string; }ProviderInfo承载了在钱包选择弹窗wallet selection popup中展示一个钱包所需的全部资产四个字段均为只读readonly字段类型语义与约束uuidstring钱包提供者专属的 UUIDv4。跨版本保持相同、跨渠道必须不同。例如 MetaMask、Trust Wallet、Enkrypt 三者应各有不同的 UUID但 MetaMask 10.22.2 与 MetaMask 9.8.1 应共享同一个 UUIDnamestring钱包提供者的名称如MetaMask或Enkrypt用于界面展示icon模板字面量类型经 Base64 编码的 SVG 图片编码规范遵循 RFC 4648类型被收窄为data:image/svgxml;base64,${string}descriptionstring钱包提供者的文字描述ProviderWithInfo携带元数据的 EIP-1193 Provider/** * Represents the new Provider with info type that extends the EIP1193 provider */ interface ProviderWithInfo extends EIP1193Provider { info: ProviderInfo; }ProviderWithInfo是EIP1193Provider的扩展在标准的 EIP-1193 Provider 之上附加了一个info: ProviderInfo字段。类型EIP1193Provider的完整定义见 EIP-1193它要求 Provider 必须实现request(args)方法返回Promise当请求被拒绝时必须以ProviderRpcError形式抛出并遵循4001用户拒绝、4100未授权、4200方法不支持、4900全部链断开、4901目标链断开等标准错误码同时必须实现on与removeListener事件方法并规范了connect、disconnect、chainChanged、accountsChanged、message五个事件。EVMProviderswindow.evmproviders的类型/** * The type of window.evmproviders */ interface EVMProviders { /** * The key is RECOMMENDED to be the name of the extension in snake_case. It MUST contain only lowercase letters, numbers, and underscores. */ [index: string]: ProviderWithInfo; }EVMProviders是一个字符串索引签名对象键被建议使用扩展名的 snake_case 命名例如 MetaMask 扩展可对应metamask且必须只包含小写字母、数字和下划线值则是ProviderWithInfo。这样一个对象即可承载任意数量的已安装钱包从机制上杜绝了只有一个赢家的注入竞争。设计动机RationaleEIP-5749 在 Rationale 部分解释了三个关键设计决策标准化ProviderInfo的意义统一的钱包元数据结构让 DApp 或接入库能够直接获取渲染钱包选择弹窗所需的全部信息。这对 Web3Modal、Web3React、Web3Onboard 这类 web3 接入onboarding库尤其有价值——它们无需为每个钱包编写特判代码只要遍历window.evmproviders即可列出用户安装的全部钱包。命名evmproviders的考量选用evmproviders而非ethereumProviders之类的名字是为了覆盖所有 EVM 兼容链EVM-compliant chains而不局限于以太坊主网本身为多链生态留下空间。选用 SVG 图片格式的原因SVG 具备灵活性、轻量级以及动态缩放能力适合作为钱包图标的统一载体。向后兼容性EIP-5749不要求立即取代window.ethereum因此它不会直接破坏现有应用——钱包可以在继续注入window.ethereum的同时额外把自身注册到window.evmproviders。不过该提案的推荐演进方向是最终以window.evmproviders全面替代window.ethereum这一步骤将破坏仍然依赖window.ethereum的存量应用。因此从长期看应用开发者应逐步迁移将钱包发现逻辑切换到新的多 Provider 模型。参考实现Reference ImplementationEIP-5749 给出了两段极简的 TypeScript 参考实现完整覆盖了钱包侧注入与 DApp 侧读取两个方向。钱包侧注入const provider: ProviderWithInfo [your wallet] window.evmproviders window.evmproviders || {}; window.evmproviders[name] provider实现要点先构造一个带info元数据的ProviderWithInfo实例[your wallet]处替换为实际的 EIP-1193 Provider 对象用window.evmproviders window.evmproviders || {}做幂等初始化避免覆盖页面上已注册的其他钱包——这是多钱包共存的关键以 snake_case 的钱包名如metamask作为键写入自身 Provider。遵循EVMProviders的约束键名必须只含小写字母、数字和下划线。DApp 侧读取全部 Providerconst allproviders Object.values(window.evmproviders)一行代码即可枚举出用户当前安装的全部钱包 Provider。在此基础上DApp 或接入库可以进一步结合各 Provider 的info字段渲染钱包选择 UI并让用户主动挑选想要连接的钱包——这正是 Web3Modal、Web3Onboard 等库能够展示所有已安装钱包的底层机制。安全注意事项EIP-5749 明确声明EIP-1193 的 Security Considerations 全部适用于本提案。回顾 EIP-1193 的安全要点Provider 本质上是暴露在不受信任环境第三方网站中的 JavaScript 对象其所有属性都可被读取或覆写因此实现方应当把 Provider 视作被对手控制的对象来防护确保 Provider 不包含任何用户私密数据、Wallet 与 Provider 程序相互隔离、Wallet/Client 对来自 Provider 的请求做限流与数据校验。除此之外EIP-5749 特别强调了SVG 图标的 XSS 风险The use of SVG images introduces a cross-site scripting risk as they can include JavaScript code. Applications and libraries must render SVG images using theimgtag to ensure no JS executions can happen.SVG 中可以内嵌 JavaScript 代码若直接以innerHTML等方式渲染或直接内联可能触发跨站脚本XSS攻击。因此应用和接入库必须通过img标签渲染 SVG 图标——img标签不会执行 SVG 内部的脚本从而消除该风险。这是所有消费ProviderInfo.icon的实现必须遵守的硬性要求。生态演进从 EIP-5749 到 EIP-6963EIP-5749 采用全局对象注册表路线解决多钱包注入问题其作者之一 Kosala Hemachandra 随后又参与了 EIP-6963Multi Injected Provider Discovery的制定。EIP-6963 提出了另一套互补方案不再依赖全局对象而是通过window事件eip6963:announceProvider与eip6963:requestProvider让钱包与 DApp 进行双向通信从而实现多个注入钱包的发现。对比两条路线EIP-5749对象注册表结构直观、实现简单钱包写入window.evmproviders[name]DApp 用Object.values读取EIP-6963事件驱动避免了对全局对象的直接写入竞争通过事件握手让 DApp 实时感知钱包的安装、卸载与状态变化信息结构EIP6963ProviderInfo也演化出uuid/name/icon/rdns四个字段其中rdns用反向域名语法标识钱包。EIP-5749 与 EIP-6963 同属 Interface 类标准均以 EIP-1193 的 Provider 模型为底座。理解 EIP-5749 是理解后续钱包发现机制演进的基础——它为如何标准化描述一个钱包ProviderInfo提供了最早的成型范式这一思想在 EIP-6963 中得到了延续与深化。总结EIP-5749 以极简的设计回应了window.ethereum单注入模型长期积累的生态问题通过window.evmproviders对象注册表与ProviderInfo标准化元数据它让一个浏览器中同时安装、同时可用多个 EVM 钱包成为可能消除了注入竞争条件为钱包选择 UI 提供了数据基础并为新钱包进入市场降低了门槛。对于 DApp 开发者而言理解并跟进这一标准及其后继的 EIP-6963 事件机制意味着能够为用户提供更丰富的钱包选项与更稳定的连接体验对于钱包开发者而言遵循ProviderWithInfo接口与img标签渲染 SVG 的安全约束则是融入开放多钱包生态的第一步。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
