为区块链应用设计本地数据库存储结构

区块链和区块链应用这两个概念是不一样的。对于一个纯区块链而言,只需要保证它拥有三个要素:1.链表结构的区块存储结构设计,2.点对点网络,3.加密技术保证不可伪造。但是对于一款应用,特别是现代的应用,这三个要素完全不够。对于一个应用,还要考虑:1.用户(账号)体系,2.鉴权体系,3.业务数据。因此,我们这篇文章要来探讨一下,一个区块链应用应该如何设计它本地的数据库存储结构。

选择底层数据库

对于区块链应用而言,有两个部分的数据:区块链数据和应用状态数据。以比特币为例,区块链数据中保存着历史交易数据,而这些数据包含了上述提到的那几个方面,除了历史交易数据,比特币客户端(应用)还需要保存没有被写入区块链的一些数据,比如过去一段时间发起的新交易。比特币的区块链数据被存储在很多.dat文件中,它采用的数据结构我至今没有搞懂,阅读了很多材料,都没有明白比特币raw data使用的是什么技术,不过市面上已经有很多软件可以直接解析比特币区块链数据,所以读取比特币区块链也不是什么问题。而比特币的这些.dat区块数据不是以我们熟悉的数据结构存储的,所以在查询数据的时候,无法像现代数据库一样通过查询语句或方法快速查询。为了解决验证某个交易的速度,比特币采用了leveldb作为key-value数据库保存着整个区块链的索引,以保证可能通过各种key快速找到需要的数据。另外,那些还没有写入区块链的chainstate数据也是用leveldb保存在另外一个库中。

那么对于非币应用,或者代币应用,怎么来搞自己的数据库呢?

上面你可以看到,实际上,一个区块链数据库结构里面包含三个(或更多)部分:1.只能执行插入和查询动作的块链数据库,2.块链数据的索引,3.chainstate数据,这个数据是可变的。而怎么把账号体系、业务体系等数据加入进去呢?很明显,账号体系、鉴权体系、业务体系的数据全部要入链。在p2p同步时,只有block数据被同步,其他数据都是通过网络广播等方式传递和接收的,索引数据在同步时创建。

用sql数据库保存区块链。

我们抓住区块链表的特征,即下一个区块保存着上一个区块的hash,同时通过merkle算法保存了区块内容的hash。所以,我们其实很好利用sql数据库来保存block数据,而且,sql数据库可以自定义索引,所以,索引数据库都省了。因此,我们的应用里面,可以最终总结为两类数据:块链数据、chainstate数据。其中块链数据使用sql数据库保存,只具备insert和select的权限。而chainstate使用kek-value数据库保存,读取效率更高。

用sqlite和leveldb作为底层数据库。

sql数据库和key-value数据库都有很多很多,比如orcal、redis等等,但是我们开发一个区块链应用,常常需要保证把数据放在客户端本地,而非服务器,所以,这个时候,数据库必须和应用代码一起发布。当然,如果你能强制用户在安装你的应用之前安装一个本地数据库服务,也是可行的,比如微软的很多软件,就要求你事先安装.net framework。不过这种需求显然体验感不是很好,除非是企业级用户。

sqlite是非常轻量级的sql数据库,最重要的是,它是基于文件的,而非内存的,它的所有数据被保存在一个.db文件里面,而且不依赖任何服务。也就是说,你可以将这个数据库打包进自己的应用,而不用要求用户在安装你的应用之前再安装一个其他什么数据库了。不过当然,sqlite的性能在遇到大数据量的时候是不怎么理想的,因此,我们需要通过各种优化手段和架构来控制单个数据库的数据量,采用分库等方式,提高后期可能的查询能力。

leveldb和sqlite一样,也是基于文件系统的,可以被打包进应用。它具备非常高的写性能,由于设计简单,它的读性能也完全不输给内存级的key-value数据库。当然,因为它的设计简单,它没有分库等功能。我们需要通过合理的控制key的前缀,来保证我们可以通过有一定规律的key来找到想要的数据集合。

数据库表结构

我们以一个博客系统为例来进行分析,毕竟基于数据库技术的应用千变万化,结构不可能只有一种。但是,我们通过这个案例,可以分析出,区块链应用怎么在业务、用户、块链三者之间建立“不可篡改”的存储数据。

首先是区块表(block table)。

