Assumeutxo

A snapshot lista cada saída gastável (UTXO) em uma altura de bloco, e seu hash é compilado no software em vez de baixado com ele. O Bitcoin Core 28.0 adicionou parâmetros da mainnet para a altura 840.000, a primeira altura contra a qual uma snapshot pode ser carregada na rede real. Sua carteira fica utilizável muito antes de todo o histórico ter sido verificado, enquanto o nó verifica silenciosamente os blocos pulados por trás.

Como funciona

O assumeutxo divide um nó em dois chainstates e os executa ao mesmo tempo.

Você entrega um arquivo de snapshot ao RPC loadtxoutset. O Bitcoin Core cria um segundo chainstate para carregá-lo, mantendo o original ativo enquanto o conteúdo é lido e verificado. Depois que o chainstate da snapshot é carregado e validado, ele se torna o ativo, um diretório chamado chainstate_snapshot aparece no diretório de dados, e o nó começa a sincronizar do bloco base da snapshot em direção à ponta da rede. Dentro desse diretório fica um pequeno arquivo chamado base_blockhash, que registra em qual bloco a snapshot foi tirada, de modo que o arranjo sobrevive a uma reinicialização.

O hash é toda a questão da confiança. A própria documentação do Core afirma que não existe uma fonte canônica de snapshots, e que qualquer snapshot que você baixe é verificada contra um valor fixado no código-fonte. Portanto, você não está confiando em quem hospedou o arquivo. Você está confiando na mesma versão que já escolheu executar, e um arquivo cujo hash não corresponde ao valor compilado é rejeitado antes mesmo de se tornar seu chainstate.

Enquanto isso, o chainstate original continua avançando penosamente a partir do bloco gênesis com todas as regras aplicadas. Quando alcança o bloco base da snapshot, ele calcula o hash de seu próprio conjunto de saídas não gastas e compara o resultado com o parâmetro compilado. O cache é entregue à cadeia que mais precisa dele: a cadeia da snapshot tem prioridade enquanto corre para a ponta, e a cadeia em segundo plano recebe a maior parte depois. O RPC getchainstates mostra as duas.

A limpeza acontece na próxima reinicialização, e não imediatamente. O Core renomeia chainstate_snapshot para chainstate, exclui os dados em segundo plano, e a partir desse momento o nó é indistinguível de um construído da forma tradicional. O arquivo base_blockhash permanece como registro de onde ele começou.

Por que isso importa quando você compra bitcoin

O assumeutxo ataca a única desvantagem que impede a maioria dos compradores de validar seus próprios bitcoins.

Das 41 carteiras analisadas neste site, o Bitcoin Core é o único que baixa e verifica toda a cadeia por conta própria, e é por isso que nossa análise lhe dá nota 4,7 e ainda lista como sua primeira desvantagem que a primeira sincronização baixa e verifica a cadeia inteira, custando horas e muito espaço em disco. Essa frase é o motivo pelo qual a maioria das pessoas nunca tenta. Uma snapshot não faz o custo desaparecer, ela o desloca: as horas ainda acontecem, só que acontecem depois que sua carteira já funciona, em vez de antes.

O momento em que isso compensa é o saque. Você compra em uma das 63 corretoras registradas aqui, envia os bitcoins para chaves que você controla, e então quer saber se chegaram. Sem um nó próprio, as duas partes a quem você pode perguntar são a corretora que acabou de enviá-los e um explorador de blocos público que agora conhece seu endereço. Com um nó, a resposta vem de uma aritmética que sua própria máquina realizou.

Isso também muda o que custa iniciar uma configuração séria. Nossa análise da Sparrow, também com nota 4,7, descreve a conexão direta ao Bitcoin Core como backend, e esse pareamento costumava significar esperar uma sincronização completa antes que a Sparrow tivesse com quem se comunicar. Uma snapshot comprime o dia de configuração em uma noite útil, e a verificação que você adiou termina sozinha enquanto você dorme.

Exemplo prático: gerar uma snapshot com dumptxoutset

