Bitcoin UTXO代码分析（三）：与其它模块的交互

Blockchain激活

Blockchain 发生变化时 UTXO 相关的逻辑：

在 blockchain 结构重新组织，当前发生变化时，某些 block 会链接上 activeChain, 某些 block 会断掉跟 activeChain 的链接，内部会调用和 ，这里会生成临时的 CCoinsViewCache 对象，后端连接上全局的另一个 CCoinsViewCache实例 , 在调用 ConnectBlock，DisconnectBlock 后，更新自己的状态到 。

Mempool相关

有一个对象专门用来处理 Mempool 相关的 UTXO，对象为:

在 rpc 请求时，比如:signrawtransaction，combinerawtransaction，构造了临时 viewcache 对象, 临时 viewMempool 对象 ，被设为 view 的后端，这样确保 mtx 交易的父交易，数据来源包括当前 activeChain 的内存部分，磁盘部分，还有 mempool。

请求：

rpc 请求 gettxout 处理时，如果 为 true，会构造临时 ViewMemPool，方便外部用户查询 utxo 时，引入 mempool 中的 utxo。

检查 timelock 交易的代码：

评估使用的交易时，需要再次构造临时ViewMemPool，查询当前blockchain tip 对应的 coin 集合与内存池的 coin 集合。

有交易进入内存池时：

在中，构造了临时 ccoinsviewcache 对象 view，

临时 ccoinsviewMemPool 对象 viewmempool，view 后端数据来源是viewmempool。

UTXO的存储

utxo 的磁盘存储使用了 leveldb 键值对数据库， 键的序列化格式：

C[32 bytes of outpoint->hash][varint(outpoint->n]

value 对应的存储格式是就是 coin 对象的序列化形式:

VARINT((coinbase?1: 0) (height

CTxout 的序列化格式(使用 CTxOutCompressor 类定制特殊压缩方式)。

在每一个 CTxout 对象本身之前， 加上了一个变长编码的数字，接着就是 txcout 本身:

接着是被压缩的数目, 使用成员函数中的算法:

CTxout 中的锁定脚本使用CScriptCompressor 对象压缩存储:

基本思路， 对于 p2pkh 类型的脚本, 比如:

压缩成:

总共 21 字节。

p2sh 类型脚本， 比如:

OP_HASH160 20 0x620a6eeaf538ec9eb89b6ae83f2ed8ef98566a03 OP_EQUAL

压缩成:

[0x01][620a6eeaf538ec9eb89b6ae83f2ed8ef98566a03]

总共 21 字节。

p2pk 类型脚本， 比如:

33 0x022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da OP_CHECKSIG

压缩成：

[0x2][2df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da]

总共 33 字节， 未压缩的 p2pk 脚本， 首字节是 0x04(pubkey[64]&0x01), 接着是 32 字节的 pubkey 的 x 坐标。

对于其它不能被压缩的脚本， 如 segwit 的 scriptPubKey，采用下面方法:

本文由 喻建写作，转载无需授权