| 字段 | 大小 | 格式 | 描述 |
|---|---|---|---|
| Version | 4 字节 | 小端序 | 区块版本号 |
| Previous Block | 32 字节 | 自然字节序 | 前一个区块的区块哈希 |
| Merkle Root | 32 字节 | 自然字节序 | 区块中包含的所有交易ID的默克尔根 |
| Time | 4 字节 | 小端序 | 当前时间的 Unix 时间戳 |
| Bits | 4 字节 | 小端序 | 目标值的紧凑表示 |
| Nonce | 4 字节 | 小端序 | 随机数，用于尝试找到有效哈希 |
| Transaction Count | 动态 | compact size | 区块中包含的交易数量 |
| Transactions | 动态 | 交易数据 | 区块中包含的所有原始交易数据 |
区块头中的 4 字节 version 字段表示创建该区块时使用的比特币协议版本。
历史
-
以上为正常字节序, 实际的区块数据中, 以小端序显示。
-
在激活高度前面的区块中, 会发现有相同的
version值, 用于表示矿工支持该升级, 直到激活高度后, 才会真正使用该版本号。
2015 年 10 月, BIP 9 被提出, 旨在提供更灵活和可扩展的升级机制, 其规定 version 字段的比特位分配, 称作 version bits。
Version Bits
version 字段占据 4 个字节, 即 32 个比特位。前 3 个比特位必须为 001, 用于表示正在使用 version bits。后 29 个比特位用于不同的软分叉升级提议, 意味着可以同时支持最多 29 个不同功能的升级。
0010 0000 0000 0000 0000 0000 0000 0000 = 0x20000000该版本号也成为了当前默认版本号。
对于不同的软分叉升级需将对应的比特位设置为 1。
Bit 1
BIP 141 隔离见证升级, 从0开始计数, 将倒数第 1 个比特位设置为 1。
如下是激活高度 481824 的区块头数据
0x02000020 转换为正常字节序为 0x20000002, 转换为二进制为
0010 0000 0000 0000 0000 0000 0000 0010Bit 2
BIP 341 Taproot升级, 将倒数第 2 个比特位设置为 1。
如下是激活高度 709632 的区块头数据。
0x04002020 转换为正常字节序为 0x20200004, 转换为二进制为
0010 0000 0010 0000 0000 0000 0000 0100软分叉激活
软分叉激活使用了该版本协议, 在一个目标值调整周期(2016个区块)内, 有 90% 区块的 version 字段将对应的新功能的比特位设置为 1, 则该升级将激活。
由于 version 字段对于版本位没有特定的限制, 所以经常可以看到区块头数据中包含一些奇怪的版本号, 这是因为矿工将其作为额外的随机数计算区块哈希了。
例如区块 860498 的区块头数据
0x00606821 转换为正常字节序为 0x21686000, 转换为二进制为
0010 0001 0110 1000 0110 0000 0000 0000再比如区块 860362 的区块头数据
0x00801520 转换为正常字节序为 0x20158000, 转换为二进制为
0010 0000 0001 0101 1000 0000 0000 0000这些版本位并没有针对任何特定升级进行信号传递, 只是方便矿工可以快速计算出小于目标值的区块哈希, 以便获得区块奖励。