Como resolver problemas na sincronização de um nó de Bitcoin

Sincronizar um nó completo de Bitcoin é uma parte fundamental de participar da rede e uma das mais exigentes do ponto de vista técnico. Este guia explica o que influencia a sincronização, quais características do equipamento fazem diferença e como evoluíram as opções para rodar um nó.

Para sincronizar toda a blockchain do Bitcoin, o nó baixa e valida todas as transações desde o bloco gênese. A tarefa exige cada vez mais recursos. Em novembro de 2026, os dados dos blocos somavam cerca de 800 GB. Com essa validação, cada participante pode verificar por conta própria todo o histórico de transações, sem depender de terceiros.

O equipamento influencia muito a velocidade da sincronização. Há três gargalos principais: a velocidade de leitura e gravação no disco, a RAM disponível e a largura de banda. O disco costuma ser o maior gargalo, sobretudo se você usa um disco rígido mecânico (HDD) em vez de uma unidade de estado sólido (SSD). O nó lê e grava dados da blockchain sem parar. Num disco lento, a sincronização pode levar semanas em vez de dias.

Três quadros em sequência. 1. Rede: há cerca de 800 GB de blocos para baixar. A 100 Mbit/s, isso leva cerca de 18 horas. A 1 Gbit/s, leva umas 2 horas. 2. Memória: o nó busca primeiro no cache de memória cada moeda gasta num bloco. O ajuste dbcache define o tamanho do cache. 3. Disco, em destaque porque costuma ser o mais lento: o nó lê no disco o que não encontra na memória. Um SSD responde rápido. Um disco rígido mecânico demora muito mais. — **Três fatores ditam o ritmo da sincronização, e o disco costuma ser o mais lento.** O nó baixa cada bloco e procura cada moeda gasta nele, primeiro na memória e depois no disco. Um disco mecânico precisa mover o braço de leitura sempre que o nó não acha uma moeda no cache.

A RAM disponível afeta quantas transações não confirmadas o nó consegue gerenciar com agilidade no mempool e quantos dados de uso frequente pode guardar no cache. Com pouca RAM, o nó precisa recorrer mais ao disco, o que agrava o gargalo. Os computadores atuais costumam vir com RAM suficiente para um nó básico, mas cada aumento de memória traz um ganho menor na sincronização.

A largura de banda importa, mas raramente é o principal gargalo numa conexão de banda larga rápida. A rede do Bitcoin distribui a carga entre várias conexões ponto a ponto e aproveita bem a largura de banda disponível. Ainda assim, uma conexão mais rápida ajuda no download inicial de blocos (IBD). Em novembro de 2026, havia cerca de 800 GB de blocos para baixar. Mesmo no limite da conexão, isso leva por volta de 18 horas a 100 Mbit/s e 2 horas a 1 Gbit/s. Os cabeçalhos, que chegam primeiro, somam só uns 78 MB.

Equipamentos pré-configurados e pacotes de software para nós resolveram muitos desses problemas técnicos. Em geral, combinam componentes bem escolhidos com configurações de software mais simples. Assim, fica mais fácil rodar um nó próprio, um avanço importante para descentralizar a infraestrutura do Bitcoin.

Entre as opções atuais estão os nós podados. Eles guardam apenas parte da blockchain e continuam validando tudo. Assim, precisam de muito menos espaço e podem sincronizar mais rápido em equipamentos com poucos recursos. No entanto, os nós podados não podem enviar dados antigos da blockchain para outros participantes. Por isso os nós completos de arquivo continuam importantes.

As dificuldades de sincronização estimularam melhorias no equipamento e no software. Diferentes implementações de nós de Bitcoin passaram a usar bancos de dados otimizados, algoritmos de validação melhores e mecanismos de cache mais avançados. Essas melhorias reduzem os recursos e o trabalho necessários para rodar um nó. O desafio de ampliar a capacidade da rede sem perder a descentralização continua.

Várias linhas de pesquisa podem tornar a sincronização mais eficiente. Os avanços no armazenamento de estado sólido, incluindo unidades NVMe, continuam reduzindo os gargalos de leitura e gravação. Propostas de melhoria do protocolo e técnicas de otimização também podem reduzir o esforço computacional para baixar e validar os blocos na primeira sincronização.

Para que o Bitcoin continue descentralizado, rodar um nó precisa estar ao alcance de mais pessoas. A comunidade busca soluções que equilibrem os requisitos técnicos e a facilidade de uso. À medida que os equipamentos e o software melhorarem, deve ficar mais fácil começar a rodar um nó de Bitcoin. Isso deve ampliar a participação e tornar a rede mais resiliente.

