123 / 736A-UTXO

AssumeUTXO

Colocar um nó em uso mais cedo com um estado verificado

AssumeUTXO ajuda um novo Full Node a alcançar mais cedo a atividade atual da rede. Ele parte de um snapshot compatível de saídas não gastas, enquanto continua verificando o histórico anterior em segundo plano. Ter um nó utilizável e concluir essa verificação são momentos distintos.

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.

DOC · 001Bitcoin Core — AssumeUTXO designDocumentação DOC · 002Bitcoin Core v29.0 — AssumeUTXO parametersDocumentação DOC · 003Bitcoin Core — loadtxoutset RPCDocumentação DOC · 004Bitcoin Core 28.0 release notesDocumentação DOC · 005Bitcoin Optech — AssumeUTXODocumentação DOC · 006Bitcoin Core — validationDocumentação DOC · 007Bitcoin Core v29.0 — Using UTXO snapshotsDocumentação DOC · 008Bitcoin Core v29.0 — getchainstatesDocumentação
Revisto em: Fontes em primeiro lugar · Não é recomendação de investimento