IBDは単なるファイル取得ではない。Full Nodeは履歴から検証済みUTXO集合を構築し、古いスクリプトの検査はassumevalid設定にも左右される。
ノードは接続先のアドレスを見つけてヘッダーを同期する。ヘッダーは履歴をつなぎProof of Workを含むが、内部の全取引の有効性を単独では証明しない。 [Bitcoin Developer Guide — Initial Block Download] [Satoshi Nakamoto — Bitcoin whitepaper]
累積作業量が検証する分岐候補を定める。ヘッダー数の多さや接続先の主張は、作業量と完全なブロック検査の代わりにならない。 [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — validation] [Satoshi Nakamoto — Bitcoin whitepaper]
ブロックは複数の接続先から並行取得できる。有効なチェーンへの接続は以前の状態に従うため、必要な履歴なしに取引出力を検証できない。 [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — validation]
Full Nodeは構造、Merkle root、支出規則、発行上限などを検査する。合意規則は高さと有効化状況に応じて適用され、ヘッダー検査だけでは完全な検証にならない。 [Bitcoin Core — validation] [Bitcoin Core — chainstate]
ブロック接続時に使用済み出力を除き、新たなUTXOを加える。このデータベースは現在の支出可能性を表し、全過去取引やアドレス残高の台帳ではない。 [Bitcoin Core — validation] [Bitcoin Core — chainstate]
既知の履歴が十分深いなどの条件下で、assumevalidは古いスクリプト検査を省略できる。任意の履歴を無検査で受理するわけではなく、assumevalid=0で最適化を無効にできる。 [Bitcoin Core — validation]
削除処理は検証処理後の古いブロックファイルを消し、UTXO集合と必要なメタデータを残す。長期保存容量を節約するが、通常のIBDで履歴を取得し処理する必要はなくならない。 [Bitcoin Core — validation] [Bitcoin Core — chainstate]
Bitcoin Core v29.0は先端の古さ、最低作業量、読み込み状態を使う。終了後は同じプロセスでフラグがtrueに戻らない。これは運用上の目安であり、世界で最新の先端を知る証明ではない。 [Bitcoin Core — validation] [Bitcoin Core — getblockchaininfo]
時間はCPU、メモリ、ディスク、ネットワーク、接続先に依存する。getblockchaininfoのverificationprogressは検証作業の推定であり、完了時刻の保証でも単なる取得バイト率でもない。 [Bitcoin Developer Guide — Initial Block Download] [Bitcoin Core — getblockchaininfo]
AssumeUTXOは対応するUTXOスナップショットを用い、先端での運用を早められる。履歴を背景で検証して結果をスナップショットと比較するため、早期利用は履歴検証完了を意味しない。 [Bitcoin Core — validation] [Bitcoin Core — AssumeUTXO design]
理解を深めるには、この項目とあわせて次もお読みください Pruned node, AssumeUTXO, Block propagation, Compact block relay. 次の項目からも参照されています Pruned node, AssumeUTXO.