Retransmisión estándar de bloques

Dos viajes de ida y vuelta y un megabyte o más, en cada salto, por datos que el destinatario ya tenía en su mayoría. Un estudio de medición de 2013 cifró en 6,5 segundos la mediana del tiempo que tardaba un nodo en enterarse de un bloque nuevo desde que se encontraba, con una media de 12,6 segundos. Bitcoin Core incorporó la retransmisión de bloques compactos en la versión 0.13.0, el 23 de agosto de 2016, y la retransmisión estándar pasó a ser la alternativa.

Cómo funciona

La retransmisión estándar de bloques usa tres mensajes y no presupone nada sobre lo que ya tiene el nodo que recibe el bloque.

Quien encuentra el bloque envía un mensaje inv que nombra el hash del bloque nuevo o, desde que BIP130 llegó a Bitcoin Core 0.12.0, un mensaje headers que lleva directamente el encabezado de 80 bytes, lo que ahorra al par un viaje de ida y vuelta aparte con el mensaje getheaders. El destinatario comprueba si tiene ese bloque. Si no, responde con un mensaje getdata. Entonces el remitente envía el mensaje block: el encabezado seguido de cada transacción serializada por completo, hasta el presupuesto de cuatro millones de unidades de peso que limita un bloque.

El desperdicio salta a la vista en cuanto se enuncia. Un nodo que lleva horas en funcionamiento ya tiene en su mempool casi todas las transacciones de ese bloque, porque recibió cada una por separado cuando se difundió. La retransmisión estándar las envía todas por segunda vez. En un bloque lleno de pagos corrientes, eso supone bastante más de un megabyte de transferencia redundante, por par y por bloque.

Las consecuencias no eran meramente estéticas. Una propagación lenta eleva la proporción de bloques obsoletos, porque un minero que todavía no se ha enterado de un bloque nuevo sigue minando sobre la antigua punta de la cadena. Los bloques obsoletos les cuestan más a los mineros pequeños que a los grandes, ya que un pool de minería grande se entera de sus propios bloques al instante. Por tanto, una retransmisión más rápida era un argumento de descentralización en la misma medida que de eficiencia, e impulsó tanto BIP152 como las redes de retransmisión dedicadas que los grandes pools operan entre sí.

La retransmisión estándar no ha desaparecido. Es lo que ocurre cuando un par nunca negoció los bloques compactos, cuando falla la reconstrucción del bloque compacto y no se pueden completar las transacciones que faltan, y durante toda la descarga inicial de bloques, en la que un nodo que se sincroniza solicita bloques completos a varios pares a la vez mediante mensajes getdata, con hasta dieciséis en tránsito por par en Bitcoin Core.

Dónde aparece

La retransmisión estándar de bloques se ve sobre todo mientras un nodo se está poniendo al día, no cuando ya está al día.

Durante una sincronización inicial, el mensaje getdata para bloques domina el tráfico, y los contadores por mensaje de la llamada RPC getpeerinfo lo muestran con claridad. Cuando el nodo llega a la punta de la cadena, esos contadores se quedan quietos y toman el relevo los contadores de bloques compactos. Una máquina con un enlace lento o con pocos pares recurre a la retransmisión estándar más a menudo, y el síntoma es una punta que va un minuto o dos por detrás de lo que muestra un explorador de bloques público.

Retransmisión estándar de bloques frente a retransmisión de bloques compactos

La retransmisión estándar envía el bloque; la retransmisión compacta envía una descripción de él y deja que el destinatario reconstruya el resto. Un mensaje cmpctblock lleva el encabezado, un nonce y un identificador corto de seis bytes por cada transacción, de modo que un bloque con unos pocos miles de pagos puede describirse en menos de veinte kilobytes en lugar de en bastante más de un megabyte. El destinatario compara esos identificadores con su propia mempool, solicita lo que falte con el mensaje getblocktxn y ensambla el bloque localmente. La validación posterior es idéntica: la retransmisión compacta cambia cómo llegan los bytes, nunca lo que cuenta como un bloque válido.