go-ethereum 源码笔记(ethdb 模块)

通过前面的文章,我们知道了有工作量证明的区块链是怎么构建的,然而区块链一直在内存中当然是不行的,我们需要将区块链持久化到数据库中。

区块链的本质是一个分布式数据库,尽管如此,底层使用的数据库并没有太大要求,不需要分布式,分片等等特性,这些特性是在数据库的上层做的。所有的节点都是一个完整的实例,是它们组成了一个分布式系统。就实现业务来说,我们只需要一个简单的 k-v 数据库就够了。

geth 采用的是 LevelDB,回头来看这个选择还是有很多可以反思的地方,LevelDB 在顺序读写的场景下性能很好,但 geth 在运行智能合约时,面临的更多的场景是大量时间耗费在世界状态的读写上,通过前面对 MPT 的分析我们知道,这些 IO 大多是离散随机的,这导致了 geth 的性能瓶颈,特别是在合约里的数据大量分布在 Storage Trie 的情况下,因为树的高度可能很高,而每加载一个节点都需要进行一次 IO。这一点在以太坊(Ethereum) 的执行交易性能瓶颈这篇文章中有论述。邓草原 正在开发的 Kesque 也可以关注一下。这不是本文重点,就不展开了。

中本聪的最初论文并没有提具体要用什么数据库,尽管如此,社区使用最多的参考实现 Bitcoin Core 最初使用的是 Berkeley DB,后来转而使用 levelDB 存区块链索引,以太坊的 Go,C++, Python 实现的客户端使用的是 LevelDB 数据库,Rust 客户端 Parity 使用的是 RocksDB。

go-ethereum 对 LevelDB 的增删改查是通过 ethdb 这个模块来交互的。ethdb 实际上是对 github.com/syndtr/goleveldb/leveldb 这个库的封装,其中增加了收集 metric 的功能。

如果想要对 LevelDB 有更深层次的了解可以自行查询相关资料。

ethdb 模块的功能比较单一,就4个文件:

  • interface.go 定义数据库增删改查的接口
  • database.go 封装 levelDB 的代码
  • memory_database.go 基于内存的数据库,不会持久化到文件,只在测试时使用
  • database_test.go 测试用例

interface.go

1
2
3
4
5
6
7
8
type Database interface {
Putter
Get(key []byte) ([]byte, error)
Has(key []byte) (bool, error)
Delete(key []byte) error
Close()
NewBatch() Batch
}

Database 接口定义了所有数据库操作,Putter 接口定义批量操作和普通操作的接口。批量操作不能多线程同时使用。

memory_database.go

1
2
3
4
type MemDatabase struct {
db map[string][]byte
lock sync.RWMutex
}

这个文件跟 LevelDB 没什么关系,它只是封装了内存里的 key-value 结构,暴露的增删改查的接口(Put,Has,Get,Keys,Delete 等等)跟对 LevelDB 的封装基本一致。加了锁以在多线程的情况下对资源进行保护。

database.go

封装了 levelDB 接口,在 go-ethereum 中大量使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
type LDBDatabase struct {
fn string
db *leveldb.DB
compTimeMeter metrics.Meter
compReadMeter metrics.Meter
compWriteMeter metrics.Meter
diskReadMeter metrics.Meter
diskWriteMeter metrics.Meter
quitLock sync.Mutex
quitChan chan chan error
log log.Logger
}

Path, Put, Has, Get 等方法是对 levelDB 的封装,没有什么特别的,也不需要用锁,因为 github.com/syndtr/goleveldb/leveldb 支持多线程访问。

Path

1
2
3
func (db *LDBDatabase) Path() string {
return db.fn
}

Put

1
2
3
func (db *LDBDatabase) Put(key []byte, value []byte) error {
return db.db.Put(key, value, nil)
}

Has

1
2
3
func (db *LDBDatabase) Has(key []byte) (bool, error) {
return db.db.Has(key, nil)
}

Get

1
2
3
4
5
6
7
func (db *LDBDatabase) Get(key []byte) ([]byte, error) {
dat, err := db.db.Get(key, nil)
if err != nil {
return nil, err
}
return dat, nil
}

Delete

1
2
3
func (db *LDBDatabase) Delete(key []byte) error {
return db.db.Delete(key, nil)
}

Metrics

compTimeMeter, compReadMeter, compWriteMeter, diskReadMeter, diskWriteMeter 这几个方法都通过 metrics.NewRegisteredMeter 注册得到。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
func (db *LDBDatabase) Meter(prefix string) {
if !metrics.Enabled {
return
}
db.compTimeMeter = metrics.NewRegisteredMeter(prefix+"compact/time", nil)
db.compReadMeter = metrics.NewRegisteredMeter(prefix+"compact/input", nil)
db.compWriteMeter = metrics.NewRegisteredMeter(prefix+"compact/output", nil)
db.diskReadMeter = metrics.NewRegisteredMeter(prefix+"disk/read", nil)
db.diskWriteMeter = metrics.NewRegisteredMeter(prefix+"disk/write", nil)
db.quitLock.Lock()
db.quitChan = make(chan chan error)
db.quitLock.Unlock()
go db.meter(3 * time.Second)
}

最后通过一个 goroutine 调用 db.meter。

该方法是一个死循环,过三秒钟就通过 db.db.GetProperty("leveldb.iostats") 获取一次 leveldb 的 stats,然后发到 metrics 系统。如果收到 quitChan 的信号就退出死循环。

业务相关代码

与业务直接相关的代码在 core/rawdb 目录下,基本上所有与底层数据库交互的代码都在这里,没有很复杂的内容,不过了解这些底层的数据结构对于理解业务很有帮助,可以自行浏览。

key->value

以下是一些 geth 中常见的 key-value 对(在 core/rawdb/schema.go 中定义)。

key value 描述
“h” + num + hash 区块头的数据 根据区块高度和区块哈希找到区块头数据(RLP 编码)
“h” + num + hash + “t” 区块总难度 根据区块高度,区块哈希找到 totalDifficulty,即累计的区块难度的和
“h” + num + “n” 区块头哈希值 根据存储的规范区块链高度找到区块头哈希值
“H” + hash 区块高度 根据哈希值找到区块高度
“b” + num + hash 区块体的数据 根据区块高度,区块哈希找到区块体的数据(RLP 编码)
“r” + num + hash 收据的数据 根据区块高度,区块哈希找到收据的数据(RLP 编码)
“l” + hash 交易,收据查找的 metadata 根据哈希值找到交易,收据查找的 metadata
“B” + bit + section + hash 布隆过滤器的结果 用于日志的过滤

References