Sincronização headers-first

Dividir o download em duas etapas é o que torna prática uma primeira sincronização. O Bitcoin Core funciona assim desde a versão 0.10.0, lançada em fevereiro de 2015, que transformou a busca de blocos de uma única fila ordenada em uma tarefa distribuída entre todos os pares conectados. Se você executa seu próprio nó para verificar seu próprio saldo, é por isso que a sincronização inicial termina em horas, e não em dias.

Como funciona

A sincronização headers-first começa pedindo cabeçalhos aos pares, não blocos.

O nó envia uma mensagem getheaders que carrega um localizador de blocos, uma lista compacta de hashes que descreve onde ele acredita estar no momento. Um par responde com uma mensagem headers contendo até 2.000 cabeçalhos de 80 bytes cada um, de modo que uma única resposta cobre cerca de duas semanas de cadeia. Para cada cabeçalho, o nó verifica que ele aponta para um pai que já possui e que seu hash atende à dificuldade declarada em seu campo nBits, e então pergunta de novo a partir da nova ponta até que nenhum par tenha algo mais recente a oferecer.

Só depois que esse esqueleto está no lugar é que o download dos corpos começa. Como o nó já conhece o hash de cada bloco que deseja, ele pode solicitar trechos diferentes a vários pares ao mesmo tempo em vez de ficar na fila atrás de uma única conexão. O Bitcoin Core limita quantas solicitações de blocos ele deixa pendentes com um mesmo par, dezesseis no código atual, e desconecta um par que trava a janela. Blocos que chegam antes de seus pais são simplesmente retidos, o que acabou com o antigo hábito de guardar dados não verificados no disco.

Duas salvaguardas acompanham os cabeçalhos. O software não adota uma cadeia até que os cabeçalhos que possui somem mais prova de trabalho acumulada do que um valor mínimo compilado na versão, de modo que um par não pode atrair um nó recém-instalado para uma cadeia lateral barata feita de blocos fáceis. Separadamente, a configuração assumevalid indica um hash de bloco recente que acompanha cada versão: as assinaturas dentro de blocos enterrados abaixo dele não são verificadas de novo, o que elimina horas de cálculos de curva elíptica enquanto cada regra que depende do estado atual da cadeia continua sendo aplicada.

Onde você vê isso

A sincronização headers-first aparece como dois contadores que não coincidem enquanto um nó se atualiza.

Chame getblockchaininfo durante uma primeira sincronização e o campo headers ficará bem à frente do campo blocks, muitas vezes por centenas de milhares. O cliente gráfico diz o mesmo em linguagem simples: ele só consegue estimar um horário de término depois que os cabeçalhos chegaram, porque até então não sabe quanto caminho ainda falta percorrer. Acompanhar esses dois números convergirem é a barra de progresso honesta.

O software leve para de propósito depois da primeira metade. Uma carteira SPV, um cliente de filtros compactos ou um nó Lightning que funciona sem seu próprio backend de cadeia mantém apenas os cabeçalhos e sobrepõe a eles provas de merkle ou filtros. É exatamente por isso que uma carteira de celular consegue conferir seu próprio histórico usando dados móveis: os cabeçalhos são pequenos e de tamanho fixo, os corpos de bloco não são nem uma coisa nem outra.

Sincronização headers-first vs sincronização blocks-first

A sincronização headers-first aprende a forma da cadeia antes de baixar seu conteúdo, enquanto a sincronização blocks-first tentava fazer as duas coisas ao mesmo tempo. O método mais antigo enviava uma mensagem getblocks, recebia uma mensagem inv com no máximo 500 hashes de bloco e os baixava um a um do par que respondesse, de modo que uma única conexão lenta travava tudo o que vinha atrás. Qualquer coisa que chegasse fora de ordem não tinha onde ficar além de um reservatório na memória que um atacante podia encher de lixo. O Bitcoin Core não sincroniza desse jeito desde o 0.10.0, embora ainda entenda essas mensagens para que softwares mais antigos possam se comunicar com ele.