Guía de Nodo Podado de Monero: Ahorra 60 GB en 2026

En mayo de 2026 la cadena de bloques de Monero pesa aproximadamente 215 GB en disco, una cifra que se disparó tras el hard fork de noviembre de 2025 que llevó FCMP++ a producción y empujó el volumen diario de transacciones por encima de las 60.000 durante varias semanas consecutivas. Para quien corre un nodo en un SSD de 256 GB en su portátil, en una Raspberry Pi 5 con un adaptador NVMe económico o en un VPS con tráfico medido, una sincronización archival completa ya no es un compromiso menor. Un nodo podado resuelve esto de forma elegante: descarta aproximadamente dos tercios de los datos históricos de firmas en anillo conservando cada cabecera de bloque, cada salida de transacción y la capacidad de verificar toda la cadena localmente y sin necesidad de confiar en terceros. El resultado es un daemon de Monero plenamente soberano que ocupa entre 85 y 95 GB en lugar de 215 GB, sigue sirviendo a las carteras vía RPC, sigue participando en el enjambre peer-to-peer y sigue difundiendo tus propias transacciones a través de Dandelion++ sin filtrar metadatos al nodo remoto de un desconocido. Esta guía explica paso a paso cómo desplegar uno en Linux, Windows, macOS y en una Raspberry Pi sin pantalla, incluyendo la unit de systemd que sobrevive a los reinicios, las reglas de cortafuegos que protegen el puerto RPC y los pasos de recuperación por resync para cuando algo inevitablemente se corrompa. Hayas llegado a este artículo después de usar MoneroSwapper para un intercambio sin KYC o estés montando tu primer nodo independiente, el destino es idéntico: menos disco consumido, sin perder privacidad.

Por qué correr un nodo podado en lugar de uno remoto

Resulta tentador, sobre todo en un equipo con recursos limitados, saltarse por completo el correr un nodo propio y apuntar la cartera a un nodo comunitario como node.moneroworld.com o a alguno de los endpoints .onion publicados en los foros de Monero. Eso funciona, técnicamente. También entrega al operador de ese nodo un registro preciso de qué transacciones escanea tu cartera, a qué hora te conectas y —mediante correlación de tráfico— una conjetura razonable sobre qué salidas te pertenecen. Los nodos remotos no pueden ver tu clave de visualización ni tu clave de gasto, pero sí pueden construir una huella conductual muy clara, y varios trabajos académicos publicados en 2024 y 2025 demostraron ataques prácticos de desanonimización contra carteras que dependían exclusivamente de infraestructura ajena.

Un nodo podado cierra esa brecha sin obligarte a buscar un terabyte libre. Las garantías de privacidad son idénticas a las de un nodo completo desde la perspectiva de la cartera, porque la lógica de poda descarta únicamente datos redundantes de firmas en anillo: nunca una salida, nunca una imagen de clave, nunca una cabecera de bloque. Tu cartera escanea la cadena contra datos almacenados localmente, tus transacciones entran al mempool a través de tus propias conexiones de pares, y el tráfico RPC jamás sale de localhost.

• Ningún operador remoto ve la actividad de tu cartera: cada refresco, cada escaneo de salidas y cada estimación de comisión ocurre en tu propia máquina.
• Sigues ayudando a la red: un nodo podado sirve aproximadamente un tercio de los bloques históricos a otros pares, lo que en conjunto significa que el enjambre no necesita que todos los nodos sean archival.
• El piso de hardware es razonable: 4 GB de RAM, una CPU ARM o x86 moderna de cuatro núcleos y 120 GB libres en SSD bastan al menos hasta 2027, incluso con supuestos conservadores de crecimiento.
• La recuperación es directa: si la base de datos se corrompe puedes resincronizar desde cero en seis a doce horas con una fibra residencial, frente a las dieciocho o treinta de un nodo archival completo.

