以太坊全节点的磁盘是很多业余运维者最先撞上的那堵墙。同步完成后数据库往往就占了大半块硬盘，之后每周还在肉眼可见地往上长。要理解怎么把盘省下来，得先理解节点把状态存在哪、按什么方式存——所谓状态方案。本文按 Geth 官方文档与以太坊基金会博客的记载，把哈希键控与路径键控两种方案、离线裁剪命令的适用边界讲清楚，把读者当作愿意认真学习的节点运维新手。
先分清：节点为什么越跑越肥
一个快照同步完成的 Geth 节点，官方文档给出的参照是磁盘占用超过约 650 GB，默认缓存下数据库每周大约再增长 14 GB。增长的来源不是新区块本身有多重，而是状态树的历史包袱：世界状态是一颗默克尔帕特里夏树，每次交易改动账户或存储槽，都会生成一批新的树节点。旧节点里有一部分不再被当前状态引用，但只要没被回收，就一直躺在数据库里占地方。回收这些不再被引用的树节点，就是裁剪（pruning）要做的事。
两种状态方案：按哈希存，和按路径存
Geth 早期把状态树节点按哈希键控存储：同一个节点对象不管被多少个区块引用，数据库里只留一份。去重很省空间，代价是致命的——你无法从数据库本身回答这个节点还被最新状态引用吗，于是裁剪几乎无从下手。以太坊基金会博客在 Geth v1.13.0 发布文中记录了这场底层改造：为了让裁剪成为可能，团队把状态改为按路径键控，同一内容的节点即使哈希相同也会按不同路径各存一份；数据库同一时刻只保留一棵状态树，最新 128 个区块的差异留在内存里形成差分层，因此 128 块以内的重组可以瞬时完成，更深的回退则靠磁盘上保留的约 9 万条反向差分回滚。换成这套模型之后，节点得以内置一个常驻的磁盘裁剪器，边跑边清理，不再攒垃圾。
离线裁剪：老方案下的手动大扫除
对仍在使用哈希键控方案的节点，Geth 文档保留了离线裁剪这条路径：停掉节点，执行 geth snapshot prune-state。文档列出的前置规则值得逐条对照：归档节点绝对不要裁剪，它按定义必须保留全部历史数据；目标盘至少留 40 GB 空闲，有报告称只剩约 25 GB 时任务会失败；Geth 版本不低于 v1.10，且已完成同步、并已生成至少 128 块之久的状态快照。执行时分三个阶段：遍历最底层快照构建布隆过滤器以圈定需要保留的树节点；删除不在过滤器里的过期节点；最后压缩数据库腾出空间。文档特别提醒，压缩阶段可能出现超过一小时没有任何日志输出的静默期，属于正常现象，看到 State pruning successful 这行日志才算真正完成，中途不要重启。一次耗时数小时到十几个小时，视硬件而定。
边界与选择
把两条路线放在一起：路径键控方案的默认裁剪让盘占用基本稳定在初始规模附近，是常规用户应该待在里面的方案；离线裁剪是历史遗留路径，文档同时注明等哈希键控方案彻底退役后它也会废弃。判断自己节点处于哪种状态，可以直接看数据目录的状态方案标记与日志里是否还有垃圾累积的迹象。还要划一条安全边界：裁剪只影响你能为别人提供什么查询——裁剪过的节点无法服务早期区块的历史状态查询——它不改变你账户里的任何资产，也不影响节点验证链的正确性。本文是机制与运维说明，涉及的数据均转述自官方文档与官方博客的记载，具体数值以你所用版本的官方说明为准，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。