用通行密钥、社交登录或某家托管服务创建过智能账户的人，常遇到一种怪事：换了台电脑登录熟悉的网站，钱包里只剩一个”默认账户”，当年的那个账户连同余额像消失了一样。账户没丢，缺的只是一次”账户发现”。ERC-7555 就是给这件事定规矩的提案，本节把它按用户视角拆开。
它解决的不是登录，是”找回签名密钥之外的账户”
普通以太坊账户（EOA）由一把 secp256k1 私钥直接控制，钱包拿着这把钥匙就能算出地址。但如果你的账户当初是用别的密钥体系（比如通行密钥这类非 secp256k1 曲线密钥）登录某个服务商后部署的智能合约账户，钱包本地根本不知道它的存在。ERC-7555 针对的就是这种场景：让应用通过一个标准化的跳转流程，向身份服务商（Provider）询问”这个登录身份在指定链上有没有账户”，并要求答案返回统一的格式。提案处于草案状态，实现集中在少数钱包与托管服务生态，用之前先确认你用的服务商是否声明支持。
流程长什么样：一次带参数的网页跳转
按提案规定，整个发现过程靠两个路由完成。第一个是认证路由，应用把用户重定向到服务商的固定地址，形如 https://服务商域名/auth/，query 里带两个参数：redirect_uri（应用自己接收回调的地址）和 chain_id（要查哪条链）。服务商确认你的登录身份后，把结果拼回你的回调地址，形如 https://你的应用域名/auth/?smart_account_address=...，其中账户地址必须用 CAIP-10 格式写——也就是”链标识+地址”合成一串，避免同址不同链的歧义。第二个路由是代发交易用的 sendTransaction 路径，把认证和注册插件合并成一次跳转，少一次来回。理解到这里就够用了：你在浏览器里看到”正在跳转到身份服务商”其实就是在执行这条协议。
用户视角的三个核对点
第一，跳转域名。协议的安全完全押在”服务商域名是真的”这一点上，回调地址里的账户地址是对方说了算的字符串。跳转前看一眼浏览器地址栏域名与当初注册服务时是否一致，思路和搜索引擎广告位里的假官网：从点击到钱包弹窗的完整链条里”从搜索点击到钱包弹窗”的核验一致：宁可手动输入官网重新进。第二，链参数。chain_id 决定服务商去哪条链上找账户，账户存在另一条链时结果自然为空，这一步和eth_chainId 怎么确认你现在在正确的链上？用 eth_chainId 确认当前链是同一个纪律的两端。第三，返回值的独立复核。拿到”发现某地址”之后，别直接当自己的账户，先在浏览器查它的创建交易与资产构成，判断路径参考合约是谁部署的？从部署交易到权限移交的链上调查法的部署交易调查法。
找不到账户时，先分清三种原因
一种是服务商不支持或你连的是它的旧域名，特征是跳转页根本没有/auth路径或直接报路由不存在；一种是链选错，换 chain_id 重走一次即可；最后一种是当初的账户就不是这家服务商部署的（比如你记混了注册渠道），此时应改用你真正用过的登录方式重走流程，而不是反复清空缓存。账户恢复期间资产风险为零——链上账户不会因为没人发现就消失，这与助记词派生账户”找回地址即可找回资产”的逻辑HD 钱包助记词、派生路径与地址的关系：换钱包地址变了怎么回事相同，急不得。
一个容易被忽略的隐私面
发现请求把”某个登录身份”与”某条链”这两个信息一起交给了服务商，服务商由此知道你在这个身份下查询过哪条链。这与直接连公共 RPC 的暴露面性质类似、范围更小，但如果你有跨多个身份混合使用的习惯，优先选支持本地枚举账户的钱包方案，把这类外部发现只当作兜底。另外，服务商代你管理签名时，你对账户的实际控制取决于它的密钥架构（MPC、托管或你本地持钥），协议本身不做任何保证，评估口径参考 MPC 分片与托管边界的既有讨论。
风险提示：本文介绍的协议在写作时为草案状态，接口细节可能随版本调整；账户发现涉及真实资产，任何跳转都要先核域名与链号，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。