--- title: "Ataque Sybil" description: "Un ataque Sybil permite que un actor obtenga una influencia desproporcionada mediante muchas identidades. Aprende dónde aparece, cómo evaluarlo y cómo elevar su coste." 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. # Ataque Sybil > Solo con fines educativos; no constituye asesoramiento de inversión. Los protocolos cripto y los sistemas de identidad pueden fallar o excluir a usuarios legítimos. ## Respuesta directa Un **ataque Sybil** ocurre cuando un actor crea o controla muchas identidades y el sistema las confunde con participantes independientes. Así puede obtener más poder de voto, recompensas, reputación, influencia sobre el enrutamiento o acceso del que le correspondería a la persona u organización subyacente. Tener varias billeteras no constituye automáticamente un ataque Sybil. Lo decisivo es si un mismo controlador las usa para eludir una regla que supone que cada identidad representa a un participante independiente. A su vez, varias personas reales que coordinan sus propias identidades incurren en colusión, no necesariamente en un ataque Sybil. ## Cómo funciona Una red abierta puede verificar la firma de una dirección, pero eso demuestra el control de una clave, no que la dirección represente a una persona única o a un operador independiente. Si crear identidades es barato y la influencia se cuenta por identidad, un actor puede dividirse en muchos participantes aparentes. El ataque resulta atractivo cuando el beneficio adicional supera el coste de crear, financiar y mantener las identidades, más el coste esperado de detección o sanción. El atacante puede separar las rutas de financiación, variar los horarios, generar actividad verosímil o recurrir a otras personas y a la automatización para ocultar los vínculos. ## Dónde aparece - **Redes entre pares:** los nodos del atacante pueden distorsionar el descubrimiento de pares, la reputación, la disponibilidad de datos o la visión de la red que recibe un objetivo. - **Gobernanza con tokens:** muchas direcciones pueden aparentar un apoyo amplio, pero contarlas no protege si el voto ya se pondera por tokens o participación delegada. - **Airdrops y listas de acceso:** un operador puede cultivar asignaciones destinadas a usuarios distintos, diluir a los participantes legítimos y deformar las métricas de uso. - **Prueba de humanidad y sistemas sociales:** las identidades falsas pueden manipular la financiación cuadrática, las valoraciones, las recomendaciones, las encuestas o los grafos de confianza. ## Ejemplo Supongamos que un airdrop entrega 100 tokens a cada dirección apta. Un usuario opera 20 direcciones y automatiza en cada una la actividad mínima exigida. Si todas son aceptadas, recibe 2,000 tokens, mientras que un usuario comparable con una sola dirección recibe 100. La cuestión económica no es solo si las 20 direcciones comparten una billetera de financiación. También hay que preguntar si la regla premia el número de identidades, cuánto cuesta hacer creíble cada una, qué solidez tienen las pruebas que las vinculan y qué daño causaría un falso positivo. ## Defensas y contrapartidas - **Vincular la influencia a un recurso escaso.** La prueba de trabajo y la prueba de participación ponderan por cómputo o capital; crear identidades no aumenta el peso total de esos recursos. - **Verificar unicidad o elegibilidad.** Credenciales oficiales, atestaciones, biometría, controles presenciales o pruebas que preservan la privacidad pueden frenar duplicados, pero introducen riesgos de confianza, privacidad, acceso y coacción. - **Analizar conducta y relaciones.** Grafos de fondos, horarios, señales de dispositivo o red y patrones de actividad ayudan a detectar grupos, aunque las heurísticas se pueden evadir y perjudicar a familias, equipos o usuarios cuidadosos con su privacidad. - **Diseñar incentivos resistentes a Sybil.** Las recompensas pueden depender de aportes escasos, beneficios marginales limitados, tiempo o resultados, en vez del número bruto de direcciones. - **Permitir recursos y retrasar la liquidación.** Publicar criterios, conservar pruebas, aceptar apelaciones y demorar la recompensa final reduce errores irreversibles; revelar demasiado también ayuda a evadir los filtros. Ninguna defensa demuestra que toda identidad sea una persona única en cualquier contexto. Un buen diseño declara qué unicidad necesita, qué adversario presupone y qué errores está dispuesto a tolerar. ## Errores comunes ### ¿Un grupo de billeteras demuestra que ataca una sola persona? No. La financiación común o una conducta similar son indicios, no pruebas definitivas. Bolsas, custodios, familias, equipos y software compartido pueden producir los mismos patrones. Las sanciones importantes deben combinar señales y ofrecer revisión. ### ¿Un token, un voto evita los ataques Sybil? Evita multiplicar el peso de los tokens solo repartiéndolos entre direcciones. No evita la concentración de capital, el voto prestado, la captura de delegaciones, los sobornos ni el uso de muchas direcciones para fingir amplitud comunitaria. ### ¿El KYC es la solución completa? No. Puede desalentar cuentas duplicadas, pero los documentos se roban o alquilan, los proveedores se equivocan y los registros centralizados crean riesgos de privacidad y exclusión. El control adecuado depende de qué protege el protocolo. ## Temas relacionados - [Cultivo de airdrops](/es/crypto/airdrop-farming/) - [DAO](/es/crypto/dao/) - [Ataque de gobernanza](/es/crypto/governance-attack/) - [Prueba de humanidad](/es/crypto/proof-of-personhood/) - [Prueba de participación](/es/crypto/proof-of-stake/) ## Fuentes - [El ataque Sybil](https://www.microsoft.com/en-us/research/publication/the-sybil-attack/) - Microsoft Research (consultado: 2026-08-21) - [Mecanismos de consenso](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (consultado: 2026-08-21) - [Referencia de la API](https://docs.world.org/reference/api) - World Documentation (consultado: 2026-08-21) Source: https://wiki.fcontext.com/es/crypto/sybil-attack/index.mdx