Glossário / Referência do desenvolvedor
MSG_CMPCT_BLOCK
- O que é MSG_CMPCT_BLOCK?
- MSG_CMPCT_BLOCK, tipo de inventário 4, é um código exclusivo de solicitações: nunca aparece em um anúncio e só é válido dentro de uma mensagem getdata enviada a um par que o aceitou antes.
Especificação no BIP-152.
Os blocos compactos são negociados, não anunciados. Um par envia sendcmpct uma vez para dizer que vai aceitá-los, e só então o outro lado pode responder a um bloco novo com o tipo 4 em vez do tipo 2. O BIP152 chegou com o Bitcoin Core 0.13.0 em agosto de 2016, e a economia é justamente o ponto: seis bytes para nomear uma transação que o receptor já tem, em vez dos duzentos ou mais que custa enviá-la duas vezes.
Como funciona
O MSG_CMPCT_BLOCK pede uma descrição de um bloco em vez do bloco, e essa descrição só vale a pena quando os dois nós têm mempools semelhantes.
A negociação vem primeiro. A mensagem sendcmpct carrega um indicador e um número de versão: a versão 1 identifica as transações pelo txid, a versão 2 pelo txid de testemunha e é a única em uso desde a segregated witness. Um nó nunca deve colocar o tipo 4 em um getdata para um par que não tenha enviado sendcmpct, porque esse par não tem nenhuma obrigação de entendê-lo.
A resposta é uma mensagem cmpctblock que contém o cabeçalho de 80 bytes, um nonce de oito bytes, um identificador curto de seis bytes por transação e algumas transações fornecidas por completo, entre elas sempre a coinbase, que o receptor não teria como já ter visto. Os identificadores curtos são gerados com SipHash, com uma chave derivada do cabeçalho e desse nonce, então eles mudam a cada bloco e a cada solicitação. A aleatorização é uma defesa: um esquema fixo permitiria a um atacante pré-calcular duas transações que colidem e travar a reconstrução em toda a rede de uma só vez.
O receptor compara os identificadores com sua mempool, pede o que estiver faltando com getblocktxn e reconstrói o bloco localmente. A validação depois disso é a habitual, e nenhuma regra de consenso é tocada.
A profundidade é limitada. O Bitcoin Core serve um bloco compacto apenas para os cinco blocos mais recentes e responde a um pedido de qualquer bloco mais antigo com um bloco completo, porque um receptor tão atrasado não tem uma mempool útil e acabaria pedindo todas as transações dela.
Onde isso aparece
A visão mais clara do MSG_CMPCT_BLOCK está no próprio registro do Bitcoin Core, que informa quão bem saiu cada reconstrução.
Inicie o nó com -debug=cmpctblock e cada bloco novo gera uma linha informando quantas transações vieram pré-carregadas, quantas foram encontradas na mempool e quantas tiveram de ser buscadas. Em uma máquina que está rodando há horas, a contagem de transações buscadas costuma ser zero, e o bloco chega com dezenas de kilobytes em vez de um megabyte e meio. Um bloco com 3.000 transações precisa de 18.000 bytes de identificadores curtos, além do cabeçalho e da coinbase.
Essa aritmética desmorona em um nó recém-iniciado. Uma mempool vazia significa que nenhum identificador encontra correspondência, a solicitação seguinte pede o bloco inteiro, e a ida e volta adicional torna o caminho compacto mais lento do que simplesmente pedir o bloco diretamente. É por isso que o código pertence aos nós que estão na ponta da cadeia e nunca aparece durante uma sincronização inicial.
Para quem executa um nó em casa, este é o recurso que decide se uma conexão comum acompanha o ritmo da rede ou fica para trás cada vez que um bloco é encontrado.