---
title: "Nœud complet"
description: "Guide axé sur la vérification des nœuds complets, clients d’exécution et de consensus Ethereum, checkpoints de synchronisation, état courant et historique, élagage, confidentialité RPC, finalité et dimensionnement opérationnel."
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.
# Nœud complet
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
Un nœud complet télécharge les données requises, vérifie blocs et transitions selon ses règles locales, suit la chaîne qu’elles sélectionnent et rejette les données invalides sans déléguer cette décision à un RPC. « Complet » décrit la responsabilité de vérification, non la conservation de tout état historique, la production de blocs, le staking, un service public ou l’absence d’erreurs.
Sur Ethereum proof-of-stake, il associe client d’exécution et client de consensus. Le premier valide transactions et payloads, gère l’état et expose JSON-RPC ; le second valide le consensus, applique fork choice et suit justification et finalité. Le client validateur, facultatif, ne sert qu’à proposer et attester avec des validateurs stakés.
## Fonctionnement
1. Définir objectif et snapshot : protocole, chaîne, genèse, forks, `chainId`, hashes courant/finalisé, versions, sync, checkpoint, élagage, RPC, horizon historique et disponibilité.
2. Installer des versions vérifiées. Relier EL et CL par Engine API locale authentifiée ; ajouter un validateur seulement pour le staking. Séparer données, ports, RPC et clés.
3. Démarrer depuis l’ancrage prévu. Full sync valide depuis la genèse ; snap/checkpoint part d’un état récent authentifié. Recouper genèse, checkpoint, chain ID, fork digest et tête finalisée.
4. Surveiller peers, retards, Engine API, state roots, horloge, disque, E/S, mémoire, CPU, erreurs et forks. « Synchronisé » exige accord des clients et import continu.
5. Adapter la rétention aux requêtes. Un nœud élagué conserve l’état courant et les données suffisantes, mais régénère ou refuse certains états anciens. Archive matérialise l’historique. Light client vérifie un chemin d’engagement plus étroit et demande des données.
6. Exposer le minimum RPC. Garder admin/Engine locaux, authentifier et limiter ; ne pas publier debug, trace, comptes ou txpool sans contrôle. Tester `latest`, `safe` et `finalized`, historique, logs et soumission.
7. Rapprocher et restaurer. Comparer hashes, racines et checkpoints ; tester arrêt, restore, rebuild, upgrade, fork, disque, peers et failover. Séparer sortie vérifiée et claims externes.
## Exemples détaillés
- **Bande passante.** Un bloc toutes les `12 seconds` avec `150 kB` produit `86,400 / 12 = 7,200 blocks/day` et `7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day` décimaux avant overhead. Ce sont des hypothèses.
- **Marge disque.** Base `1.20 TB`, croissance `18 GB/month`, sur `30 months` : `1,200 + 18 * 30 = 1,740 GB`. Réserve `25%` : `1,740 * 1.25 = 2,175 GB`, soit `2.175 TB`.
- **Disponibilité.** Sur `30 days = 720 hours`, maintenance `2 hours`, panne CL `3 hours`, courant `1 hour`, sans chevauchement. Downtime `6 hours` ; disponibilité `(720 - 6) / 720 = 99.1666666667%`. Un processus actif peut être obsolète.
- **État historique.** Snapshot `18,000,000`, cible `18,250,000` : rejouer `250,000 blocks`. À `500 blocks/second`, idéal `250,000 / 500 = 500 seconds = 8.3333333333 minutes`, hors E/S, reçus, reorgs et cache.
## Risques
- Mauvaise chaîne, genèse, forks ou `chainId`.
- Checkpoint malveillant ou obsolète.
- Client non mis à jour au fork.
- Divergence EL/CL ou Engine API coupée.
- Bug client et données incorrectes.
- Monoculture et pannes corrélées.
- Peers rares, malveillants ou eclipse.
- Dérive de l’horloge.
- Disque plein/lent ou base corrompue.
- Confondre uptime, sync et finalité.
- Confondre head, safe et finalized.
- Attendre tout l’historique d’un nœud élagué.
- Supposer des index off-chain en archive.
- Exposer Engine/admin/debug/trace/txpool.
- Divulguer adresses, requêtes ou intention.
- RPC prive la validation de ressources.
- Restaurer une sauvegarde périmée/incohérente.
- Perdre les clés cohébergées.
- Confondre chain data et honnêteté externe.
- Appliquer le modèle Ethereum ailleurs.
## Idées reçues
- Tout nœud complet est une archive permanente.
- Exécuter un nœud rend automatiquement validateur.
- « Synchronisé » garantit la bonne chaîne finalisée.
- Un RPC auto-hébergé élimine tous les risques.
- Plus de disque, de peers ou d’uptime prouve la correction.
## Sujets connexes
- [Client léger](/fr/crypto/light-client/)
- [Nœud RPC](/fr/crypto/rpc-node/)
- [Racine d’état](/fr/crypto/state-root/)
## Sources
- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (consulté le 2026-08-12)
- [Node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/) - Ethereum.org (consulté le 2026-08-12)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consulté le 2026-08-12)
- [Ethereum Archive Node](https://ethereum.org/developers/docs/nodes-and-clients/archive-nodes/) - Ethereum.org (consulté le 2026-08-12)
- [Client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (consulté le 2026-08-12)
- [Sync modes](https://geth.ethereum.org/docs/fundamentals/sync-modes) - go-ethereum (consulté le 2026-08-12)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consulté le 2026-08-12)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consulté le 2026-08-12)
Source: https://wiki.fcontext.com/fr/crypto/full-node/index.mdx