---
title: "Preuve d'enjeu"
description: "Preuve d'enjeu est une famille de conceptions de consensus blockchain qui attribue le pouvoir de proposition ou de vote en utilisant la mise placée à risque économique. La sécurité dépend du protocole complet, de la répartition des validateurs, des règles de finalité, des sanctions et des hypothèses de récupération, et pas seulement de la mise."
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.
# Preuve d'enjeu
> À 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
Preuve d'enjeu (PoS) est une famille de conceptions de consensus dans laquelle les validateurs mettent en jeu un actif défini par le protocole à risque économique et reçoivent un poids de proposition ou de vote selon les règles du réseau. Les validateurs honnêtes proposent des blocs, vérifient les transitions d'état et votent sur l'historique de la chaîne. Des messages provablement conflictuels peuvent déclencher des sanctions dans les protocoles qui les mettent en œuvre, tandis que les manquements aux devoirs entraînent généralement des pénalités plus faibles ou la perte de récompenses. La participation est une ressource résistante au Sybil : elle rend l'influence coûteuse à acquérir, mais ne rend pas une transaction invalide valide.
PoS n'est pas un seul algorithme. Les systèmes basés sur des chaînes, tolérants aux fautes byzantines, délégués et nommés diffèrent par l'admission des validateurs, la sélection du leader, le choix des forks, la finalité, la délégation, le déliennement et la punition. Les valeurs spécifiques à Ethereum telles qu'un solde d'activation 32 ETH, des créneaux de 12 secondes et les votes de checkpoint des deux tiers ne sont pas des propriétés universelles de PoS. Toute analyse doit nommer le réseau et la version du protocole.
La revendication de sécurité nécessite également plus que « beaucoup est en jeu ». Elle dépend de qui peut contrôler ou coordonner cette mise, de la fraction nécessaire pour arrêter ou violer le consensus, des hypothèses de synchronisation du réseau, de la diversité des clients, de la sécurité des clés, des règles de points de contrôle et de récupération, et de savoir si des pénalités peuvent réellement être imposées. Une délégation concentrée ou un service commun peut faire en sorte que des milliers de validateurs nominales se comportent comme un seul opérateur.
Les récompenses de staking sont une compensation pour le capital, le travail opérationnel et le risque de protocole, et non un intérêt garanti. Une décomposition utile est :
Taux de mise brut = récompenses annuelles du protocole / mise active moyenne
Rendement net de l'opérateur = récompenses + frais alloués et MEV - pénalités - frais de service - coûts d'exploitation
Le rendement mesuré dans le token mis en jeu est séparé du rendement du marché du token. Les files d'attente d'entrée et de sortie, les périodes de déliement, l'exposition aux pénalités, les taxes, les décotes des tokens de staking liquide et le risque de contrepartie peuvent modifier de manière significative le résultat réalisé par l'investisseur.
## Comment ça fonctionne
Un protocole PoS complet combine un registre de mises, les responsabilités des validateurs, une règle de choix de fourche, une règle de finalité ou de confirmation, des incitations et des procédures de récupération. Les noms et les seuils varient, mais une revue peut suivre sept étapes :
1. **Définir la limite de mise et de validateur.** Identifier l'actif à risque, le solde minimum ou effectif, les règles d'admission des validateurs, le modèle de délégation, la file d'attente d'activation, les informations d'identification de retrait et les entités qui contrôlent réellement les clés de signature.
2. **Sélectionnez les devoirs selon l'aléa du protocole.** Le protocole attribue des propositions de blocs, des attestations, des votes ou du travail de comité. La sélection peut être pondérée par mise, plafonnée par validateur ou médiée par un ensemble de délégués; la part de mise publiée n'est pas toujours identique au poids de vote effectif.
3. **Vérifier les transitions d'état proposées.** Les nœuds complets vérifient indépendamment les signatures, les soldes, l'exécution et les règles de consensus. La participation ou le vote majoritaire d'un validateurs ne peut pas autoriser une transaction qui viole les règles de validité déterministes.
4. **Votez et appliquez le choix de fourche.** Les validateurs signent des messages de protocole concernant les blocs ou les points de contrôle. Lorsque des historiques valides concurrents existent, la règle de choix de fork utilise les messages éligibles et leurs poids pour choisir la tête; les retards du réseau peuvent temporairement produire différentes vues locales.
5. **Atteindre la confirmation ou la finalité.** Certains systèmes offrent une finalité économique explicite après un vote à la supermajorité, tandis que d'autres fournissent une confiance croissante avec la profondeur. La sécurité se demande si des nœuds honnêtes peuvent finaliser des histoires conflictuelles; la vivacité se demande si la chaîne peut continuer à finaliser.
6. **Appliquer les récompenses, les pénalités et le slashing.** L'exécution correcte et ponctuelle des devoirs peut entraîner l'émission, des frais ou d'autres récompenses. L'inactivité peut entraîner la perte de récompenses ou des pénalités. L'équivocation ou d'autres violations prouvables peuvent provoquer l'exclusion et la destruction de la mise, mais les conditions et les montants sont spécifiques au protocole.
7. **Sortir, se retirer et récupérer.** Les validateurs peuvent être confrontés à des files d'attente de sortie, des délais de déliaison ou des périodes de pénalisation après la sortie avant que les fonds ne deviennent transférables. Les clients ont également besoin de points de contrôle fiables ou d'autres procédures de récupération lorsque la subjectivité faible, les historiques à longue portée ou des échecs exceptionnels de consensus s'appliquent.
PoS et la Preuve de Travail utilisent tous deux des ressources rares pour rendre les attaques contre le consensus coûteuses, mais les ressources et les modèles de récupération diffèrent. La PoW dépense continuellement de l'énergie et de la capacité matérielle et fournit généralement un règlement probabiliste. PoS bloque du capital pouvant être réduit (slashable), peut fournir une finalité économique explicite et utilise beaucoup moins de calcul en cours, mais introduit des hypothèses sur la clé du validateur, la concentration des enjeux, le long terme et les points de contrôle. Aucun des deux mécanismes ne garantit par lui-même la décentralisation, la résistance à la censure, des frais bas ou des applications correctes.
Ethereum illustre une implémentation, pas la définition. Ses validateurs attestent des blocs et des points de contrôle, LMD-GHOST sélectionne la tête, Casper FFG finalise les points de contrôle avec des votes représentant au moins les deux tiers de la participation active, et les points de contrôle de faible subjectivité aident un nœud nouveau ou hors ligne depuis longtemps à s'ancrer à un état canonique récent. D'autres réseaux PoS peuvent utiliser des conceptions différentes de comité, de délégation et de finalité.
## Exemples travaillés
### La sélection pondérée par la mise est une attente, pas un calendrier
Supposons qu'un protocole illustratif sélectionne chaque proposeur proportionnellement à la mise effective et dispose de 720 possibilités de proposition par jour. Un opérateur détenant 2 000 unités sur 1 000 000 possède une part de 2 000 / 1 000 000 = 0,2 %. Il reçoit donc en moyenne 720 x 0,2 % = 1,44 proposition par jour. La sélection étant aléatoire, il peut recevoir zéro, une ou plusieurs attributions un jour donné ; la formule ne garantit pas une proposition toutes les 16,7 heures.
### Les récompenses brutes ne sont pas le rendement net
Une position mise en commun représente 32 jetons. En un an, elle reçoit 1,28 jeton de récompenses du protocole et 0,20 jeton de frais attribués, mais perd 0,08 jeton pour indisponibilité. Le service prélève 10 % des récompenses positives : (1,28 + 0,20) x 10 % = 0,148 jeton. La récompense nette est de 1,28 + 0,20 - 0,08 - 0,148 = 1,252 jeton, soit 1,252 / 32 = 3,9125 %, avant matériel, fiscalité et variation du prix du jeton. N'afficher que le taux d'émission de 4 % surestimerait le résultat de l'utilisateur.
### La production de blocs peut continuer tandis que la finalité est en pause
Considérons une règle de finalité de type Ethereum exigeant plus des deux tiers d'une mise active de 1 000 000 d'unités : plus de 666 667 unités environ doivent donc s'accorder. Si des validateurs représentant 340 000 unités se déconnectent ensemble, il ne reste au plus que 660 000 unités disponibles. Des blocs peuvent encore être proposés, mais la supermajorité nécessaire à la finalité manque. Un mécanisme d'inactivité propre au protocole peut réduire le poids inactif au fil du temps ; il n'efface pas l'échec initial de la finalité.
### Une décote du staking liquide ne signifie pas automatiquement un slashing
Un investisseur détient 100 unités d'un jeton de staking liquide représentant une créance sur des actifs stakés. Lors d'un choc de liquidité, le jeton se négocie à 0,96 unité de l'actif de base. Une vente immédiate rapporte 100 x 0,96 = 96 unités, soit une décote de 4 unités ou 4 %. Cette décote peut refléter un délai de sortie, un manque de liquidité ou un risque de contrepartie, même sans slashing de validateur et avec une comptabilité sous-jacente intégralement couverte.
## Risques et contrôles
### Sécurité et vivacité du consensus
- **Contrôle efficace concentré :** Les échanges, pools ou délégués peuvent coordonner plus de participation que ce que le nombre de validateurs suggère. Mesurez le contrôle par l'opérateur, les clés, la gouvernance et l'infrastructure, pas seulement par les adresses.
- **Échec de finalité ou partition :** Mise en jeu hors ligne, bogues clients ou divisions du réseau peuvent arrêter la finalité de la supermajorité tandis que les blocs continuent. Surveillez les points de contrôle finalisés et la santé du protocole, pas seulement la hauteur des blocs.
- **Risque de longue portée et de subjectivité faible :** Les anciens validateurs peuvent construire des anciennes histoires alternatives après que leur mise soit retirée. Démarrez à partir des points de contrôle récents obtenus par des canaux indépendants de confiance lorsque le protocole l'exige.
- **Erreur de seuil spécifique au protocole :** Un tiers, une moitié et deux tiers de chiffres ont des significations différentes selon les protocoles. Lisez la spécification réelle du fork-choice, de la sécurité et de la vivacité avant d'appliquer un seuil.
### Opérations et clés du validateur
- **Double signature pendant la migration :** Exécuter des clés de signature copiées sur deux machines peut créer des votes conflictuels. Utilisez des bases de données de protection contre le slashing, un signataire actif et une procédure de migration contrôlée.
- **Compromis de clé de signature :** Un attaquant peut signer des messages passibles de sanction, censurer ou rediriger des tâches. Isolez les clés du validateur, restreignez l'accès, surveillez les messages et maintenez l'autorité de retrait séparée lorsqu'elle est prise en charge.
- **Temps d'arrêt et pannes corrélées :** Les pannes de puissance, de réseau, de cloud, de client ou de configuration entraînent la perte de récompenses et peuvent déclencher des pénalités d’inactivité plus importantes. Diversifiez les clients et l’infrastructure et testez le basculement sans dupliquer les signataires.
- **Échec des informations d'identification de retrait :** Les clés de retrait perdues, incorrectes ou contrôlées par le fournisseur peuvent bloquer la récupération même lorsque le validateur fonctionne correctement. Vérifiez les identifiants avant le dépôt et maintenez des sauvegardes testées ainsi que des procédures de succession.
### Récompenses, capital et économie de sortie
- **Taux de récompense variable :** Formules d'émission, participation active, exécution des obligations, frais et MEV évoluent dans le temps. Modélisez une gamme de rendements brut et net plutôt que de considérer que le TAP affiché est fixe.
- **Prix du jeton et risque de dilution :** Plus de tokens mis en jeu ne garantissent pas un pouvoir d'achat en fiat plus élevé, et l'émission peut diluer les détenteurs qui ne mettent pas en jeu ou tous les détenteurs. Séparez le rendement libellé en tokens du rendement total du marché.
- **Activation, sortie et délai de désengagement :** La croissance de la file d'attente peut laisser le capital inactif à l'entrée ou indisponible en période de stress. Mesurez chaque étape du cycle de vie et évitez de supposer un rachat immédiat.
- **Pénalité et incertitude de tranchage :** La perte dépend de l'infraction, de la version du protocole et du comportement corrélé. Examinez les règles d'exposition maximale et d'allocation des fournisseurs au lieu de supposer que seules les récompenses sont variables.
### Délégation, garde et staking liquide
- **Défaut du dépositaire ou de l'opérateur :** Un service peut perdre des clés, mal utiliser des fonds, arrêter les retraits ou échouer opérationnellement. Déterminez qui détient l'autorité de signature et de retrait et si les créances sont séparées en cas d'insolvabilité.
- **Risque du contrat intelligent de la piscine :** Les dépôts, la comptabilité, les mises à jour et les files d'attente de retrait peuvent dépendre de contrats au-delà du staking natif. Examinez les autorisations, les audits, les contrôles d'urgence et les dépendances du protocole.
- **Décote du jeton de staking liquide :** Un jeton représentatif peut se négocier en dessous de sa réclamation en raison de la liquidité, de la durée, du slashing ou des préoccupations liées à l’émetteur. Soulignez le prix de sortie du marché séparément du rachat éventuel par le protocole.
- **Concentration de la délégation :** Les utilisateurs de conservent une exposition économique tandis qu'un petit nombre d'opérateurs gagne en influence sur le consensus. Suivez la répartition des participations, les plafonds des opérateurs, les changements de délégation et le pouvoir de gouvernance.
### Censure, mise en œuvre et mesure
- **Censure et concentration MEV :** Les grands opérateurs ou relais courants peuvent exclure ou réorganiser les transactions. Surveillez le comportement d'inclusion et la dépendance aux constructeurs, relais et intermédiaires de politique.
- **Monoculture du client et de la mise en œuvre :** Un bug partagé peut corréler les échecs entre des validateurs autrement indépendants. Utilisez des clients divers et maintenus et comprenez les conséquences des échecs de la majorité des clients.
- **Indicateurs de décentralisation trompeurs :** Le nombre de validateurs, le nombre d'adresses et la mise totale peuvent cacher une propriété ou un hébergement commun. Combinez l'attribution d'entité, les mesures géographiques, client, cloud et de gouvernance.
- **Gouvernance et risque de récupération sociale :** La coordination d'urgence peut être nécessaire après une panne grave, mais la définition du rétablissement canonique peut être contestée. Comprenez le contrôle des mises à niveau, les sources de points de contrôle et le précédent de récupération.
## Idées reçues
### Chaque détenteur de jeton valide automatiquement dans Preuve d'enjeu
Détenir l'actif n'est pas la même chose que faire fonctionner un validateur. L'admission au protocole, les clés, les logiciels, le temps de disponibilité et les responsabilités restent valables. Les délégateurs ou les détenteurs de jetons de staking liquide peuvent transférer le contrôle de vote ou opérationnel à une autre entité et assumer un risque contractuel ou de contrepartie supplémentaire.
### Un montant total misé plus élevé signifie toujours que le réseau est plus sûr
Le coût d'une attaque peut augmenter avec un enjeu précieux, mais la sécurité dépend également de la concentration, de la liquidité, de l'emprunt et de la délégation, de la diversité des clients, des seuils et des règles de récupération. Dix millions d'unités contrôlées de manière indépendante sont différentes de la même quantité contrôlée par un seul opérateur.
### Le rendement du staking est un intérêt sans risque
Les récompenses compensent le blocage du capital, les opérations et l'exposition au protocole. Les pénalités, le slashing, les frais, les files d'attente, les pertes de prix des jetons, les défaillances de contrats intelligents et les risques de garde peuvent dépasser les récompenses. Un APY affiché n'est ni garanti ni directement comparable à un taux sans risque.
### Les validateurs subissent un slashing chaque fois qu'ils se déconnectent
De nombreux protocoles distinguent l'inactivité ordinaire des comportements manifestement conflictuels. Sur Ethereum, les manquements aux devoirs entraînent généralement une perte de récompenses ou des pénalités, tandis que les propositions doubles et les attestations sanctionnables peuvent entraîner un slashing et une expulsion. D'autres réseaux définissent différentes infractions et montants.
### Preuve d'enjeu rend les transactions bon marché et immédiatement finales
Le consensus détermine l'accord sur l'historique valide ; la capacité d'exécution et les marchés de frais déterminent le coût des transactions. La finalité nécessite toujours des votes et du temps définis par le protocole, et elle peut être retardée en cas de participation insuffisante ou de défaillances du réseau, même si les blocs continuent d'apparaître.
## Sujets liés
- [Mécanisme de consensus](/fr/crypto/consensus-mechanism/)
- [Mise en jeu](/fr/crypto/staking/)
- [Entaillant](/fr/crypto/slashing/)
- [Validateur](/fr/crypto/validator/)
- [Preuve de travail](/fr/crypto/proof-of-work/)
## Sources
- [Aperçu de la technologie Blockchain](https://csrc.nist.gov/pubs/ir/8202/final) - NIST (consulté : 2026-08-19)
- [Ouroboros : Un protocole de blockchain Proof-of-Stake prouvablement sécurisé](https://eprint.iacr.org/2016/889) - IACR Archives ePrint de Cryptologie (consulté : 2026-08-19)
- [Preuve d'enjeu (PoS)](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (consulté : 2026-08-19)
- [Récompenses et pénalités de preuve d'enjeu](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (consulté : 2026-08-19)
- [Attaque et défense par preuve d'enjeu Ethereum](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consulté : 2026-08-19)
- [Mise en jeu Ethereum](https://ethereum.org/staking/) - Ethereum.org (consulté : 2026-08-19)
- [Phase 0 -- Validateur Honnête](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Spécifications du consensus Ethereum (consulté : 2026-08-19)
- [Preuve d'enjeu contre preuve de travail](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/pos-vs-pow/) - Ethereum.org (consulté : 2026-08-19)
Source: https://wiki.fcontext.com/fr/crypto/proof-of-stake/index.mdx