Guia de Nó Monero Pruned: Economize 60GB em 2026

Em maio de 2026 a blockchain do Monero já ocupa cerca de 215 GB em disco, um número que disparou após o hard fork de novembro de 2025 que ativou o FCMP++ em produção e empurrou a contagem diária de transações para além das 60.000 durante várias semanas consecutivas. Para quem corre um nó num portátil com SSD de 256 GB, num Raspberry Pi 5 com um chapéu NVMe modesto, ou num VPS com tráfego medido, uma sincronização arquival completa deixou de ser um compromisso casual. Um nó pruned (podado) resolve a equação de forma elegante: descarta cerca de dois terços dos dados históricos de ring signatures, mas preserva cada cabeçalho de bloco, cada output de transação e toda a sua capacidade de verificar a cadeia inteira localmente e sem confiar em terceiros. O resultado é um daemon Monero plenamente soberano que ocupa entre 85 e 95 GB em vez de 215 GB, continua a servir carteiras via RPC, continua a participar no enxame peer-to-peer e continua a difundir as suas próprias transações via Dandelion++ sem revelar metadados ao daemon remoto de um desconhecido. Este guia mostra exatamente como o pôr em pé no Linux, Windows, macOS e num Raspberry Pi headless — incluindo o ficheiro unit do systemd que sobrevive a reinícios, as regras de firewall que protegem a porta RPC e o procedimento de ressincronização para quando algo inevitavelmente corromper. Quer tenha chegado aqui depois de usar o MoneroSwapper para uma troca sem KYC, quer esteja a montar o seu primeiro nó independente, o destino é o mesmo: menos disco consumido, zero privacidade perdida.

Por que correr um nó pruned em vez de um nó remoto

É tentador, sobretudo num equipamento limitado, dispensar por completo a ideia de correr um nó e apontar a carteira para um nó comunitário como o node.moneroworld.com ou para um dos endpoints .onion listados nos fóruns do Monero. Tecnicamente funciona. Também entrega ao operador desse nó um registo preciso de quais transações a sua carteira examina, a que horas se liga e — através de correlação de tráfego — uma estimativa razoável de quais outputs lhe pertencem. Nós remotos não conseguem ver a sua view key nem a sua spend key, mas conseguem perfeitamente construir uma impressão digital comportamental, e vários artigos académicos publicados em 2024 e 2025 demonstraram ataques práticos de desanonimização contra carteiras que dependiam exclusivamente de infraestrutura de terceiros.

Um nó pruned fecha essa lacuna sem o obrigar a arranjar um terabyte extra. As garantias de privacidade são idênticas às de um nó completo do ponto de vista da carteira, porque a lógica de poda descarta apenas dados redundantes de ring signatures — nunca um output, nunca uma key image, nunca um cabeçalho de bloco. A sua carteira examina a cadeia contra dados detidos localmente, as suas transações entram no mempool pelas suas próprias ligações de pares, e o tráfego RPC nunca sai do localhost.

• Nenhum operador remoto vê a atividade da sua carteira: cada refresh, cada varredura de output, cada estimativa de taxa acontece na sua máquina.
• Continua a ajudar a rede: um nó pruned serve cerca de um oitavo dos blocos históricos a outros pares, o que significa coletivamente que o enxame não precisa que todos os nós sejam arquivais.
• Piso de hardware razoável: 4 GB de RAM, um CPU ARM ou x86 quad-core moderno e 120 GB livres em SSD chegam pelo menos até 2027 mesmo com hipóteses de crescimento conservadoras.
• Recuperação é simples: se a base de dados se corromper consegue ressincronizar do zero em cerca de seis a doze horas numa ligação de fibra residencial, contra dezoito a trinta de um nó arquival completo.

Pruned vs Nó Completo: o que muda na prática

