Ataques de Gobernanza a DAOs: ¿Qué Son y Cómo Evitarlos?

Muchos proyectos de Web3 permiten a sus usuarios votar en las decisiones. Pero esto abre las puertas a que ocurran ataques de gobernanza que puedan destruir el protocolo…

Esta es una versión traducida y adaptada del artículo “DAO governance attacks, and how to avoid them” publicado por Pranav Garimidi, Scott Duke Kominers y Tim Roughgarden el 28 de julio de 2022 en el blog de A16Z Crypto.

Muchos proyectos de Web3 permiten a sus usuarios votar con un token fungible que puede comprarse y venderse en el mercado. Las votaciones “permissionless” tienen muchas ventajas, como bajar las barreras a la entrada y fomentar la competencia.

Los tenedores de los tokens de un proyecto pueden utilizarlos para votar en una amplia variedad de temas, desde simples ajustes de parámetros hasta transformaciones profundas del proceso de gobernanza. (Para una revisión general de gobernanza de DAOs, ver “Lightspeed Democracy.”).

Pero los sistemas en los que cualquiera puede votar por la mera posesión de un token tienen sus problemas: son vulnerables a ataques de gobernanza en los que un atacante adquiere poder de voto a través de medios legítimos (por ejemplo, comprando tokens en el mercado) y lo utiliza para manipular el protocolo en su propio beneficio.

Como estos ataques ocurren completamente dentro del protocolo, no es posible resolverlos a través de la criptografía. Evitarlos requiere de un buen diseño de mecanismo. Para este fin, hemos desarrollado un marco que permite a las DAOs evaluar el problema y potencialmente responder a los ataques.

Ataques de Gobernanza en la Práctica

Los ataques de gobernanza no son un problema teórico. Ya han ocurrido y seguirán ocurriendo.

En un famoso ejemplo, Steemit, una startup que construía una red social descentralizada en el blockchain Steem, tenía un sistema de gobernanza on-chain controlado por 20 validadores. Los votantes usaban sus tokens STEEM (la moneda nativa de la plataforma) para elegir a los validadores. Mientras que Steemit estaba ganando tracción, Justin Sun había hecho planes para fusionar a la blockchain de Steem con Tron, el protocolo que había fundado en 2018.

Para obtener suficiente poder de voto, Sun compró tokens por una cantidad del 30% de la oferta total a uno de los fundadores de Steem. Cuando los validadores de Steem descubrieron la compra, congelaron los tokens de Sun. A esto le siguió un ida y vuelta público entre Sun y Steem para controlar los tokens suficientes para instalar a sus validadores preferidos.

Tras gastar cientos de miles de dólares en tokens, Sun finalmente se salió con la suya y obtuvo el control de la red.

En otro caso, Beanstalk, un protocolo de stable coin, sufrió un ataque de gobernanza a través de un flash loan. Un atacante tomó un préstamo y adquirió una cantidad suficiente de tokens de gobernanza de Beanstalk como para hacer aprobar inmediatamente una propuesta que le permitía quedarse con 182 millones de dólares de las reservas del proyecto. A diferencia del caso de Steem, el ataque a Beanstalk ocurrió en un único bloque, por lo que terminó antes de que nadie tuviese tiempo de reaccionar.

Si bien estos dos ataques ocurrieron en público, los ataques de gobernanza también pueden realizarse de manera sigilosa a lo largo del tiempo. Un atacante podría crear numerosas cuentas anónimas y lentamente acumular tokens de gobernanza, mientras se comporta como cualquier otro holder para evitar levantar sospechas.

De hecho, dado cuan baja suele ser la participación de votación en muchas DAOs, esas cuentas podrían estar inactivas durante un largo período sin levantar sospechas. Desde la perspectiva de la DAO, esas cuentas anónimas del atacante podrían contribuir a que el poder de votación parezca más descentralizado.

Pero eventualmente, el atacante podría alcanzar cierto umbral a partir del cual sus wallets controlan unilateralmente la gobernanza sin que la comunidad tenga tiempo de responder. De manera similar, actores maliciosos podrían adquirir suficiente poder de voto para controlar la gobernanza cuando la participación es suficientemente baja, y luego intentar hacer pasar propuestas maliciosas cuando los otros tenedores de tokens están inactivos.

Así como las políticas públicas de un gobierno pueden ser capturadas por grupos de interés, la gobernanza de DAOs puede tener resultados subóptimos si no se la estructura correctamente.

