Quando um minerador encontra um bloco, a velocidade importa. Quanto mais um bloco demora a chegar a outros mineradores, mais provável que dois blocos concorram, e propagação lenta favorece mineradores grandes e bem conectados. Ainda assim, a maioria das transações num bloco novo já está no mempool de cada nó. BIP152, de Matt Corallo, evita enviá-las duas vezes. O Bitcoin Core o apoia desde a versão 0.13.0 em 2016.
O que é enviado
Um bloco compacto contém o cabeçalho de 80 bytes, um nonce aleatório, uma lista de IDs curtos de transação de 6 bytes e algumas transações completas «pré-preenchidas», pelo menos a transação coinbase. IDs curtos vêm de SipHash-2-4, com chave a partir de um hash do cabeçalho e do nonce, para que um atacante não possa prevê-los de antemão para criar colisões.
Reconstruir o bloco
O receptor calcula IDs curtos das próprias transações do mempool e as combina. Se algo falta, pede com getblocktxn e recebe um blocktxn. Uma colisão de ID curto é possível, mas rara. Quando acontece, o nó cai para baixar o bloco completo.
Dois modos
- Baixa largura de banda: o peer anuncia o bloco como de costume, após validá-lo, e o receptor pede a versão compacta. Isso leva 1,5 ida e volta, ou 2,5 se faltarem transações, mas usa bem menos largura de banda do que antes.
- Alta largura de banda: o peer empurra o bloco compacto de imediato, mesmo antes de validá-lo por completo. Se nada falta, nenhuma ida e volta extra é necessária. O Bitcoin Core escolhe até 3 peers para este modo.
Versões
A versão 1 usa txids. A versão 2 usa wtxids, então os IDs curtos também cobrem dados de witness. Nós modernos usam a versão 2.
Por que importa
Retransmissão de blocos mais rápida e leve reduz a parcela de blocos obsoletos e torna mais barato rodar um nó completo. Também reduz a vantagem que grandes mineradores obtêm de redes de relay rápidas.