O algoritmo de poda do Monero, introduzido na v0.15 e refinado de forma constante até à v0.18.4 em 2025, divide a cadeia em 8 "faixas de poda" (pruning stripes) de 4096 blocos cada. Um nó pruned mantém os dados completos de exatamente uma dessas faixas (escolhida pseudoaleatoriamente por par quando o nó é inicializado) mais os 5500 blocos mais recentes na íntegra, e mantém cabeçalhos, key images, montantes de output e dados de minerador para todos os outros blocos. Os dados das ring signatures — que são o grosso do peso em disco — são descartados para as sete faixas que o nó não hospeda.

Como cada nó hospeda uma faixa diferente, o enxame retém coletivamente toda a blockchain histórica mesmo que todos os nós podem. Uma carteira a fazer uma sincronização nova que precise de dados de ring signature para um bloco antigo simplesmente os baixa do par pruned que por acaso hospeda essa faixa, de forma transparente e sem intervenção do utilizador. Do ponto de vista da verificação nada se sacrifica: cada nó pruned valida a cadeia inteira na primeira sincronização e continua a validar cada novo bloco à medida que chega.

O único compromisso significativo de um nó pruned é não poder servir como fonte de dados para um block explorer ou para ferramentas académicas de análise de cadeia que precisem das ring signatures históricas completas. Se isso não está no seu horizonte — e para a esmagadora maioria dos utilizadores self-hosted não está — a poda é estritamente melhor do que arquival numa máquina limitada.

Hardware e requisitos de sistema em 2026

O piso de hardware para um nó pruned Monero confortável subiu modestamente desde a ativação do FCMP++, principalmente porque a verificação das provas de pertença (membership proofs) nos blocos recebidos é cerca de 18% mais intensa em CPU do que a verificação CLSAG anterior ao fork. A boa notícia é que qualquer máquina fabricada depois de 2021 lida com isso sem problemas. A má notícia é que computadores monoplaca mais antigos — Raspberry Pi 4 original com 2 GB de RAM, mini-PCs com Atom de baixo consumo — vão sofrer para acompanhar a ponta da cadeia em dias de tráfego pesado.

Linha de base recomendada

• CPU: ARM Cortex-A76 quad-core (Raspberry Pi 5) ou qualquer x86-64 moderno com AES-NI. Evite hosts a 32 bits por completo; o desempenho do LMDB degrada-se e várias RPCs de carteira comportam-se mal.
• RAM: 4 GB mínimo, 8 GB confortável. O memory map do LMDB beneficia de folga; se a RAM estiver apertada, o monerod ainda corre mas a verificação de blocos torna-se visivelmente mais lenta.
• Armazenamento: 120 GB livres em SSD ou NVMe. Disco mecânico tecnicamente funciona, mas um HDD transforma uma sincronização de 6 horas num suplício de 36 horas — o padrão de acesso aleatório do LMDB é brutal sobre pratos.
• Rede: 25 Mbps simétricos chegam de sobra para operação em regime permanente. A sincronização inicial vai saturar o que tiver; conte com 90 a 110 GB de download para o bootstrap pruned.
• Sistema operativo: Ubuntu 24.04 LTS, Debian 12, Fedora 41, macOS 14+, ou Windows 11. Quem usa NixOS tem um módulo de serviço mantido; em Arch existe monero-bin no AUR.

Se vai montar num Raspberry Pi 5, use a NVMe Base oficial da Pimoroni ou um chapéu M.2 equivalente; o slot de cartão SD é aceitável para o sistema operativo mas nunca deve hospedar a blockchain. Cartões SD morrem com este padrão de escrita em poucos meses, e a latência de I/O faz o daemon parecer perpetuamente atrasado em relação à ponta mesmo depois de sincronizado.

Passo a passo no Linux

O caminho de referência é o Linux por ser o mais simples de reproduzir, o alvo de produção mais comum e o mais fácil de manter a correr sem assistência. Adaptações para macOS e Windows seguem no final.