Nodo podado frente a nodo completo: qué cambia realmente

El algoritmo de poda de Monero, introducido en la v0.15 y refinado progresivamente hasta la v0.18.4 durante 2025, divide la cadena en 8 "franjas de poda" de 4096 bloques cada una. Un nodo podado conserva íntegros los datos de exactamente una de esas franjas (elegida pseudoaleatoriamente por par cuando el nodo se inicializa) más los 5500 bloques más recientes completos, y mantiene cabeceras, imágenes de clave, montos de salida y datos del minero para todos los demás bloques. Los datos de firmas en anillo —que constituyen el grueso del peso en disco— se descartan para las siete franjas que el nodo no aloja.

Como cada nodo aloja una franja distinta, el enjambre en su conjunto retiene la cadena histórica completa aunque todos los nodos sean podados. Una cartera que hace una sincronización nueva y necesita datos de firmas en anillo de un bloque antiguo simplemente los descarga del par podado que aloje esa franja, de forma transparente y sin intervención del usuario. Desde el punto de vista de la verificación no se sacrifica nada: cada nodo podado valida la cadena por completo en su primera sincronización y sigue validando cada bloque nuevo a medida que llega.

La única contrapartida real de un nodo podado es que no puede servir como fuente de datos para un explorador de bloques ni para herramientas de análisis académico de la cadena que requieran firmas en anillo históricas completas. Si eso no figura en tu hoja de ruta —y en la inmensa mayoría de los autoalojamientos no figura—, la poda es estrictamente mejor que el archival en una máquina con recursos limitados.

Requisitos de hardware y sistema en 2026

El umbral de hardware para un nodo Monero podado cómodo ha subido modestamente desde la activación de FCMP++, fundamentalmente porque la verificación de las pruebas de pertenencia en los bloques entrantes es alrededor de un 18% más intensiva en CPU que la verificación CLSAG previa al fork. La buena noticia es que cualquier dispositivo fabricado a partir de 2021 lo lleva sin esfuerzo. La mala es que los placas únicas más antiguas —la Raspberry Pi 4 original con 2 GB de RAM, mini-PC de bajo consumo basados en Atom— se quedarán cortas para seguir la punta de la cadena en días de transacciones intensas.

Línea base recomendada

• CPU: ARM Cortex-A76 de cuatro núcleos (Raspberry Pi 5) o cualquier x86-64 moderno con AES-NI. Evita por completo los hosts de 32 bits; el rendimiento de LMDB se degrada y varias RPC de cartera se comportan de forma errática.
• RAM: 4 GB mínimo, 8 GB cómodo. El mapa de memoria de LMDB agradece el margen; si la RAM es escasa, monerod sigue funcionando pero la verificación de bloques se ralentiza visiblemente.
• Almacenamiento: 120 GB libres en SSD o NVMe. Técnicamente funciona un disco duro mecánico, pero convertirá una sincronización de 6 horas en un calvario de 36 — el patrón de acceso aleatorio de LMDB es brutal con los platos.
• Red: 25 Mbps simétricos son de sobra para el régimen estacionario. La sincronización inicial saturará lo que tengas; presupuesta 90–110 GB de descarga para el arranque podado.
• Sistema operativo: Ubuntu 24.04 LTS, Debian 12, Fedora 41, macOS 14+ o Windows 11. Los usuarios de NixOS disponen de un módulo de servicio mantenido; en Arch hay monero-bin en el AUR.

Si vas a desplegar en una Raspberry Pi 5, usa la NVMe Base oficial de Pimoroni o un adaptador M.2 equivalente; la ranura de tarjeta SD es aceptable para el sistema operativo, pero jamás debe alojar la cadena de bloques. Las SD se mueren con este patrón de escritura en cuestión de meses, y la latencia de E/S hace que el daemon parezca perpetuamente retrasado respecto a la punta incluso cuando ya está totalmente sincronizado.

