Recientemente, Gavin se ha centrado en el tema de los ataques Sybil (resistencia civil). PolkaWorld revisó el discurso de apertura del Dr. Gavin Wood en Polkadot Decoded 2024, explorando algunas de sus ideas sobre cómo prevenir los ataques de Sybil. Si te interesa, ¡sigue leyendo!

¿Qué es un ataque Sybil?

Es posible que ya sepas que he estado trabajando en varios proyectos. Estoy escribiendo un “libro gris” y enfocándome en el proyecto JAM, haciendo algo de trabajo de codificación en el camino. Durante los últimos dos años, he estado pensando mucho en un problema crucial que es bastante significativo en este espacio: cómo prevenir los ataques de Sybil (resistencia civil). Este problema está en todas partes. Los sistemas de blockchain se basan en la teoría de juegos, y al analizar juegos, a menudo necesitamos limitar el número de participantes o gestionar los comportamientos impredecibles que podrían exhibir.

Cuando se diseñan sistemas digitales, queremos determinar si un punto final específico -una interfaz digital- es operado por un ser humano. Para aclarar, no estoy discutiendo la identidad aquí. La identidad es obviamente importante, pero no nos estamos enfocando en determinar la identidad del mundo real de alguien aquí. En cambio, el objetivo es distinguir entre dispositivos y si están siendo operados activamente por un ser humano en cualquier momento dado. Además, surge otra pregunta importante: si un dispositivo está siendo operado por un ser humano, ¿podemos proporcionarles un seudónimo que nos permita identificarlos en un contexto particular, y si regresan para interactuar con nosotros, podemos reconocerlos de nuevo?

A medida que nuestras interacciones han pasado de comunicarnos principalmente con otras personas (en los años 80, cuando nací) a interactuar con sistemas, sistemas digitales en particular, descentralizados de Web3, se han vuelto cada vez más relevantes. En los años 80, las personas interactuaban principalmente directamente con otras personas; en los años 90, comenzamos a interactuar con servicios a través del teléfono, como la banca telefónica. Esto fue un cambio importante para nosotros. Inicialmente, la banca telefónica implicaba grandes centros de llamadas operados por humanos, pero con el tiempo, estos sistemas evolucionaron hacia los sistemas de respuesta de voz automatizados de hoy en día. Con el surgimiento de internet, las interacciones humanas se volvieron más raras y en la mayoría de los servicios diarios, ya no nos comunicamos directamente con humanos. Por supuesto, con el crecimiento del comercio electrónico de Web2, esta tendencia se hizo aún más evidente. Web3 refuerza aún más esto: dentro de Web3, rara vez interactúas con personas. La idea fundamental de Web3 es que interactúas con máquinas y, a veces, las máquinas interactúan entre sí.

¿Por qué importa estudiar los ataques de Sybil?

Entonces, ¿por qué importa esto? Es un elemento fundamental de cualquier sociedad real y se encuentra en el núcleo de muchos sistemas sociales, incluyendo negocios, gobernanza, votación y construcción de consenso. Todos estos dependen en gran medida de prevenir los ataques de Sybil para construir comunidades genuinas. Muchos mecanismos que se dan por sentado en las corporaciones se basan en prevenir los ataques de Sybil. Ya sea el uso justo, control de ruido o gestión de la comunidad, todos dependen de esta capacidad defensiva. Muchas cosas requieren que confirmemos que una entidad es realmente humana. Si alguien se comporta inapropiadamente, es posible que queramos eliminarlos temporalmente de la comunidad. Esto es algo que se puede observar en los servicios digitales, y por supuesto, también existe en el mundo real.

Al prevenir los ataques de Sybil, podemos introducir mecanismos que restrinjan el comportamiento sin aumentar las barreras de entrada o comprometer la accesibilidad del sistema. Por ejemplo, hay dos formas básicas de incentivar el comportamiento: una es a través de un enfoque de "zanahoria y palo" (un sistema de recompensas y penalizaciones). El método del palo (penalización) requiere que pagues un depósito, y si te portas mal, ese depósito es confiscado. El staking es un ejemplo simple de esto. El método de la zanahoria (recompensa) asume que te comportarás bien, y si no cumples con las expectativas, pierdes algunos de tus derechos. Básicamente, así es como operan la mayoría de las sociedades civiles.