Entonces, ¿cómo podemos evitar estos ataques a través del diseño de mecanismos?

El Desafío Fundamental: Indistinguibilidad

Los mecanismos de mercado para la distribución de tokens no pueden distinguir entre los usuarios que quieren hacer una contribución valiosa a un proyecto y los atacantes que quieren destruirlo o controlarlo.

Mientras los tokens puedan comprarse o venderse en un mercado público, ambos grupos son imposibles de distinguir desde el comportamiento: ambos están dispuestos a comprar grandes cantidades de tokens a valores crecientes.

El problema de la indistinguibilidad significa que los diseñadores de protocolos enfrentan trade-offs fundamentales entre descentralizar la gobernanza abiertamente y prevenir ataques que busquen explotar los mecanismos de gobernanza. Mientras más miembros de la comunidad sean libres de ganar poder de gobernanza e influir sobre el protocolo, más fácil es para los atacantes utilizar ese mismo mecanismo para hacer cambios maliciosos.

El problema de la indistinguibilidad ya nos resulta familiar desde el diseño de las redes de blockchain de Proof of Stake. Un mercado altamente líquido del token hace más fácil que los atacantes adquieran una cantidad suficiente como para poner en riesgo las garantías de seguridad de la red.

Sin embargo, una combinación entre incentivos de tokens y diseño de liquidez hace que las redes de Proof of Stake sean posibles. Estrategias similares pueden ayudar a construir protocolos de DAO seguros.

Un Marco para Evaluar y Responder a Vulnerabilidades

Para analizar la vulnerabilidad de diferentes proyectos, utilizamos un marco capturado por la siguiente ecuación:

Para que un protocolo pueda considerarse seguro contra ataques de gobernanza, los beneficios del atacante deberían ser negativos. Al diseñar las reglas de gobernanza de un proyecto, esta ecuación puede utilizarse como guía para evaluar el impacto de diferentes opciones.

Para reducir los incentivos a explotar el protocolo, la ecuación ofrece tres opciones claras: reducir el valor de los ataques, aumentar el costo de adquirir poder de voto y aumentar el costo de ejecutar ataques.

Reduciendo el Valor de los Ataques

Mientras más exitoso se vuelve un proyecto, mayor valor puede obtener un atacante por ejecutar un ataque exitoso. Obviamente, un proyecto no debería sabotear intencionalmente su propio éxito sólo para reducir el valor de un ataque.

Sin embargo, podemos limitar el valor de los ataques limitando el alcance de lo que se puede hacer a través de la gobernanza.

Si la gobernanza sólo permite cambiar ciertos parámetros en un proyecto (ej. tasas de interés en un protocolo de lending), entonces el alcance de un potencial ataque será mucho menor que si la gobernanza permite un control general sobre el smart contract que gobierna a la DAO.

El alcance de la gobernanza puede ser una función del grado de avance del proyecto.

En los primeros tiempos, un proyecto podría tener una gobernanza con poderes más amplios mientras trata de encontrar sus casos de uso. En este caso, la gobernanza estaría fuertemente controlada por el equipo fundador y la comunidad.

A medida que el proyecto madura y que el control se descentraliza, puede tener sentido introducir cierto grado de fricción en la gobernanza — como mínimo, pedir niveles elevados de quorum para las decisiones más importantes.

Aumentar el Costo de Adquirir Poder de Voto

Otra alternativa es intentar hacer más difícil adquirir el poder de voto necesario para un ataque. Mientras más líquido sea un token, más fácil es lograr ese poder de voto.

Esto lleva a la conclusión paradójica de que un proyecto podría tener interés en reducir la liquidez de su token para proteger la gobernanza. Podría intentarse reducir la liquidez de manera directa reduciendo la transabilidad de los tokens en el corto plazo. Pero, en algunos casos, esto podría ser imposible de implementar.

Otra alternativa es reducir la liquidez de manera indirecta. Esto podría hacerse proveyendo incentivos para que los tenedores de tokens tengan menos voluntad de vender. Para esto, pueden tomarse medidas como incentivar el staking o dar a los tokens un valor que va más allá que la pura gobernanza. Mientras más valor tenga el token para los tenedores, mayor será su alineamiento con el proyecto.

