Initial Block Download, ou IBD, é a sincronização inicial de um nó Bitcoin. No procedimento habitual, ele obtém blocos antigos, verifica-os conforme as regras do seu software e constrói um registro atual dos fundos ainda não gastos.
Você inicia em casa um Full Node: um programa que verifica blocos e transações de Bitcoin de forma independente. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. Os outros participantes já conhecem um longo histórico; o seu novo nó ainda não. Primeiro, ele obtém os cabeçalhos, registros compactos que ligam os blocos. Eles também contêm Proof of Work, a prova de trabalho computacional. Os mineradores procuram essa prova repetindo cálculos; os demais podem verificar rapidamente o resultado. A lista de cabeçalhos se parece com o sumário de um livro: ajuda a se orientar, mas tê-lo não significa ter lido e conferido todas as páginas. [1] [7]
Se os pares oferecem diferentes ramificações do histórico, o nó não conta votos. Os cabeçalhos permitem comparar o trabalho computacional acumulado e escolher uma candidata para verificação mais profunda. Mais blocos não significam necessariamente mais trabalho. Mesmo uma grande quantidade de trabalho não dispensa transações inválidas de cumprir as regras; o conteúdo da ramificação escolhida ainda precisa ser conferido. [1] [2] [6]
O nó pode obter blocos de vários pares ao mesmo tempo, sem depender da velocidade de um único remetente. Para incorporá-los ao histórico validado, porém, precisa conhecer o estado anterior. As entradas de um pagamento apontam para valores anteriores que ele pretende gastar. O nó precisa verificar que eles existem e ainda não foram gastos. Por isso, um bloco posterior já baixado pode esperar pelo processamento de um anterior. Dados baixados não são a mesma coisa que sincronização concluída. [1] [2]
O nó compara o conteúdo do bloco com a impressão digital das transações em seu cabeçalho, produzida por uma Merkle Tree. Também confere, por exemplo, a sequência de gastos e se a recompensa do minerador não excede o valor permitido. Aplica as regras vigentes naquele ponto do histórico. 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. Verificações antigas de assinaturas e outras condições de gasto têm uma configuração especial, assumevalid, explicada adiante. Cabeçalhos ou um arquivo de um par aparentemente confiável não substituem esse conjunto de verificações. [2] [3]
A cada bloco processado, o nó remove saídas gastas e adiciona novas. Uma saída é um valor específico com condições para seu uso posterior. Enquanto não tiver sido gasta, ela é chamada de UTXO. O conjunto dessas saídas permite verificar o próximo pagamento sem percorrer todo o histórico novamente. Não é uma lista de contas bancárias nem uma cópia de todas as transações passadas. [2] [3]
Sob determinadas condições, Bitcoin Core pode pular antigas verificações de scripts, ou seja, de assinaturas e outras condições de gasto. A configuração assumevalid indica um bloco conhecido cujo histórico foi verificado externamente; também importam sua ancestralidade, trabalho suficiente e profundidade. As demais verificações necessárias continuam, mas parte do resultado é presumida. Uma suposição incorreta, portanto, não é isenta de risco. assumevalid=0 desativa essa otimização, ao custo de mais trabalho para o seu computador. [2]
Um Pruned Node apaga arquivos de blocos antigos depois de processá-los, mantendo os UTXO atuais e outros dados necessários. Durante o IBD comum, ele continua obtendo e processando o histórico; apenas não o armazena inteiro permanentemente. Isso economiza espaço em disco, não automaticamente o volume do primeiro download. Uma tarefa posterior que precise de blocos apagados pode exigir obtê-los novamente. [2] [7]
Bitcoin Core v29.0 considera, entre outros fatores, a idade do último bloco aceito, um mínimo de trabalho acumulado e o estado do carregamento. Depois que esse indicador operacional muda para false (indicando que a sincronização inicial terminou), não volta a true (indicando que ela ainda está em andamento) durante a mesma execução. Ele orienta o comportamento do programa, não prova que nenhum bloco mais recente existe em outro lugar. Mesmo uma perda posterior de conexão não o transforma em um indicador confiável de atualização. [2] [5]
Uma conexão rápida ajuda, mas o computador também precisa calcular e gravar no disco. Processador, memória, armazenamento e disponibilidade dos pares influenciam a duração. Na saída técnica de getblockchaininfo, verificationprogress estima o avanço da verificação. Não promete um número de minutos restantes nem representa simplesmente a proporção de bytes baixados. Após encerrar o programa corretamente, a próxima inicialização pode retomar o progresso salvo em vez de começar tudo do zero. [5] [7]
AssumeUTXO permite usar um snapshot compatível de UTXO, um estado salvo em determinado bloco. O software compara seu conteúdo com uma impressão digital esperada e pode chegar ao presente mais cedo a partir desse estado, enquanto processa o histórico em segundo plano. Depois, compara também o estado produzido por essa validação histórica. Não se trata de qualquer banco de dados fornecido por um desconhecido nem de uma forma de nunca verificar o passado. Usabilidade antecipada e validação histórica concluída são etapas diferentes. [4] [8]
Para ter uma visão mais completa, leia este verbete junto com Pruned Node, AssumeUTXO, Block Propagation, Compact Blocks, Bitcoin, Bitcoin Core. Também há referências a este verbete em Block Propagation, Compact Blocks, Pruned Node, AssumeUTXO.