Instalación paso a paso en Linux

El camino de referencia es Linux porque es el más sencillo de reproducir, el objetivo de producción más habitual y el más fácil de mantener funcionando sin supervisión. Las adaptaciones para macOS y Windows aparecen al final.

1. Crea un usuario y un directorio dedicados. Como root, ejecuta useradd -r -s /bin/false monero y luego mkdir -p /var/lib/monero/blockchain /var/log/monero, seguido de chown -R monero:monero /var/lib/monero /var/log/monero. Correr monerod bajo una cuenta de servicio en lugar de tu usuario de inicio de sesión es la mayor mejora de hardening individual y no cuesta nada.
2. Descarga el binario oficial. Entra en getmonero.org/downloads y toma el tarball Linux de 64 bits — al cierre de esta redacción la versión vigente es la v0.18.4.2. Descarga también el hashes.txt correspondiente y verifica el SHA256 con shasum -a 256 monero-linux-x64-v0.18.4.2.tar.bz2, luego confirma la firma del hashes.txt con gpg --verify hashes.txt usando la clave PGP de binaryFate. Saltarse esta verificación es como se cuela el malware en tu máquina.
3. Extrae e instala. Descomprime con tar xjf monero-linux-x64-v0.18.4.2.tar.bz2 y luego mueve los binarios: install -m 755 monero-x86_64-linux-gnu-v0.18.4.2/monero* /usr/local/bin/. Esto deja monerod, monero-wallet-cli y monero-wallet-rpc en tu PATH.
4. Escribe el archivo de configuración. Crea /etc/monero/monerod.conf con, como mínimo, este contenido: 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. La opción sync-pruned-blocks=1 es crítica: sin ella, monerod descarga la cadena entera y la poda localmente, desperdiciando ancho de banda y tiempo.
5. Crea la unit de systemd. Guarda lo siguiente como /etc/systemd/system/monerod.service: un bloque [Unit] con Description=Monero Full Node (pruned) y After=network-online.target; un bloque [Service] con 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 y MemoryMax=5G; y un bloque [Install] con WantedBy=multi-user.target.
6. Habilita y arranca el servicio. Ejecuta systemctl daemon-reload y después systemctl enable --now monerod. Sigue el progreso con journalctl -u monerod -f o tirando del archivo de log directamente. La sincronización inicial de un nodo podado desde cero en una línea residencial de 1 Gbps suele tardar entre 6 y 10 horas; en una Pi 5 con NVMe espera 14–20 horas porque el cuello de botella es la verificación, no la descarga.
7. Abre el puerto P2P, no el RPC. Si quieres conexiones entrantes de pares (lo que ayuda a la red y mejora la diversidad de tus propios pares), abre el TCP 18080 en tu router o cortafuegos. Nunca expongas el 18081 al internet público — ese es el endpoint RPC de tu cartera y debe permanecer atado a localhost. Si necesitas acceso remoto a la cartera, túnelo por SSH o por Tor, jamás mediante un port forward en crudo.
8. Apunta tu cartera al daemon local. En el monedero GUI oficial, elige "Conectar a un nodo local" y usa 127.0.0.1:18081. En CLI, pasa --daemon-address=127.0.0.1:18081 a monero-wallet-cli. En Feather Wallet, el conmutador de nodo local está en Settings → Node, y Cake Wallet en escritorio lo soporta a través de Settings → Privacy → Custom node.

Nunca corras monerod con --restricted-rpc=0 en una interfaz pública. En menos de cuarenta y ocho horas tras ser indexado por Shodan, un endpoint RPC sin restricciones recibirá el martilleo de scrapers de pools de minería, bots de escaneo de carteras y cosas peores. Que el binding por defecto sea localhost-only no es casualidad.

Adaptación de la instalación a otras plataformas

Raspberry Pi 5 con NVMe

