MSG_BLOCK

4バイトの型タグが、複数あるブロック形式のうちどれが届くかを決めます。型2は元の形式を意味します。80バイトのヘッダーの後にすべてのトランザクションを完全な形で続け、ウィットネスデータを取り除いたもので、ブロックが保持できる400万ウェイトユニットまでです。チェーンへの追いつき中のノードは、こうした要求を数千件送り、それ以外はほとんど送りません。

仕組み

MSG_BLOCKはメッセージではなく数値であり、invメッセージとgetdataメッセージが組み立てられる36バイトのエントリーの中でのみ意味を持ちます。

エントリーは4バイトの型の後に32バイトのハッシュが続くもので、型はそのハッシュが何を指すかを受信者に伝えます。型2のエントリーを入れたgetdataを送ることは、このブロックのハッシュを持っているため、そのブロックを送ってくださいという意味です。ピアはblockメッセージ1件で応答するか、提供できない場合はnotfoundで応答します。プルーニング済みのノードは、すでに削除したものにはすべてnotfoundを返します。そのため、プルーニング済みのピアは、ゼロから同期する相手には役に立ちません。

型2単体は、かつてよりも狭い意味を持つようになりました。2017年にSegWitが有効になって以降、この方法で要求されたブロックは、ウィットネスデータを取り除いた旧形式のシリアライズで返ります。古いソフトウェアにも応答できるようにするために必要だったことです。ブロックを検証しようとするノードはそのウィットネスを必要とするため、0x40000000ビットを立てて、代わりにウィットネス付きの形式を要求します。現代のピア同士では、この単純なコードは主に、誰も更新していないソフトウェアからの要求に現れます。

告知の方法も進みました。BIP130はヘッダーの直接告知を導入し、Bitcoin Core0.12.0以降、新しいブロックは通常invではなくheadersメッセージで告知されるため、この型コードは今では主に会話の要求側に存在します。

Bitcoin Coreはダウンロード中に無制限に先へ進むことはありません。検証済みの最後のブロックから1,024ブロック分のウィンドウを保つため、1つのピアが停止しても、ノードが接続できないブロックの無限のキューを抱え込むことはありません。

どこで見かけるか

ブロック要求がノードの通信量を占めるのは、最初の同期のときの一度だけで、その後はほとんど二度とありません。

チェーンは2024年4月20日の半減期で840,000ブロックを超え、1日に約144ブロックずつ伸びるため、新規に起動したマシンは最新になるまでに100万個近くを取得します。これはgetpeerinfoで確認できます。ピアごとにメッセージ種別あたりのバイト数を数えており、ログでは-debug=netで確認できます。ノードがチェーンの先端に達すると、これらのカウンターは静まり、コンパクトブロックの通信が取って代わります。

MSG_BLOCK vs MSG_CMPCT_BLOCK

MSG_BLOCKとMSG_CMPCT_BLOCKは、取得する内容だけでなく、どこで認められるかも異なります。型2はinvでもgetdataでも有効で、事前の取り決めなしにどのピアにも送ることができ、ブロックの古さに関係なく使えます。型4はgetdataでのみ有効で、sendcmpctメッセージでコンパクトブロックをすでに提供したピアにしか送ることができず、Bitcoin Coreでは直近5ブロックにのみ応答されます。型4でそれより深いものを要求しても、完全なblockメッセージが返ってきます。