一个区块的表,需要记录这个区块的各种信息,特别是区块头信息。我的设计如下:

字段名 类型 长度 备注
version string 8 客户端的版本
block_hash string 128 区块hash
previous_block_hash string 128 上一个区块hash
timestamp number 16 挖矿时间戳
diffculty number 32 挖矿难度
nonce number 16 挖矿随机数
merkle_root string 128 业务数据的merkle root hash

这就是一个区块链的区块表,这些是基础字段,作为一个应用,可以在这个基础上进行扩展,但是应该遵循一个规则,就是尽可能的保证存储的数据更少,能够通过计算得到的数据,就不要设计在sql数据库里面去,可以考虑放在key-value数据库里面去。要知道,当一个应用运行N年以后,即使看上去这么几个字段的表,也会多到爆炸。

业务数据表。

下面是业务数据,也就是我们这里假设的博客的内容。对于一篇博客,我们必要的字段其实不多:

字段名 类型 长度 备注
version string 8 客户端的版本
article_hash string 128 文章hash(相当于文章ID)
article_title string 128 文章标题
article_timestamp number 16 文章时间戳
article_content longtext 文章内容
article_author string 128 撰写文章的用户hash
block_hash string 128 这篇文章所在的区块hash

你看到block_hash可能会觉得奇怪,没错,在插入文章数据前,block_hash已经被计算出来了。

既然是博客系统,那么评论也是必须的:

字段名 类型 长度 备注
version string 8 客户端的版本
comment_hash string 128 评论hash(相当于评论ID)
comment_article_hash string 128 这条评论是属于哪一篇文章的
comment_parent_hash string 128 这条评论是回复给哪一条评论的,默认为0,表示不是回复给评论,而是直接评论给文章
comment_timestamp number 16 评论时间戳
comment_content longtext 评论内容
comment_author string 128 评论的用户hash
block_hash string 128 这条评论所在的区块hash

上面就是区块链的数据库表了。

等一等,用户数据呢?难道你都不把用户数据保存下来,这顶什么用?难道界面上直接显示用户的hash就算了?别慌。用户数据属于加密体系的一部分,不会被记录到区块链中,而是记录在chainstate中,你想想,用户难道还不要经常换换头像、改改昵称什么的么?而且,我们可以通过用户的密钥来对用户的权限进行验证。这下面的部分再详细阐述。

总之,对于一个博客系统,就上面这些字段就够用啦。但是,要保证区块链数据的不可篡改性,我们还要做一些设计。

merkle_root = sha256(sha256( article_hash1 + article_hash2 + ... comment_hash1 + comment_hash2 + ... ))

在验证一个数据是否被改动时,利用merkle的验证算法,从区块链里面查询出对应的数据进行merkle验证就可以知道是不是有问题了。

chainstate数据结构

前面提到我们用key-value数据库保存chainstate数据,我们尽量让key-value更加扁平,不要做多层嵌套。现在我们来看下用户数据:

"author_03a89fc89aa9c7b7..." => {
  "nickname": "tony",
  "publicKey": "a8fcdc982eda..",
  "avatar": "data:image/png;base64,...",
  "description": "I'm a clear boy."
}

而一个用户的hash是通过该用户的公钥经过加密得到的,要验证该用户的真实性,只需要用他的公钥加密某个随机数,让他用私钥解密进行验证即可。

另外,有很多发布了但还没有记录到区块链里面的文章,等着被矿工写入。为了防止矿工篡改用户发布的内容,用户发布时,仅广播内容的hash,原始内容经过加密,矿工仅利用这些hash进行挖矿,挖矿成功后才能解锁原始内容:

"block_0ca452ced99..._merkle_hashes" => [
  {
    "author_hash": "03a89fc89aa9c7b7...",
    "article_hash": "0034cd00e37...",
    "article_raw_script": "xxx..."
  },
  ...
]

评论数据也是一样,它们被暂时保存在chainstate里面,等到区块生成之后,这些临时数据就可以从chainstate里面清除。

总结

本文从一个区块链应用的底层数据库出发去看区块链应用。当然,这里面还有很多细节,需要在开发中去解决,这里只是提供了底层数据库选择和设计的一个思路。在一些具体问题上,比如共识机制,比如如何刺激用户贡献内容等等,都是一个待解决的问题。

2018-04-07 678 ,

为价值买单

本文价值6.78RMB