block headers 以 80 字节的格式进行序列化, 然后作为比特币工作量验证算法的一部分进行哈希处理, 使序列化头部格式成为共识规则的一部分
bytes | name | 数据类型 | 描述 |
---|---|---|---|
4 | version | int32_t | block version 指示要遵循哪一组块验证规则 |
32 | previous block header hash | char[32] | SHA256(SHA256()) hash,以前面 block 的 header 的内部字节顺序排列。这确保在不改变该块的头部的情况下不能改变先前的块。 |
32 | merkle root hash | char[32] | SHA256(SHA256()) 是按照内部字节排序的 hash。 merkle root 源自该块中包含的所有交易的 hash 值,确保在不修改头部的情况下不会修改这些交易。 |
4 | time | uint32_t | 块时间是矿工开始散列头部时的 Unix 纪元时间(根据矿工)。 必须严格大于前 11 个 block 的平均时间。 根据其时钟,全节点将不会接受超过两个小时的 headers。 |
4 | nBits | uint32_t | 此块的 header hash 的目标阈值的编码版本必须小于或等于。 |
4 | nonce | uint32_t | 任意数量的矿工都可以修改头部 hash 来确保能够产生小于或等于目标阈值的 hash。 如果所有 32 位值都经过测试,则可以更新时间或更改 coinbase 交易并更新 merkle 根。 |
哈希按内部字节顺序排列; 其他值都是小端顺序
block header 的消息示例如下:
- 02000000 ........................... Block version: 2
- b6ff0b1b1680a2862a30ca44d346d9e8
- 910d334beb48ca0c0000000000000000 ... Hash of previous block's header
- 9d10aa52ee949386ca9385695f04ede2
- 70dda20810decd12bc9b048aaab31471 ... Merkle root
- 24d95a54 ........................... Unix time: 1415239972
- 30c31b18 ........................... Target: 0x1bc330 * 256**(0x18-3)
- fe9f0864 ........................... Nonce
- Block Versions
Version 1: 在创世区块中被引入(January 2009)
Version 2: 在 Bitcoin Core 0.7.0(2012 年 9 月)中通过软分叉被引入如 BIP34 所述, 有效的 version2 block 需要 block height parameter in the coinbase 在 BIP34 中还描述了拒绝某些块的规则; 根据这些规则, Bitcoin Core 0.7.0 及更高版本在 block height 为 224,412 处开始拒绝在 coinbase 中没有 version2 的 block height, 并在块高度为 227,930 的三周后开始拒绝新生成的 version1 的块
version3: 在 Bitcoin Core 0.10.0(2015 年 2 月)中通过软分叉被引入当 fork 达到全面执行 (2015 年 7 月) 时, 它需要严格按照 BIP66 中所描述的对新块中的所有 ECDSA 签名进行 DER 编码 自从 Bitcoin Core 0.8.0(2012 年 2 月)以来, 不使用严格 DER 编码的交易是非标准的
version4: 在 BIP65 中指定并在 Bitcoin Core 0.11.2(2015 年 11 月)中引入的区块, 通过软分叉开始启动 (2015 年 12 月) 这些块现在支持该 BIP 中描述的新 OP_CHECKLOCKTIMEVERIFY 操作码
用于 version23 和 4 升级的机制通常称为 IsSuperMajority(), 该功能添加到 Bitcoin Core 中以管理这些软分支更改有关此方法的完整说明, 请参阅 BIP34
Merkle Trees
merkle root 是使用此块中所有交易的 TXID 构建的, 但首先需要按照共识规则的要求排列 TXID:
coinbase 交易的 TXID 总是排在第一位
此块中的任何输入都可以使用同时出现在此块中的输出 (假设花费是有效的) 但是, 对应于输出的 TXID 必须放置在与输入对应的 TXID 之前的某个点 这可以确保整个区块链的交易在输入之前都有与之对应的输出
如果一个块只有一个 coinbase 交易, coinbase TXID 将会被用作 merkle root 的 hash
如果一个块只有一个 coinbase 交易和一个其他交易, 那么这两个交易的 TXID 按顺序排列, 连接成 64 个原始字节, 然后 SHA256(SHA256()) hash 在一起最终形成 merkle root
如果一个块有三个或更多的交易, 则会形成中间的 Merkle 树行 TXID 按顺序排列并配对, 从 coinbase 交易的 TXID 开始 每个对连接在一起作为 64 个原始字节和 SHA256(SHA256()) hash 形成第二行 hash 如果有一个奇数 (非偶数) 的 TXID, 则将最后一个 TXID 与其自身的副本连接并进行 hash 如果第二行中有两个以上的 hash, 则重复该过程以创建第三行(并且, 如有必要, 可以进一步重复以创建附加行) 一旦获得一行只有两个 hash 值, 这些 hash 值被连接并哈希来产生 merkle root
上面逻辑有点绕, 我们通过一张图来直观感受一下:
串联时, TXID 和中间 hash 总是以内部字节顺序排列, 并且当它放入 block header 时, 生成的 merkle root 也按照内部字节顺序排列
Target nBits
target threshold 是一个 256 位无符号整数, header hash 必须等于或低于该 header 才能成为块链的有效部分 然而, header 字段 nBits 仅提供 32 位空间, 因此目标号码使用一些称为紧凑的精确格式, 其工作方式类似于科学记数法的基本 256 版本:
作为一个 base-256 的数字, nBits 可以像字节一样快速地解析, 这与解析 10 进制科学记数法中的小数相同:
尽管 target threshold 应该是一个无符号整数, 但原始 nBits 实现继承了已签名数据类的属性, 如果设置了有效数的高位, 则 target threshold 为负值 这是无用的 - header hash 被视为无符号数, 因此它永远不会等于或低于负目标阈值 Bitcoin 以两种方式处理这个问题:
在解析 nBits 时, Bitcoin 将负目标阈值转换为零目标, 该 header hash 可以等于(理论上至少)
当为 nBits 创建一个值时, Bitcoin 会检查它是否会产生 nBits, 这会被解释为负值; 如果是这样, 它将有效位数除以 256, 并将指数增加 1 以产生具有不同编码的相同数字
难度 1, 允许的最小难度, 在 mainnet 和当前 testnet 上由 nBits 值 0x1d00ffff 表示 Regtest 模式使用不同的难度值 1-0x207fffff,uint32_max 以下可以编码的最高值; 这允许在 regtest 模式下几乎立即构建块
Serialized Blocks
根据当前的共识规则, 除非序列化大小小于或等于 1 MB, 否则块无效下面介绍的所有字段均按序列化的大小计算
bytes | name | 数据类型 | 描述 |
---|---|---|---|
80 | block header | block_header | block header 部分中描述的格式。 |
Varies | txn_count | compactSize uint | 此区块中的交易总数,包括 coinbase 交易。 |
Varies | txns | raw transaction | 此块中的每笔交易都是原始交易格式。交易必须与他们的 TXID 出现在 merkle 树的第一行中相同的顺序出现在数据流中。 |
在一个区块中的第一笔交易必须是一个 coinbase 交易, 该交易应收集并消费本区块交易支付的任何交易费用
block height 低于 6,930,000 的所有 block 都有权获得新创建的比特币价值的区块补贴, 这也应该用于 coinbase 交易 (区块补贴从 50 比特币开始, 每 210,000 块减半 - 大约每四年一次, 截至 2017 年 11 月, 为 12.5 比特币)
交易费和区块补贴一起被称为区块奖励如果它试图花费比块奖励可用的更多价值, 则 coinbase 交易是无效的
来源: https://sdk.cn/news/8134