---
title: "Nodo completo"
description: "Guía centrada en la verificación sobre nodos completos, clientes de ejecución y consenso de Ethereum, checkpoints de sincronización, estado actual e histórico, poda, privacidad RPC, finalidad y dimensionamiento operativo."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Nodo completo
> Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.
## Respuesta directa
Un nodo completo descarga los datos exigidos por su protocolo, verifica bloques y transiciones con reglas locales de consenso y ejecución, sigue la cadena elegida por ellas y rechaza datos inválidos sin delegar la decisión en un proveedor RPC. «Completo» describe la responsabilidad de verificación, no conservar cada estado histórico, producir bloques, hacer staking, prestar una API pública ni ser inmune a errores.
En Ethereum proof-of-stake, un nodo completo operativo combina un cliente de ejecución y uno de consenso. El primero valida transacciones y execution payloads, mantiene el estado y expone JSON-RPC; el segundo valida objetos de consenso, aplica fork choice y sigue justificación y finalidad. El cliente validador es opcional y solo se requiere para proponer y atestiguar con validadores en staking.
## Cómo funciona
1. Definir objetivo y snapshot: protocolo, cadena, génesis, forks, `chainId`, hashes actual y finalizado, versiones, sync, checkpoint, poda, métodos RPC, horizonte histórico y disponibilidad. Los requisitos dependen de la cadena.
2. Instalar versiones verificadas e independientes. En Ethereum actual, unir ejecución y consenso mediante Engine API local autenticada; añadir validador solo para staking. Separar directorios, puertos, RPC y claves.
3. Arrancar desde el ancla prevista. Full sync valida desde génesis; snap o checkpoint parte de un estado autenticado reciente y valida hacia delante. Contrastar génesis, checkpoint, chain ID, fork digest y cabecera finalizada por canales independientes.
4. Vigilar ambos pipelines: peers, desfase de head y finalidad, Engine API, state roots, reloj, disco, E/S, memoria, CPU, errores y preparación para forks. “Sincronizado” exige que ambos clientes coincidan y sigan importando datos válidos.
5. Ajustar retención a consultas. Un nodo podado conserva estado actual y datos suficientes, pero puede regenerar o rechazar estados antiguos. Archive materializa estados históricos. Un light client verifica una ruta de compromisos más estrecha y solicita datos: no es un nodo completo pequeño.
6. Exponer la superficie RPC mínima. Mantener APIs administrativas y Engine locales, autenticar, filtrar y limitar; no publicar debug, trace, cuentas o txpool sin controles. Probar `latest`, `safe` y `finalized`, consultas históricas, logs y envío; failover solo a endpoints comprobados.
7. Conciliar y recuperar. Comparar hashes, state roots y checkpoints con otro cliente; ensayar apagado, snapshot, restauración, reconstrucción, upgrades, forks, cambio de disco, pérdida de peers y failover. Separar datos verificados de afirmaciones de frontend, oracle, bridge o aplicación.
## Ejemplos desarrollados
- **Modelo de ancho de banda.** Suponga un bloque cada `12 seconds` y `150 kB` por cuerpo y datos laterales. Son `86,400 / 12 = 7,200 blocks/day` y `7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day` decimales antes de overhead, reintentos, consenso, snapshots o subidas. Son supuestos, no constantes de Ethereum.
- **Margen de disco.** Un nodo podado parte de `1.20 TB` y crece `18 GB/month`. En `30 months` usa `1,200 + 18 * 30 = 1,740 GB`. Reservar `25%` requiere `1,740 * 1.25 = 2,175 GB`, o `2.175 TB` decimal. Cliente, poda y forks pueden romper la proyección.
- **Disponibilidad operativa.** En `30 days = 720 hours`, mantenimiento cuesta `2 hours`, fallo de consenso `3 hours` y apagón compartido `1 hour`, sin solape. Downtime `6 hours`; disponibilidad `(720 - 6) / 720 = 99.1666666667%`. Un proceso activo puede estar obsoleto o particionado.
- **Regeneración histórica.** Un cliente podado tiene snapshot en `18,000,000` y necesita `18,250,000`: reproduce `250,000 blocks`. A `500 blocks/second`, tiempo ideal `250,000 / 500 = 500 seconds = 8.3333333333 minutes`, sin lecturas, recibos, reorgs ni fallos de caché. Archive intercambia almacenamiento por acceso directo.
## Riesgos
- Cadena, génesis, forks o `chainId` incorrectos.
- Checkpoint malicioso, obsoleto o poco contrastado.
- Cliente desactualizado durante un upgrade.
- Desacuerdo EL/CL o pérdida de Engine API.
- Bug del cliente que acepte, rechace o sirva datos erróneos.
- Monocultivo de clientes y fallos correlacionados.
- Pocos peers, eclipse o peers maliciosos.
- Deriva del reloj.
- Disco lleno o lento, filesystem o base corruptos.
- Confundir uptime con sincronización y finalidad.
- Confundir head, safe y finalized en un reorg.
- Esperar toda consulta histórica de un nodo podado.
- Suponer que archive contiene índices y etiquetas off-chain.
- Exponer Engine, admin, debug, trace o txpool sin autenticar.
- Filtrar direcciones, consultas o intención por logs RPC.
- Sobrecarga RPC que prive a la validación.
- Restaurar backups obsoletos o inconsistentes.
- Perder claves por co-localización descuidada.
- Tratar datos verificados como prueba de honestidad externa.
- Aplicar el modelo de Ethereum a otra cadena.
## Errores comunes
- Todo nodo completo es archive y conserva cada estado para siempre.
- Ejecutarlo convierte automáticamente al operador en validador.
- “Sincronizado” implica cadena canónica y finalizada correcta.
- Autoalojar RPC elimina todo riesgo de confianza y privacidad.
- Más disco, peers o uptime demuestran verificación correcta.
## Temas relacionados
- [Cliente ligero](/es/crypto/light-client/)
- [Nodo RPC](/es/crypto/rpc-node/)
- [Raíz de estado](/es/crypto/state-root/)
## Fuentes
- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (consultado: 2026-08-12)
- [Node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/) - Ethereum.org (consultado: 2026-08-12)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consultado: 2026-08-12)
- [Ethereum Archive Node](https://ethereum.org/developers/docs/nodes-and-clients/archive-nodes/) - Ethereum.org (consultado: 2026-08-12)
- [Client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (consultado: 2026-08-12)
- [Sync modes](https://geth.ethereum.org/docs/fundamentals/sync-modes) - go-ethereum (consultado: 2026-08-12)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consultado: 2026-08-12)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consultado: 2026-08-12)
Source: https://wiki.fcontext.com/es/crypto/full-node/index.mdx