Glossário / Referência do desenvolvedor
MSG_BLOCK
- O que é MSG_BLOCK?
- MSG_BLOCK é o tipo de inventário 2, o código que um nó coloca em uma mensagem getdata para pedir a um par um bloco completo pelo seu hash.
Quatro bytes de código de tipo decidem qual de vários formatos de bloco chega. O tipo 2 designa o original: um cabeçalho de 80 bytes seguido de todas as transações na íntegra, com os dados de testemunha removidos, até quatro milhões de unidades de peso que um bloco pode conter. Um nó se atualizando com a cadeia envia milhares dessas solicitações e muito pouco mais.
Como funciona
MSG_BLOCK é um número, não uma mensagem, e só tem significado dentro dos elementos de 36 bytes com os quais as mensagens inv e getdata são construídas.
Um elemento é um tipo de quatro bytes seguido de um hash de 32 bytes, e o tipo informa ao destinatário o que o hash designa. Enviar getdata com um elemento de tipo 2 equivale a dizer: tenho o hash deste bloco, envie-me o bloco. O par responde com uma mensagem block, ou com notfound se não puder fornecê-lo. Um nó podado retorna notfound para tudo o que já excluiu, e por isso um par podado não serve para quem sincroniza do zero.
O tipo 2 sozinho agora significa algo mais restrito do que antes. Desde que a segregated witness foi ativada em 2017, um bloco solicitado desse modo chega na serialização antiga com os dados de testemunha removidos, o que era necessário para continuar atendendo ao software mais antigo. Todo nó que pretende validar o bloco precisa dessas testemunhas, então define o bit 0x40000000 e solicita a variante com testemunha. Entre dois pares modernos, o código simples aparece principalmente em solicitações de software que ninguém atualizou.
O anúncio também evoluiu. O BIP130 introduziu o anúncio direto de cabeçalhos, e desde Bitcoin Core 0.12.0 um novo bloco é normalmente anunciado com uma mensagem headers em vez de um inv, então esse código de tipo hoje vive sobretudo no lado de quem solicita.
Bitcoin Core não se adianta sem limite enquanto baixa. Mantém uma janela de 1.024 blocos além do último que validou, de modo que um único par travado não pode deixar o nó com uma fila ilimitada de blocos que não tem como conectar.
Onde isso aparece
As solicitações de blocos dominam o tráfego de um nó exatamente uma vez, durante a primeira sincronização, e depois quase nunca mais.
A cadeia passou de 840.000 blocos no halving de 20 de abril de 2024 e cresce cerca de 144 blocos por dia, então uma máquina que começa do zero baixa perto de um milhão deles antes de estar em dia. Você pode acompanhar isso com getpeerinfo, que conta bytes por tipo de mensagem para cada par, ou no registro com -debug=net. Quando o nó chega à ponta da cadeia, esses contadores silenciam e o tráfego de blocos compactos assume.
MSG_BLOCK vs MSG_CMPCT_BLOCK
MSG_BLOCK e MSG_CMPCT_BLOCK diferem tanto em onde são permitidos quanto no que buscam. O tipo 2 é válido em um inv e em um getdata, pode ser enviado a qualquer par sem acordo prévio e serve para um bloco de qualquer idade. O tipo 4 é válido apenas em um getdata, só pode ser enviado a um par que já tenha oferecido blocos compactos com uma mensagem sendcmpct e, no Bitcoin Core, é servido apenas para os cinco blocos mais recentes. Solicite algo mais antigo com o tipo 4 e uma mensagem block completa chega de todo modo.