《迅雷链精品教程》第六课：主流区块链数据存储分析（一）

上节课我们学习了区块链中的账户和账本，了解了区块链账户的特点和本质。 今天我们就来系统的学习一下区块链数据存储。 在学习课程之前，您可以思考以下问题： 区块链数据是如何存储的？ 区块链如何在没有中心信任节点的情况下快速证明数据的可靠性和正确性？ 如何在区块链上访问典型智能合约中的数据？

下面我们以比特币和以太坊这两个典型的区块链项目为例，用最通俗的语言来解释以上问题。

学习课程时，还可以获得为期一个月的BaaS平台试用机会，免费使用高性能区块链服务（点击链接免费领取）。 课程学习结合实操，让你快速成为区块链高手！

*以下是第6课的内容~

第6课主流区块链数据存储分析比特币

块状结构

Block Size：整个块的数据大小（除此字段外）

Block Header：区块头信息，包括版本号、时间戳、随机数等。

Transaction Counter：区块包含的交易数据

Transactions：区块包含的所有交易数据，交易总数为Transaction Counter的值

块头结构

版本：软件版本号

Previous Block Hash：前一个区块的哈希值

Merkle Root：区块中所有交易的指纹——Merkle树的根节点，区块在节点间广播，所有节点按照相同的算法（Merkle树）组织交易，判断交易是否被修改时间戳: 块创建时间

Diffculty Target：根据PoW算法计算出的区块难度值。 该字段是难度值的编码数据。 相关算法可以查看比特币的相关资料

Nonce：PoW算法用来计算难度值的随机数

默克尔树

从比特币的区块结构我们知道，Merkle Root代表了区块中所有交易的指纹，这样接收到区块的节点就可以验证区块中的交易数据是否被修改，如果有交易数据被修改，则基于区块中所有交易计算的Merkle Root与区块头的Merkle Root不同。

Merkle Root 是 Merkle Tree 的根节点。 在一个比特币区块中，用区块中包含的所有交易数据构建一个Merkle Tree，然后得到根节点Merkle Root。 让我们仔细看看默克尔树：

Merkle Tree 通常也被称为 Hash Tree，顾名思义，它是一种存储哈希值的树。 Merkle Tree的叶子是数据块（如一个文件或文件集合）的哈希值，非叶子节点是其对应子节点串接后的哈希值。 树的构建过程就是递归计算哈希值。 如上图所示，首先计算交易a和交易b的哈希值得到Ha和Hb，然后结合Ha和Hb计算哈希值得到Hab。 其他节点也以同样的方式递归比特币UTXO，最终得到Merkle Root。

Merkle Tree还可以提供一条数据是否在树中的证明信息，即Merkle Proof。 Merkle Proof从树中的某个点开始，向上遍历计算出Merkle Root需要经过的路径节点。 在上面的例子中，如果比特币轻节点想要验证区块中是否包含Txb（红框），可以向全节点请求Txb交易的Merkle Proof来证明Txb的存在。 过程是：

所有节点只需要返回黄色部分的节点信息（Ha和Hcd）

轻节点执行计算Hash(Txb)=Hb → Hash(Ha+Hb)=Hab → Hash(Hab+Hcd)=Habcd，并将计算出的Merkle Root（即Habcd）与已知的Merkle Root进行比较block header ，若相同则认为交易确实进入了区块

在上图中，只有少量交易。 如果区块包含很多交易，Merkle 证明只需要有 LOG2(n) 个节点。 这时候，Merkle Proof 的优势就会变得非常明显。

贸易

比特币交易包括交易输入和交易输出。 交易输入代表交易的资产来源，交易输出代表资产流向。 比特币区块链的初始资产来源是“挖矿”获得的奖励。 奖励也用交易来表示比特币UTXO，即coinbase transaction或coinbase transaction。 参考为交易输入的交易。

比特币使用 UTXO（Unspent Transaction Output）数据模型来记账。 它只表明有多少比特币属于谁，而不是谁拥有多少比特币。 每笔交易的输出是一个UTXO。 所有输出但未使用的 UTXO 的集合称为 UTXO 集。 这些 UTXO 记录被区块上的整个网络识别为有效。 一个UTXO可以代表一个任意大小的比特币，但一旦创建，它就不可分割，是比特币区块链交易环节的最小单位，即一个UTXO要么不被使用，要么被完全使用。 下面两张图说明了与比特币交易相关的输入和输出编码格式：

交易输入编码格式

Transaction Hash：使用的UTXO的原始交易哈希，即原始交易的输出有这个UTXO

