术语表 /节点与软件
初始区块下载
又称 IBD。
- 初始区块下载是什么？
- 初始区块下载是新的比特币节点所经历的追赶阶段，在此阶段中，节点获取并验证从创世区块到当前链尖的每一个区块。
这是运行自己的节点时唯一真正缓慢的环节，而且只发生一次。截至2026年8月，节点需要收集并检查759 GB 的历史数据，在配备固态硬盘的高速机器上需要数小时，在配置较弱的机器上则需要数天。当链尖的时间距今不足24小时，且所持有的链带有足够的累计工作量时，Bitcoin Core 即判定同步已完成。
运作方式
初始区块下载有意将成本最低的证据放在最前面。
区块头优先。自2015年2月16日发布的0.10.0版本起，Bitcoin Core 会先向对等节点索取80字节区块头组成的链，然后才请求任何区块体。验证这些区块头很快，可以确定哪条链拥有最多的工作量证明，并且让软件事先知道要获取多少个区块。随后可以同时向多个对等节点并行请求区块，而不是逐个请求，这正是以小时计的同步与以周计的同步之间的差别。
签名检查是开销最大的部分，因此设有一条带开关的捷径。Bitcoin Core 0.14.0引入了一项设置，它指定一个特定的历史区块（经审查后硬编码在每个发行版中），并跳过对其下方所有内容的脚本签名验证。其他所有规则仍然适用：金额、双重支付、区块补贴、默克尔根、工作量证明。把该选项设为零，节点就会检查自2009年以来的每一个签名；如果您想做到完全不信任任何一方，这样做一次是值得的。
现在，在同步完成之前也有办法发挥作用。Bitcoin Core 28.0附带了一些参数，用于加载在区块高度840,000时生成的未花费输出集快照，使节点能在几分钟内为您的钱包提供服务，同时在后台悄悄重建更早的历史。当后台同步到达快照高度时，节点会将自己计算出的哈希值与发行版中的哈希值进行比较；不一致则节点关闭。
内存是大多数人从未调节过的杠杆。数据库缓存默认为450 MiB，在有富余容量的机器上将其提高到数 GB，可以把未花费输出集保留在内存中，而不是让磁盘反复读写，从而让总耗时减少数小时。
在哪里会遇到它
您第一次启动 Bitcoin Core 时会遇到初始区块下载，节点关闭数月后再次启动时也会遇到。
界面会提示正在同步区块头，然后显示落后了多少周。早期的估算并不可靠，因为2011年的区块非常小，而去年的区块则不然。进度并非线性，节点看起来停在60%时，通常是在处理区块链上数据量最大的那几年。
出现问题时，三条实用规则几乎涵盖了全部情况。使用固态硬盘，因为机械硬盘会把一天的工作变成一周的工作。为该进程提供带宽和稳定的连接，因为整份存档都必须下载下来。同步真正完成之前，不要连接钱包并因余额缺失而慌张，因为部分同步的节点对尚未到达的区块中的币没有任何结论。
初始区块下载 vs Blocks-first 同步
初始区块下载是目标；Blocks-first 同步是实现该目标的一种已过时的方式。阅读较早的文档时，这一区别很重要，因为那些文档常常把两者描述得好像是同一回事。任何正在追赶的节点都在执行初始区块下载，无论它是向单个对等节点按顺序请求区块，是先获取区块头再同时从多个对等节点拉取区块体，还是加载快照后回填。这一阶段之所以有专门的名称，是因为它的性能特征和攻击面都不同于稳态运行，而不是因为它规定了某种方法。