网页想发交易，当年只有两条路
今天你在网页上点一个按钮，钱包扩展弹出确认框，看完内容按一下就完成——这套”先过目、再放行”的默认流程，在 2016 年并不存在。那时的生态里没有主流浏览器钱包，dApp 要读写链上数据，最直接的通道是调用你本机运行节点的 JSON-RPC 接口。问题是浏览器基于同源策略会拦住这种跨域调用，于是出现了 EIP-107，作者在 2016 年 6 月 5 日提交，状态至今是 Stagnant（停滞）。它想解决的不是新功能，而是一个安全性缺口：怎么让普通浏览器里的网页用上节点账户，又不把账户控制权整个交出去。读懂这个最古老的接口层提案，能帮你看清今天钱包弹窗里每一行提示的来历。
CORS 开关的二难：打开就等于交出全部解锁账户
提案的动机部分把当年的困境写得很直白。要让网页能访问节点 RPC，用户往往需要给该网站的域名开启 CORS 跨域许可；可一旦开了，这个网页就能对节点上任何处于解锁状态的账户直接发起 eth_sendTransaction——不需要你点任何确认，钱就可能被动。换句话说，“用得上”与”守得住”被绑在同一个开关上，用户被迫在信任网站和放弃使用之间二选一。当时的临时绕法也很别扭：普通转账被引导去独立的钱包软件里手工填一遍，复杂交互则要求用户懂得用节点命令行拼交易。提案认为这种既要改节点默认配置、又要用户无条件信任网页的结构不可接受，这正是今天”最小授权”思想在以太坊接口层的早期版本。
提案的解法：只读走代理，写入走弹窗
EIP-107 给节点设计了一套双面接口。所有只读的 RPC 调用被静默重定向到节点自己域名下的一个隐形 iframe，由节点代为执行，网页拿到数据但得不到任何权限。而任何想上链的写入操作，节点都会弹出一个 HTML 确认窗，展示这笔交易的内容，由用户选择取消或确认——账户处于解锁状态时看到的就是这一屏。如果账户是锁定的，且节点开放了 personal 系列接口，弹窗还会提供一个密码框，让用户只为这一笔交易临时解锁。整套设计的核心是不给网站任何权限：网页永远只是请求方，“同意”这个环节被固定在用户与节点之间，第三方无从代答。
它为什么停在原地
这条路线要求每个节点都长出一套面向浏览器的授权界面，而当年节点软件的目标用户是运维与开发者，内嵌一个确认弹窗意味着把密钥管理、界面安全、浏览器兼容全揽进节点仓库。生态随后果然分叉出了另一条路：把授权界面做成独立的钱包扩展或独立客户端，节点退居纯数据端。今天 MetaMask 等扩展的确认弹窗、一条通道完成连接：ERC-7846 的 wallet_connect 把授权与登录合成一次弹窗 里把连接与登录合并进一次弹窗的 wallet_connect，走的都是”界面归钱包、数据归节点”的分工。EIP-107 因此失去推进动力，但它主张的原则——每笔交易单独确认、授权不给网站、临时解锁只覆盖单笔——几乎被后来的钱包全盘继承。
今天的残留风险：自建节点加暴露 RPC
提案的幽灵在今天并未完全消散。自己跑全节点的技术用户，若把 RPC 端口暴露到不信任的网络环境、长期保持账户解锁，等于复刻了 107 想修补的原始困境：任何能访问该端口的程序都能替你发交易，而且没有弹窗。合理的边界是把 RPC 只绑定本机回环地址、为网页使用专门的钱包扩展而不是共享节点的解锁账户、钱包密钥与节点数据目录分离存放。怀疑某台公共 RPC 有此类行为时，可用 eth_chainId 怎么确认你现在在正确的链上？ 的方法核对链号，并观察它在未确认情况下是否就能改变你的账户状态——能，就是危险信号，应立即停止使用并检查该账户授权记录（参见 区块浏览器怎么读：确认数、失败原因和交易状态逐项解释 的浏览器核对路径）。
三点可带走的经验
第一，“连接不等于授权”这条常识有具体的技术史：107 之前的世界里连接就是全部授权，今天所有钱包产品把两者拆开，正是这类早期提案提出的问题推动的。第二，判断任何新工具的授权模型时，可以问一句它有没有独立的同意环节、同意的粒度是单笔还是整个网站，答案直接决定事故半径。第三，接口层的兼容债会长期存在：你今天签的每笔交易仍在走 107 时代的 eth_sendTransaction 语义，理解这一层，才知道扩展报错、网站连不上钱包时问题出在哪一环。本文为机制科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。