Sincronização blocks-first

Ninguém mais sincroniza desse modo, e a razão é aritmética. Um download estritamente sequencial não pode usar mais do que a velocidade de upload de um único par, e em 2015 a cadeia já era grande demais para que isso terminasse em tempo razoável. A técnica sobrevive como alternativa no protocolo e como fonte de confusão em documentação antiga.

Como funciona

Status: a sincronização blocks-first foi substituída pela sincronização headers-first no Bitcoin Core 0.10.0, lançado em 16 de fevereiro de 2015. As mensagens que ela usava ainda fazem parte do protocolo ponto a ponto e ainda são respondidas, mas nenhum cliente atual depende delas para se atualizar.

A troca era um ciclo entre duas máquinas. Seu nó enviava uma mensagem getblocks com os hashes dos blocos que já tinha. O par respondia com um inventário que listava até 500 hashes de blocos seguintes. Seu nó pedia esses blocos com getdata, recebia-os, validava cada um por completo e então enviava outro getblocks para perguntar o que vinha depois. Repita isso vários milhares de vezes.

Três problemas surgiram desse desenho. Não havia paralelismo, porque não fazia sentido pedir a um segundo par blocos cuja existência você ainda não conhecia, então toda a sincronização avançava na velocidade do par com quem você estivesse falando naquele momento. Não havia como saber quanto faltava, já que a cadeia se revelava 500 hashes por vez, e por isso os clientes antigos não conseguiam mostrar uma barra de progresso significativa. E um par lento ou hostil podia simplesmente entregar os dados aos poucos, sem que seu nó tivesse uma forma barata de perceber que havia uma cadeia melhor disponível em outro lugar.

A sincronização headers-first resolveu os três problemas separando a evidência barata da cara. Baixe e verifique primeiro a cadeia de cabeçalhos, que em dezembro de 2014 ocupava 27 megabytes para todo o histórico, e você conhece tanto o formato da melhor cadeia quanto seu comprimento antes de baixar uma única transação. Depois, os corpos podem ser solicitados a muitos pares ao mesmo tempo. O efeito colateral foi que os blocos começaram a chegar fora de ordem e a ser gravados no disco fora de ordem, e por isso o diretório de dados criado pela versão 0.10.0 não pode ser lido por nada mais antigo.

Onde você encontra isso

Você vai encontrar a sincronização blocks-first em documentação, não em software.

Material de referência escrito antes de 2015, incluindo boa parte do material para desenvolvedores que ainda circula, descreve o ciclo sequencial como se fosse assim que o bitcoin funciona. Não é, e páginas que descrevem uma sincronização inicial como um download sequencial de um único par estão simplesmente desatualizadas. O Bitcoin Core continua atendendo a pedidos getblocks em benefício de clientes muito antigos ou incomuns, então as mensagens aparecem em capturas de pacotes e em especificações do protocolo.

Para quem executa um nó hoje não há nada a configurar nem nada a escolher. Seu cliente baixa os cabeçalhos primeiro porque toda implementação mantida faz isso.

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

A sincronização blocks-first e a sincronização headers-first diferem no que pedem primeiro, e todo o resto decorre disso. A blocks-first pedia blocos completos em sequência e aprendia o formato da cadeia à medida que avançava, então descobria a melhor cadeia e a baixava na mesma passagem lenta. A headers-first divide o trabalho: estabelece qual cadeia carrega mais prova de trabalho usando 80 bytes por bloco e depois reúne os corpos em paralelo com quem quiser enviá-los. A validação aplicada a cada bloco é idêntica nas duas. O que mudou foi a ordem das operações, e só isso reduziu uma sincronização inicial de semanas para horas.