Reorg

Anna recebe 20.000 satoshis, as pequenas unidades do bitcoin. A carteira mostra uma confirmação: o pagamento está num bloco aceite pelo seu nó. Então o nó descobre um ramo concorrente válido que ainda não contém esse pagamento. Quando esse ramo demonstra mais trabalho de mineração acumulado, o nó passa a segui-lo. Essa substituição de parte do histórico chama-se Reorg. O pagamento de Anna pode voltar a esperar confirmação sem que alguém tenha roubado as suas chaves ou alterado a assinatura. O que decide não é uma votação nem apenas a quantidade de blocos, mas o chainwork: a soma do trabalho que cada bloco demonstra conforme a sua dificuldade. O nó rejeita um ramo inválido mesmo que tenha mais trabalho. [1] [4]

O que Anna verá depois depende do novo ramo. Se também contiver o seu pagamento, este continua confirmado, embora o número de confirmações possa mudar. Caso contrário, o Bitcoin Core pode tentar devolvê-lo ao Mempool, a sua lista temporária de transações não confirmadas que esperam um bloco. O regresso não é garantido. Uma saída de uma transação anterior regista um montante e as condições para o gastar. O novo ramo pode já ter gasto os mesmos fundos noutra transação; também pode faltar uma saída anterior que se pretende gastar, ou condições de tempo e outros critérios de admissão podem não estar satisfeitos. Um pagamento novamente à espera é, portanto, diferente de um pagamento que o novo histórico já não permite. [1]

Uma confirmação corresponde ao bloco que contém o pagamento. Cada bloco seguinte acrescenta uma confirmação e mais trabalho que um ramo concorrente precisaria superar. Um pagamento no último bloco tem, assim, uma confirmação; quanto mais fundo estiver no histórico aceite, mais difícil costuma ser substituir essa parte. Mas nenhum número finito de confirmações garante matematicamente que a substituição seja impossível. Comerciantes e plataformas de negociação ajustam a espera ao valor do pagamento e ao risco que aceitam. [3] [5]

Um Reorg, por si só, não prova um ataque. Dois mineradores podem encontrar quase ao mesmo tempo blocos com o mesmo antecessor. A informação sobre os blocos não atravessa a rede instantaneamente, e os nós podem acompanhar por um momento finais diferentes da cadeia. Quando um ramo válido acumula mais trabalho, passam a segui-lo; o bloco abandonado é um Stale Block. O mesmo mecanismo pode, porém, ser explorado num ataque Double Spend: o atacante tenta impor um histórico em que os mesmos fundos foram pagos a outro destino. Por isso importa descobrir a causa da mudança e quais pagamentos ela alterou. [4] [5]

Durante um Reorg, o nó mantém as mesmas regras e escolhe entre históricos que as cumprem. Um Hard Fork altera as regras de validade, de modo que o software antigo e o novo podem avaliar o mesmo bloco de formas diferentes. Uma reorganização não cria, por si só, outra moeda nem reescreve as regras do Bitcoin. Os capítulos seguintes explicam como o nó executa essa mudança de histórico. [4]

Tip é o último bloco do ramo aceite no momento. O ponto de bifurcação é o último bloco comum à cadeia atualmente ativa e ao ramo alternativo. A profundidade da reorganização é normalmente descrita pelo número de blocos da extremidade ativa que é necessário desligar para regressar a esse antepassado comum. Uma reorganização de um bloco substitui a ponta; uma reorganização mais profunda reverte vários blocos confirmados. A profundidade depende da perspetiva de cada nó. [1]

Um Full Node verifica as regras por conta própria. Os nomes de funções abaixo descrevem a implementação no Bitcoin Core. O Bitcoin Core não escolhe simplesmente o ramo mais alto ou mais popular. Durante a ativação, a cadeia candidata tem de cumprir as regras de consenso do nó; mais chainwork não torna válido um bloco inválido. FindMostWorkChain seleciona o candidato com mais trabalho que não se sabe ser inválido. Isto ainda não significa validação completa: são efetuadas verificações adicionais ao ligar os blocos em ActivateBestChain. Os ramos cuja invalidade é conhecida são excluídos. [1]

Um UTXO é uma saída de transação ainda não gasta; o conjunto UTXO reúne essas saídas disponíveis. Os dados undo guardam o necessário para desfazer os efeitos de um bloco. DisconnectTip e a lógica de validação subsequente desfazem os efeitos dos blocos desligados pela ordem inversa. Os UTXO gastos são restaurados e as saídas criadas pelo bloco removido deixam de estar confirmadas. É por isso que o Bitcoin Core guarda dados de reversão: tem de conseguir reconstruir o conjunto UTXO exatamente no ponto de bifurcação. [1]

Rollback significa aqui voltar ao estado anterior aos blocos desconectados; chainstate é o estado de trabalho do nó correspondente ao histórico aceite. Após a reversão, ConnectTip liga os blocos do ramo com maior chainwork pela ordem de avanço da cadeia. Cada transação é novamente validada face ao conjunto UTXO reconstruído e às regras em vigor na altura de bloco correspondente. O resultado é um chainstate correspondente a uma única história concreta, e não uma mistura de transações dos dois ramos. [1]

A Coinbase Transaction é a primeira transação do bloco e atribui a recompensa ao minerador. A altura h indica a posição do bloco na cadeia. A transação coinbase é uma exceção: não regressa ao mempool depois de o bloco ser desligado. Segundo as regras de consenso, uma saída coinbase criada à altura h só pode ser gasta a partir do bloco h + 100. Quando a ponta está à altura h + 99, o bloco de origem tem 100 confirmações e a condição de maturidade permite incluir o gasto no bloco seguinte. Quando uma reorganização remove o bloco que contém a coinbase, a recompensa desse bloco desaparece do chainstate ativo. As transações subsequentes que dependiam da história removida também podem ser inválidas. [1] [2] [3]

Estes são nomes de funções de uma versão específica do programa, não etapas adicionais para quem usa uma carteira. No Bitcoin Core v29.0, os passos são explícitos: FindMostWorkChain encontra o candidato com maior chainwork cuja invalidade não é conhecida; ActivateBestChainStep pode desligar a ponta atual; ConnectTip verifica e liga os blocos alternativos; e MaybeUpdateMempoolForReorg volta a verificar as transações dos blocos desligados. A ativação pode revelar que o candidato é inválido e prosseguir com a procura de outro ramo. Uma reorganização extensa exige o processamento de mais blocos desligados e ligados, pelo que pode prolongar o processamento de ActivateBestChain. [1]