注入之外的第三条路
网页与钱包的沟通标准是 EIP-1193 定义的请求接口，钱包主动广播身份则见多播发现提案 EIP-6963，网页怎么在一堆钱包扩展里找对的那个：EIP-6963 与多钱包共存 里拆过它的用法。在 网页请钱包签名前那份英文名单：EIP-1193 的 Provider 接口与事件 那份 Provider 接口规范成型前后，还有一个更安静的思路：不注入脚本、不监听事件，而是利用浏览器最古老的机制——协议处理器。2023 年 5 月提交的 EIP-7039 就是这个方案的规范文本，作者给它起的绰号叫 SHADOW，目前状态 Stagnant。
连接的五步
按提案写法，网页发起连接分五步：先在窗口上监听 message 事件；再创建一个 src 指向 web+evm:// 的空窗口并挂进页面；浏览器会问系统——这个协议的活儿谁接？已安装并注册过的钱包便来应答；应答以一条消息投递回来，第一份消息可以附带钱包的名称与图标；网页保存下应答里的首个通信端口，此后两边就在这条通道上说标准的 JSON-RPC 话——请求体必须满足 EIP-1193 的 RequestArguments 接口，回答里结果与错误二者只居其一。这套流程里没有任何”权限申请”弹窗：网页自始至终只是往一个空窗口塞了个地址。
信道可以直连，身份必须验来路
提案有个细节：应答方可以把一条专用回线作为端口的首项转移过来，之后的请求和回答直接在这条线上跑，空窗口彻底靠边站，只做一次引荐。好处是省掉中转，代价全落在同一点上——通道越安静，越依赖双方的自觉。提案的安全部分只写了一句话，主语是双方：网页与钱包都必须先验证每条消息的来路再采信。能发消息不等于有资格发消息，这与 网页递给钱包的话会不会被偷改：ERC-7754 TWIST 的签名请求机制 里”把裸消息变成签了名的请求”是同一个担忧的不同侧面。提案自己的安全章节还挂着待完善的标注，整个方案的状态也停在 Stagnant，没有走入任何主流钱包的实现路线。
它照出的真问题
协议处理器注册的逻辑是：谁在系统里登记了 web+evm，谁就有资格应答。这个”谁都能应答”的世界，后来被 网页怎么在一堆钱包扩展里找对的那个：EIP-6963 与多钱包共存 讲到的多钱包发现规范用另一套办法处理了——让所有在场者自报身份、由用户挑。对普通用户，值得记住的结论有两条。其一，网页与钱包之间的桥不止一种：脚本注入、iframe、系统协议唤起，各有各的信任假设；你批准”连接”的那一刻，真正该问的是这条桥上的信息会不会被中间人改写。其二，主流流程里网站能看到的账户列表来自你的授权而不是扫描；若某个页面声称”自动发现你全部钱包”却不弹任何授权界面，这比”走了哪条发现路线”更值得警惕。
从系统设置里能看到的那一行
这套机制有个特殊的可观测面：协议处理器注册最终落在操作系统层。在桌面系统上，装一个支持 web+evm 的钱包，往往会在系统的默认应用或协议处理列表里留下一行登记；反过来，这行登记本身也可以被恶意软件写入。于是排查思路和普通扩展不一样——如果你从不记得装过某个钱包，却在系统协议列表里发现了陌生条目，它的风险等级和浏览器里多出一个陌生扩展相当，值得当作入侵痕迹处理。清理时也要按这个顺序来：先在钱包与浏览器里断开网站连接，再回到系统层删除协议登记，最后重启浏览器确认网页上的连接按钮彻底没反应——只删系统登记而留着旧的网站授权，等于关了一扇门留着窗户。
本文为技术说明，不构成投资建议；任何连接与签名请求都请先核对发起方与范围。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。