Como sincronizar um nó completo de Bitcoin passo a passo

Este guia mostra como configurar e sincronizar do zero um nó de Bitcoin Core no Linux. Você vai ver como escolher o equipamento, fazer a configuração e acompanhar o progresso.

Passo 1. Escolha o equipamento adequado. Você precisa de pelo menos um SSD de 2 TB, NVMe se o computador aceitar, 8 GB de RAM e um processador de quatro núcleos. Em novembro de 2026, a blockchain de arquivo ocupava cerca de 800 GB e crescia de 6 a 7 GB por mês, então um disco de 1 TB enche em mais ou menos um ano. Com orçamento apertado, um Raspberry Pi 5 com 8 GB de RAM e um SSD ligado por USB 3 funciona e sincroniza em cerca de dois a quatro dias. Um Pi 4 demora mais. Um computador de mesa moderno ou um servidor pequeno, como um Intel NUC ou um Dell OptiPlex usado, sincroniza em um ou dois dias com uma unidade NVMe. Evite discos mecânicos. A validação da blockchain lê e grava em muitos pontos do disco, e num HDD isso pode levar semanas.

Passo 2. Instale o Bitcoin Core. Baixe o binário, o arquivo de somas de verificação SHA256SUMS e o arquivo de assinaturas SHA256SUMS.asc em bitcoincore.org. Verifique o binário antes de confiar nele. A verificação só vale se você importar antes as chaves de quem compila o programa e em quem decidiu confiar. Caso contrário, o GPG vai indicar uma assinatura válida, mas de uma chave que não reconhece. Importe as chaves de quem compila o Bitcoin Core no repositório bitcoin-core/guix.sigs. São essas as chaves usadas para assinar cada versão. Clone o repositório e importe todas as chaves com git clone https://github.com/bitcoin-core/guix.sigs && gpg --import guix.sigs/builder-keys/*.gpg. Importe o conjunto completo em vez de copiar uma única impressão digital à mão. É fácil errar ao copiar ou identificar a impressão digital, ou deixá-la desatualizada. Com todas as chaves, gpg --verify pode confirmar assinaturas válidas de várias pessoas conhecidas. Verifique as assinaturas do arquivo de somas com gpg --verify SHA256SUMS.asc. Procure Good signature de uma chave que você importou. Por fim, confirme o hash do binário com sha256sum --ignore-missing --check SHA256SUMS. O comando precisa mostrar OK ao lado do arquivo que você baixou. A opção --ignore-missing é importante porque SHA256SUMS lista os binários de todas as plataformas. Sem ela, você veria várias linhas FAILED/No such file para os arquivos que não baixou e poderia ignorar uma falha real ou achar que o binário está corrompido. Extraia os arquivos em /usr/local/bin/ e crie um usuário dedicado com sudo adduser --disabled-login bitcoin. (Verificado em junho de 2026 com as instruções oficiais em bitcoincore.org/en/download.)

Duas verificações antes de rodar o Bitcoin Core. 1. Pessoas em quem você confia assinaram a lista? As chaves que você importou do guix.sigs são de quem compila o programa e assinou SHA256SUMS, a lista de hashes. gpg --verify SHA256SUMS.asc precisa mostrar Good signature, o que indica que a lista é legítima. 2. Seu arquivo é o que está na lista? sha256sum --ignore-missing --check SHA256SUMS compara o hash do arquivo que você baixou com o de SHA256SUMS. Precisa mostrar OK. Rode o Bitcoin Core só se passar nas duas verificações. — **Duas verificações respondem a duas perguntas.** A assinatura mostra que a lista de hashes veio das pessoas que compilaram o programa e em quem você confia. Se o hash conferir, o arquivo que você baixou é o da lista. Juntas, as duas verificações provam que a sua cópia é a versão que essas pessoas assinaram.

Passo 3. Configure bitcoin.conf. Crie o arquivo de configuração em ~/.bitcoin/bitcoin.conf com estes ajustes essenciais:

server=1
daemon=1
txindex=0
dbcache=4096
maxconnections=40
listen=1

