AssumeUTXO antecipa o uso de um nó Bitcoin carregando um snapshot, um estado salvo em determinado bloco. Temporariamente, o nó se apoia em uma impressão digital esperada desse estado, incorporada ao programa. Depois processa o histórico por conta própria e compara o resultado; o snapshot não substitui esse trabalho.
Pedro inicia seu primeiro Full Node, um programa que verifica as regras do Bitcoin por conta própria. Um bloco reúne transações em um lote acrescentado ao histórico compartilhado. Uma inicialização comum exige percorrer primeiro um longo histórico. AssumeUTXO permite começar por um conjunto UTXO preparado: saídas de transações ainda não gastas, cada uma com um valor e as condições para gastá-lo. O snapshot registra o estado após um bloco específico. Não é um arquivo de todos os pagamentos nem prova de que o computador de Pedro já verificou todo o passado. [1] [3]
O nome do arquivo não torna um snapshot correto. Ao carregá-lo por loadtxoutset, Bitcoin Core v29.0 confere formato, bloco-base (o bloco ao qual o snapshot corresponde) e parâmetros compatíveis. Também calcula o hash do conteúdo UTXO, uma impressão digital criptográfica, e o compara com o valor esperado antes da ativação. Um conteúdo alterado não passa na verificação só porque alguém deu ao arquivo um nome que parece confiável. [2] [3] [6]
Depois de aceitar o snapshot, o nó continua a partir daquele estado, verifica os blocos posteriores e pode alcançar o fim atual da cadeia. Não os aceita sem conferir: as condições de gasto e a criação permitida de novos bitcoins continuam sendo verificadas. A vantagem é que esse caminho até a atividade presente não precisa esperar pelo término do histórico anterior. Isso não significa que o passado já tenha sido verificado localmente. [1] [6]
Ao mesmo tempo, um segundo estado é construído a partir dos blocos históricos, desde o começo até a base do snapshot. É um cálculo independente com base no histórico, não outra cópia do inventário baixado. Por algum tempo, o programa mantém dois estados com avanços diferentes. O comando técnico getchainstates permite vê-los; o estado ativo chegar aos últimos blocos não confirma, por si só, a conclusão do trabalho em segundo plano. [1] [8]
O hash esperado e o bloco-base compatível pertencem a uma versão específica do programa. Até que o nó de Pedro percorra o histórico por conta própria, ele depende da correção dessa informação incorporada. A comparação dos hashes permite verificar se os conteúdos coincidem, mas não prova, por si só, que vieram de um histórico válido. Se o estado esperado estivesse errado, o uso antecipado do nó se apoiaria nessa suposição incorreta. Por isso, a verificação histórica posterior não deve ser confundida com a conferência do arquivo durante o carregamento. [2] [6]
O arquivo pode vir de outro operador, mas isso não lhe dá autoridade para determinar o estado aceito. O que importa é a correspondência com o valor compatível com o programa, não a promessa do fornecedor. Também não é possível carregar qualquer snapshot de qualquer bloco: o suporte depende da versão e da rede. A conferência do hash não garante a entrega do arquivo nem elimina o tempo, a conexão e o espaço consumidos para baixá-lo e processá-lo. [2] [4] [7]
Quando o trabalho em segundo plano chega ao mesmo bloco-base, o nó calcula o hash do conjunto UTXO que construiu e o compara com o hash esperado do snapshot. Não está comparando o estado atual com uma fotografia antiga: ambos se referem ao mesmo ponto do histórico. Se houver diferença, a implementação descrita aqui encerra o nó e deixa de usar o estado derivado do snapshot. Não esconde a divergência nem informa uma verificação bem-sucedida. [1] [6]
AssumeUTXO muda principalmente o tempo até o nó ficar utilizável. O download e a verificação históricos continuam, e duas bases de dados de estado são mantidas temporariamente. Isso exige processamento e atividade de disco. Um Pruned Node economiza espaço apagando arquivos de blocos antigos já processados, sem deixar de verificar as regras. Um Pruned Node também pode usar um snapshot, mas a economia de armazenamento tem limites próprios. Alguns índices auxiliares precisam processar o histórico desde o início; portanto, disponibilizar o nó antes não deixa todas as aplicações conectadas prontas de imediato. [5] [7]
O conjunto UTXO contém informações sobre saídas não gastas, não as chaves privadas que autorizam gastos. 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. O conjunto UTXO não é um backup da carteira e não recupera uma Seed Phrase perdida, as palavras de recuperação de uma carteira que utiliza esse mecanismo. Pagamentos antigos também podem não aparecer imediatamente: encontrá-los pode exigir blocos anteriores ao snapshot. Fazer backup das chaves, localizar o histórico da própria carteira e verificar o estado da rede são tarefas diferentes. [1] [7]
Os nomes parecidos podem confundir. AssumeUTXO começa a partir de um estado carregado e reconstrói o histórico anterior em segundo plano. Já assumevalid pode, em condições específicas, dispensar parte das verificações históricas de scripts, ou seja, das condições de gasto, incluindo assinaturas. É uma otimização separada que também pode afetar a verificação histórica; concluir AssumeUTXO não demonstra que ela estava desativada. Ao ler instruções, separe o ponto de partida do nó, o que ele realmente verifica e quando cada etapa termina. [5] [6]
Para ter uma visão mais completa, leia este verbete junto com Initial Block Download, Pruned Node, Block Propagation, Nakamoto Consensus, Bitcoin, Bitcoin Core. Também há referências a este verbete em Initial Block Download, Pruned Node, Utreexo.