Output Index：UTXO索引，index代表这个UTXO在原始交易输出中的序号，第一个UTXO序号为0

Unlocking-Script Size：解锁脚本长度

Unlocking-Script：解锁脚本，即证明这个UTXO可以使用，所有节点都可以验证，对应锁定脚本

交易输出编码格式

amount：比特币的数量，以“聪”为单位

Locking-Script Size：锁定脚本长度

Locking-Script：锁定脚本，即只有可以解锁的账户才能使用这些比特币，一般是指目标账户的信息

在单个比特币交易中，它可以包括多个输入和多个输出。 把UTXO比作平时使用的纸币，不考虑手续费的话，那么一笔交易输入可以是10张10元的UTXO，输出是2张50元的UTXO，也就是10张10元折算成两张50元。 如果资产投入总量大于资产产出总量，投入产出的差额将被“矿工”收取手续费。 上面的例子也很形象地说明了为什么UTXO要么没有被使用，要么被完全使用。 它是比特币交易中的最小单位。 图 3 说明了比特币区块链中四个账户通过三笔交易转移比特币的过程。 上一笔交易的输出是下一笔交易的输入。 所有的交易形成一个交易链，每笔交易的有效性都可以被验证。 那么交易前后是如何验证的呢？

首先，每一个UTXO都有一个对应的锁定脚本（Locking-Script），它是目标账户、加密方式、验证方式等信息的组合。 这些信息的目的是说明这个UTXO属于谁，目标账户在什么条件下可以使用这个UTXO，所以UTXO一旦产生，就确定了它属于谁。 比特币钱包也会根据账户地址收集账户所有的UTXO，显示可用的比特币，并使用UTXO进行交易。

其次，每笔交易中的交易输入都有原始交易哈希、UTXO所在索引以及解锁脚本（Unlocking-Script），其中包括私钥和公钥的签名。 通过原始交易和UTXO索引，可以唯一确定一个UTXO，然后使用UTXO中的解锁脚本和锁定脚本来验证正确性，比如公钥生成的账户是否与中的地址相同解锁脚本； private key signature 是否可以用公钥验证正确性。 如果验证不成功，交易将不会被批准； 如果验证成功，这个UTXO代表的比特币数量就可以作为支付，所以在交易输入结构中看不到交易的原始数量。 交易输入验证成功后，需要比较输入的比特币总数是否大于等于输出的总数，否则交易也无效。

最后，交易验证打包成功后，使用交易输入中的UTXO，并将该UTXO从UTXO集合中删除； 交易输出中的 UTXO 将被添加到 UTXO 集合中。 UTXO 集合只有两个操作：添加和删除。 同时，每个块处理完后，都会将相应的信息写入磁盘文件。

三、关联交易流程

磁盘文件

比特币使用普通文件和leveldb数据库来存储所有与区块相关的文件。 普通文件主要存储完整的块信息，leveldb用于存储元数据信息和块的一些状态信息。 数据目录主要分为以下四个部分：

blocks/blk*.dat :​​ 完整的区块数据信息

blocks/index/*：这是一个leveldb数据库，存储了所有的区块元数据信息，包括区块高度，区块存储在哪个文件，以及在文件中的偏移位置，方便查询的详细信息块，否则查询块很慢

chainstate/*：这是一个leveldb数据库，存储了当前所有未花费的交易输出以及与这些交易来源相关的一些元数据，方便快速验证新交易是否有效，否则只能通过扫描所有区块来验证，所以效率很低，数据在存储时被压缩

blocks/rev*.dat：这里存放undo blocks数据，类似于mysql中的undo log，用于异常发生时的错误恢复

块/块*.dat

block文件以blk00000.dat、blk00001.dat、blk00002.dat等格式命名，每个文件大小约为128M。 为了防止碎片过多，分配了16MB作为一个chunk。 每个blk*.dat文件也会有一个rev*.dat文件与之对应，单个文件的相关信息也会存储在块索引数据库中。

块/索引/*

区块高度信息、存储文件、文件中的偏移位置、交易信息等元数据信息以kv的形式存储在leveldb数据库中，便于快速检索和查询。 索引数据库中的kv解释如下：

概括

本文从区块结构、交易结构和存储方式等方面介绍了比特币实现和存储的相关内容，展示了区块链在去中心化和数据不可篡改方面的优势。 下一篇文章将继续介绍以太坊区块链的相关方面。

*恭喜你完成了第六课。 在第七课中，我们将继续了解以太坊区块链的相关方面。 欢迎关注~