Sin embargo, sin mecanismos para prevenir los ataques de Sybil en la cadena de bloques, este enfoque no puede ser realmente aplicado. En la sociedad civil, estos mecanismos funcionan porque, si alguien está encarcelado, no puede cometer el mismo delito de nuevo, al menos, no mientras esté encarcelado. La libertad es un derecho inherente y, en principio, el gobierno puede quitarla. No estoy sugiriendo que encarcelemos a nadie en la cadena, pero actualmente no podemos imponer restricciones similares en la cadena de bloques. Esto hace que sea difícil frenar el mal comportamiento al ofrecer servicios gratuitos, y terminamos confiando solo en fomentar el buen comportamiento. El comercio y las actividades promocionales dependen en gran medida de poder confirmar que los usuarios son personas reales.

Aquí hay una captura de pantalla de un sitio web que a veces uso. Ofrece un whisky muy bueno que a mucha gente le encanta, y es difícil de encontrar en su país de origen. Pero en Europa, es relativamente barato, y parece que mantienen los precios bajos limitando la cantidad de botellas que cada persona puede comprar. Sin embargo, este tipo de operación es casi imposible de hacer cumplir en un sistema Web3 real.

También hay desafíos significativos en la construcción de la comunidad, los airdrops, y la identificación y distribución a los miembros de la comunidad. Los airdrops son generalmente ineficientes en términos de gasto de capital porque buscan cubrir a tantas personas como sea posible. Para distribuir airdrops de manera justa, es necesario identificar a los individuos y dar a todos la misma cantidad. Pero en la práctica, surgen muchos problemas, como los saldos de la billetera variables. Eventualmente, es posible que se encuentre en una situación en la que la curva de distribución se vuelva extremadamente desequilibrada, con grandes disparidades. Como resultado, la mayoría de las personas reciben casi ningún incentivo.

En cuanto al "uso justo", si bien el impacto actual es pequeño, si se abusa de los recursos de red, el sistema simplemente ralentiza la conexión, aunque aún se puede utilizar la red.

Hace 10 o 15 años, si usabas demasiado internet, tu proveedor de servicios de internet (ISP) podía considerar que no estabas utilizando este servicio "ilimitado" de manera responsable. Por lo tanto, te cortaban por completo el servicio en lugar de simplemente ralentizarlo como hacen ahora. Este enfoque les permitía ofrecer servicios de internet casi ilimitados a la mayoría de los usuarios porque podían identificar quién estaba utilizando los recursos de manera responsable.

Web2 se basa en un modelo de servicio avanzado, que depende en gran medida de la capacidad de identificar a los usuarios. Hace veinte años, los mecanismos de identificación eran menos complejos, pero ahora es muy diferente. Si quieres abrir una cuenta, generalmente hay al menos tres formas diferentes de confirmar que eres una persona real y que no te han encontrado antes. Por ejemplo, si intentas registrar una cuenta de Apple sin comprar un iPhone, es como pasar por un circuito de obstáculos. Estas empresas básicamente no están dispuestas a darte una cuenta. Por supuesto, anuncian que puedes obtener una cuenta de forma gratuita, pero no sé qué está haciendo la IA detrás de escena. Me llevó 10 intentos antes de que finalmente tuviera éxito, y al final, todavía tuve que comprar un iPhone.

Creo que si pudiéramos identificar mejor a las personas, muchos procesos como "Oracleización" (verificación de información) serían mucho más fáciles.

Un ejemplo típico de uso de la resistencia de Sybil como una "prueba de humanidad" para la verificación de información en la sociedad es el sistema de jurados. Cuando necesitamos un juez imparcial (es decir, un Oráculo) para determinar la culpabilidad de alguien, el sistema selecciona al azar un número impar de personas comunes de la sociedad para escuchar las pruebas y tomar una decisión. De manera similar, en otras áreas de la vida social, como la representación y la recopilación de opiniones, la representación es una parte importante de la sociedad, y gestionamos la representación utilizando métodos de resistencia de Sybil. Por supuesto, este tipo de gestión no siempre es perfecta debido a las fallas en la infraestructura civil actual, especialmente cuando la representación se confunde con la identidad. A menudo, cuando quieres votar, tienes que demostrar tu identidad real, como mostrar tu licencia de conducir o pasaporte. Pero en realidad, votar representa tus derechos de voto, no un vínculo directo con tu identidad personal.

¿Cómo podemos prevenir los ataques de Sybil? ¿Qué soluciones están actualmente disponibles?

Entonces, ¿cómo podemos abordar esto?

