用助记词管理的普通地址有个常被忽略的优点：它在任何钱包应用里都能用。导入助记词，换一家 App，地址、余额、操作全部照旧——因为普通地址本身没有状态，密钥和地址的关系在哪里都一样重建。EIP-7702 出现之后，这个”随便换 App”的惯性遇到一个新变量：你的地址可以委托给某家实现智能账户逻辑的代码，而逻辑一旦挂上,账户就有了自己的存储。ERC-7779 草案处理的就是这个变量：委托型地址在钱包之间迁移时，存储该怎么管。
委托之后，账户第一次”带行李搬家”
按提案描述的场景，EIP-7702 让普通外部账户获得执行抽象能力——代付 gas、批量执行、一步式兑换、自动订阅这类体验都来自地址背后委托的智能账户实现。问题在于：不同钱包厂商的实现各不相同，而委托型地址会把签名者密钥对应的存储一直带在账户上。今天你甲 App 委托给 A 实现，明天想换成乙 App 配 B 实现，旧实现的存储还挂在你的地址上。提案明确警告：存储管理不当会造成存储冲突，后果包括账户被锁、出现安全漏洞。换句话说，行李搬不好，新家门都可能打不开。
ERC-7779 的解法：给委托关系立一份通用接口
提案的思路不是规定所有钱包共用一套存储，而是让”我委托了谁、密钥归谁管”这类关键信息按统一接口存放，使得任何一家新实现在接管委托前，能先读懂旧实现留下的账。它要求实现 InteroperableDelegatedAccount 一侧的约定，并建立在 ERC-7201 的命名空间存储实践之上——各家把自家数据圈在各自的命名空间里，井水不犯河水，迁移时新实现读得懂公共部分、绕开旧实现的私有部分。提案同时强调这是”主权”问题：用户自由更换钱包应用的能力，不应该因为账户升级成智能账户而退化。
用户视角：现在该核对什么
第一，判断自己是否在这个局面里。纯粹的助记词钱包不受影响；只有当你通过 EIP-7702 类功能把地址”升级”过，或者你的钱包明示你在使用某厂商的智能账户实现，才涉及委托存储。第二，把”换 App”拆成两层来检查：密钥层迁移照旧是助记词导入那一套，和手机换机钱包怎么迁移？备份确认、新机导入与旧设备处置清单讲的传统迁移没有区别；逻辑层则要看新 App 是否支持你当前委托的实现、能否读懂旧存储——这在链上可以核验：用浏览器查你地址的代码委托记录，读它的委托目标合约。第三，迁移前做小额演练：用少量资产走一遍发送、批量、代付各项功能，确认新组合下行为一致，再搬大额。
边界与现状
这份提案标注为草案，接口细节可能变动，别把它当现网功能找按钮。它依赖 EIP-7702 与 ERC-7201，前者本身也在快速演进，两条时间线要对齐着读。还要分清两类”迁移丢资产”事故：一类是助记词抄错了一个词的位置：为什么恢复出来是个空钱包那种派生层面的地址对不上，本质是密钥树没找对；另一类才是本文说的委托存储冲突，账户还是那个账户，坏的是逻辑层的数据读取。排查时先看地址是否相同：地址都变了，往密钥树方向查；地址没变而功能异常，往委托实现和存储方向查。
一句话收尾
普通地址时代，钱包迁移拼的是助记词；委托账户时代，还要拼”谁在读你的存储”。ERC-7779 想做的是让这件事有一张通用说明书——在它普及之前，迁移前的委托目标核验和小额演练，就是你自己能做的保险。
风险提示：委托与智能账户功能涉及合约逻辑变更，任何迁移先小额演练再批量操作，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。