ブロックファースト同期

現在この方法で同期するものはなく、その理由は算数の問題です。厳密に順次ダウンロードする方式では、1つのピアのアップロード速度より速くは進められず、2015年にはチェーンがすでに大きすぎて、妥当な時間内に完了できませんでした。この手法はプロトコル内の代替手段として、また古いドキュメントにおける混乱の元として残っています。

仕組み

状況：blocks-first同期は、2015年2月16日にリリースされたBitcoin Core 0.10.0でheaders-first同期に取って代わられました。この同期が使っていたメッセージは今もピアツーピアプロトコルの一部であり、今も応答が返されますが、現在のどのクライアントも追いつくためにそれらに依存していません。

やり取りは2台のマシン間のループでした。ノードは、すでに持っているブロックのハッシュを載せたgetblocksメッセージを送信しました。ピアは、それに続く最大500個のブロックハッシュを列挙したインベントリで応答しました。ノードはgetdataでそれらのブロックを要求し、受け取り、それぞれを完全に検証してから、次に何が来るかを問い合わせる別のgetblocksを送信しました。これを数千回繰り返します。

この設計から3つの問題が生じました。並列性がありませんでした。まだ存在を知らされていないブロックを2番目のピアに要求するのは筋が通らないため、同期全体が、たまたま通信しているピアの速度で進みました。どこまで進めばよいかを知る方法もありませんでした。チェーンは一度に500個のハッシュずつしか明らかにならないため、古いクライアントは意味のある進捗バーを表示できませんでした。そして、遅いピアや敵対的なピアはブロックを少しずつしか送らずに済み、ノード側には、より良いチェーンが別の場所にあると安価に判断する方法がありませんでした。

headers-first同期は、安価な証拠と高価な証拠を分けることで、3つの問題すべてを解決しました。まずヘッダーのチェーンを取得して検証します。2014年12月時点では全履歴で27メガバイトであり、1件のトランザクションもダウンロードする前に、最良のチェーンの形とその長さの両方が分かります。その後、ブロック本体は多数のピアから同時に要求できます。副作用として、ブロックが順不同で到着し、順不同でディスクに書き込まれるようになりました。そのため、バージョン0.10.0が作成するデータディレクトリは、それより古いものでは読み取れません。

目にする場面

blocks-first同期は、ソフトウェアよりもドキュメントで目にします。

2015年より前に書かれた参考資料には、今も出回っている開発者向け資料の多くを含め、順次ループがあたかもビットコインの仕組みであるかのように説明しているものがあります。そうではなく、初回同期を単一ピアからの順次ダウンロードとして説明するページは、単に古くなっているのです。Bitcoin Coreは非常に古い、または珍しいクライアントのためにgetblocks要求への応答を続けているため、これらのメッセージはパケットキャプチャやプロトコル仕様に現れます。

今日ノードを運用する人にとって、設定すべきことも選ぶべきこともありません。現在も保守されている実装はすべてそうしているため、クライアントはまずヘッダーを取得します。

blocks-first同期vs headers-first同期

blocks-first同期とheaders-first同期は、最初に何を要求するかが異なり、その他のすべてはそこから導かれます。blocks-first同期は完全なブロックを順番に要求し、その過程でチェーンの形を学んだため、最良のチェーンの発見とダウンロードを同じ遅いパスで行いました。headers-first同期は作業を分割します。ブロックあたり80バイトを使ってどのチェーンが最も多くのプルーフ・オブ・ワークを蓄積しているかを確定し、その後、送ってくれる相手からブロック本体を並行して収集します。各ブロックに適用される検証は双方で同一です。変わったのは操作の順序であり、それだけで初回同期は数週間から数時間になりました。