1. Crie um utilizador e diretório dedicados. Como root, execute useradd -r -s /bin/false monero e depois mkdir -p /var/lib/monero/blockchain /var/log/monero seguido de chown -R monero:monero /var/lib/monero /var/log/monero. Correr o monerod sob uma conta de serviço e não com o seu utilizador de login é o maior ganho isolado de endurecimento e não custa nada.
2. Descarregue o binário oficial. Vá a getmonero.org/downloads e pegue o tarball Linux 64-bit — na altura desta redação a versão atual é v0.18.4.2. Crucialmente, descarregue também o hashes.txt correspondente e verifique o SHA256 com shasum -a 256 monero-linux-x64-v0.18.4.2.tar.bz2, depois confirme a assinatura do hashes.txt com gpg --verify hashes.txt usando a chave PGP do binaryFate. Saltar a verificação é como o malware entra na sua máquina.
3. Extraia e instale. Descompacte com tar xjf monero-linux-x64-v0.18.4.2.tar.bz2 e mova os binários: install -m 755 monero-x86_64-linux-gnu-v0.18.4.2/monero* /usr/local/bin/. Isto coloca monerod, monero-wallet-cli e monero-wallet-rpc no seu PATH.
4. Escreva o ficheiro de configuração. Crie /etc/monero/monerod.conf com pelo menos o seguinte conteúdo: data-dir=/var/lib/monero/blockchain, log-file=/var/log/monero/monerod.log, log-level=0, prune-blockchain=1, sync-pruned-blocks=1, rpc-bind-ip=127.0.0.1, rpc-bind-port=18081, p2p-bind-port=18080, out-peers=32, in-peers=64, limit-rate-up=1048576, no-igd=1, enable-dns-blocklist=1. A flag sync-pruned-blocks=1 é crítica: sem ela, o monerod baixa a cadeia completa e poda localmente, o que desperdiça largura de banda e tempo.
5. Crie o unit do systemd. Guarde o seguinte como /etc/systemd/system/monerod.service: um bloco [Unit] com Description=Monero Full Node (pruned) e After=network-online.target; um bloco [Service] com User=monero, Group=monero, Type=simple, ExecStart=/usr/local/bin/monerod --config-file=/etc/monero/monerod.conf --non-interactive, Restart=on-failure, RestartSec=30, MemoryHigh=3G, e MemoryMax=5G; e um bloco [Install] com WantedBy=multi-user.target.
6. Ative e arranque o serviço. Execute systemctl daemon-reload e depois systemctl enable --now monerod. Acompanhe o progresso com journalctl -u monerod -f ou seguindo o ficheiro de log diretamente. A sincronização inicial de um nó pruned do zero numa linha residencial de 1 Gbps costuma completar-se em 6 a 10 horas; num Pi 5 com NVMe conte com 14 a 20 horas porque o gargalo é a verificação, não o download.
7. Abra a porta P2P, não a porta RPC. Se quer ligações de pares de entrada (o que ajuda a rede e melhora a sua própria diversidade de pares), abra TCP 18080 no router ou firewall. Nunca exponha a 18081 à internet pública — essa é o endpoint RPC da sua carteira e deve permanecer ligada ao localhost. Se precisa de acesso remoto à carteira, faça túnel via SSH ou Tor, jamais via redirecionamento de porta cru.
8. Aponte a carteira para o daemon local. Na carteira GUI oficial, escolha "Ligar a um nó local" e use 127.0.0.1:18081. Na CLI, passe --daemon-address=127.0.0.1:18081 ao monero-wallet-cli. Na Feather Wallet, o interruptor do nó local fica em Definições → Nó, e a Cake Wallet no desktop suporta-o através de Definições → Privacidade → Nó personalizado.

Nunca corra o monerod com --restricted-rpc=0 numa interface pública. Em menos de quarenta e oito horas após ser indexado pelo Shodan, um endpoint RPC sem restrições vai ser bombardeado por scrapers de mining pools, bots de varredura de carteiras e coisas piores. A vinculação só ao localhost é o padrão por uma razão.