En la era de la Web 2, e incluso antes de eso, teníamos varios métodos para verificar la identidad. En los sistemas Web 2 de hoy en día, estos métodos a menudo se combinan. Por ejemplo, si desea crear una nueva cuenta de Google, es posible que deba pasar un CAPTCHA y verificar tanto su correo electrónico como su número de teléfono. A veces, la verificación por SMS puede sustituir a hablar con una persona real. Si alguna vez has tenido tu cuenta de Amazon bloqueada, sabrás de lo que estoy hablando: se siente como navegar por un laberinto complicado hasta que finalmente presionas el botón correcto para hablar con un verdadero representante de servicio al cliente. Para una prevención de ataques Sybil más avanzada, podríamos confiar en las identificaciones o la información de la tarjeta de crédito.

Sin embargo, cuando nos trasladamos al mundo Web 3, la solución perfecta sigue siendo esquiva. Hay algunas soluciones candidatas, pero difieren enormemente en tres áreas clave: descentralización, protección de la privacidad y resistencia (la capacidad de resistir ataques).

La resiliencia se está convirtiendo en un tema cada vez más importante, y la mayoría de los sistemas enfrentan desafíos en estas áreas.

Un ejemplo es lo que yo llamo el "sistema de confesión", donde revelas tu información privada a una autoridad central. Esta autoridad tiene información sobre ti que quizás no quieres que otros vean. Por ejemplo, podrías escanear tu pasaporte y presentarlo a una institución, dándoles acceso a todos tus datos personales. Esto les da una posición de poder porque controlan información sensible. Este enfoque no es adecuado para la Web 3.

También puedes encontrarte con sistemas que parecen Web 3 pero dependen de “instituciones centralizadas de gestión de claves”. Estas instituciones tienen el poder de decidir quién califica como usuario legítimo controlando las claves. A veces, incluso poseen las claves de los usuarios. En ambos casos, controlan quién es considerado un participante válido.

Este control centralizado sobre la identidad y la privacidad contradice los principios fundamentales de la Web 3, que se centran en la descentralización y la autonomía del usuario.

Simplemente poner algo en cadena no lo convierte en Web 3. Puedes transferir prácticas de la Web 2 o modelos de autoridad centralizados a la cadena de bloques, pero eso no cambia la naturaleza del sistema. Solo lo hace más resistente, pero no lo descentraliza. Una larga dirección hexadecimal no garantiza automáticamente la privacidad. Sin medidas específicas de privacidad, esta cadena aún podría estar vinculada a identidades del mundo real.

Si un sistema depende de un 'mecanismo de confesión', no es una solución que preserva la privacidad. Hemos visto innumerables violaciones de datos que demuestran que almacenar datos detrás de cortafuegos corporativos o hardware de confianza no garantiza la seguridad. Una solución adecuada para la Web 3 no debe centrarse en identidades locales o identidades específicas de la comunidad, sino en identidades globales y descentralizadas. Estos son conceptos completamente diferentes.

Algunos sistemas intentan abordar este problema, pero a menudo dependen de hardware específico y de la gestión centralizada de claves, por lo que no cumplen completamente con los estándares de la Web 3. Por ejemplo, el proyecto Worldcoin intenta abordar esto con hardware confiable, pero depende de un sistema centralizado de gestión de claves y fuente de datos, lo que no se alinea con el ethos descentralizado de la Web 3.

Gitcoin Passport es otro ejemplo. Se utiliza ampliamente en la comunidad de Ethereum como una plataforma de solución de identidad integral. Sin embargo, depende de un sistema de gestión de claves federado, y las fuentes de datos a menudo provienen de entidades centralizadas como Coinbase.

Idena es una solución Web 3 interesante que no utiliza gestión de claves centralizada o autoridades. Sin embargo, es un único mecanismo y con el surgimiento de la IA, no está claro si este enfoque tendrá la resistencia necesaria para el futuro. Hasta ahora, ha funcionado bien, pero solo tiene alrededor de mil usuarios.

En resumen, ninguna solución actual aborda completamente el problema de los ataques de Sybil.

Perspectiva de Gavin sobre la resolución de ataques de Sybil

Cuando se trata de la identidad individual, hay dos enfoques para pensar en ella: remoto y local. Las máquinas no entienden inherentemente la “identidad individual”, y es poco probable que veamos alguna tecnología de cifrado resolver esto repentinamente. Algunos podrían argumentar que las herramientas biométricas como las huellas dactilares podrían hacer que cada ser humano sea único, y las máquinas podrían medir eso, pero es difícil para los sistemas puramente digitales demostrarlo. Lo más cercano a lograr esto podría ser Worldcoin, pero incluso entonces, es solo una máquina que puede verificar a las personas de una manera difícil de engañar.

