Aller au contenu
Financial Context Wiki

Validateur

Un validateur est une identité de consensus reconnue par le protocole, pas nécessairement une seule machine, opérateur ou propriétaire. Analysez son admission, ses clés, ses devoirs, son poids effectif, ses récompenses, ses sanctions, sa délégation et sa sortie selon les règles exactes du réseau.

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 validateur est une identité qu’un protocole reconnaît comme éligible pour remplir des fonctions de consensus telles que proposer, voter, attester ou finaliser des blocs. Le protocole associe cette identité à des clés, un statut et un poids de vote ou de sélection. La règle précise d’admission, l’ensemble des devoirs et le mécanisme de responsabilité sont spécifiques au réseau : les systèmes de preuve d’enjeu pondèrent couramment les validateurs selon la mise engagée ou effective, tandis que certains systèmes tolérants aux fautes byzantines ou autorisés utilisent un ensemble de validateurs fixe ou gouverné.

Un validateur n’est pas automatiquement la même chose qu’un nœud, une machine, un opérateur, un staker, un délégateur, un pool ou une entité juridique. Un opérateur peut gérer plusieurs identités de validateur ; un validateur peut utiliser plusieurs clients ou machines ; un nœud complet peut vérifier la chaîne sans être autorisé à voter ; et la mise déléguée peut appartenir économiquement à des personnes qui ne contrôlent pas la clé de consensus. Ces distinctions déterminent l’attribution des fautes, la concentration, et qui reçoit ou subit les récompenses et les pertes.

Gardez ces objets séparés :

  • Nœud ou client : Logiciel et infrastructure qui reçoivent, vérifient, exécutent et transmettent les données du protocole ; de nombreux nœuds ne sont pas des validateurs.
  • Identité Validateur : l’enregistrement du protocole ou la clé publique à laquelle sont attachés le statut, les devoirs, le poids, les récompenses et les pénalités.
  • Opérateur Validateur : la personne ou l’organisation contrôlant les systèmes de signature et opérationnels, éventuellement pour de nombreuses identités.
  • Staker ou délégateur : le propriétaire économique ou contributeur de participation ; la délégation attribue généralement un poids sans transférer l’autorité de signature du validateur.
  • Ensemble de validateurs actifs et poids effectif : les identités actuellement éligibles aux devoirs et le poids mesuré par le protocole utilisé dans les calculs de sélection ou de quorum, qui peut différer des soldes bruts des portefeuilles.

Le mot ne signifie pas non plus qu’un validateur décide si une transaction arbitraire est légalement ou économiquement souhaitable. Les nœuds appliquent des règles de validité déterministes. Les participants au consensus aident à sélectionner ou à finaliser une histoire ordonnée parmi des candidats valides. Un bloc valide peut toujours perdre un concours de choix de fourche, et un bloc invalide ne devient pas valide simplement parce qu’un validateur puissant le signe.

Comment analyser un validateur

1. Corrigez le protocole et le jeu de règles

Enregistrez le network, chain ID, le fork ou runtime actif, le bloc ou l’époque, la version client/spécification, et les contrats ou modules de staking pertinents. Les termes validator, nominator, delegator, vote account, et operator ne sont pas interchangeables entre les chaînes Ethereum, Cosmos SDK, Polkadot et Solana. Vérifiez les paramètres en direct et l’état finalisé plutôt que de transférer les règles d’un autre réseau.

2. Résoudre les identités, les clés et le contrôle

Cartographiez l’index du validateur, l’adresse, le vote ou la clé publique de consensus, l’autorité de retrait ou du propriétaire, le destinataire des frais, l’opérateur et le bénéficiaire. Déterminez quelle clé peut signer des messages de consensus, quelle autorisation peut rediriger ou retirer des fonds, et si un signataire à distance, une politique de signature multiple, un dépositaire ou un contrat intelligent se trouve entre eux. Ethereum, par exemple, sépare une clé de signature du validateur des informations d’identification de retrait ; ce modèle de clé n’est pas universel.

3. Tracer l’admission, l’activation et la sortie

Identifier les exigences minimales de mise ou de nomination, les transactions d’enregistrement, les files d’attente de délégation et d’activation, la sélection de l’ensemble actif, les limites de sessions ou d’époques, les limites de rotation, la désolidarisation, la sortie forcée et l’achèvement du retrait. Deposited, bonded, eligible, active, exiting, withdrawable et withdrawn sont des états distincts. Un validateur en file d’attente peut ne rien gagner, tandis qu’un validateur en sortie peut encore avoir des obligations ou être exposé à des pénalités.

4. Énumérer les fonctions et les contraintes de signature

Listez le proposeur, l’attestation, le prevote, le precommit, la disponibilité, l’agrégation, la synchronisation ou d’autres tâches et leurs délais. Pour chaque message signé, enregistrez le domaine, la hauteur ou le créneau, la source et la cible lorsque cela est pertinent, le contexte de fork et la règle anti-équivocation. Distinguez la validité déterministe des blocs du choix de fork et de la finalité. Omettre une tâche, signer en retard, signer un message invalide et signer des messages conflictuels peut avoir des conséquences différentes.