O parâmetro dbcache influencia muito a velocidade da sincronização. Reserve para ele cerca de metade da RAM disponível, em megabytes. Durante a sincronização inicial, 4.096 MB (4 GB) reduzem muito as leituras e gravações em disco, pois o nó guarda na memória uma parte maior do conjunto UTXO, a lista de moedas não gastas. Ao terminar, apague a linha para voltar ao padrão. Desde o Bitcoin Core 31.0, o padrão é 1.024 MiB num computador de 64 bits com pelo menos 4 GB de RAM e 450 MiB em equipamentos com menos memória. Use um valor menor só se outros programas precisarem da memória. Se você pretende rodar um nó Lightning sobre o Bitcoin Core, acrescente zmqpubrawblock=tcp://127.0.0.1:28332 e zmqpubrawtx=tcp://127.0.0.1:28333.

Dois gráficos mostram quanta memória o cache de moedas usa enquanto um nó sincroniza o mesmo trecho de blocos. Com dbcache=1024, o valor padrão num computador com 4 GB de RAM ou mais, o cache enche três vezes. A cada vez, o nó grava os dados no disco e esvazia o cache. Com dbcache=4096, o ajuste indicado neste guia para bitcoin.conf, o cache só enche uma vez no mesmo trecho. Depois de esvaziar o cache, o nó precisa ler no disco as moedas gastas nos blocos seguintes. — **Com um dbcache maior, o cache enche menos vezes.** Quando enche, o Bitcoin Core grava os dados no disco e esvazia o cache. Para processar os blocos seguintes, ele precisa ler as moedas do disco de novo. Quanto menos vezes esvazia o cache, menos leituras lentas o Bitcoin Core faz no disco.

Passo 4. Inicie o download inicial de blocos. Inicie o Bitcoin Core com bitcoind e acompanhe o progresso com bitcoin-cli getblockchaininfo. O campo verificationprogress estima o avanço de 0 a 1 (1,0 significa que o nó está sincronizado). Durante o IBD, o nó baixa todos os blocos desde janeiro de 2009 e valida cada transação. Essa é a fase que mais exige do computador. Acompanhe as leituras e gravações no disco com iostat -x 5 para identificar gargalos.

Passo 5. Acompanhe o progresso da sincronização. Rode bitcoin-cli getblockchaininfo | jq '.blocks, .headers, .verificationprogress'. O campo blocks mostra os blocos validados e headers, os cabeçalhos conhecidos, que chegam primeiro. O campo verificationprogress estima a proporção de transações já verificadas. Avança mais devagar que a contagem de blocos porque os blocos antigos tinham menos transações. Você também pode acompanhar o registro de depuração. Procure mensagens como UpdateTip: new best= em ~/.bitcoin/debug.log para saber a altura de bloco que o nó alcançou.

Um nó novo sincroniza em duas etapas. Primeiro baixa os cabeçalhos, um de 80 bytes por bloco, somando cerca de 78 MB. Ao terminar, getblockchaininfo mostra headers 974.796. Depois baixa os blocos, cerca de 800 GB no total, e verifica cada transação. As barras mostram quantas transações há em cada vigésimo da blockchain. De 2009 a 2012, quase não houve transações. Nos últimos anos houve muito mais. Na metade do caminho, blocks mostra 487.398, mas a metade laranja das barras representa menos de um quinto das transações. Por isso verificationprogress só marca cerca de 0,17. O valor 1 significa que o nó está sincronizado. — **Primeiro os cabeçalhos, depois os blocos.** Os cabeçalhos chegam primeiro e somam cerca de 78 MB. Os blocos somam uns 800 GB. verificationprogress conta transações, não blocos. Os primeiros blocos tinham poucas transações, então esse indicador avança mais devagar que a contagem de blocos durante quase toda a sincronização.

Passo 6. Configure a poda se precisar. Se faltar espaço em disco, ative a poda acrescentando prune=550 ao bitcoin.conf (mínimo de 550 MB). Um nó podado valida todo o histórico da blockchain durante a sincronização, mas só guarda os blocos mais recentes no disco. Isso reduz o espaço necessário a cerca de 15 GB, contando os 550 MB de blocos recentes e o banco de moedas não gastas, que o Bitcoin Core 32.1 estima em cerca de 14 GB. O nó continua validando tudo. A limitação é que não pode enviar blocos antigos para outros nós nem usar txindex.

