Block Propagation

Imagine que Ana trabalha com mineração e acaba de encontrar um bloco com transações. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. Bitcoin não tem uma central que o envie para todos ao mesmo tempo. O nó de Ana avisa os vizinhos, os computadores aos quais está conectado. A notícia segue adiante e chega a cada pessoa em momentos diferentes. Esse percurso é Block Propagation. Sua velocidade influencia por quanto tempo os demais continuam trabalhando sobre a versão anterior do histórico. [1] [6]

Pedro mantém em casa um Full Node: um programa que verifica blocos e transações de Bitcoin de acordo com as regras. O aviso de um novo bloco não basta; ele precisa do conteúdo completo. Pode baixá-lo inteiro ou reconstruí-lo com a mensagem recebida e as transações que já possui. É como receber uma lista de páginas e encontrá-las na própria biblioteca: menos dados viajam, mas o livro pronto precisa ser o mesmo. [1] [7]

Um bloco tem um cabeçalho curto, o Block Header. Ele aponta, entre outras coisas, para o bloco anterior e permite verificar Proof of Work, a prova do trabalho computacional exigido pela mineração. Os mineradores procuram essa prova repetindo cálculos; os demais podem verificar rapidamente o resultado. É uma primeira conferência útil, não uma garantia para cada pagamento. Só pelo cabeçalho Pedro não sabe se as assinaturas são válidas nem se as transações gastam fundos disponíveis que ainda não foram usados. Uma assinatura digital comprova a autorização de um pagamento por meio de uma chave privada, um valor numérico secreto, sem revelar essa chave. Um UTXO é uma saída de transação ainda não gasta: um registro de um valor e das condições para gastá-lo. [6] [8]

Pedro recebeu muitas transações antes da mineração do bloco. Elas ficam em seu Mempool, o conjunto local de transações ainda não confirmadas. O mecanismo Compact Blocks, definido em BIP 152, aproveita isso: a mensagem leva principalmente identificadores curtos e algumas transações completas, em vez de repetir todas. Pedro organiza as peças conhecidas na ordem certa. A mensagem de rede fica menor, não o bloco verificado; suas regras de validade permanecem iguais. [2] [7]

Não existe um Mempool único para o mundo inteiro. Cada nó pode conhecer transações um pouco diferentes. Se faltarem algumas a Pedro, ele pede os dados necessários ou recorre ao bloco completo. Esse pedido e a resposta exigem mais tempo de comunicação. Isso não permite adivinhar o conteúdo nem pular verificações. A economia real depende também de quantas transações o destinatário já conhece. [2] [7]

O modo mais rápido de BIP 152 permite repassar antes de terminar todas as verificações das transações. Não é enviar às cegas: o remetente precisa conferir, entre outros requisitos, a ligação com a cadeia validada, Proof of Work e a correspondência criptográfica do cabeçalho com as transações transmitidas. O envio e as verificações restantes podem ocorrer em paralelo. Ainda assim, um Full Node só incorpora o bloco ao histórico ativo depois de verificá-lo por completo. [2] [4] [7]

Antes de o bloco de Ana chegar a todos, outro minerador pode encontrar um bloco com o mesmo predecessor. Por um breve período, parte da rede vê uma ramificação válida e parte vê outra. O trabalho acumulado posteriormente decide entre as ramificações válidas; não há votação de computadores. Um bloco válido deixado de lado é chamado Stale Block. Uma propagação mais rápida reduz essa janela de disputa, mas não a elimina. [6] [8]

Se o bloco de Ana se espalhar devagar, aumenta a chance de outros continuarem a partir de um concorrente e deixarem o dela fora da cadeia aceita. Ela não recebe a recompensa desse bloco naquele histórico. Uma boa conexão é, portanto, mais do que conveniência. Sua vantagem pode favorecer a concentração da mineração em operadores mais bem conectados. Uma conexão lenta, sozinha, porém, não mede centralização nem comprova um ataque. [7] [8]

FIBRE é um exemplo de sistema especializado na transmissão rápida de blocos. Ele procura reduzir atrasos, inclusive os causados pela perda de pacotes: pequenas partes da mensagem enviada. Esse caminho pode entregar um bloco antes, mas seu operador não passa a decidir por Pedro se ele é válido. O Full Node de Pedro precisa verificar as mesmas regras, independentemente do trajeto dos dados. [3] [9]

A rede também precisa considerar volume de dados, privacidade e resistência das conexões a falhas. Depender de um único caminho continua sendo uma fragilidade, mesmo que ele seja rápido. As melhorias também têm funções diferentes: BIP 330, um componente de Erlay, ajuda nós vizinhos a identificar diferenças entre conjuntos de anúncios de transações. Ele não substitui a transmissão de blocos de BIP 152. O objetivo comum é comunicar melhor sem abrir mão da verificação independente de cada nó. [1] [5]