標準ブロックリレー

受信側がほとんどすでに持っているデータのために、各ホップで往復2回と1メガバイト以上の転送が発生します。2013年の計測研究では、新しいブロックが見つかってからノードがそれを知るまでの中央値が6.5秒、平均が12.6秒でした。Bitcoin Coreは2016年8月23日にバージョン0.13.0でコンパクトブロックリレーを導入し、標準リレーはフォールバックとなりました。

仕組み

標準ブロックリレーは3つのメッセージを使用し、受信側のノードがすでに何を保持しているかについては何も前提としません。

ブロックを見つけたノードは、新しいブロックのハッシュを示すinvを送信します。または、BIP130がBitcoin Core 0.12.0に加わってからは、80バイトのヘッダーを直接運ぶheadersメッセージを送信します。これにより、ピアは別途getheadersの往復を省けます。受信側はそのブロックを保持しているかを確認します。保持していなければ、getdataで応答します。送信側は続いてblockメッセージを送信します。これはヘッダーに続けて、すべてのトランザクションを完全なシリアライズ形式で並べたもので、ブロックの上限である400万ウェイト単位の予算まで含みます。

無駄は言葉にすれば明らかです。何時間も稼働しているノードは、そのブロック内のほぼすべてのトランザクションをすでにmempoolに保持しています。それぞれがブロードキャストされたときに個別に受信しているからです。標準リレーはそれらすべてを2度目に送信します。通常の支払いで満たされたブロックでは、ピアごと、ブロックごとに、1メガバイトをはるかに超える冗長な転送になります。

その結果は単に見た目の問題ではありませんでした。伝播が遅いとステールブロックの割合が上がります。新しいブロックをまだ知らないマイナーは、古い先端で作業を続けるからです。ステールブロックは大規模なマイナーよりも小規模なマイナーに多くの負担をかけます。大きなプールは自身のブロックを即座に知るからです。したがって、より速いリレーは効率の問題であると同時に分散化の論点でもあり、BIP152と、大きなプールが相互に運用する専用のリレーネットワークの両方を後押ししました。

標準リレーはなくなっていません。ピアがコンパクトブロックを交渉しなかった場合、コンパクトな再構築に失敗して不足するトランザクションを補えない場合、そして初期ブロックダウンロードの間ずっと行われるものです。同期中のノードは複数のピアにgetdataで完全なブロックを同時に要求し、Bitcoin Coreではピアごとに最大16件が処理中となります。

どこで見られるか

標準ブロックリレーは、ノードが追いついたときよりも、追いついている最中に最もよく見られます。

初回同期の間は、ブロックに対するgetdataがトラフィックの大部分を占め、getpeerinfoのメッセージ別カウンターにはっきりと現れます。ノードが先端に到達すると、それらのカウンターは静まり、コンパクトブロックのカウンターが取って代わります。回線が遅い、またはピアが少ないマシンは標準リレーにより頻繁にフォールバックし、症状は公開ブロックエクスプローラーが表示している先端より1～2分遅れることです。

標準ブロックリレーvsコンパクトブロックリレー

標準リレーはブロックを送信し、コンパクトリレーはその記述を送信して残りを受信側に再構築させます。cmpctblockはヘッダー、ナンス、および各トランザクションの6バイトの短い識別子を運ぶため、数千件の支払いを含むブロックでも、1メガバイトをはるかに超える代わりに20キロバイト未満で記述できます。受信側はそれらの識別子を自身のmempoolと照合し、不足するものをgetblocktxnで要求し、ブロックをローカルで組み立てます。その後の検証は同一です。コンパクトリレーはバイトがどのように届くかを変えるだけで、有効なブロックとみなされるものが変わることはありません。