utxo和block逻辑抽象

utxo

core目前的utxo架构逻辑，主要分为三个模块：

1. 第一类是硬盘上的，
2. 第二类是对硬盘做的一个缓存，
3. 第三类才是说mempool里面，交易进来mempool之后，你后面的交易可以复用前面的mempool交易里面的utxo，事实上，这个交易是没有成交的，严格来讲，称不上一个utxo，但是它可以从它父链中的out推算出来。

当一个交易进来mempool之后，即使没有打包，他也是可以产生可花费的输出的。这就对mempool有一个要求，当我交易来的时候，如果我花费的txin并不在标准的utxo里面的时候，我需要去mempool里面去寻找，他是不是花的还是没有打包的交易，如果是，我们需要在mempool中抽象出来一个东西，内存版的utxo，区别于utxo的cache，就是要把所有已经进入mempool中的out抽象为这个utxo存到集合中。core将以上三个view使用继承关系，封装出来，实现有点复杂。

图示如下：

101.png

jiangda：他们可以完全拆分开来，如果需要mempool的，我直接就去mempool中去寻找。

根据上述分析，我们可以将utxo模块进行拆分，一部分是utxo集，另一部分是mempool中的逻辑，我们将二者分开处理。

utxo cache是db utxo的一个子集，当读的时候，先去cache中寻找，cache中没有再去db中寻找，写的时候，也是先往cache中写，然后，再刷新到db中。当重启的时候，会把所需要的数据从db load进cache中。

拆分后的逻辑，如下所示：

image.png

目前的思路是：coincache和db是一个逻辑，我先去coincache中寻找，找不到再去db中找，如果还是没找到，再去coinpool中寻找，虽然先去查mempool更快，但是每一个节点的mempool都一样，但是db是最准的，所以只能是先去查cache再去mempool中找。

coinPool是对mempool的一个抽象，coinCache是对utxoCache的一个抽象。

实现时，可以封装两个函数 getFromUTXO() 和 getFromMempool() 分别从utxo集和mempool中获取数据。

关于out设置为单个的coin还是数组的形式的争论

设置为一个coin更符合utxo的设置逻辑

jiangda：关于之前数组的设计有一个重大的bug，会把所有内存较小的节点搞挂掉，所以最后都修改为单个coin的形式。

yujian：如果这个outpoint已经花掉了，它在持久化的时候会独立的存储，单个的时候，只要这个key没有，它是一定不能花的。

空间换时间：内存和cpu需要舍弃一个，数组的思路浪费内存，内存的使用效率没有单个coin的好，但是确实比单个coin的要快。

综合考虑，使用单个coin来实现。

block

因为写到盘上的现有数据，你就必须承认，所以block的数据结构没有太大的变化。

图示如下：

image.png

块的数据同时会写入db和undo文件中，undo文件是用来恢复块的时候使用的，类似于mysql的undo log。

一个node节点中可以存储 blockheader 和block，block就是一个完整的块，block header分为三类：

• active
• branch
• orphan

图示如下：

image.png

当我接收块的时候，我希望是按照上述正常的顺序来接收，但事实上我是没有办法控制我接收的一个顺序的，可能会造成下面的错误的接收顺序，假设我先接收到block 3，那就是一个orphan，也就是说，一个节点我只能根据pre hash找到我的父亲，但是没办法去找到自己的孩子，所以只有当block 2进来的时候，我block 3才是有价值的。

孤块.png

• orphan表示孤块，孤块自己本身就是一条链。
• branch记录的是一段时间内，所有的块数据，它是按照工作量从小到大的顺序排列。
• active记录的是当前的激活链。

当前块的高度不是拿现在的块的高度计算出来的，而是拿上一个块的height+1计算出来的，这样能够防止作弊。