为了帮助大家更深入地理解 ArcBlock 的开放链访问协议的实现和技术细节,我们的工程团队将定期写技术文章来“解密”我们在设计和开发 OCAP 过程中的一些技术细节。 希望读者能借此了解 OCAP 背后的设计思路和实现细节,也许你可以参与来实现更多的 OCAP 链适配器,支持更多的区块链协议。 也欢迎大家来指出我们设计中的不足,在讨论中完善我们的设计。
作者:丁沛灵 (ArcBlock 团队软件工程师)
为什么要解析 Bitcoin 数据?
我们在七月底如期发布了 OCAP 的第一版本。在这一版本中,OCAP 提供了针对 Bitcoin 数据的查询服务。用户不仅可以快速的通过 Hash 拿到某一个 Block 或者 Transaction 的信息,并且还可以做复杂的级联查询,比如查询特定的两个地址之间的交易。下面的这个 query 就可以返回那个著名的 Pizza 交易
{
transactionsByAddress(sender: "17SkEw2md5avVNyYgj6RiXuQKNwkXaxFyQ", receiver: "13TETb2WMr58mexBaNq1jmXV1J7Abk2tE2") {
data {
blockHeight
hash
total
numberInputs
numberOutputs
}
}}
原生的 Bitcoin API 并不支持这样的数据查询,所以想要让 OCAP 具备这样的查询功能,我们就必须预处理 Bitcoin 上的数据,让它以我们想要的方式存储。这也就引出了我们今天的主题 – 如何解析 Bitcoin 数据?
概述
在讲技术细节之前我们先从整体上理解一下我们要干什么,为了说清楚一点,我们可以类比搜索引擎。
众所周知,互联网上的数据纷繁复杂,而搜索引擎却能在海量的数据里面迅速的查找出用户想要的结果。其之所以能够做到这一点是因为搜索引擎的后面还有两个默默付出的组件 – 爬虫和倒排索引。 爬虫负责不停的从互联网上搜集数据,倒排索引负责将数据以特定的形式存储,以便搜索引擎能够快速的查询。
同样的,ArcBlock OCAP 所支持的区块链查询就相当于提供针对区块链的“搜索引擎”服务,也少不了类似的预处理过程。不同于搜索引擎,我们不需要一个爬虫,因为 Bitcoin 的数据都是以二进制的形式存在节点的磁盘上的。但是数据是以一种对人不太友好的方式组织在一起的,所以我们首先需要一个解析器,将这些二进制数据读出来,还原成它们本来的面目。之后我们再对这些数据进行一些加工,就得到了 OCAP 所需要的数据。
技术细节
在这里我会主要谈谈 Bitcoin 的数据具体是怎么存储的,并且在得到这些数据之后还需要做哪些额外的计算。
Bitcoin 数据是如何存储的
存储数据的文件
Bitcoin 的原始数据可以在$HOME/.bitcoin/blocks 下面找到。这个目录下面主要有两类文件,一种是类似于这样的文件:blk00952.dat, 而另一种是类似于这样的文件:rev000952.dat。 前一种 blk 开头的文件就是存储 Bitcoin 源数据的文件,而后一种是用来做 rewind 的。关于 rewind 我们下回再表,我们这次的重点在源数据文件。每一个 blk 数据文件大小的上限都是 128MB。当一个文件写满后,Bitcoin 程序会新建一个类似的文件来