区块链/等级 III · 网络/3.1 节点/课程 3
初始区块下载
从零开始重构历史：独立验证的代价
材料配备至少8GB内存及SSD的电脑Bitcoin Core 软件（最新稳定版）通过 `bitcoin-cli` 进行终端访问
好奇
- 为什么新节点在下载任何区块之前要先下载区块头？
- 当启用“assumevalid”时，会跳过哪些具体的检查？这样做为何是安全的？
- 如果带宽快到几分钟就能填满一块硬盘，为什么初始同步仍可能需要好几天？
探索
- 一个全新的 Bitcoin Core 实例只包含硬编码在源代码中的创世区块。它对链的长度和有效性一无所知。与对等节点建立连接后，它会启动初始区块下载（IBD），重建从2009年1月3日到当前链尖的全部历史。这不是被动的复制，而是主动的重建：除下文所述的捷径外，每个区块在被接受之前都要依据共识规则进行检查。
- 从 0.10 版本（2015年）开始，IBD 采用两阶段策略。首先，节点会下载所有区块头——这些数据体积小且传输速度快。节点会验证这些区块头中的工作量证明，以确保其符合难度要求，从而构建出工作量链，但此时还不检查交易的有效性。一旦区块头链建立完成，节点就会同时向多个对等节点请求完整的区块，并在收到这些区块后依次对其进行验证。
- 由于需要进行密码学签名检查，交易验证的计算开销很大。为了加快同步，0.14版本（2017年）引入了“assumevalid”。该参数会对某个经过广泛审查的区块（其哈希值硬编码在软件中）之前、被深埋的所有区块跳过签名验证。节点仍会检查其他所有内容，包括工作量证明、金额以及UTXO集；对于那段久远的历史，只有脚本和签名检查会被跳过。用户可以关闭这一设置，从创世区块起验证每一个签名，代价是同步时间显著延长。
- 较新的版本提供了“assumeUTXO”这一实验性功能，允许节点从预先计算好的当前UTXO集快照开始运行。节点能很快投入使用，同时在后台验证完整历史。在这项检查完成之前，节点信任的是一个哈希值硬编码在软件中的快照（快照文件本身可以来自任何地方）；检查完成后，节点即完全独立。
- IBD所需时间因硬件不同而差异巨大。在配备高速SSD和8GB内存的现代电脑上，同步可能只需数小时；而在树莓派（Raspberry Pi）这类性能受限的设备上，可能需要数天甚至更久。瓶颈很少是带宽，而是UTXO缓存（dbcache）的磁盘写入速度以及脚本验证所需的CPU周期。即使拥有千兆网络，慢速机械硬盘也会让整个过程停滞，因为节点必须不断读写状态数据。
- 同步完成后，节点便到达累计工作量最多的有效链的链尖。它从观察者转变为完整的参与者，能够向对等节点转发交易和区块。`bitcoin-cli getblockchaininfo` 命令通过 `verificationprogress` 字段显示这一进度，随着历史链逐步通过验证，该值会逐渐接近1.0。此时，节点便持有一份完整的、经过独立验证的货币历史副本。
关键事实
- Bitcoin Core 0.10 版本（2015年）引入了区块头优先（headers-first）同步，以优化初始区块下载。
- 0.14 版本中的“assumevalid”参数会对某个硬编码哈希值之前的区块跳过签名检查，以加快同步速度。
- “assumeUTXO”允许节点从UTXO快照开始运行，并在后台验证历史，该功能已在近期版本中以实验性方式引入。
- 在 IBD 过程中，UTXO 缓存的磁盘写入速度和内存分配往往是比带宽更显著的瓶颈。
- 即使区块是从多个对等节点同时下载的，新的节点也会按顺序对其进行检查验证。
- `bitcoin-cli getblockchaininfo` 会显示 `verificationprogress`，表示链已有多大比例完成验证。
练习 九、六、三、一
9收集列出用于运行比特币节点的9种不同的硬件配置（CPU、RAM、存储类型）。同时注明每种配置在首次安装时的典型同步时间。
6归类根据这9种配置的主要瓶颈，将它们分为6类：CPU受限、内存受限、磁盘I/O受限、带宽受限，或是均衡型。
3提炼将这6类归纳为最能决定初始同步耗时的3个因素。
1凝结用一句话解释：在初始区块下载中，同步速度与密码学上的独立性之间存在怎样的权衡。
事实核查
日期、数字及数据均依据下方列出的已发表资料进行核实。