Por lo tanto, debemos reconocer que la identidad individual se trata más de autenticación. Se trata de cómo los elementos dentro de un sistema digital verifican si otros elementos son personas reales. La pregunta entonces es: ¿en qué se basa esta autenticación? ¿Es el contacto físico o alguna otra forma de prueba? Podríamos confiar en que una cuenta está vinculada a una persona real porque los hemos conocido y suponemos que no han interactuado con nadie más. O tal vez confiamos en la identidad de alguien basándonos en cierta información que vemos en la pantalla, respaldada por otras pruebas.

Cuando hablamos de autenticación remota (autenticación sin prueba física directa), la inteligencia artificial (IA) podría crear complicaciones. Por otro lado, si confiamos en pruebas físicas, la implementación práctica se vuelve desafiante. Así que nos encontramos atrapados entre estas limitaciones. Pero creo que con creatividad e innovación, podemos encontrar soluciones viables.

¿Qué necesitamos hacer?

¿Cuál es la solución? ¿Cuál es el plan?

Para hacer que Polkadot sea más práctico en el mundo real (más allá de solo DeFi, NFT y espacios virtuales de blockchain), la clave es encontrar una forma simple de identificar a las personas. Esto no significa saber quién es alguien, como "Sé que esto es Gavin Wood", sino más bien reconocer "esta es una persona única". No creo que haya una solución única, así que necesitamos un marco modular y escalable.

En primer lugar, podemos integrar soluciones existentes (como Idena). En segundo lugar, el sistema no debe estar limitado por las ideas de una sola persona o basarse únicamente en la visión de un individuo sobre lo que podría funcionar. Debe ser abierto, permitiendo que otros contribuyan a la solución. A continuación, necesitamos una seudonimia contextual sólida. Al principio, escribí "anonimato" y de alguna manera, sí me refiero al anonimato, especialmente al anonimato de tu identidad en el mundo real. Pero al mismo tiempo, queremos una seudonimia, para que en un contexto específico, puedas demostrar que eres una persona única. Además, cuando vuelvas a utilizar el sistema en ese mismo contexto, deberías poder demostrar que eres la misma persona que antes.

Finalmente, necesitamos un SDK y API robustos para que esta funcionalidad sea tan fácil de usar como cualquier otra característica en contratos inteligentes de Substrate o Polkadot, o en el próximo ecosistema JAM. Debe ser simple de implementar. Para ser más específico: si has escrito código de Frame antes, es posible que hayas encontrado una línea como let account = ensure_signed (origin). Esto recupera la fuente de la transacción y verifica si proviene de una cuenta, diciéndome de qué cuenta se trata. Pero una cuenta no es lo mismo que una persona. Una persona puede usar varias cuentas, al igual que un script. Las cuentas no proporcionan información sobre la identidad individual. Si queremos asegurarnos de que una transacción provenga de una persona real, no solo de una de un millón de cuentas, necesitamos reemplazar este código con algo así como let alias = ensure_person (origin, &b”Mi contexto”).

Hay dos beneficios clave en esto. Primero, en lugar de simplemente preguntar si una cuenta está firmando la transacción, estamos preguntando si una persona la está firmando. Esto abre muchas nuevas posibilidades.

En segundo lugar, se llevan a cabo diferentes operaciones en diferentes contextos, y podemos mantener tanto el anonimato como la protección de seudónimos en esos contextos. Cuando cambia el contexto, también lo hace el seudónimo, y los seudónimos en diferentes contextos no pueden ser vinculados o rastreados hasta la persona detrás de ellos. Estos seudónimos son completamente anónimos, lo que los convierte en una herramienta poderosa en el desarrollo de blockchain, especialmente al desarrollar sistemas útiles en el mundo real.

Entonces, ¿qué restricciones podríamos imponer a los mecanismos que identifican a las personas? En primer lugar, estos mecanismos deben ser ampliamente accesibles. Si solo están disponibles para un grupo selecto de personas, no serán muy útiles. No deben requerir poseer activos ni venir con altas tarifas, al menos nada excesivo.

Inevitablemente habrá compensaciones entre diferentes mecanismos. No creo que haya una solución única que sirva para todos. Pero algunas compensaciones son aceptables, mientras que otras no lo son. No debemos comprometer la resistencia, la descentralización o la soberanía del usuario. Algunos mecanismos pueden requerir menos esfuerzo pero más confianza, mientras que otros pueden exigir más esfuerzo pero ofrecer mayor garantía. Debemos tener expectativas realistas de que las personas verificadas por el sistema (ya sean cuentas vinculadas a personas o seudónimos) son realmente únicas, personas reales.

