网页递给钱包的话会不会被偷改：ERC-7754 TWIST 的签名请求机制

弹窗之前，请求已经可能被改过

你看到的签名弹窗，是网页代码一路递给钱包的结果。这条内部通道在传统架构里是裸奔的：页面里的注入脚本、被入侵的前端依赖、恶意浏览器扩展，都有机会在请求抵达钱包之前调包内容——改收款地址、改 EIP-712 参数、把一次签名的成果挪用到另一笔交易。前端依赖投毒类事件已经反复演示过这条攻击面的存在，思路可以回看 官网没被改，脚本先变坏：前端依赖投毒与签名请求防线。ERC-7754 即 TWIST 针对的就是这一环：让应用给自己的请求签名，钱包验过签名再干活，使中途篡改在数学上变得不可能。这份 ERC 状态为草案（Draft）。

信任链怎么搭

原文给出一条完整链条，每一步都能独立核验：先由浏览器验证域名的传输层证书，确认可信；该域名的 DNS 记录里放一条 TXT 指向一个公开清单地址，规范示例建议放在域名的 well-known 路径下；清单里是一组带标识、算法和公钥的条目；应用后端用对应私钥对请求载荷签名；签名后的请求经新的 wallet_signedRequest 方法送入钱包；钱包取回公钥验签，通过才按正常流程处理。整体思路类似于电子邮件里的 DKIM 域名签名，只不过对象换成了钱包请求。

规范给了一份清单文件的示例形态：每个条目含 id、alg、publicKey 三个字段，允许一把或多把钥匙、不同算法并存。id 的作用是在请求里点名用的是哪把钥匙，轮换密钥时新旧条目可以共存。

两小时缓存与无撤销难题

验签要取公钥，每次都跑一趟 DNS 太慢，钱包自然会缓存。缓存带来一个规范里点名的问题：密钥泄露后没有撤销机制，被污染的公钥在被换下之前仍能被用来伪造请求。原文的缓解手段是给缓存时长封顶——建议缓存不超过两小时，把泄露后的可用窗口压短，同时把刷新成本控制在应用方可接受的量级。这个设计值得单独体会：标准没有发明撤销协议，只是用时间换风险，属于典型的工程折中，读草案时注意区分规范要求（MUST）、建议（SHOULD）和示例，三者效力不同。

对普通用户意味着什么

TWIST 的主体工作在开发侧，用户侧的直接可见物可能是弹窗上的一个状态提示：本次请求来自已验证签名的来源。由此要注意两点。其一，验签通过证明的是请求内容从那个域名发出且未被改动，不等于那个网站值得信任——钓鱼站同样可以部署签名基础设施；域名逐字符核对、请求内容逐项核对这两件事一件都不能省。其二，验签失败或提示不匹配时，正确动作是停止，而不是重新发起或换个浏览器重试——那可能意味着你正在一个被注入的会话里。

它挡不住的部分也要说清：如果攻击发生在应用自己的后端，签名照样是合法的；如果你的私钥或签名设备本身失守，请求验签再完备也没有意义；对没有接入 TWIST 的网站，通道回到原来的信任模型。它是对中间篡改这一环的补强，不是全站安全的答案。多扩展与注入环境的历史风险在 网页点连接钱包没反应：多扩展抢一个入口与 EIP-6963 的排查顺序 一类话题里有更多展开，防御习惯的优先级不因新标准出现而改变。

现状与风险提示

草案阶段意味着钱包和网站双方都要跟进才有效果，短期内主流路径仍是旧通道。就接口而言，这套东西与 EIP-1193 定义的基础通信层是叠加关系，不是替换。本文只解释防御性机制，不构成投资建议或产品背书；即便一切防篡改机制就位，签名批准的后果自负原则不变——批准前看清域名、地址与授权范围，仍然是你唯一可靠的一道闸门。