Adaptando a configuração a outras plataformas

Raspberry Pi 5 com NVMe

A configuração acima funciona essencialmente sem alterações num Pi 5. Os dois ajustes que valem a pena: defina db-sync-mode=fast:async:250000000 no monerod.conf para reduzir a amplificação de escrita no NVMe (o padrão é seguro mas mais lento), e considere baixar out-peers para 16 e in-peers para 32 se estiver numa ligação doméstica que estrangule em upload sustentado. O quad Cortex-A76 do Pi 5 verifica blocos a cerca de 0,6× a velocidade de um desktop moderno, portanto a sincronização inicial demora mais, mas a operação em regime permanente acompanha a ponta da cadeia sem problemas.

macOS

Instale via Homebrew com brew install monero, o que coloca o monerod em /opt/homebrew/bin/monerod em Apple Silicon. Use um plist do launchd em ~/Library/LaunchAgents/io.getmonero.monerod.plist em vez do systemd. O mesmo conteúdo de ficheiro de configuração aplica-se — basta apontar data-dir para algum sítio dentro do seu diretório pessoal, como ~/Library/Application Support/monero. As janelas da firewall do macOS aparecerão na primeira execução; permita entrada na porta P2P se quer servir pares.

Windows 11

Descarregue o instalador Windows 64-bit do getmonero.org, corra-o, e deixe-o criar o diretório de dados em C:\ProgramData\bitmonero. Para correr o monerod como serviço em vez de processo em primeiro plano, use o NSSM (Non-Sucking Service Manager) e aponte-o ao monerod.exe com o mesmo argumento --config-file. O Windows Defender por vezes assinala o monerod como "mineração de moedas" — ele não mineira, mas a heurística é burra, portanto adicione uma exclusão para o diretório do binário.

Manutenção, monitorização e recuperação

Um nó pruned corretamente configurado fica perto do "esqueça-e-deixe-correr", mas três hábitos operacionais evitam 90% das dores.

Primeiro, verifique o espaço em disco mensalmente. A cadeia pruned cresce cerca de 4 a 6 GB por mês aos volumes atuais de transação, e um enchimento inesperado pode corromper o LMDB de formas feias. Configure um simples monit ou timer do systemd que alerte quando /var/lib/monero caia abaixo de 15 GB livres.

Segundo, mantenha o monerod atualizado. As atualizações de rede (hard forks) acontecem a cada 6 a 9 meses, e um nó a correr a versão de protocolo anterior deixa de aceitar blocos no momento em que o fork ativa. O calendário de releases do Monero é publicado na página de releases do GitHub e anunciado no r/Monero e na lista de discussão oficial tipicamente quatro a seis semanas antes. Atualize pelo menos duas semanas antes da altura do fork para se dar margem.

Terceiro, saiba como ressincronizar. Se o LMDB alguma vez devolver "MDB_CORRUPTED" ou o daemon recusar arrancar após uma falha de energia, a recuperação é brutal mas fiável: pare o serviço, apague o conteúdo de /var/lib/monero/blockchain e reinicie. O nó vai ressincronizar do zero em 6 a 12 horas. Não existe uma ferramenta de reparo incremental porque o LMDB não tem uma; uma ressincronização limpa é a correção canónica e funciona desde 2017.

Para um exemplo do mundo real: um colaborador do backend do MoneroSwapper opera uma frota de sete nós pruned distribuídos por três países para fornecer endpoints de daemon diversificados ao nosso serviço de swap anónimo. Cada nó é provisionado de forma idêntica — Debian 12, o unit do systemd mostrado acima, armazenamento NVMe e exposição da porta P2P via hidden service do Tor. Em trinta e oito meses de uptime cumulativo na frota, a única intervenção necessária foram três ressincronizações após reinícios não programados em datacenter e a troca normal de binário em dia de fork. É esse o regime permanente que deve esperar de uma instalação bem endurecida.