Cuando diferentes mecanismos en los sistemas Web3 descentralizados evalúan la identidad individual, utilizando bases resistentes y no autoritarias, puede haber cierta superposición. Esto significa que no debemos esperar la perfección, pero el margen de error debería ser mucho menor que un orden de magnitud. Además, el sistema debe ser altamente resistente al abuso de identidad para evitar que un pequeño grupo u organización obtenga el control de un gran número de identidades.

Es crucial que el sistema tenga salvaguardas para evitar ese tipo de abuso. Algunos mecanismos podrían ofrecer puntajes de identidad individual de baja confianza, lo que podría ser un objetivo más alto. Algunos podrían tener éxito en lograr esto, otros no, y algunos podrían adoptar un enfoque binario: o confiamos en que la cuenta pertenece a un individuo único, o no lo hacemos. Otros mecanismos podrían sugerir que tenemos un 50% de confianza, lo que significa que el individuo podría tener dos cuentas y estamos 50% seguros de ambas.

Todo esto debe ser sin permisos y relativamente fácil de implementar. No debería tener que enfatizar esto, pero el sistema no debería depender de mecanismos de confesión comunes o instituciones de gestión de claves.

¿Cuál es el beneficio de este enfoque?

¿Por qué deberíamos hacer esto? ¿Cuáles son los beneficios?

Hemos hablado de cómo la sociedad utiliza y depende de identidades individuales, pero ¿cómo se puede aplicar esto en la cadena? Imagina un sistema Polkadot donde las comisiones de transacción no tienen que pagarse, haciendo que el uso razonable sea gratuito. Imagina algo así como una “cadena Plaza” (Plaza), que es esencialmente un Centro de Activos mejorado con capacidades de contrato inteligente y un sistema de participación.

En este tipo de cadena de Plaza, se podría visualizar un escenario en el que no se requieran tarifas de gas. Siempre y cuando utilices el sistema dentro de límites razonables, el gas es gratuito. Por supuesto, si estás ejecutando scripts o realizando un gran número de transacciones, tendrías que pagar tarifas, ya que eso va más allá de lo que haría un usuario típico. Imagina que estos sistemas se abran de forma gratuita al público. Podríamos impulsar eficientemente comunidades utilizando métodos dirigidos como airdrops. Al mismo tiempo, podríamos imaginar modelos de gobierno aún más avanzados para Polkadot.

Personalmente, no estoy del todo convencido de la idea de "una persona, un voto". En algunos casos, es necesario para garantizar legitimidad, pero no siempre produce los mejores resultados. Sin embargo, podríamos considerar modelos de votación alternativos, como el voto cuadrático o el voto regional. En algunos elementos representativos, "una persona, un voto" podría ser bastante esclarecedor.

También podemos imaginar un sistema Oracle similar a un jurado, donde las parachains y los contratos inteligentes pueden utilizar sistemas Oracle locales y subordinados, tal vez para predicciones de precios o resolver disputas de usuarios. También podrían tener un sistema de “gran jurado” o “Tribunal Supremo”, donde los miembros son seleccionados al azar de un grupo conocido de individuos para tomar decisiones, ayudar a resolver disputas y recibir pequeñas recompensas. Dado que estos jurados son elegidos al azar de un grupo neutral y grande, este método ofrecería una forma resiliente y confiable de resolver conflictos.

También podrías imaginar un sistema de control de ruido, especialmente dentro de integraciones descentralizadas de redes sociales, para gestionar el spam y el comportamiento no deseado. En DeFi, podríamos ver sistemas basados en la reputación similares a las puntuaciones de crédito, pero más centrados en si alguien ha fallado en el pago a tiempo. De esta manera, el sistema podría operar en un modelo freemium, ofreciendo diferentes niveles de servicio.

Bien, eso concluye la primera parte de este discurso. Espero que haya sido útil.

Descargo de responsabilidad:

1. Este artículo es un reimpresión de [PolkaWorld]. Los derechos de autor pertenecen al autor original [PolkaWorld]. Si hay alguna preocupación acerca de la reproducción, por favor contacte alequipo Gate Learn, y el equipo abordará el problema tan pronto como sea posible.
2. Aviso legal: Las opiniones y puntos de vista expresados en este artículo son exclusivamente del autor y no constituyen ningún consejo de inversión.
3. Otras versiones del artículo han sido traducidas por el equipo de Gate Learn. A menos queGate.ioSe prohíbe mencionar, copiar, distribuir o plagiar el contenido traducido.