5. Reproduire les calculs de poids effectif et de quorum

Déterminez si le protocole utilise une mise brute, effective stake plafonné, des parts déléguées, une exposition par nomination, la réputation, un validateur-une-vote, ou un autre poids. Réconciliez la mise au niveau du snapshot pertinent, et non le solde actuel du portefeuille. Ensuite, calculez la probabilité de sélection, les seuils de quorum et la concentration par opérateur commun, signataire, cloud, client ou contrôle de gouvernance, plutôt que de simplement compter les enregistrements de validateurs.

6. Réconcilier l’économie et la répartition des pertes

Répartir les flux entrants en émission, frais prioritaires, MEV ou paiements du proposeur, commission de délégation et revenus de services. Détaillez les récompenses manquées, les pénalités ordinaires, les réductions, les effets de sortie forcée, les frais de conservation, les coûts d’infrastructure, les taxes et les assurances. Indiquez si les récompenses se composent automatiquement et si l’opérateur, l’auto-stakeur, le délégateur, le nominator, le détenteur de pool ou le restaker supporte chaque perte.

7. Examiner les opérations et vérifier l’état en chaîne

Vérifiez la garde des clés, l’exclusivité des signataires, la protection contre le slashing, la synchronisation de l’horloge, la connectivité des pairs, la marge sur le disque et la mémoire, la diversité des clients et des emplacements, le fencing en cas de basculement, la restauration des sauvegardes, la surveillance et la réponse aux incidents. Réconciliez les tableaux de bord et les déclarations des fournisseurs avec les blocs finalisés, l’état du validateur, les messages signés, les enregistrements de récompense, les pénalités et l’état des retraits. Les étiquettes de l’explorateur sont des pistes utiles, non des définitions de protocole faisant autorité.

Exemples travaillés

Probabilité et variance d’affectation

Supposons qu’un protocole échantillonne les validateurs en proportion de leur poids effectif. Validateur V a 64 unités sur 3,200,000, donc une opportunité a pour probabilité :

64 / 3,200,000 = 0.00002 = 0.002%.

À travers 100,000 opportunités illustratives indépendantes, les affectations prévues sont lambda = 100,000 * 0.00002 = 2. Sous une approximation Poisson, la probabilité d’obtenir zéro affectation est :

P(0) = exp(-2) = 13.5335%.

Ne recevoir aucune affectation pendant cette fenêtre ne prouve donc pas à lui seul une indisponibilité. Les protocoles réels peuvent échantillonner sans indépendance, attribuer des comités, plafonner les soldes effectifs ou programmer les tâches différemment, il faut donc utiliser leur algorithme de sélection réel.

La vivacité pondérée n’est pas le nombre de validateurs

Supposons que la finalité nécessite strictement plus des deux tiers du poids total des votes et que le snapshot ait 1,000,000 unités. Le plus petit seuil entier est 666,667. Si les validateurs en ligne représentent 655,000, le déficit est :

666,667 - 655,000 = 11,667.

Même si 65 des enregistrements de validateurs 100 sont en ligne, le simple comptage ne peut pas établir le seuil. Inversement, un petit nombre de validateurs à forte pondération peut le satisfaire tout en créant une concentration d’opérateurs et d’infrastructures.

Cascade de récompense et de commission

Pour une période, supposons qu’un validateur gagne 1,800 unités de récompenses du protocole et 300 en frais, subit 60 de pénalités du protocole, et prélève 15% de commission sur les 2,040 restants :

1,800 + 300 - 60 = 2,040.

operator_commission = 2,040 * 0.15 = 306.

delegator_distribution = 2,040 - 306 = 1,734.

Si l’infrastructure et le personnel coûtent à l’opérateur 240, son résultat net illustratif avant impôts est 306 - 240 = 66. Cela suppose que le contrat applique la commission après pénalités aux deux catégories de revenus ; une autre chaîne ou un autre fournisseur peut utiliser une base, un calendrier, un arrondi ou une répartition des pertes différente.

Dossiers contre contrôle commun

Un explorateur montre les enregistrements du validateur 120, chacun avec 32 unités effectives, pour un poids total :

120 * 32 = 3,840.

L’enquête associe les enregistrements 60 à l’opérateur A, 40 à B et 20 à C. Leurs poids effectifs sont 1,920, 1,280 et 640, ou 50%, 33.3333% et 16.6667%. L’interface signale les identités des validateurs 120, mais seulement trois opérateurs connus. Une analyse plus approfondie devrait également regrouper les signataires, clients, clouds et propriétaires bénéficiaires partagés ; le nombre d’enregistrements n’est pas une mesure de décentralisation.

