恢复以太坊钱包时，你看到的派生路径大多以 m/44'/60' 开头。但标准文档里还有另一条线：ERC-600 和 ERC-601，为以太坊专门设计的 m/43' 层级，两份都是走完流程的 Final 标准。为什么几乎所有钱包都不用它？这条标准线讲了什么，对”导入助记词后余额为空”这种真实故障又能提供什么线索？下面按四步说清。
为什么要另起一条线
BIP-44 的路径设计预设了一类 UTXO 币种：收款要频繁换新地址，所以 account 层和 address_index 层都很忙。以太坊是账户模型，一个地址长期收付款是常态，BIP-44 的账本假设套上去水土不服。2017 年前后各以太坊客户端与钱包各自定路径，一部分甚至不符合 BIP-44 规范，直接后果就是跨钱包导入时”刚才还在的钱不见了”，有的实现干脆让用户手工填路径。ERC-600 的作者认为问题出在从根上借错了体系，于是提议以太坊整体改走 BIP-43 的通用格式。
ERC-600：三层全硬化的骨架
规范定义的路径是 m / purpose' / subpurpose' / EIP'，撇号表示该层使用 BIP-32 硬化派生。purpose 固定为 43，沿用 BIP-43 给非比特币币种预留的用途号；subpurpose 取 60，即 SLIP-44 里以太坊的编号，这一层与 m/44'/60' 传统里的 coin_type 是同一个数；第三层直接放”负责规定这条路径其余部分的规范编号”。这个设计的意图很直白：以后以太坊想定义新的路径布局，走 ERC 流程发一个新编号就行，不必每次回到比特币的 BIP 流程里排队。
ERC-601：把第四层补上
ERC-601 是上述骨架的第一个具体应用，路径变成 m / purpose' / subpurpose' / EIP' / wallet'，最后多出的 wallet 层是”你第几个钱包”的索引，同样硬化。EIP 层填 ERC-601 自己的编号。换句话说，ERC-600 是框架、ERC-601 是框架下第一种布局，两者的目的都是让以太坊钱包在同一个体系下互认路径，终结各说各话。
状态是 Final，采用是另一回事
值得普通用户记住的是两份标准的后续：ERC-600 的 Implementation 字段写明”None yet”，至今没有列出任何实现；整个生态继续以 m/44'/60' 为事实标准，Final 的标签只说明提案流程走完了，不代表任何钱包真的支持这条路径。所以当你恢复账户发现余额是零，正确的问题不是”我该不该用 m/43’ 路径”，而是钱包实现层面的三件事：账户索引是否扫到了你用过的第 N 个账户、派生路径窗口是否足够深、地址类型是否与创建时一致。跨钱包导入与换机场景的排查顺序，手机换机钱包怎么迁移？备份确认、新机导入与旧设备处置清单和恢复助记词后账户找不到怎么办？分别给了操作清单；路径每一层的读法在BIP-44 派生路径怎么读：为什么同一句助记词，导入后地址却不一样里逐段拆过，可以对照着看。再补一个动手层面的细节：多数钱包不会把派生路径直接显示在界面上，但硬件钱包的详情页通常能核对当前账户的完整路径字符串，部分浏览器插件也在账户菜单里暴露该字段。核对时的正确姿势是从已知有资产的旧环境里把路径抄下来，再到新环境里确认导入设置一致，而不是反过来靠新环境默认值去猜；找不到任何路径线索时，让导入工具对 m/44'/60' 下的连续账户索引多扫一段窗口，往往比手工试路径更快命中。
一点延伸思考
这段历史对钱包用户的真正价值，是理解”标准与生态”的两层世界：一份标准从草案到 Final 是流程进度条，而它是否出现在你钱包的设置项里，取决于实现者的取舍与存量兼容成本。因此任何核对都要同时查两处——标准文档看语义，自己钱包的实际设置看现实；两边都确认过，才把结论说死。顺带一条安全提醒：需要你在网页上手工输入派生路径的场景，本身就超出正常恢复流程，助记词只应该输入在你信任的钱包或硬件设备里，这一条底线不会因为路径体系的变化而改变。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。