Gerar uma snapshot de assumeutxo é uma operação deliberada em um nó em que você já confia, não um arquivo que você vai buscar.

O RPC dumptxoutset a produz, seja na ponta atual usando o tipo "latest", seja em uma altura recente usando o tipo "rollback". Durante a maior parte do tempo em que é executado, o nó fica em um estado temporário que não reflete a realidade, marcando como inválidos blocos que sabe estarem corretos, e por causa desse estado a atividade de rede é desligada e todos os pares são desconectados. A documentação do Core recomenda -rpcclienttimeout=0 porque o dump demora um pouco, qualquer que seja o hardware e qualquer que seja o tipo escolhido, e desaconselha mexer no nó para qualquer outra coisa nesse meio-tempo.

Dois detalhes pegam as pessoas de surpresa. Uma snapshot só é utilizável se sua altura já tiver um hash listado nos parâmetros da cadeia, então escolher qualquer outra altura significa editar esse código e recompilar, e o tipo "rollback" também serve para verificar um hash fixado no código, regenerando a snapshot e comparando. E o Bitcoin Core 28.0 mudou a serialização: dumps no formato antigo não são mais aceitos e precisam ser recriados em um nó 28.0 ou posterior antes que o loadtxoutset os aceite.

O Bitcoin Core 29.0 adicionou uma ferramenta relacionada, contrib/utxo-tools/utxo_to_sqlite.py, que converte uma snapshot com serialização compacta em um banco de dados SQLite3. Isso não tem nada a ver com sincronizar um nó e tudo a ver com o que uma snapshot realmente é: um retrato completo e autônomo de quem possui o quê em uma altura, o que acaba sendo algo útil de consultar.

Assumeutxo vs download inicial de blocos

O assumeutxo não substitui o download inicial de blocos, ele muda a ordem em que o trabalho acontece.

Um nó que carregou uma snapshot ainda faz um download inicial de blocos completo a partir do bloco gênesis em seu chainstate em segundo plano, que é o chainstate encarregado da validação completa do trecho de cadeia que a snapshot lhe permitiu presumir. Nada é pulado permanentemente. O que a snapshot proporciona é que a carteira deixe de ser inútil durante a espera, porque o chainstate ativo já conhece o estado atual de cada endereço que lhe interessa. A região entre o bloco gênesis e a altura da snapshot é rastreada como presumidamente válida em vez de ser contada discretamente como verificada, e é por isso que o Core mantém dois chainstates em vez de uma marcação em um único. Um nó que carregou uma snapshot e nunca terminou a sincronização em segundo plano está em um estado real e nomeado, não em um estado oculto.

Assumeutxo vs um nó podado

O assumeutxo e a poda reduzem ambos o que um nó precisa administrar, e reduzem coisas opostas.

A poda tem a ver com o disco após a validação: um nó podado verifica cada bloco e depois exclui os arquivos brutos de que não precisa mais. O assumeutxo tem a ver com o tempo antes da validação: ele adia verificações que ainda assim realizará. Os dois se combinam, e o Core flexibiliza uma de suas próprias regras para permitir isso. O piso habitual de -prune é 550 MiB, e um nó que carrega uma snapshot ignora esse mínimo e usa pelo menos 1100 MiB. O espaço não é o único item: enquanto a sincronização em segundo plano é executada, há temporariamente dois diretórios de chainstate, cada um deles com vários gigabytes e com probabilidade de crescer além do tamanho da snapshot que você baixou.

É nos índices que os dois mais divergem. Um índice não ganha nada com uma snapshot, porque os índices sempre começam a ser construídos a partir do bloco gênesis e só podem aplicar blocos em ordem, de modo que um índice só alcança a ponta quando a validação em segundo plano levou o nó além do bloco da snapshot. A poda agrava isso: um índice que oferece suporte à poda permite ao nó excluir apenas blocos que já indexou, então uma snapshot antiga deixa no disco um acúmulo de blocos baixados, não indexados e impossíveis de excluir até que a indexação se atualize.