ブロックチェーン/レベル III · ネットワーク/3.1 ノード/レッスン 3
初期ブロックダウンロード
履歴をゼロから再構築する：独立した検証のコスト
用意するものRAMが8GB以上でSSDを搭載したコンピューターBitcoin Coreソフトウェア（最新の安定版）`bitcoin-cli`が使えるターミナル環境
問い
- なぜ新しいノードは、どのブロックもダウンロードする前にブロックヘッダーをダウンロードするのでしょうか？
- 「assumevalid」を有効にすると、具体的にどのチェックがスキップされるのでしょうか。また、それが安全なのはなぜでしょうか？
- 帯域幅が十分に速く、数分でドライブを満たせるのであれば、なぜ初期同期には依然として数日かかるのでしょうか？
探究
- 新しく起動したBitcoin Coreには、ソースコードにハードコーディングされたジェネシスブロックしか含まれていません。チェーンの長さや有効性については何も知りません。ピアに接続すると、2009年1月3日から現在のチェーンの先端までの全履歴を再構築するプロセスである初期ブロックダウンロード（IBD）を開始します。これは受動的なコピーではなく、後述するショートカットを除き、各ブロックが受け入れられる前にコンセンサスルールに照らしてチェックされる能動的な再構築です。
- バージョン0.10（2015年）以降、IBDは2段階の戦略を採用しています。まず、ノードはサイズが小さく高速に送信できるすべてのブロックヘッダーをダウンロードします。そしてそれらのヘッダーのプルーフ・オブ・ワークを検証して難易度ターゲットを満たしていることを確認し、トランザクションの有効性はまだチェックしないまま、作業量のチェーンを構築します。ヘッダーチェーンが確立すると、ノードは複数のピアから並行してフルブロックを要求し、届いたものを順番に検証していきます。
- 暗号署名のチェックがあるため、トランザクションの検証には多大な計算コストがかかります。同期を高速化するため、バージョン0.14（2017年）で「assumevalid」が導入されました。このパラメータは、広くレビューされたブロックのハッシュをハードコーディングし、それより深く埋もれたすべてのブロックについて署名検証をスキップします。ただし、ノードはプルーフ・オブ・ワーク、金額、UTXOセットなど、それ以外のすべてを引き続きチェックします。その深い履歴について省略されるのは、スクリプトと署名のチェックだけです。ユーザーはこの機能を無効にして、ジェネシスブロック以降のすべての署名を検証することもできますが、その代わりに同期時間は大幅に長くなります。
- 最近のバージョンでは、現在のUTXOセットの事前計算済みスナップショットからノードを起動できる実験的な機能「assumeUTXO」が提供されています。ノードはバックグラウンドで全履歴を検証しながら、すぐに使用可能になります。そのチェックが完了するまでは、ソフトウェアにハッシュがハードコーディングされたスナップショットを信頼します（ファイル自体はどこから入手しても構いません）。チェック完了後は完全に独立した状態になります。
- IBDの処理時間は使用するハードウェアによって大きく異なります。高速なSSDと8GBのRAMを搭載した最新のマシンでは、同期に数時間かかることもあります。Raspberry Piのような性能が限られたデバイスでは、数日以上かかることもあります。ボトルネックはほとんどの場合帯域幅ではなく、UTXOキャッシュ（dbcache）のディスク書き込み速度や、スクリプトの検証に必要なCPUサイクルです。ノードが常に状態を読み書きしなければならないため、ギガビット級のインターネット環境であっても、性能の低いハードドライブでは処理が遅延します。
- 同期が完了すると、ノードは最も作業量の多い有効なチェーンの先端に到達します。これにより、ノードは観察者から完全な参加者へと移行し、ピアにトランザクションやブロックを中継できるようになります。`bitcoin-cli getblockchaininfo`コマンドでは、`verificationprogress`フィールドによってこの進捗が示され、過去のチェーンが検証されるにつれてその値は1.0に近づいていきます。その時点で、ノードはお金の履歴の完全なコピーを、独立して検証した状態で保持していることになります。
重要な事実
- Bitcoin Coreバージョン0.10（2015年）では、初期ブロックダウンロードを最適化するためにヘッダー優先の同期が導入されました。
- バージョン0.14の「assumevalid」パラメータは、同期を高速化するために、ハードコーディングされたハッシュのブロックより下にあるブロックの署名チェックをスキップします。
- ‘assumeUTXO’は、ノードがUTXOのスナップショットから開始し、バックグラウンドで履歴を検証することを可能にする機能で、最近のバージョンで実験的に導入されました。
- IBDにおいては、UTXOキャッシュのディスク書き込み速度とメモリ割り当てのほうが、帯域幅よりも大きなボトルネックになることがよくあります。
- 新しいノードは、複数のピアから並行してブロックがダウンロードされても、順番にそれらを検証します。
- `bitcoin-cli getblockchaininfo`を実行すると、チェーンのどの程度が検証されたかを示す`verificationprogress`が表示されます。
演習 九・六・三・一
9集めるビットコインノードの運用に使われる、異なるハードウェア構成（CPU、RAM、ストレージの種類）を9つ挙げてください。それぞれについて、新規インストール時に報告されている一般的な同期時間も記録してください。
6まとめるこれら9つの構成を、主なボトルネックに基づいて、CPUバウンド、RAMバウンド、ディスクI/Oバウンド、帯域幅バウンド、バランス型の6つのカテゴリーに分類してください。
3絞り込む6つを、初期同期にかかる時間を最も大きく左右する3つの要因に絞り込んでください。
1結晶化する初期ブロックダウンロードにおける、同期速度と暗号学的な独立性のトレードオフを1文で説明してください。
事実確認
日付、数字、主張は、下記に記載された公表資料と照合して確認しました。