网页找钱包的老办法为什么会漏
到目前为止，大多数网页钱包仍以浏览器扩展的形式存在：扩展往页面的全局对象里注入一个入口，再指望 dApp 自己去读取。AIP-62 在动机部分点出了这套做法的三个老毛病。第一，dApp 必须预先知道”去哪找、找谁”，实际支持的往往只是少数几个它认识的钱包；第二，为了避免错过在页面加载之后才注入的钱包，dApp 只能反复扫描全局对象；第三，这个扫描本身就埋着竞态——如果 dApp 先加载、钱包扩展后加载，晚到的钱包可能始终不被察觉。AIP 还补了两条 Aptos 生态自己的问题：旧标准与钱包适配代码包深度绑定，改一处就要一堆 dApp 和钱包跟着改；每个 dApp 各自维护钱包插件依赖，等于多开一个供应链攻击面。
改成事件制：钱包主动登记，dApp 收通知
AIP-62（状态 Accepted，2024-01-29 创建，类型为 Ecosystem Standard）借鉴了链无关的 wallet-standard 通用方案——同一条路线已在 Solana 和 Sui 落地，以太坊生态的相近思路是 EIP-6963（多钱包发现机制在两条链上的思路可以对读，见 网页点连接钱包没反应：多扩展抢一个入口与 EIP-6963 的排查顺序）。变化在于方向反转：不再是 dApp 轮询翻找，而是钱包实现标准的 AptosWallet 类后调用 registerWallet 主动登记；dApp 一侧通过 getAptosWallets 取当前已登记的钱包列表，并监听 register 与 unregister 事件。钱包晚加载也能立刻被看到，dApp 不需要再跑轮询。用户角度看到的差别是：连接弹窗里的钱包名单来自钱包们的自我登记，而不是 dApp 硬编码的白名单。
功能清单：能力按名字拆开声明
标准把钱包能力拆成一组带名字的功能，dApp 按名取用。必需项包括：aptos:connect（建连接，可带 silent 参数做免弹窗自动连接、可带网络信息）、aptos:disconnect、aptos:getAccount、aptos:getNetwork、aptos:signTransaction（对新版 TypeScript SDK 生成的原始交易签名，返回账户认证器）、aptos:signMessage，以及账户切换与网络切换两个事件（onAccountChange、onNetworkChange）。可选项包括 signAndSubmitTransaction（签名并代为提交）、changeNetwork、openInMobileApp（手机上从浏览器跳到钱包 App 内浏览器）。所有需要用户拍板的调用返回统一的 Approved 或 Rejected 状态——用户关掉弹窗也算一次明确的拒绝，而不是无声超时。
对普通用户来说，这改变了什么
接口层的变化传导到体验上，大概是三条。其一，“连接钱包”名单更全、更不容易出现”明明装了钱包却扫不到”；其二，账户和网络有了标准的切换事件，dApp 理论上能跟着钱包走，不再停留在旧账户上签新交易；其三，交易签名与提交可以分开：多数路径是 dApp 构造、钱包只签名，是否由钱包代为提交取决于可选功能有没有实现。要提醒的是，钱包名单来自自报家门，自报本身不等于可信——EIP-6963 的经验同样适用，签名弹窗里核对地址、网络与交易内容这一步永远不能省。
连接类弹窗的三个常见误判
接口标准解决”找得到”，不解决”看得懂”。结合该标准的设计能指出三处易错点。其一，aptos:connect 允许 silent 参数发起免弹窗连接，适合老用户自动重连，但也意味着某次访问可能在你没看到确认框的情况下已经拿到账户地址——定期在钱包里清点已连接站点是必要动作。其二，disconnect 与 openInMobileApp 之类的功能只影响连接会话或跳转方式，不改变任何链上授权与资产状态，把”断开连接”误当成”撤销授权”是跨生态通用的误区。其三，onAccountChange 事件要求 dApp 跟随切换，但没实现事件的旧 dApp 可能停留在旧账户上继续请求签名，核对弹窗里显示的当前账户是唯一保险。
边界与风险提示
AIP-62 是接口与发现约定，不是安全协议：它不鉴定钱包善恶，也不替你核对交易内容；实现细节以 aptos-labs/wallet-standard 仓库与各钱包实际版本为准。涉及资产的操作，任何一次签名前都应确认网络、地址与金额与你的意图一致。本文为机制说明，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。