---
title: "Attaque Sybil"
description: "Une attaque Sybil permet à un acteur d'obtenir une influence disproportionnée grâce à de nombreuses identités. Découvrez ses usages, son évaluation et ses défenses."
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.
# Attaque Sybil
> À but éducatif uniquement ; ceci ne constitue pas un conseil en investissement. Les protocoles crypto et les systèmes d'identité peuvent échouer ou exclure des utilisateurs légitimes.
## Réponse directe
Une **attaque Sybil** se produit lorsqu'un acteur crée ou contrôle de nombreuses identités et que le système les prend à tort pour des participants indépendants. Il peut alors obtenir davantage de droits de vote, de récompenses, de réputation, d'influence sur le routage ou d'accès que ne devrait en avoir la personne ou l'organisation sous-jacente.
Posséder plusieurs portefeuilles ne constitue pas automatiquement une attaque Sybil. Il faut déterminer si un même contrôleur s'en sert pour contourner une règle supposant un participant indépendant par identité. Plusieurs personnes réelles coordonnant leurs propres identités relèvent plutôt de la collusion.
## Fonctionnement
Un réseau ouvert peut vérifier la signature d'une adresse, mais cela prouve le contrôle d'une clé, pas que l'adresse représente une personne unique ou un opérateur indépendant. Si les identités coûtent peu et que l'influence est comptée par identité, un acteur peut se diviser en une multitude de participants apparents.
L'attaque devient intéressante lorsque le gain supplémentaire dépasse le coût de création, de financement et d'entretien des identités, augmenté du coût attendu de la détection ou des sanctions. L'attaquant peut séparer les circuits de financement, varier les horaires, créer une activité plausible ou recourir à des tiers et à l'automatisation pour masquer les liens.
## Contextes concernés
- **Réseaux pair à pair :** les nœuds de l'attaquant peuvent fausser la découverte des pairs, la réputation, la disponibilité des données ou la vision du réseau présentée à une cible.
- **Gouvernance par jetons :** de nombreuses adresses peuvent simuler un large soutien, mais leur nombre ne protège pas si les votes sont déjà pondérés par les jetons ou la participation déléguée.
- **Airdrops et listes d'autorisation :** un opérateur peut capter des allocations destinées à des utilisateurs distincts, diluer les participants légitimes et fausser les mesures d'usage.
- **Preuve d'humanité et systèmes sociaux :** les fausses identités peuvent manipuler le financement quadratique, les notes, les parrainages, les sondages ou les graphes de confiance.
## Exemple
Imaginons qu'un airdrop attribue 100 jetons à chaque adresse éligible. Un utilisateur exploite 20 adresses et automatise pour chacune l'activité minimale requise. Si elles passent toutes, il reçoit 2,000 jetons, contre 100 pour un utilisateur comparable n'ayant qu'une adresse.
La question économique ne se limite pas à savoir si les 20 adresses partagent un portefeuille de financement. Il faut aussi examiner si la règle récompense le nombre d'identités, le coût nécessaire pour rendre chacune crédible, la solidité des liens observés et le préjudice causé par un faux positif.
## Défenses et compromis
- **Lier l'influence à une ressource rare.** La preuve de travail et la preuve d'enjeu pondèrent la participation par le calcul ou le capital ; multiplier les identités n'augmente donc pas le poids total de la ressource.
- **Vérifier l'unicité ou l'éligibilité.** Pièces officielles, attestations, biométrie, contrôles physiques ou preuves préservant la confidentialité peuvent limiter les doublons, mais créent des risques de confiance, de vie privée, d'accès et de coercition.
- **Analyser les comportements et les relations.** Flux de fonds, horaires, signaux d'appareil ou de réseau et schémas d'activité peuvent révéler des groupes, mais les heuristiques se contournent et peuvent pénaliser familles, équipes ou utilisateurs soucieux de leur vie privée.
- **Concevoir des incitations résistantes aux Sybil.** Les récompenses peuvent dépendre d'une contribution rare, d'un avantage marginal plafonné, du temps ou des résultats plutôt que du nombre brut d'adresses.
- **Prévoir des recours et un règlement différé.** Publier les critères, conserver les preuves, accepter les contestations et retarder la récompense finale réduisent les erreurs irréversibles ; trop dévoiler facilite aussi le contournement.
Aucune défense ne prouve dans tous les contextes que chaque identité correspond à une personne unique. Une conception robuste précise l'unicité recherchée, l'adversaire supposé et les erreurs tolérées.
## Idées reçues
### Un groupe de portefeuilles prouve-t-il qu'une seule personne attaque ?
Non. Un financement commun ou un comportement semblable constitue un indice, pas une preuve. Bourses, dépositaires, familles, équipes et logiciels communs peuvent produire les mêmes motifs. Une sanction importante doit croiser les signaux et permettre un recours.
### Une voix par jeton empêche-t-elle les attaques Sybil ?
Elle empêche de multiplier le poids des jetons en les répartissant simplement entre plusieurs adresses. Elle n'empêche ni la concentration du capital, ni les voix empruntées, ni la capture des délégations, ni la corruption, ni la simulation d'une communauté étendue.
### Le KYC est-il une solution complète ?
Non. Il peut décourager les doublons, mais les documents peuvent être volés ou loués, les prestataires se tromper et les registres centralisés créent des risques de confidentialité et d'exclusion. Le contrôle approprié dépend de ce que le protocole protège.
## Sujets connexes
- [Farming d'airdrops](/fr/crypto/airdrop-farming/)
- [DAO](/fr/crypto/dao/)
- [Attaque de gouvernance](/fr/crypto/governance-attack/)
- [Preuve d'humanité](/fr/crypto/proof-of-personhood/)
- [Preuve d'enjeu](/fr/crypto/proof-of-stake/)
## Sources
- [L'attaque Sybil](https://www.microsoft.com/en-us/research/publication/the-sybil-attack/) - Microsoft Research (consulté le : 2026-08-21)
- [Mécanismes de consensus](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consulté le : 2026-08-21)
- [Référence de l'API](https://docs.world.org/reference/api) - World Documentation (consulté le : 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/sybil-attack/index.mdx