Glosario / Referencia para desarrolladores
MSG_BLOCK
- ¿Qué es MSG_BLOCK?
- MSG_BLOCK es el tipo de inventario 2, el código que un nodo pone en un mensaje getdata para solicitar a un par un bloque completo por su hash.
Cuatro bytes de código de tipo deciden cuál de varios formatos de bloque llega. El tipo 2 designa el original: un encabezado de bloque de 80 bytes seguido de todas las transacciones completas, sin los datos de testigo, hasta los cuatro millones de unidades de peso que puede contener un bloque. Un nodo que se está poniendo al día con la cadena envía miles de estas solicitudes y muy poco más.
Cómo funciona
MSG_BLOCK es un número y no un mensaje, y solo tiene significado dentro de los elementos de 36 bytes con los que se construyen los mensajes inv y getdata.
Un elemento es un tipo de cuatro bytes seguido de un hash de 32 bytes, y el tipo le indica al destinatario qué designa el hash. Enviar un mensaje getdata con un elemento de tipo 2 equivale a decir: tengo el hash de este bloque, envíeme el bloque. El par responde con un mensaje block, o con un mensaje notfound si no puede proporcionarlo. Un nodo podado devuelve notfound para todo lo que ya ha borrado, y por eso un par podado no le sirve a quien sincroniza desde cero.
El tipo 2 por sí solo significa ahora algo más limitado que antes. Desde que SegWit se activó en 2017, un bloque solicitado de este modo llega en la serialización antigua sin los datos de testigo, lo que era necesario para seguir sirviendo al software más antiguo. Todo nodo que quiera validar el bloque necesita esos testigos, así que activa el bit 0x40000000 y solicita en su lugar la variante con testigo. Entre dos pares modernos, el código simple aparece sobre todo en solicitudes de software que nadie ha actualizado.
El anuncio también evolucionó. BIP130 introdujo el anuncio directo de encabezados, y desde Bitcoin Core 0.12.0 un bloque nuevo se anuncia normalmente con un mensaje headers en lugar de con un mensaje inv, así que este código de tipo vive ahora sobre todo en el lado de la conversación que solicita.
Bitcoin Core no se adelanta sin límite mientras descarga. Mantiene una ventana de 1.024 bloques más allá del último que ha validado, de modo que un solo par estancado no puede dejar al nodo con una cola ilimitada de bloques que no tiene forma de conectar.
Dónde aparece
Las solicitudes de bloques dominan el tráfico de un nodo exactamente una vez, durante su primera sincronización, y después casi nunca más.
La cadena superó los 840.000 bloques en el halving del 20 de abril de 2024 y crece aproximadamente 144 bloques al día, así que una máquina que empieza de cero descarga cerca de un millón de ellos antes de estar al día. Puede verlo con la llamada RPC getpeerinfo, que cuenta los bytes por tipo de mensaje de cada par, o en el registro con -debug=net. Cuando el nodo llega a la punta de la cadena, esos contadores se callan y el tráfico de bloques compactos toma el relevo.
MSG_BLOCK frente a MSG_CMPCT_BLOCK
MSG_BLOCK y MSG_CMPCT_BLOCK se diferencian tanto en dónde están permitidos como en lo que obtienen. El tipo 2 es válido en un mensaje inv y en un getdata, puede enviarse a cualquier par sin acuerdo previo y sirve para un bloque de cualquier antigüedad. El tipo 4 solo es válido en un getdata, solo puede enviarse a un par que ya haya ofrecido bloques compactos con un mensaje sendcmpct y, en Bitcoin Core, solo se sirve para los cinco bloques más recientes. Solicite algo más profundo con el tipo 4 y le llegará de todos modos un mensaje block completo.