Duas barras de armazenamento na mesma escala. Um nó de arquivo guarda todos os blocos desde 2009 e o banco de moedas, cerca de 900 GB com o Bitcoin Core 32.1. Um nó podado com prune=550 verifica os mesmos blocos, apaga os antigos e guarda cerca de 15 GB. Na ampliação em escala, quase todos esses 15 GB correspondem ao banco de moedas, com cerca de 14 GB, que lista todas as moedas não gastas. Os últimos 550 MB de blocos ocupam uma faixa estreita. Os dois nós verificam cada bloco e transação por conta própria. Só o nó de arquivo pode enviar blocos antigos para outros nós e manter um índice de transações (txindex). — **Um nó podado verifica tudo o que um nó de arquivo verifica.** Apaga os blocos antigos depois de verificá-los. Por isso precisa de cerca de 15 GB em vez de 900 GB, e a maior parte desses 15 GB corresponde à lista de moedas não gastas. Em troca, já não pode enviar blocos antigos para outros nós nem manter um índice de transações.

Passo 7. Confirme o fim da sincronização e reforce a segurança. Quando blocks coincidir com headers e verificationprogress mostrar 1 ou um valor pouco abaixo disso, seu nó estará sincronizado. Apague a linha dbcache=4096 do bitcoin.conf para o Bitcoin Core voltar ao cache padrão (1.024 MiB num computador de 64 bits com pelo menos 4 GB de RAM). Reinicie o programa com bitcoin-cli stop e depois bitcoind. Use bitcoin-cli getnetworkinfo para conferir se connections_out chega a 10, o número padrão de conexões de saída com outros nós. Ative a inicialização automática com um arquivo de serviço do systemd para o nó voltar a rodar quando o computador reiniciar. Se quiser contribuir com a rede aceitando conexões, configure o firewall para permitir conexões de entrada na porta 8333.

Aviso. Não interrompa a sincronização forçando o fim do processo. Use sempre bitcoin-cli stop para parar o Bitcoin Core com segurança. Um desligamento incorreto pode corromper o banco de dados chainstate e obrigar você a refazer a sincronização inteira. Se faltar energia de repente, o Bitcoin Core vai tentar se recuperar quando reiniciar, mas isso acrescenta horas ao processo.

Erros comuns a evitar

Usar um HDD em vez de um SSD. Essa é a causa mais comum de sincronizações muito lentas. O banco de dados UTXO do Bitcoin Core exige muitas leituras e gravações aleatórias que os discos mecânicos não conseguem atender bem. Um SSD NVMe é o ideal, mas até um SSD SATA lida com essa carga muito melhor do que um HDD. Se você estiver sincronizando num HDD com previsão de 2 a 3 semanas, pare, compre um SSD e comece de novo. Vai ser mais rápido do que esperar.

Configurar um dbcache muito baixo durante a sincronização inicial. O dbcache padrão, desde o Bitcoin Core 31.0, é de 1.024 MiB num computador de 64 bits com pelo menos 4 GB de RAM e de 450 MiB nos demais. Com esse valor, o cache enche e o nó grava os dados no disco várias vezes durante a primeira sincronização. Cada moeda que sai da memória precisa ser lida no disco de novo. Durante o IBD, se houver RAM de sobra, subir o valor para 2.048 a 4.096 MB pode reduzir bastante o tempo de sincronização. Ao terminar, apague a linha para voltar ao padrão (passo 7).

Rodar o Bitcoin Core num equipamento sem refrigeração adequada. Validar a blockchain exige muito do processador. Muitos sistemas com Raspberry Pi reduzem a velocidade quando esquentam sob carga prolongada. Um gabinete com dissipador passivo ou uma ventoinha evita a perda de desempenho e ajuda a prever o tempo de sincronização. Acompanhe a temperatura do processador com vcgencmd measure_temp no Raspberry Pi ou sensors no Linux de um computador de mesa.

Sincronizar por Wi-Fi ou numa conexão com limite de dados. O download inicial de blocos transfere cerca de 800 GB de dados em novembro de 2026. O Wi-Fi pode acrescentar latência e perda de pacotes, o que torna mais lenta a comunicação com outros nós. Use Ethernet sempre que puder. Se sua conexão tiver limite de dados, como ao compartilhar a internet do celular ou usar um plano com franquia, o IBD vai consumir toda a franquia e ultrapassá-la.

Não reservar espaço suficiente no disco. A blockchain cresce entre 70 e 85 GB por ano, por volta de 6 a 7 GB por mês no ritmo de meados de 2026. Um disco de 1 TB já fica cerca de 90% cheio no fim da sincronização, pois o Bitcoin Core 32.1 prevê cerca de 900 GB. Assim, você teria de ampliar o armazenamento em até um ano. Compre um disco de 2 TB. Se faltar espaço, a alternativa é ativar a poda. É uma configuração, não uma limpeza que você roda de vez em quando. A poda impede o funcionamento do Electrs e do Fulcrum. Se você desativá-la depois, vai precisar baixar a blockchain inteira de novo.