La configuración anterior funciona prácticamente sin cambios en una Pi 5. Los dos ajustes que conviene hacer: poner db-sync-mode=fast:async:250000000 en el monerod.conf para reducir la amplificación de escritura sobre la NVMe (el valor por defecto es seguro pero más lento), y plantearte bajar out-peers a 16 y in-peers a 32 si tienes una conexión doméstica que se ahoga con la subida sostenida. El quad Cortex-A76 de la Pi 5 verifica bloques a aproximadamente 0,6× la velocidad de un sobremesa moderno, así que la sincronización inicial dura más, pero la operación en régimen sigue la punta de la cadena sin problema.

macOS

Instala vía Homebrew con brew install monero, que deja monerod en /opt/homebrew/bin/monerod en Apple Silicon. Usa un plist de launchd en ~/Library/LaunchAgents/io.getmonero.monerod.plist en lugar de systemd. El contenido del archivo de configuración es el mismo — simplemente apunta data-dir a algún lugar bajo tu directorio de usuario, como ~/Library/Application Support/monero. Aparecerán avisos del cortafuegos de macOS en el primer arranque; permite el tráfico entrante en el puerto P2P si quieres servir pares.

Windows 11

Descarga el instalador de 64 bits para Windows desde getmonero.org, ejecútalo y deja que cree el directorio de datos en C:\ProgramData\bitmonero. Para correr monerod como servicio y no como proceso en primer plano, usa NSSM (Non-Sucking Service Manager) y apúntalo a monerod.exe con el mismo argumento --config-file. Windows Defender ocasionalmente marca monerod como "coin mining" — no mina nada, pero la heurística es torpe, así que añade una exclusión para el directorio del binario.

Mantenimiento, monitorización y recuperación

Un nodo podado bien configurado es prácticamente set-and-forget, pero tres hábitos operativos evitan el 90% del dolor.

Primero, revisa el espacio en disco cada mes. La cadena podada crece aproximadamente 4–6 GB al mes con los volúmenes de transacciones actuales, y un disco lleno inesperado puede corromper LMDB de formas muy desagradables. Configura un monit sencillo o un timer de systemd que te avise cuando /var/lib/monero baje de 15 GB libres.

Segundo, mantén monerod actualizado. Las actualizaciones de red (hard forks) ocurren cada 6–9 meses aproximadamente, y un nodo con la versión anterior del protocolo deja de aceptar bloques en el instante en que se activa el fork. El calendario de releases de Monero se publica en la página de releases de GitHub y se anuncia en r/Monero y en la lista oficial de correo típicamente con cuatro a seis semanas de antelación. Actualiza al menos dos semanas antes de la altura del fork para darte margen.

Tercero, ten claro cómo resincronizar. Si LMDB lanza alguna vez "MDB_CORRUPTED" o el daemon se niega a arrancar tras un corte de luz, la recuperación es bruta pero fiable: detén el servicio, borra el contenido de /var/lib/monero/blockchain y reinicia. El nodo resincronizará desde cero en 6–12 horas. No hay herramienta de reparación incremental porque LMDB no la tiene; un resync limpio es la solución canónica y lleva funcionando desde 2017.

Un ejemplo del mundo real: un contribuyente del backend de MoneroSwapper opera una flota de siete nodos podados repartidos en tres países para ofrecer endpoints de daemon diversificados a nuestro servicio de intercambio anónimo. Cada nodo se aprovisiona de forma idéntica — Debian 12, la unit de systemd mostrada más arriba, almacenamiento NVMe y exposición del puerto P2P por un servicio oculto de Tor. En treinta y ocho meses de uptime acumulado en toda la flota, la única intervención requerida han sido tres resyncs tras reinicios no planificados del datacenter y el habitual cambio de binario en día de fork. Ese es el régimen estacionario que deberías esperar de un despliegue correctamente endurecido.

Preguntas frecuentes

¿Puedo convertir un nodo completo existente en uno podado sin resincronizar?