Risques et échecs de révision

  • Modèle de protocole incorrect : une règle provenant d’une autre chaîne, bifurcation, runtime ou contrat de staking peut produire un mauvais statut, devoir ou seuil.
  • Confusion du validateur de nœud : compter les nœuds atteignables comme des validateurs actifs, ou traiter chaque identité de validateur comme une machine séparée, déforme la topologie.
  • Conflation des opérateurs d’identité : un opérateur peut contrôler de nombreuses clés, donc le nombre d’enregistrements peut masquer la gouvernance et la concentration des défaillances.
  • Confusion entre staker et opérateur : La propriété économique déléguée n’inclut pas nécessairement l’autorité de signature ou le contrôle opérationnel.
  • État obsolète : La mise actuelle et le statut de peuvent différer de l’instantané utilisé pour l’affectation, le quorum, les récompenses ou les pénalités.
  • Déséquilibre brut-efficace : Les caps, planchers, incréments d’arrondi, actions et règles de nomination de peuvent rendre les soldes de portefeuille sans importance pour le poids du consensus.
  • Confusion de rôle clé : une clé de consensus, une référence de retrait, un propriétaire de compte, un bénéficiaire de frais et une clé de gouvernance peuvent avoir des pouvoirs différents.
  • Clés de signature dupliquées : deux instances en fonctionnement peuvent équivoquer même lorsque chaque machine semble saine.
  • Basculement non sécurisé : La propriété principale ambiguë de , les verrous périmés ou les sauvegardes restaurées peuvent créer des signatures conflictuelles.
  • Défaut du client : Les bugs de consensus, d’exécution, de signataire ou de middleware de peuvent entraîner des manquements aux devoirs, proposer des données invalides ou corréler des échecs.
  • Défaillances du réseau et de l’horloge : Les partitions , la latence, les conditions d’éclipse ou la dérive de l’horloge peuvent rendre une participation correcte et en temps voulu impossible.
  • Épuisement des ressources : La croissance du disque , de la mémoire, de la bande passante, des descripteurs de fichiers ou de l’état peut dégrader un validateur avant que les tableaux de bord n’indiquent une panne.
  • Infrastructure corrélée : partagé nuages, régions, relais, signataires, clients et plans de contrôle créent un risque en mode commun.
  • Censure et risque politique : Les relais , les opérateurs ou les contraintes légales peuvent exclure certaines transactions ou réduire la neutralité crédible.
  • Conflit MEV : Les incitations au revenu des proposants, à la dépendance des constructeurs et à la réorganisation peuvent diverger des hypothèses de récompense ordinaires.
  • Concentration de la délégation : La mise peut transférer le pouvoir de vote vers quelques opérateurs même si le nombre de délégateurs augmente.
  • Modifications de la commission : Les taux mutables , les mises à jour retardées, les taux promotionnels et les différentes bases de frais peuvent invalider les comparaisons de rendement.
  • Passe en conséquence pour faute et pénalité : Les conditions du fournisseur peuvent attribuer les pertes de protocole aux délégateurs, aux nominateurs ou aux détenteurs de pool.
  • Sortir de l’illiquidité : L’activation, le déliaison, le retrait ou les files d’attente de restaking de peuvent retarder l’accès tandis que l’exposition au prix et aux pénalités continue.
  • Lacunes en matière d’observabilité et d’attribution : Les étiquettes d’explorateur , les divulgations des opérateurs et les clusters de propriété peuvent être incomplets ou incorrects.

Idées reçues

Chaque nœud complet est-il un validateur ?

Non. Un nœud complet peut vérifier et relayer la chaîne sans détenir une identité de consensus active. Un validateur dépend normalement d’un logiciel de nœud, mais le protocole peut représenter un validateur comme une clé ou un enregistrement tandis qu’un opérateur utilise plusieurs machines et clients derrière lui.

Un validateur valide-t-il les transactions par jugement personnel ?

Non. Le logiciel vérifie les transactions et les blocs par rapport aux règles du protocole. Les fonctions de consensus d’un validateurs aident à proposer, sélectionner ou finaliser un historique ordonné. Il ne peut pas rendre valide une transition d’état invalide par préférence, et l’approbation du consensus n’est pas une certification légale, financière ou de fraude.

Est-ce que plus de registres de validateurs signifie toujours plus de décentralisation ?

Non. De nombreux enregistrements peuvent partager un opérateur, un signataire, un bénéficiaire effectif, un client, un cloud, un relais ou une politique de gouvernance. Mesurez le poids de vote effectif et le contrôle commun à travers les domaines de défaillance. Le nombre d’enregistrements n’est qu’une seule observation.

Le rendement de staking annoncé est-il le profit de l’opérateur du validateur ?

Non. Le rendement indiqué peut ignorer le temps d’activation, les devoirs manqués, les pénalités, la commission, l’allocation MEV, la capitalisation, l’infrastructure, la garde, les impôts, les variations du prix du jeton et les périodes inactives ou de délégation non réalisée. Les revenus de l’opérateur et le rendement du délégant sont des flux de trésorerie différents.

Un opérateur peut-il sortir et se retirer immédiatement lorsque le risque augmente ?

Pas nécessairement. Les protocoles peuvent imposer des rotations d’activation, des files d’attente de sortie, des périodes de déliaison, des retraits retardés et une responsabilité continue pour les infractions précédentes. Les contrats de restaking ou de staking liquide peuvent ajouter des files d’attente et des contreparties séparées. Suivez chaque transition d’état et le dernier moment susceptible de sanctions.

Sujets liés

Sources

Navigation

Rechercher dans le wiki...