---
title: "Nothing at Stake : équivocation, slashing, finalité et risque des anciennes clés"
description: "Nothing at Stake est le problème d'incitation de la preuve d'enjeu où soutenir des historiques concurrents peut avoir un faible coût marginal. Analysez séparément messages sanctionnables, rendement attendu, intersection des quorums, exécution des preuves, choix de fork et hypothèses de subjectivité faible."
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.
# Nothing at Stake : équivocation, slashing, finalité et risque des anciennes clés
> À 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
Nothing at Stake est un problème d'incitation de la preuve d'enjeu : si produire une signature supplémentaire coûte peu et que le protocole n'impose aucun coût effectif au soutien d'options incompatibles, un validateur peut gagner davantage en aidant chaque historique concurrent plutôt qu'en en choisissant un. Si de nombreux validateurs suivent cette incitation privée, les forks peuvent conserver du soutien, la convergence peut s'affaiblir et un attaquant peut obtenir des signatures qui auraient été coûteuses à reproduire en preuve de travail.
L'expression ne signifie pas que tout système de preuve d'enjeu est dépourvu de budget de sécurité ni que chaque vote sur un fork perdant est fautif. Capital immobilisé, récompenses manquées, slashing, retraits différés, règles de choix de fork et règles de finalité peuvent modifier le rendement. Les messages signés et conflits sanctionnables dépendent du protocole et de sa version ; une mise à jour normale du vote, un message retardé ou un fork honnête temporaire peuvent être autorisés.
Trois questions doivent rester distinctes. Premièrement, un validateur dont la garantie est actuellement immobilisée peut-il équivoquer à faible coût entre des branches récentes ? Deuxièmement, un poids de vote indisponible ou hostile peut-il arrêter la progression sans créer deux historiques finalisés ? Troisièmement, d'anciennes clés peuvent-elles fabriquer un long historique alternatif après que l'enjeu est retirable ? Ces risques d'incitation et de consensus sont liés, mais leurs preuves, seuils et défenses diffèrent.
Ethereum est un exemple utile, pas un modèle universel. Ses spécifications de consensus rendent sanctionnables deux propositions distinctes pour le même slot ainsi que les attestations constituant un double vote ou un vote englobant. Le choix de fork peut ignorer l'influence des validateurs qui équivoquent, tandis que la finalité utilise des votes à supermajorité et des pénalités. D'autres familles de preuve d'enjeu appliquent une sélection des dirigeants, un choix de chaîne, des points de contrôle, des hypothèses de disponibilité ou des modèles formels de sécurité différents.
## Comment analyser Nothing at Stake
1. **Fixez le contexte du protocole.** Consignez `protocol`, `version`, `network`, `epoch`, `slot`, `validator set` et l'heure d'observation. Identifiez les `fork choice`, `finality gadget`, `reward rule`, `penalty rule` et `withdrawal delay` actifs ; l'étiquette « PoS » n'en détermine aucun.
2. **Définissez les actions signées.** Énumérez propositions de bloc, attestations, prévotes, préengagements, certificats ou autres messages et leurs domaines. Distinguez deux messages qui favorisent simplement des descendants différents d'un `double proposal`, `double vote` ou `surround vote` formellement sanctionnable selon les règles citées.
3. **Modélisez le rendement sans pénalité.** Estimez probabilités des branches, récompenses de la branche canonique, coût supplémentaire de signature et de propagation, pots-de-vin, occasions manquées et récompense éventuelle des messages contradictoires. Comparez `EV(honest)` à `EV(equivocate)` au lieu de supposer qu'une faible consommation électrique prouve la rentabilité d'une déviation.
4. **Modélisez la perte exécutoire.** Identifiez solde immobilisé, probabilité de détection, fenêtre de validité des preuves, voie de signalement, risques d'inclusion et de censure, pénalité initiale, pénalité corrélée, éviction, calendrier de retrait et revenus futurs perdus. Une pénalité inscrite dans la documentation n'équivaut pas à une exécution fiable de `slashing evidence`.
5. **Séparez choix de fork et finalité.** Reconstituez comment les derniers votes, les équivocations et le calendrier des messages influencent la tête, puis calculez le poids nécessaire pour justifier ou finaliser des points de contrôle. Analysez `safety threshold` et `liveness threshold` séparément : retenir des votes peut arrêter la finalité sans produire de finalité contradictoire.
6. **Testez les hypothèses sur les anciennes clés et la synchronisation.** Déterminez quand l'enjeu retiré cesse d'être sanctionnable, quel historique finalisé un nœud en ligne rejettera, comment un nœud nouveau ou longtemps hors ligne obtient un `weak-subjectivity checkpoint`, et comment son ancienneté et sa provenance sont vérifiées. C'est le problème de longue portée, pas simplement un double vote récent.
7. **Mettez les opérations et le contrôle à l'épreuve.** Testez clés dupliquées, nœuds de basculement, signataires distants, restauration de base de données, bogues clients, hébergement corrélé, pools de staking, garde déléguée, partitions, attaques par éclipse et censure des preuves. Comptez les voies de contrôle et logicielles indépendantes, pas seulement les identifiants de validateurs.
Le résultat doit être une évaluation versionnée des incitations et du consensus, non un verdict fondé sur le terme. Montrez les messages exacts qu'une clé peut signer, les preuves contradictoires objectivement vérifiables, jusqu'à quand la garantie reste saisissable, quel seuil protège la sécurité, quel seuil permet la progression et quel état fiable est nécessaire à un nœud en synchronisation.
## Exemples chiffrés
### 1. Une stratégie sans pénalité peut favoriser les deux branches
Supposons qu'une seule des deux branches devienne canonique : la branche A avec une probabilité de `0.55` et la branche B avec `0.45`. Une signature sur la branche canonique rapporte `1.00 unit`, tandis qu'une signature sur la branche perdante ne rapporte rien. En ignorant toutes les pénalités et tous les coûts d'exploitation supplémentaires, signer uniquement A donne `EV(A only) = 0.55 * 1.00 = 0.55 units`. Signer les deux donne `EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit`.
Ce calcul illustre le problème d'incitation ; il ne prédit pas un rendement de staking. Il suppose que la signature de la branche canonique est récompensée quelle que soit la branche gagnante, que les actions sont autorisées ou non sanctionnées, que les résultats des branches s'excluent mutuellement et que le validateur ne subit aucune perte de prix, de réputation, de latence ou de revenus futurs.
### 2. Un slashing exécutoire peut inverser le rendement
Conservez la récompense brute canonique de `1.00 unit` et ajoutez un pot-de-vin de `0.02 unit` pour l'équivoque. Supposons qu'une preuve valide atteigne le mécanisme de pénalité avec une probabilité de `0.80` et que la perte totale attribuable soit de `5.00 units`. Le rendement simplifié est `EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units`, inférieur aux `0.55 units` obtenues en signant uniquement A.
Le résultat change si la détection, l'inclusion, la garantie recouvrable ou les revenus futurs diffèrent. Les pénalités réelles peuvent dépendre du solde effectif, des infractions corrélées, du temps et de l'état du protocole. Les opérateurs doivent modéliser une distribution de résultats et confirmer le chemin d'implémentation ; multiplier trois nombres choisis ne prouve pas qu'un système déployé est compatible avec les incitations.
### 3. L'intersection des quorums protège la sécurité mais peut exposer la vivacité
Considérons `100 stake units` et une règle exigeant au moins `67 units` pour un vote de finalité. Deux quorums de ce type se chevauchent d'au moins `67 + 67 - 100 = 34 units`. Deux finalisations contradictoires exigent donc qu'au moins 34 unités participent aux deux certificats de quorum ; un protocole responsabilisant peut rendre cette intersection manifestement sanctionnable.
Le même seuil a une autre conséquence sur la vivacité. Si `34 units` retiennent des votes valides, il ne reste que `66 units`, moins de 67, et la finalité peut s'arrêter. Ces 34 unités ne finalisent pas seules deux branches. Défaillance de sécurité, preuve attribuable et absence de progression ne doivent pas être décrites comme un seul événement.
### 4. Les anciennes clés créent un autre problème de synchronisation
Supposons qu'un nœud en ligne ait finalisé le point de contrôle `epoch 39,900`, tandis qu'un nouveau nœud ne possède aucun état fiable. Un attaquant obtient des clés qui contrôlaient assez d'enjeu vers `epoch 10,000`, après le retrait de ces validateurs et lorsque leur garantie n'est plus saisissable, puis fabrique un historique alternatif jusqu'à `epoch 40,000`. Les signatures historiques bon marché sont pertinentes, mais le slashing des validateurs récents peut ne plus dissuader ces anciennes clés.
Le nœud en ligne rejette un historique en conflit avec sa vue finalisée. Le nouveau nœud a besoin d'un point de contrôle récent authentifié ou d'une règle de protocole équivalente pour distinguer les historiques avant de poursuivre la vérification objective. La subjectivité faible et le calendrier de retrait appartiennent donc à l'examen, tout en restant analytiquement distincts de l'équivoque en direct par des validateurs liés.
## Risques et erreurs d'examen
### Erreurs de protocole et de preuve
- Qualifier de sanctionnable tout vote sur un fork non canonique sans vérifier les champs signés et les domaines exacts.
- Traiter fork, réorganisation, proposition manquée, vote tardif et équivoque démontrable comme des événements interchangeables.
- Appliquer les conditions de proposant et d'attestateur d'Ethereum à un protocole dont les messages ou règles de finalité diffèrent.
- Omettre identité de chaîne, version de fork, epoch ou slot en comparant des signatures prétendument contradictoires.
- Supposer que deux signatures suffisent à prouver une infraction sans identité du validateur, domaines, ascendance et cryptographie valide.
- Confondre influence sur le choix de fork avec justification, finalisation ou règlement au niveau applicatif.
- Lire un théorème de sécurité sans ses hypothèses de synchronie, d'honnêteté, de disponibilité et d'adversaire.
### Erreurs d'incitation et d'exécution
- Dire que les signatures sont bon marché sans chiffrer perte immobilisée, récompenses manquées et revenus futurs.
- Traiter le slashing nominal maximal comme la perte attendue recouvrable dans tout état.
- Supposer que la preuve est toujours observée, propagée, incluse et traitée avant le retrait.
- Ignorer censure du proposant, partitions réseau, isolement par éclipse et expiration de la fenêtre de preuve.
- Utiliser une espérance simplifiée comme preuve alors que probabilités, pots-de-vin et pertes ne sont pas mesurés.
- Ignorer pénalités corrélées, variations du prix du jeton, couvertures, pots-de-vin externes et gains de l'attaque.
- Supposer que l'ancienne clé d'un validateur sorti reste garantie par un collatéral actuellement sanctionnable.
### Erreurs d'exploitation, de concentration et de reprise
- Exécuter la même clé de signature sur des nœuds de basculement sans protection durable et partagée contre le slashing.
- Restaurer le signataire ou la base de données de slashing depuis des sauvegardes périmées et recréer des conflits déjà signés.
- Compter les clés de validateurs comme opérateurs indépendants malgré une garde, un client, un cloud ou un contrôle de gouvernance commun.
- Supposer que les délégants ne supportent aucune perte causée par un opérateur, un pool ou une dépendance au restaking.
- Faire confiance à un unique explorateur, fournisseur ou point de contrôle intégré lors de la reprise d'un nœud longtemps hors ligne.
- Affirmer qu'une forte participation au staking prouve la sécurité sans analyser répartition, seuil et contrôle de l'enjeu.
## Idées reçues
- **La preuve d'enjeu n'expose littéralement rien à un risque.** Un système bien conçu peut exposer le capital immobilisé, les récompenses et la participation future ; il faut savoir si ces coûts sont suffisants et exécutoires pour la déviation concernée.
- **Tout message d'un validateur sur deux forks est un double vote.** La sanction dépend des champs, domaines et règles de conflit du protocole ; les mises à jour honnêtes du choix de fork ont besoin d'une marge.
- **Le slashing garantit le consensus.** Il apporte responsabilité et incitations, mais sécurité et vivacité dépendent aussi des seuils, du réseau, des implémentations, de la sécurité des clés et des hypothèses de comportement honnête.
- **Un tiers de l'enjeu peut finaliser seul deux branches.** Dans un modèle de finalité aux deux tiers, environ un tiers peut généralement arrêter la progression ; une finalité contradictoire exige des supermajorités qui se chevauchent et une participation sanctionnable dans leur intersection.
- **Nothing at Stake et les attaques de longue portée sont identiques.** Les deux exploitent des signatures bon marché, mais l'un concerne le soutien en direct à des branches concurrentes, tandis que l'autre peut employer des clés historiques contre des nœuds sans état fiable récent.
## Sujets associés
- [Preuve d'enjeu](/fr/crypto/proof-of-stake/)
- [Slashing](/fr/crypto/slashing/)
- [Règles de choix de fork](/fr/crypto/fork-choice-rule/)
- [Finalité](/fr/crypto/finality/)
- [Attaques de longue portée](/fr/crypto/long-range-attack/)
## Sources
- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (consulté le 2026-08-19)
- [Formal Barriers to Longest-Chain Proof-of-Stake Protocols](https://economics.princeton.edu/working-papers/formal-barriers-to-longest-chain-proof-of-stake-protocols/) - Princeton University (consulté le 2026-08-19)
- [Ethereum Consensus Specifications: Validator](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/validator.md) - Ethereum Foundation (consulté le 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (consulté le 2026-08-19)
- [Casper the Friendly Finality Gadget](https://eips.ethereum.org/assets/eip-2982/arxiv-1710.09437-Casper-the-Friendly-Finality-Gadget.pdf) - Ethereum Improvement Proposals (consulté le 2026-08-19)
- [Ethereum Proof-of-Stake Attack and Defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consulté le 2026-08-19)
- [Weak Subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (consulté le 2026-08-19)
- [Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol](https://eprint.iacr.org/2016/889) - IACR Cryptology ePrint Archive (consulté le 2026-08-19)
Source: https://wiki.fcontext.com/fr/crypto/nothing-at-stake/index.mdx