Sí. Detén monerod, ejecuta monerod --prune-blockchain como comando puntual (no como servicio) y espera. La operación de poda tarda entre 30 y 90 minutos según la velocidad del disco y reescribe la base de datos en sitio. Cuando termine, reinicia tu servicio con la configuración de podado. Sin pérdida de datos ni resync, pero haz una copia de seguridad de las claves de la cartera antes como precaución — nunca de la cadena en sí, que es reproducible desde cualquier par.

¿Sirve un nodo podado para minar o para correr un gateway de comercio de Monero?

Para minería en solitario o en pool, sí — el minero solo necesita la punta de la cadena, no las firmas en anillo históricas. P2Pool también funciona con un nodo podado y es, de hecho, el emparejamiento recomendado para la minería estilo solo autosoberana desde 2023. Para un gateway de comercio que procesa pagos entrantes vía monero-wallet-rpc, un nodo podado es igualmente apto. Los únicos roles que requieren un nodo archival son los exploradores de bloques y el utillaje académico de análisis de cadena.

¿Perjudica un nodo podado la privacidad de mi propia cartera?

No. Los escaneos de la cartera usan el índice de salidas y la base de datos de imágenes de clave, que se mantienen íntegros en un nodo podado. Los datos que se descartan —las firmas en anillo históricas— no intervienen en el escaneo con clave de visualización de tu cartera ni en la selección de señuelos que esta hace al construir una nueva transacción. Desde la óptica de la cartera, el daemon local es indistinguible de uno archival, y es drásticamente más privado que cualquier nodo remoto sin importar lo fiable que diga ser su operador.

¿Cómo interactúa la poda con FCMP++ ahora que las pruebas de pertenencia están en producción?

El hard fork de noviembre de 2025 introdujo las pruebas de pertenencia de cadena completa junto al esquema existente de firmas en anillo, y la poda trata ambos de manera consistente: conserva cada prueba y cada imagen de clave necesaria para validar la cadena, y descarta solo los bytes redundantes del payload de firmas en anillo que las transacciones antiguas todavía arrastran. Las transacciones post-FCMP++ son ligeramente más pequeñas que las CLSAG heredadas, por lo que la ratio de poda es en realidad marginalmente más favorable en los bloques recientes que en los históricos.

¿Puedo correr un nodo podado enteramente sobre Tor?

Sí, y es un despliegue habitual para quienes quieren tanto eficiencia en disco como privacidad a nivel de red. Añade tx-proxy=tor,127.0.0.1:9050,32 y anonymous-inbound=TUDIRECCIONONION.onion,127.0.0.1:18083,16 en monerod.conf, con el hidden service correspondiente configurado en /etc/tor/torrc. La sincronización inicial por Tor es más lenta — 24–48 horas en lugar de 6–12 — pero la operación en régimen es perfectamente válida, y ganas la propiedad adicional de que ninguna de tus transacciones ni de tus escaneos de cartera toca jamás la clearnet.

Conclusión

Un nodo podado de Monero entrega las garantías completas de privacidad y verificación de un nodo archival con aproximadamente el 40% de la huella en disco, lo que marca la diferencia entre "no me cabe en el portátil" y "esto convive sin problema con todo lo demás". El montaje es un proyecto de una tarde en cualquier máquina moderna, la carga de mantenimiento ronda la hora cada seis meses y el resultado es una base autosoberana para cada transacción de Monero que vayas a enviar o recibir en tu vida. Combina un nodo podado local con un servicio de intercambio sin KYC como MoneroSwapper, y tienes la pila completa: privacidad en la capa de protocolo mediante RingCT y FCMP++, privacidad en la capa de red mediante tu propio daemon, y privacidad en la rampa de entrada mediante intercambios atómicos a tipo fijo que jamás ven tu identidad. El espacio en disco que ahorras es lo de menos; la independencia operativa es la verdadera victoria.