Perguntas frequentes

Posso converter um nó completo existente num pruned sem ressincronizar?

Sim. Pare o monerod, execute monerod --prune-blockchain como comando único (não como serviço) e espere. A operação de poda demora 30 a 90 minutos consoante a velocidade do disco e reescreve a base de dados no lugar. Quando terminar, reinicie o serviço com a configuração pruned. Sem perda de dados, sem ressincronização, mas faça primeiro uma cópia de segurança das chaves da carteira por precaução — nunca da blockchain em si, que é reproduzível a partir de qualquer par.

Um nó pruned serve para mineração ou para gateway de pagamento Monero?

Para mineração solo ou em pool, sim — o minerador só precisa da ponta da cadeia, não das ring signatures históricas. O P2Pool também funciona com um nó pruned e é, de facto, o emparelhamento recomendado para mineração estilo solo soberano desde 2023. Para uma gateway de comerciante a processar pagamentos via monero-wallet-rpc, um nó pruned é igualmente adequado. Os únicos papéis que exigem um nó arquival são block explorers e instrumentos académicos de análise de cadeia.

Correr um nó pruned prejudica a privacidade da minha própria carteira?

Não. As varreduras da carteira usam o índice de outputs e a base de dados de key images, ambas mantidas na íntegra num nó pruned. Os dados que são descartados — ring signatures históricas — não entram na varredura por view key da sua carteira nem na seleção de iscas (decoys) feita pela carteira ao construir uma nova transação. Do ponto de vista da carteira o daemon local é indistinguível de um arquival, e é dramaticamente mais privado do que qualquer nó remoto, independentemente de quão fiável esse operador remoto se diga.

Como interage a poda com o FCMP++ agora que as provas de pertença estão ativas?

O hard fork de novembro de 2025 introduziu as provas de pertença completas à cadeia (full chain membership proofs) ao lado do esquema de ring signature existente, e a poda trata ambos de forma consistente: mantém cada prova e cada key image necessárias para validar a cadeia, e descarta apenas os bytes redundantes de payload de ring signature que as transações mais antigas ainda carregam. As transações pós-FCMP++ são ligeiramente mais pequenas do que as transações legadas CLSAG, portanto o rácio de poda é, na verdade, marginalmente mais favorável em blocos recentes do que em históricos.

Posso correr um nó pruned inteiramente sobre Tor?

Sim, e este é um padrão de instalação comum entre utilizadores que querem simultaneamente eficiência de disco e privacidade ao nível da rede. Adicione tx-proxy=tor,127.0.0.1:9050,32 e anonymous-inbound=SEUENDERECO.onion,127.0.0.1:18083,16 ao monerod.conf, com o hidden service correspondente configurado em /etc/tor/torrc. A sincronização inicial sobre Tor é mais lenta — 24 a 48 horas em vez de 6 a 12 — mas a operação em regime permanente está bem, e ganha a propriedade adicional de nenhuma das suas transações ou varreduras de carteira chegar a tocar na clearnet.

Conclusão

Um nó Monero pruned entrega as garantias plenas de privacidade e verificação de um nó arquival a cerca de 40% da pegada em disco, o que é a diferença entre "não consigo encaixar isto no portátil" e "isto corre confortavelmente ao lado de tudo o resto". A montagem é um projeto de uma noite em qualquer máquina moderna, a manutenção é da ordem de uma hora a cada seis meses, e o resultado é uma fundação soberana para cada transação Monero que vier a enviar ou receber. Combine um nó pruned local com um serviço de swap sem KYC como o MoneroSwapper e tem a stack completa: privacidade na camada de protocolo via RingCT e FCMP++, privacidade na camada de rede via o seu próprio daemon, e privacidade na rampa de entrada via swaps atómicos a taxa fixa que nunca veem a sua identidade. O espaço em disco poupado é acessório; a independência operacional é a verdadeira vitória.