Envio de bloco não solicitado

Enviar sem convite é falta de educação na maioria dos protocolos e correto neste. Cada ida e volta que um bloco passa em trânsito é tempo que algum minerador passa trabalhando em uma ponta da cadeia que não existe mais, então o BIP152 formalizou o atalho: até três pares escolhidos podem disparar um bloco contra você no momento em que o tiverem. Seu nó o valida do zero de qualquer forma e não deve nada ao remetente.

Como funciona

Duas coisas diferentes circulam sob o nome de envio de bloco não solicitado, uma antiga e informal, outra especificada.

A forma antiga é simplesmente uma mensagem block que chega sem um getdata correspondente. O protocolo nunca a proibiu e os receptores sempre processaram esses blocos, ainda que com condições. O Bitcoin Core verifica a prova de trabalho no cabeçalho antes de fazer qualquer coisa cara, não repassa o bloco adiante até que ele esteja totalmente validado e se conecte à melhor cadeia, e trata um bloco que não se conecta a nada que conheça como algo a descartar, e não como um quebra-cabeça a resolver. Essas regras existem porque dados não solicitados são gratuitos para o remetente e custosos para o receptor, que é a forma de todo ataque de negação de serviço no protocolo.

A forma especificada é o modo de alta largura de banda do BIP152. Um nó envia ao seu par uma mensagem sendcmpct cujo primeiro byte é 1, ou seja: não anuncie, apenas envie. Esse par pode então transmitir uma cmpctblock no instante em que ouve falar de um bloco novo, possivelmente antes de ter terminado de validá-lo. O BIP152 estabelece um teto rígido de três desses pares e o Bitcoin Core aplica exatamente isso, mantendo uma lista de no máximo três nós escolhidos por terem entregado os blocos recentes primeiro. Três é um meio-termo: redundância suficiente para que um par lento não possa atrasar você, e poucos o bastante para que você não receba o mesmo bloco por todas as conexões que tem.

Como um anúncio de alta largura de banda pode preceder a validação, o nó receptor o trata como uma afirmação e não como um fato. A prova de trabalho é verificada primeiro, por ser a única parte de um bloco que não pode ser falsificada a baixo custo, e todo o resto segue o caminho normal. A versão de protocolo 70015 existe justamente para que um nó sinalize que não penalizará um par por anunciar um bloco que depois se revele não ter sido totalmente verificado.

Onde você o vê

Os envios não solicitados se concentram onde os segundos valem dinheiro.

Os pools de mineração mantêm conexões diretas entre si e com redes de retransmissão como a FIBRE, construídas para mover blocos entre continentes com tão pouco anúncio e pedido quanto a física permite. Em uma máquina comum, a chamada getpeerinfo informa dois sinalizadores por par, bip152_hb_to e bip152_hb_from, mostrando de quais pares você pediu que enviassem blocos a você e quais pediram o mesmo a você. Ver três do primeiro é normal, e três é o limite.

Envio de bloco não solicitado vs retransmissão padrão de blocos

A retransmissão padrão de blocos e um envio não solicitado diferem quanto a quem decide que os bytes vão se mover. Na retransmissão padrão o receptor pede, então ele governa sua própria largura de banda e pode recusar qualquer coisa que já tenha. Em um envio o remetente decide, economizando uma ida e volta, mas entregando a um estranho uma alavanca sobre seus recursos. A resposta do Bitcoin não é escolher um dos dois: permitir o envio, limitá-lo a três pares que você mesmo selecionou, verificar a prova de trabalho antes de gastar qualquer coisa e validar o bloco por completo, não importa com quanta cortesia ele tenha chegado.