Dois discos desenhados em escala. O Bitcoin Core 32.1 prevê cerca de 900 GB. Num disco de 1 TB, sobra espaço para no máximo mais um ano de blocos, uns 80 GB. Os blocos do segundo ano não cabem. Num disco de 2 TB, os mesmos 900 GB deixam espaço para mais de dez anos no ritmo atual, de cerca de 80 GB por ano. Um disco de 1 TB fica cerca de 90% cheio no dia em que a sincronização termina. — **Planeje usar um disco de 2 TB.** O Bitcoin Core 32.1 prevê cerca de 900 GB, e os blocos crescem uns 80 GB por ano. Por isso um disco de 1 TB enche em um ano. Um disco de 2 TB tem espaço para mais de dez anos no ritmo atual.

Perguntas frequentes

Quanto tempo leva para sincronizar um nó completo de Bitcoin?

Num mini PC com SSD NVMe, 16 GB de RAM e banda larga, a sincronização inicial leva um ou dois dias. Num Raspberry Pi 5 com SSD, cerca de dois a quatro dias. Um Pi 4 demora mais. Em equipamento mais antigo com HDD, pode levar de 2 a 4 semanas ou mais. O que mais pesa é a velocidade do disco, seguida da RAM disponível para o ajuste dbcache.

Preciso deixar meu nó ligado 24/7?

Não, mas é muito recomendável. Ao voltar depois de ficar offline, o nó se atualiza baixando e validando os blocos que perdeu. Se ficou offline por algumas horas, leva poucos minutos para se atualizar. Se ficou muito tempo offline, leva mais. Um nó Lightning precisa ficar ativo 24/7 na prática. Para um nó que só valida, interrupções ocasionais são aceitáveis.

Qual é a diferença entre um nó de arquivo e um nó podado?

Os dois são nós completos. Tanto o nó de arquivo como o podado validam todas as transações do histórico da blockchain durante a sincronização inicial. A diferença está no armazenamento. Um nó de arquivo guarda a blockchain inteira. Em novembro de 2026, são cerca de 800 GB de blocos. Um nó podado descarta os blocos antigos após validá-los e guarda só os mais recentes. Com prune=550, pode guardar apenas 550 MB de blocos e usar cerca de 15 GB no total com o banco de moedas não gastas. Os nós de arquivo podem enviar blocos antigos para outros nós e manter um índice de transações. Os nós podados não oferecem esses recursos, mas dão o mesmo nível de segurança para quem verifica por conta própria.

Posso sincronizar um nó com dados da blockchain de outra pessoa?

Tecnicamente sim, copiando os diretórios blocks/ e chainstate/ de outro nó de confiança. Você pula o download, mas o nó ainda precisa reindexar e verificar os dados, a menos que você decida confiar neles sem verificar. O projeto Bitcoin Core desaconselha esse método por motivos de segurança. O objetivo de rodar um nó é verificar sem confiar em terceiros. Se pular a validação, você passa a confiar em quem passou os dados. Para a maioria das pessoas, um IBD completo num SSD é rápido o bastante para dispensar esses atalhos.

Rodar um nó de Bitcoin gasta muita eletricidade?

Um Raspberry Pi com SSD consome cerca de 5 a 10 watts. Um Intel NUC ou mini PC semelhante consome de 10 a 25 watts, e um computador de mesa reaproveitado, de 30 a 80 watts. Multiplique os watts por 8,76 para obter os quilowatts-hora por ano. Com um preço de US$ 0,20 por kWh, isso dá entre US$ 9 e US$ 18 por ano para o Pi, entre US$ 18 e US$ 44 para o mini PC e entre US$ 53 e US$ 140 para o computador de mesa. Faça a conta com o preço que você paga por kWh. Depois da sincronização inicial, o uso do processador cai muito. Um nó sincronizado passa a maior parte do tempo esperando novos blocos e transações, o que exige pouco poder computacional.

Recursos relacionados

Faz parte do nosso curso de Bitcoin:Este tema é explicado em Como configurar seu nó de Bitcoin passo a passo, do curso Rede Lightning e nós de Bitcoin.

Categoria: Nós e infraestrutura