Retransmissão padrão de blocos

Duas idas e voltas e um megabyte ou mais, a cada salto, por dados que o receptor em grande parte já tinha. Um estudo de medição de 2013 cronometrou a mediana do tempo que um nó levava para saber de um bloco novo em 6,5 segundos depois de ele ser encontrado, com média de 12,6 segundos. O Bitcoin Core passou a oferecer a retransmissão de blocos compactos na versão 0.13.0, em 23 de agosto de 2016, e a retransmissão padrão se tornou a alternativa.

Como funciona

A retransmissão padrão de blocos usa três mensagens e não presume nada sobre o que o nó receptor já tem.

Quem encontra o bloco envia um inv com o hash do bloco novo ou, desde que o BIP130 chegou ao Bitcoin Core 0.12.0, uma mensagem headers que carrega diretamente o cabeçalho de 80 bytes, o que poupa ao par uma ida e volta separada de getheaders. O receptor verifica se tem esse bloco. Se não tiver, responde com getdata. O remetente então transmite a mensagem block: o cabeçalho seguido de cada transação em serialização completa, até o limite de quatro milhões de unidades de peso que restringe um bloco.

O desperdício é óbvio assim que se enuncia. Um nó que está em execução há horas já tem na sua mempool quase todas as transações desse bloco, pois recebeu cada uma individualmente quando foi difundida. A retransmissão padrão envia todas elas uma segunda vez. Em um bloco cheio de pagamentos comuns, isso é bem mais de um megabyte de transferência redundante, por par, por bloco.

As consequências não eram apenas estéticas. A propagação lenta aumenta a taxa de blocos obsoletos, porque um minerador que ainda não soube de um bloco novo continua trabalhando sobre a ponta antiga. Blocos obsoletos custam mais aos mineradores pequenos do que aos grandes, já que um pool grande fica sabendo dos próprios blocos na hora. Uma retransmissão mais rápida era, portanto, um argumento de descentralização tanto quanto de eficiência, e impulsionou tanto o BIP152 quanto as redes de retransmissão dedicadas que os grandes pools operam entre si.

A retransmissão padrão não desapareceu. É o que acontece quando um par nunca negociou blocos compactos, quando a reconstrução compacta falha e as transações que faltam não podem ser completadas, e ao longo do download inicial de blocos, em que um nó em sincronização solicita blocos completos por getdata a vários pares ao mesmo tempo, com até dezesseis em trânsito por par no Bitcoin Core.

Onde você a vê

A retransmissão padrão de blocos é mais visível enquanto um nó está se atualizando do que quando já está atualizado.

Durante uma sincronização inicial, o getdata para blocos domina o tráfego, e os contadores por mensagem do getpeerinfo mostram isso claramente. Quando o nó chega à ponta, esses contadores silenciam e os contadores de blocos compactos assumem. Uma máquina em um link lento ou com poucos pares recorre à retransmissão padrão com mais frequência, e o sintoma é uma ponta que fica um ou dois minutos atrás do que um explorador de blocos público mostra.

Retransmissão padrão de blocos vs retransmissão de blocos compactos

A retransmissão padrão envia o bloco; a compacta envia uma descrição dele e deixa o receptor reconstruir o resto. Um cmpctblock carrega o cabeçalho, um nonce e um identificador curto de seis bytes para cada transação, de modo que um bloco com alguns milhares de pagamentos pode ser descrito em menos de vinte kilobytes em vez de bem mais de um megabyte. O receptor compara esses identificadores com a própria mempool, solicita o que estiver faltando com getblocktxn e monta o bloco localmente. A validação posterior é idêntica: a retransmissão compacta muda como os bytes chegam, nunca o que conta como um bloco válido.