Aller au contenu
Financial Context Wiki

Nœud complet

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.

Mis à jour

À 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

Sources

Navigation

Rechercher dans le wiki...