换软件时最容易出事的是文件而不是密钥
验证者节点换客户端、钱包换工具，教程都会告诉你「密钥不用搬，配置好了直接读」。现实里踩坑的人多半栽在文件上：上一个软件把钱包写在某个目录，新软件去另一个目录找，找不到就顺手新建一个同名钱包，旧文件原地吃灰；或者迁移时手工复制粘贴，拷一半、留一半。ERC-2680 想解决的就是这类事故。这份 2020 年 5 月提交的提案给钱包在磁盘上的摆法定了一套标准布局，状态是 Stagnant，并未成为各家工具的强制规范，但它对「钱包目录该有哪几层」的描述，仍然是一份很实用的自查框架。
四层结构：基址、容器、钱包清单、密钥环
标准把一次钱包落盘拆成四个要素。第一层是基址，也就是钱包都放在哪个根目录下：文件系统场景有按操作系统区分的预定义路径约定；对象存储这类场景则要求基址是对特定前缀字符串拼接存储标识后做 SHA-256 得到的十六进制串，保证同一个云账户在任何实现里算出同一个根。第二层是钱包容器，容器目录名就是钱包的 UUID。第三层是 walletstore 文件，记录钱包本身的元数据，文件名同样是这个 UUID。第四层是 keystore，每个密钥一个文件，用密钥自己的 UUID 命名。所有 UUID 都必须符合 RFC 4122 第 3 节的语法。在非层次化的键值存储里，布局压平成「钱包UUID:密钥UUID」形式的键名。
索引文件与它的红线
实现可以在基址放一个名为 index 的索引，也可以在钱包容器里放账户索引，方便软件列清单而不用扫描整个目录树。格式是标准 JSON 数组，每项必须有 uuid 和 name 两个字段。规范特意写了一条红线：索引里不得存放公钥。这条看似琐碎的规定划出了职责边界——索引只是目录，真身永远是 walletstore 和 keystore 文件本身。用户排查「钱包列表显示异常」时因此有了明确判断：索引损坏可以重建，文件才是不可再生的那一份，任何情况下都不该为了修列表去动 keystore。
并发写入与迁移纪律
规范专门列了防并发写这一节，但内容留白（规范原文标注为待定）：两个软件同时打开同一个钱包容器再各自保存，后写的会把先写的覆盖掉，标准却没给出统一解法——这恰恰说明真实事故里「同时开两个客户端指向同一目录」反复上榜。对普通操作者的翻译只有一条纪律：一个钱包目录同一时刻只允许一个软件有写权限，迁移永远用先复制、验证新位置可用、再清理旧位置的单向顺序。
迁移或备份时的五步顺序
第一步，确认根目录：以所用工具官方文档为准，找不到再按提案给的系统路径示例逐层查。第二步，核对 UUID：容器目录名与 walletstore 文件名里的 UUID 应当一致，UUID 是这段布局里所有指针的公共钥匙。第三步，完整复制容器目录，而不是只拷某一个 keystore 文件。第四步，在新位置以只读方式验证能列出账户，再谈启用。第五步，确认新环境正常出块或签名之前，旧文件保持原样不动。涉及助记词与私钥的保管纪律不因文件布局而改变：布局管的是放哪里，泄露风险取决于那个位置有没有进云备份、会不会被同步盘悄悄上传。
顺带能回答的两个常见疑问
一是「为什么同一份 keystore 在这个软件里能导入、那个软件里看不见」。答案多半不在密钥本身，而在布局：前者的导入器认得这套 UUID 目录约定，后者只认自家数据库里的记录。标准布局的价值正在于此——文件即账本，能被任何兼容实现枚举出来。二是「备份到底拷什么」。按四层结构看，答案是整个钱包容器目录：walletstore 少了，账户元数据断链；keystore 少了，密钥本体丢失；只拷索引更等于什么都没备份。把容器目录整包加密归档，比研究单个文件的内容更有可操作性，也不要试图手工编辑 walletstore 里的任何字段——那是软件之间的接口，不是给用户改的配置项。 加密 JSON 的三种模块：ERC-2335 keystore 的文件结构与核对点 助记词能用纸和钢板备份吗？物理备份、恢复演练与损坏补救
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。