以太坊状态存储机制详解：HashScheme vs PathScheme

1. 问题背景

当节点重启后出现区块号从头开始的问题，通常与状态存储机制有关。这个问题的典型错误日志是：

lvl=warn msg="Head state missing, repairing" number=184 hash=0x8eaadd... diskRoot=0x45cea0...
lvl=info msg="Genesis block reached" number=0

 

这表明本地状态树（Trie）与区块头中的状态根哈希不匹配，导致节点被迫回滚到创世块。

2. 状态存储机制

以太坊目前有两种主要的状态存储机制：HashScheme 和 PathScheme。

 

 

2.1 HashScheme 特性

1. 存储机制：

• 使用节点哈希作为数据库键

• 支持存储多个版本的状态数据

• 适合构建归档节点

2. 运行模式：

 

3. 状态提交机制：
    

   if bc.cacheConfig.TrieDirtyDisabled {  // 归档模式
       return bc.triedb.Commit(root, false)
   }
   // 非归档模式：基于时间间隔和内存限制的提交
   if bc.gcproc > flushInterval {
       // ... 检查并提交状态
   }

2.2 PathScheme 特性

1. 存储机制：

• 使用节点路径作为数据库键

• 只存储一个版本的状态数据

• 原生支持状态修剪

2. 关键特点：

• 不支持历史状态查询

• 更好的数据局部性

• 不需要额外的GC操作

• 使用异步节点缓冲区管理状态

3. 配置建议

1. 普通节点推荐配置（PathScheme）：
    

   StateScheme = "path"
   PathSyncFlush = false     # 是否同步刷新
   StateHistory = 128        # 保留的状态历史数量

    

2. 归档节点配置（HashScheme）：
    

   StateScheme = "hash"
   NoPruning = true            # 启用归档模式
   TrieCleanCache = 154        # 清洁缓存大小
   TrieDirtyCache = 256        # 脏缓存大小
   TrieTimeLimit = "60m"       # 状态提交间隔

4. 状态提交流程

 

 

5. 注意事项

1. 模式选择：

• PathScheme 适合普通节点：更好的性能和存储效率

• HashScheme 适合归档节点：支持历史状态查询

2. 模式切换：

• 不能随意切换 StateScheme，会导致错误：
   

  Fatal: Failed to register the Ethereum service: incompatible state scheme, stored: path, user provided: hash

3. PathScheme 限制：

• 不支持历史状态查询

• 不支持归档模式

• 不使用 TrieTimeLimit 参数

6. 未来发展

PathScheme 计划通过状态历史功能来支持归档功能，但目前该特性还在开发中：

 

// TODO historic state is not supported in path-based scheme.
// Fully archive node in pbss will be implemented by relying
// on state history, but needs more work on top.

这个修改后的版本更准确地反映了两种状态存储机制的特点，特别是纠正了关于 PathScheme 状态提交机制的描述。PathScheme 使用异步节点缓冲区来管理状态，而不是依赖时间间隔控制。