Estos beneficios podrían incluir acceso a eventos en persona o experiencias sociales. Este tipo de beneficios tienen un alto valor para los individuos alineados con el proyecto pero no tienen ningún valor para el atacante.

De esta forma, aumentan el precio que debe pagar un atacante para adquirir los tokens: los actuales tenedores tendrán menos voluntad de vender (dado que perderían esos beneficios), lo que tiende a aumentar el precio de mercado.

Aunque el atacante tenga que pagar ese valor mayor, la existencia de esos beneficios no aumenta el valor que el token tiene para el atacante (ya que no planea asistir a esos eventos).

Aumentar el Costo de Ejecutar Ataques

Además de aumentar el costo de obtener poder de voto, es posible introducir fricciones que vuelvan más difícil para un atacante ejercer su poder de voto una vez que ha adquirido los tokens.

Por ejemplo, podríamos exigir cierto tipo de autenticación de usuario para participar en las votaciones como un KYC o algún puntaje de reputación. Incluso podríamos limitar la posibilidad de que un agente sin autenticar pueda adquirir tokens de voto, tal vez pidiendo a actuales validadores que certifiquen la legitimidad de los nuevos votantes.

En cierto sentido, esta es la forma en que muchos proyectos realizan su distribución inicial de tokens. Buscan asegurarse de que sólo agentes de confianza controlen una parte importante del poder de voto. (Muchas soluciones de Proof of Stake utilizan técnicas similares para defender su seguridad — controlando estrictamente quién tiene acceso a estar en los primeros stakers y luego descentralizando progresivamente desde allí.)

Alternativamente, los proyectos pueden hacer que, incluso si un atacante controla una cantidad sustancial del poder de voto, igualmente le resultaría difícil hacer aprobar propuestas maliciosas.

Por ejemplo, algunos proyectos tienen time locks para que una moneda no pueda ser utilizada para votar durante cierto período después de haber sido comprada. Así, un atacante que busque comprar o pedir prestada una gran cantidad de tokens enfrentaría costos adicionales por la espera antes de poder votar — además del riesgo de que los demás miembros descubran el ataque y tomen medidas para frustrarlo.

En este punto, también puede ser útil la delegación de votos. Al dar a los participantes activos pero no maliciosos el derecho a votar en su nombre, los miembros que no quieren tener un rol activo en la gobernanza igual pueden contribuir con su poder de voto para proteger al sistema.

Algunos proyectos usan poderes de veto para permitir que una votación sea postergada por cierto tiempo. Esto sirve para alertar a los votantes inactivos sobre una propuesta potencialmente peligrosa. Bajo este esquema, incluso si un atacante hace una propuesta maliciosa, los votantes tienen la posibilidad de responder y eliminarla.

La idea detrás de estos diseños es dar tiempo a la comunidad para preparar una respuesta ante propuestas maliciosas. Idealmente, las propuestas que estén alineadas con el bien del protocolo no tendrían que enfrentar esta demora.

En Nouns DAO, por ejemplo, el poder de veto lo tiene la Nouns Foundation hasta que la DAO esté lista para implementar un esquema alternativo. Como dice su website: “La Nouns Foundation va a vetar propuestas que introduzcan riesgos legales o existenciales no triviales a la Nouns DAO o la Nouns Foundation.”

Las DAO enfrentan una situación paradójica: deben alcanzar un balance entre permitir cierto nivel de apertura a cambios que vienen de la comunidad mientras que al mismo tiempo impiden que propuestas maliciosas pasen por debajo de la puerta.

A veces basta con sólo una propuesta maliciosa para destruir un protocolo. Por eso, es clave tener una clara comprensión de los trade-offs y los riesgos de aceptar versus rechazar propuestas.

Y por supuesto, también existe un trade-off de alto nivel entre la seguridad de la gobernanza y la posibilidad misma de la gobernanza. Cualquier mecanismo que introduzca fricción para bloquear a un potencial atacante también hace que la gobernanza se vuelva más difícil de usar.

Las soluciones que presentamos aquí caen en un espectro entre una gobernanza completamente decentralizada y sacrificar parcialmente algunos ideales de descentralización para la salud general del protocolo.

Nuestro marco destaca diferentes caminos que los proyectos pueden elegir a medida que se aseguran de que los ataques de gobernanza no sean rentables para el atacante.

Esperamos que la comunidad utilice el marco para desarrollar más mecanismos a través de sus experiencias y hacer que las DAOs sean más seguras en el futuro.