Nœuds, validateurs et rôles du réseau

Une question de départ

Votre ami dit : « Mon application interroge un nœud, donc elle ne fait confiance à personne. » Est-ce vrai ? Cela dépend entièrement du nœud. Pour répondre, il faut deux questions pour chaque rôle du réseau :

1. Que stocke-t-il ? (tout l'historique, seulement l'état récent, seulement les en-têtes de blocs)
2. Que vérifie-t-il lui-même ? (chaque transaction et chaque transition d'état, ou seulement des preuves et des signatures)

Rappel de l'atelier 110 : un bloc a un en-tête (hauteur, empreinte du bloc précédent, racines de Merkle) et un corps (les transactions). L'état est le tableau des soldes et des données après chaque bloc ; l'en-tête en contient une empreinte, la racine d'état.

Les rôles, un par un

• Nœud complet (full node) : télécharge les blocs, rejoue chaque transaction et vérifie les règles du protocole. Il refuse un bloc invalide même si tout le monde le signe. Il conserve l'état récent et, selon sa configuration, peut élaguer (supprimer) les états anciens.
• Nœud d'archive : un nœud complet qui ne supprime rien : il peut répondre à « quel était le solde de ce compte au bloc 1 200 000 ? ». Il est donc beaucoup plus gros.
• Client léger (light client) : ne garde que les en-têtes (ou même seulement un en-tête récent de confiance). Pour une donnée précise, il demande une preuve de Merkle à un nœud complet et la compare à la racine de l'en-tête. Il ne rejoue pas les transactions.
• Validateur (preuve d'enjeu) ou mineur (preuve de travail) : participe à la production et au vote des blocs. Il doit, pour sa propre sécurité et celle du réseau, être un nœud complet : il ne devrait pas voter sur ce qu'il n'a pas vérifié (le protocole ne l'impose pas toujours : certains mineurs de pool travaillent sur un modèle de bloc fourni par l'opérateur). Il détient en plus une clé de signature qui engage ses fonds.
• Collateur (collator) : terme propre à Polkadot et à ses parachaînes. Il rassemble les transactions d'une parachaîne et prépare les blocs candidats que les validateurs de la chaîne relais vérifient. Il ne sécurise pas la chaîne relais lui-même. Ailleurs, le mot n'existe pas ou désigne autre chose : vérifiez le vocabulaire de chaque réseau.
• Nœud RPC : un nœud complet (ou d'archive) dont l'interface JSON-RPC est ouverte à des applications. C'est un usage du nœud, pas un type de données.

Tableau de synthèse

Exemple détaillé : qui peut répondre ?

Un réseau fictif a 2 000 000 de blocs. Trois questions : (a) « Ce paiement figure-t-il dans le bloc 1 999 990 ? » (b) « Quel était le solde du compte X au bloc 500 000 ? » (c) « Cette transaction respecte-t-elle les règles ? »

• (a) Un client léger peut y répondre avec une preuve de Merkle contre l'en-tête.
• (b) Seule une archive a immédiatement l'état du bloc 500 000 ; un nœud complet élagué l'a supprimé (s'il a gardé les blocs, il pourrait le recalculer en les rejouant, lentement). Un client léger ne peut que demander, et devra croire la réponse sauf si elle vient avec une preuve contre la racine d'état de cet en-tête.
• (c) Seul un nœud qui rejoue la transaction (complet, archive, validateur) la vérifie vraiment.

Ce que cela ne garantit PAS

• Lancer un nœud complet ne vous rend pas validateur : il n'y a ni vote ni récompense sans clé de validation et, en preuve d'enjeu, sans enjeu déposé.
• Un nœud complet ne vous protège pas d'une chaîne valide selon les règles mais fausse : s'il est connecté seulement à des pairs malveillants (attaque d'éclipse), il peut suivre une branche que le reste du réseau ne suit pas. Il vérifie les règles, pas la vérité du monde.
• Les noms ne sont pas normalisés : deux projets peuvent appeler « léger » deux choses différentes.

À retenir

Un rôle se définit par ce qu'il garde et ce qu'il vérifie. Moins il vérifie, plus il délègue de confiance ; moins il garde, moins il coûte.

Le problème

Quatre équipes de Douala et de Yaoundé ont chacune besoin d'un « nœud ». Elles ne devraient pas toutes lancer la même chose. Pour choisir, on part du besoin, pas de la technologie.

Grille de décision

Posez ces quatre questions dans l'ordre :

1. Dois-je vérifier moi-même les règles ? Si une erreur de la source coûte de l'argent (encaisser un dépôt, signer un virement), oui.
2. Ai-je besoin de l'historique ancien ? Soldes passés et traces d'exécution anciennes → archive. Les journaux d'événements anciens sont souvent disponibles sur un nœud complet qui garde les blocs (vérifiez la documentation de la chaîne). Sinon, un nœud complet élagué suffit.
3. Combien de requêtes par seconde ? Une application publique a besoin de plusieurs nœuds derrière un répartiteur de charge, pas d'un seul gros.
4. Quelle machine et quel réseau ai-je ? Un téléphone avec une connexion facturée au volume ne peut pas suivre une chaîne en continu.

Quatre cas

Exemple détaillé : la bande passante d'un nœud

Les chiffres suivants sont fictifs (aucun réseau réel n'est décrit) : un réseau produit un bloc toutes les 6 secondes, chaque bloc pèse 80 Ko.

• Blocs par jour : 86 400 s ÷ 6 s = 14 400 blocs.
• Données de blocs par jour : 14 400 × 80 Ko = 1 152 000 Ko ≈ 1,15 Go.
• Un nœud reçoit aussi les transactions en attente et les messages des pairs. Supposons, pour l'exemple, un surcoût de ×5 : ≈ 5,76 Go par jour, soit environ 173 Go par mois.

Sur une connexion mobile facturée au volume, 173 Go par mois est hors de portée de nombreux budgets. Conclusion pratique : on héberge le nœud chez un fournisseur au volume non facturé ou dans un centre de données, et l'on s'y connecte depuis son téléphone. Le facteur ×5 est une hypothèse de l'exemple : mesurez le vôtre avec les compteurs de l'interface réseau pendant 24 heures.

Temps de synchronisation : deux limites distinctes

Mettre un nœud à niveau demande de télécharger puis de vérifier. Le téléchargement suit le modèle de l'atelier 101 : durée ≈ allers-retours × latence + taille × 8 ÷ débit. Mais la vérification — rejouer les transactions, calculer les empreintes — dépend du processeur et du disque, pas du débit. Une fibre rapide ne rend pas un nœud synchronisé plus vite si son disque est lent.

Ce que cela ne garantit PAS

• Un service RPC public gratuit n'est ni un nœud complet à vous ni un engagement de disponibilité : il peut limiter le débit, filtrer des méthodes ou renvoyer des données en retard.
• « Plus gros » ne veut pas dire « plus sûr ». Un nœud d'archive vérifie exactement les mêmes règles qu'un nœud complet ; il se contente de garder plus.
• Les chiffres de bande passante ci-dessus sont une méthode de calcul, pas une mesure d'un réseau réel.

À retenir

On choisit un nœud en partant du besoin : qui supporte l'erreur ? faut-il le passé ? quel volume de requêtes ? quelle machine ? Et l'on écrit noir sur blanc l'hypothèse de confiance qu'on accepte.

Le problème

Votre équipe veut un nœud d'archive pour un service régional. Le directeur demande : « Combien de disque, et combien d'argent, pour trois ans ? » Une réponse sérieuse est un calcul avec hypothèses écrites, pas un chiffre trouvé sur un forum.

Méthode en quatre étapes

1. Blocs par an = (secondes par an) ÷ (temps entre blocs).
2. Octets par bloc conservés = corps du bloc + variations d'état + index. L'archive conserve l'état passé : le point délicat est de savoir combien d'état change à chaque bloc. On le mesure sur un nœud réel de la chaîne visée.
3. Taille par an = blocs par an × octets par bloc.
4. Marges : espace libre pour que le disque ne soit jamais plein (au moins 20 à 30 %), croissance du trafic, sauvegarde.

Exemple détaillé (réseau FICTIF)

Hypothèses : un bloc toutes les 6 s ; en moyenne 50 Ko de corps de bloc et 30 Ko de variations d'état et d'index par bloc, soit 80 Ko.

1. Blocs par an : 14 400 par jour × 365 = 5 256 000.
2. Taille par an : 5 256 000 × 80 Ko = 420 480 000 Ko ≈ 420 Go par an (Go décimaux).
3. Sur 3 ans, sans croissance du trafic : 3 × 420 = 1 260 Go ≈ 1,26 To.
4. Marge de 30 % d'espace libre : il faut un disque d'au moins 1 260 ÷ 0,7 = 1 800 Go utilisables, donc on achète 2 To.

Si le trafic double après un an, l'hypothèse « sans croissance » est fausse : refaites le calcul par tranche. Une estimation qui ne dit pas comment elle serait fausse n'est pas une estimation.

Coût : le disque n'est pas qu'une capacité

Un nœud lit et écrit en désordre. Le débit d'entrées/sorties (opérations par seconde) compte autant que les téraoctets : un disque mécanique peut être trop lent pour suivre la chaîne. Les clients de nœud recommandent en général des disques SSD, souvent NVMe ; la documentation de votre client donne le minimum.

Dans cet atelier, « estimer le coût de stockage » veut dire estimer la taille de disque à prévoir ; le coût en argent s'obtient en multipliant par un tarif. Pour le budget, additionnez : disque × prix du Go du fournisseur (vous lisez le tarif au moment de l'achat : il change), bande passante, sauvegarde, et le temps d'une personne pour la maintenance. Dans cet atelier, nous n'utilisons aucun prix réel : l'important est la structure du calcul.

Pourquoi tout le monde ne lance pas une archive

Comparons avec un nœud complet élagué. Supposons qu'il ne garde que 100 000 blocs d'état récents : 100 000 × 30 Ko = 3 Go d'état, plus les blocs 5 256 000 × 50 Ko ≈ 263 Go si on les garde tous. L'élagage de l'état ancien fait donc passer l'ordre de grandeur de 420 à environ 266 Go par an dans cet exemple, et surtout il plafonne la partie état. Le nœud complet vérifie les mêmes règles ; il a seulement oublié le passé de l'état. Attention : ce jouet ne compte que les variations d'état par bloc ; l'état courant complet (tous les comptes) vient s'ajouter, et sa taille est une donnée à mesurer, non à déduire de ces variations.

Ce que cela ne garantit PAS

• Le calcul ne dit pas combien de temps prend la synchronisation initiale : elle dépend du processeur, du disque et du réseau.
• La taille ne croît pas toujours de façon linéaire : un changement de protocole, un pic d'usage ou une attaque de spam peut la faire bondir.
• Un nœud d'archive plus gros n'est pas plus « décentralisé » : si peu de gens peuvent se payer le matériel, il y a peu d'archives indépendantes, et l'on retombe sur la confiance envers quelques fournisseurs (voir l'atelier 114).

À retenir

Taille = blocs × octets conservés par bloc, avec une marge d'espace libre. Écrivez vos hypothèses, mesurez-les sur un vrai nœud, et refaites le calcul quand elles changent.

Le problème

Un portefeuille mobile affiche « Solde : 25 000 ». D'où vient ce chiffre ? Si l'application a demandé à un serveur et fait confiance à la réponse, c'est ce serveur qui décide de ce que vous voyez. Un client léger essaie de réduire cette confiance, mais pas de la supprimer.

Le validateur : un nœud complet qui signe

Dans un réseau à tolérance aux fautes byzantines (atelier 108), n validateurs décident à la supermajorité (strictement plus des deux tiers des voix). Avec n = 3f + 1, le réseau tolère f validateurs byzantins et exige un quorum de 2f + 1 votes. Exemple : n = 10, donc f = 3, quorum = 7. Si 3 validateurs sont hors ligne ou malveillants, 7 restent : le quorum est atteignable. Avec 4 validateurs fautifs, il ne l'est plus. Si ce sont 4 pannes franches, la vivacité (liveness) est perdue mais la sûreté (safety) tient ; si ce sont 4 byzantins, la sûreté elle-même n'est plus garantie (elle ne tient que jusqu'à f = 3 byzantins).

Essayez le simulateur de quorum : fixez n, désignez des validateurs fautifs et regardez à partir de quand le quorum n'est plus atteignable.

Un validateur doit tenir deux contraintes opposées :

• Disponibilité : hors ligne, il manque des votes et peut être pénalisé.
• Prudence de clé : sa clé de signature est utilisée en continu, donc stockée sur un serveur connecté. Lancer la même clé sur deux machines « pour la redondance » peut produire deux signatures contradictoires ; dans beaucoup de réseaux à preuve d'enjeu, ce comportement (équivocation, ou double signature) est sanctionné, parfois par la destruction d'une partie de l'enjeu. Les règles exactes dépendent du réseau.

Pratique courante : placer le validateur derrière des nœuds « sentinelles » qui seuls parlent au reste du réseau, et ne jamais exposer sa propre interface RPC.

Ce que délègue un client léger

Le client léger suit les en-têtes. Pour savoir « mon solde vaut 25 000 », il demande à un nœud complet la valeur et une preuve de Merkle qui relie cette valeur à la racine d'état de l'en-tête (atelier 106).

Ce qu'il vérifie :

• que la valeur reçue est bien celle que contient l'état dont la racine figure dans l'en-tête (la preuve se recalcule) ;
• selon le protocole, que l'en-tête est signé par assez de validateurs (preuve d'enjeu) ou porte assez de travail (preuve de travail).

Ce qu'il délègue, donc suppose :

1. L'en-tête de départ est le bon. Il faut un point de départ de confiance : un en-tête embarqué dans l'application, ou la liste des validateurs à un instant donné. Si cet en-tête est faux, tout ce qui suit l'est.
2. Les validateurs qui ont signé ont vérifié. Le client léger n'a pas rejoué le bloc ; il croit qu'un quorum honnête l'a fait. Une majorité malveillante de validateurs pourrait signer un bloc invalide, que seul un nœud complet repérerait.
3. On lui montre la dernière chaîne. Un nœud complet malhonnête peut cacher des blocs récents (valeur à jour manquante) ou, s'il est le seul pair, vous éclipser.
4. L'en-tête de départ est assez récent. Les ensembles de validateurs changent : un en-tête trop ancien peut être signé par des clés qui n'engagent plus d'enjeu.

Si l'application n'obtient aucune preuve et se contente de la réponse du serveur, elle ne délègue pas « un peu » : elle délègue tout à ce serveur.

Exemple : lire une preuve

Dans l'explorateur de Merkle, construisez un arbre de huit feuilles « comptes », cliquez sur une feuille et vérifiez la preuve. Modifiez ensuite la valeur d'une feuille : la racine change, et la preuve ne mène plus à l'ancienne racine. Voilà pourquoi une preuve valide contre l'en-tête fiable protège d'un serveur menteur sur cette donnée. Elle ne protège pas d'un en-tête faux.

Ce que cela ne garantit PAS

• Une preuve de Merkle valide ne prouve pas que l'en-tête est final : sur une chaîne à finalité probabiliste, il peut encore être réorganisé (atelier 109).
• Faire tourner un validateur ne garantit pas l'honnêteté de ses pairs ; seul le seuil 2f + 1 sur n = 3f + 1 borne le nombre de fautifs tolérés.
• Un client léger n'est pas « sans confiance » : il remplace la confiance dans un serveur unique par la confiance dans l'en-tête de départ et dans le quorum de validateurs.

À retenir

Le validateur signe et devrait donc vérifier ; le client léger vérifie des preuves et délègue le reste. Toute délégation est une hypothèse de confiance qu'il faut nommer.