¿Qué es un ataque de gobernanza en crypto y cómo pueden protegerse los protocolos?

¿Qué es un ataque de gobernanza en crypto?

Un ataque de gobernanza es un ataque en el que alguien utiliza o toma el control de la toma de decisiones de una DAO o protocolo para llevar a cabo una acción (normalmente) perjudicial. Una DAO es una organización que toma decisiones mediante reglas en smart contracts y los votos de los participantes.

En muchos protocolos, los tokens determinan cuánto derecho de voto tiene cada persona. Quien acumula suficiente poder de voto puede, por ejemplo, proponer cambios en la configuración, añadir nuevas funciones, actualizar la lógica de un contrato o mover fondos de una tesorería. Una tesorería es, en términos simples, el fondo común de con recursos de un protocolo.

No todo ataque de gobernanza se debe a un error de programación. A veces, un atacante sigue formalmente las reglas, pero acumula suficiente influencia para imponer una propuesta perjudicial para otros usuarios. A eso se le llama governance capture: la toma de decisiones queda, en la práctica, en manos de una sola parte o de un grupo pequeño.

Un posible truco en este contexto es un flash loan. Se trata de un préstamo que debe reembolsarse dentro de la misma transacción de blockchain. Si un protocolo basa el peso de voto en la cantidad actual de tokens en una cartera, sin tiempo de espera ni instantánea histórica, un atacante puede obtener temporalmente mucho poder de voto.

Ejemplo: Supongamos que un protocolo equipara un token con un voto. Alguien toma prestados temporalmente muchos tokens, vota a favor de una propuesta para mover fondos de la tesorería y devuelve el préstamo de inmediato. Si el sistema cuenta esos tokens temporales, eso puede ser suficiente para influir en la votación.

Puntos clave

• Un ataque de gobernanza aprovecha la toma de decisiones de una DAO o protocolo para realizar una acción perjudicial.
• En la gobernanza ponderada por tokens, el número de tokens suele determinar cuánto derecho de voto tiene una persona.
• Un ataque puede aprovechar un fallo técnico, pero también puede producirse dentro de las reglas existentes.
• Los flash loans pueden aportar temporalmente mucho poder de voto si un protocolo utiliza saldos actuales.
• Las propuestas pueden, entre otras cosas, ajustar configuraciones, actualizar contratos o mover activos de la tesorería.

¿Cómo funciona un ataque de gobernanza?

Un ataque de gobernanza suele funcionar porque un atacante primero reúne suficiente poder de voto efectivo, después consigue que se apruebe una propuesta perjudicial y, finalmente, la ejecuta. La forma exacta depende de las reglas del protocolo.

El peso de voto puede provenir, por ejemplo, de los tokens que posee una persona, de votos que otros le delegan, de tokens en staking o de posiciones LP. Una posición LP es su participación en una liquidity pool. El punto crucial es: ¿en qué momento fija el protocolo cuánto derecho de voto tiene cada persona?

A menudo, un ataque se desarrolla de forma aproximada así:

1. Reunir derecho de voto El atacante compra tokens, acumula delegaciones, utiliza poder de voto grande ya existente o toma prestados tokens temporalmente mediante un flash loan.

2. Presentar una propuesta La propuesta contiene una o varias acciones que los smart contracts deben ejecutar. Por ejemplo, pueden ser cambios en la configuración, pero también una actualización o una transferencia desde la tesorería.

3. Ganar la votación La propuesta debe obtener suficientes votos y alcanzar el quorum requerido. Un quorum es la cantidad mínima de participación necesaria para que una votación sea válida.

4. Ejecutar la acción Tras una votación exitosa, la gobernanza ejecuta las transacciones previstas. Sin demora, eso puede ocurrir de inmediato. Con un timelock, la acción debe esperar primero.

Una instantánea histórica ayuda frente a ciertos ataques con flash loans. Una instantánea es, en esencia, una foto de los derechos de voto en un momento anterior y fijo. Un voting delay, es decir, un tiempo de espera antes de que los votos cuenten, solo funciona bien si los tokens prestados temporalmente no aparecen ya en esa instantánea.

Beanstalk muestra cuán grande puede ser el impacto. El 17 de abril de 2022, el protocolo fue atacado mediante gobernanza on-chain. El atacante utilizó un flash loan para comprometer el mecanismo de gobernanza de ese momento y retirar activos de la DAO.

Por cierto, una instantánea no es una solución completa. Si un atacante ya compró o controla los tokens antes del momento elegido, ese poder de voto simplemente cuenta.

¿Qué consecuencias puede tener un ataque de gobernanza?

Un ataque de gobernanza puede hacer que un atacante obtenga dinero, derechos o configuraciones importantes de un protocolo. La gravedad depende por completo de lo que la gobernanza pueda hacer realmente.

En algunos protocolos, la gobernanza puede, entre otras cosas, ajustar configuraciones del sistema, añadir nuevos mercados o funciones y actualizar partes del protocolo. Si la gobernanza también controla proxies importantes, componentes de configuración o contratos de tesorería, una propuesta maliciosa puede causar mucho daño.

Las posibles consecuencias incluyen, entre otras:

• pérdida de activos de la tesorería o de los usuarios;
• acuñación no deseada de nuevos tokens;
• cambios de configuración que perjudiquen a los usuarios;
• modificación de derechos administrativos;
• una actualización hacia lógica de contrato maliciosa;
• la paralización temporal o total de funciones.

En el ataque a Beanstalk, el 17 de abril de 2022 se robaron todos los activos de usuarios que no eran BEAN, por un valor de aproximadamente 77 millones de dólares. Después, el protocolo fue pausado, se eliminó la gobernanza on-chain y cambió la estructura de gobernanza.

El daño suele ser mayor que la pérdida directa. Un protocolo puede tener que migrar a nuevos contratos, pagar auditorías y trabajos de recuperación, y otorgar temporalmente más control de emergencia a un grupo pequeño. Eso puede afectar seriamente la confianza de los usuarios.

¿Cómo puede un protocolo perder el control?

Un protocolo pierde el control, en la práctica, en el momento en que un atacante tiene suficientes derechos sobre los contratos que ejecutan acciones críticas. Piense en el propietario de un proxy, una cuenta que puede realizar actualizaciones, un rol que puede programar propuestas en un timelock o el controlador de la tesorería.

Un proxy es, en términos simples, una dirección de contrato fija que apunta a una determinada versión de la lógica del contrato. En un protocolo actualizable, la gobernanza puede hacer que esa dirección apunte a una nueva lógica. Así, una sola propuesta aprobada puede cambiar de forma importante el funcionamiento del protocolo.

Para ello, un atacante no siempre necesita la mayoría de todos los titulares de tokens. Con baja participación, un quorum bajo o delegaciones muy concentradas, un grupo relativamente pequeño ya puede tener suficiente poder de voto efectivo.

Después de una ejecución maliciosa, la recuperación puede ser aún más difícil. El atacante puede cambiar permisos, desviar activos o incluso modificar las futuras reglas de gobernanza. En ese caso, es posible que la comunidad ya no pueda intervenir por la misma vía, o solo mucho más tarde.

La pérdida de control también puede producirse sin un ataque. Si las cuentas autorizadas de un timelock autogestionado dejan de estar disponibles, un contrato administrado por ese timelock puede quedar bloqueado indefinidamente.

¿Cómo pueden protegerse los protocolos de crypto y DeFi?

Los protocolos de crypto y DeFi pueden reducir el riesgo evitando que el poder de voto, los permisos y la ejecución coincidan demasiado fácilmente en un solo momento. No existe una configuración mágica que detenga todos los ataques, pero varias capas combinadas dificultan el abuso.

Las medidas importantes son:

1. Usar instantáneas y un voting delay Fije el peso de voto en un momento anterior e incorpore un tiempo de espera. Así resulta más difícil conseguir tokens justo antes de una votación y utilizarlos de inmediato.

2. Elegir umbrales de voto adecuados Un mínimo para presentar propuestas dificulta las propuestas de spam baratas. Un quorum evita que una participación muy pequeña decida por sí sola. El equilibrio sigue siendo difícil: umbrales demasiado bajos facilitan la captura, mientras que umbrales demasiado altos pueden volver la gobernanza inoperante.

3. Poner las acciones sensibles detrás de un timelock Las actualizaciones, los grandes cambios de parámetros y las acciones de tesorería no tienen por qué ejecutarse inmediatamente después de una votación. Un timelock da tiempo a los usuarios para revisar una acción prevista y, si lo desean, cerrar su posición.

4. Limitar los derechos por rol No otorgue a la gobernanza poder ilimitado de forma automática. En especial, los derechos para actualizaciones, minting y llamadas externas ilimitadas merecen restricciones adicionales. Los derechos de emergencia deben estar claramente delimitados.

5. Probar las acciones reales de las propuestas No basta con revisar solo el módulo de votación. Los equipos también deben probar y simular las transacciones exactas detrás de una propuesta. Una propuesta puede parecer inocua a grandes rasgos, mientras que las llamadas concretas hacen algo muy distinto.

6. Vigilar las propuestas y el poder de voto La supervisión no evita por sí sola un ataque, pero sí puede hacer que una propuesta sospechosa o un gran cambio en las delegaciones se detecte a tiempo. Un plan de incidentes acordado de antemano ayuda a reaccionar más rápido.

Las auditorías siguen siendo útiles, pero no garantizan la seguridad. No todo ataque de gobernanza se debe a un fallo en el código. Las propuestas engañosas, la baja participación y las transacciones mal evaluadas también pueden causar problemas.

¿Cómo pueden ayudar los timelocks y la gobernanza multisig?

Los timelocks y las multisigs pueden aportar una capa adicional de seguridad, porque evitan que una sola cuenta aprobada o comprometida pueda ejecutar todo de inmediato.

Un timelockcontroller impone un tiempo mínimo de espera entre la programación y la ejecución de una acción importante. Si el timelock es el administrador de un contrato, esa demora también se aplica a acciones que, de otro modo, podrían ocurrir de inmediato con derechos administrativos.

Ese margen de reacción es importante. Los usuarios y los investigadores de seguridad pueden revisar los datos exactos de la transacción antes de que el cambio entre en vigor. Ante una propuesta peligrosa, por ejemplo, los usuarios pueden cerrar su posición antes de que se ejecute la acción. El timelock no invalida automáticamente una acción perjudicial, pero sí le quita velocidad a un ataque visible.

Compound v2, por ejemplo, utiliza varias fases: dos días de revisión, tres días de votación y luego dos días de timelock. Eso hace que un cambio de protocolo tarde como mínimo una semana.

Una multisig funciona de otra manera. En ella, varios propietarios deben confirmar una transacción. En una multisig 3 de 5, se necesitan tres firmas válidas. Una sola clave robada o comprometida no basta para mover fondos o cambiar configuraciones por sí sola.

Una multisig puede, por ejemplo, ser la única parte autorizada para programar acciones en un timelock. Así, primero debe aprobar un grupo de firmantes y, después, comienza el tiempo de espera establecido.

Sin embargo, es importante saber que una multisig traslada la confianza a los firmantes. Si suficientes firmantes conspiran, si se roban demasiadas claves o si los firmantes no están disponibles, siguen surgiendo problemas. También las módulos o extensiones adicionales merecen atención, porque en determinadas circunstancias pueden ejecutar transacciones fuera del control normal de firmas.

¿Cuáles son las limitaciones de la gobernanza en crypto?

La gobernanza en crypto puede ejecutar decisiones de forma transparente y automática, pero el sistema no sabe por sí mismo si una propuesta también es sensata o justa. Una votación on-chain válida solo demuestra que se han seguido las reglas.

En la gobernanza ponderada por tokens, la influencia está vinculada al peso económico. Los grandes tenedores, los fondos y los delegates conocidos pueden tener mucha más influencia que los participantes pequeños, incluso sin ataque ni error en el código. La delegación facilita votar, pero también puede concentrar el poder en un grupo reducido.

La velocidad y la seguridad también chocan a veces. Los periodos de votación más largos y los timelocks dan más tiempo para evaluar bien las propuestas y reaccionar. Al mismo tiempo, retrasan actualizaciones útiles, ajustes y, en ocasiones, también la respuesta a un incidente.

Los quorums y los mínimos para presentar propuestas tienen el mismo intercambio. Si son demasiado bajos, un grupo pequeño pero bien organizado puede tomar decisiones. Si son demasiado altos, las propuestas normales pueden quedar bloqueadas porque vota muy poca gente.

Otro problema es la complejidad. Los datos calldata exactos de una propuesta, una actualización de la lógica del contrato o la interacción entre varios smart contracts son difíciles de evaluar para muchos votantes. Como resultado, una propuesta puede cumplir el procedimiento, aunque pocas personas entiendan realmente lo que ocurre.

Una multisig o un guardian pueden reducir el riesgo de un ataque rápido, pero también añaden riesgos de centralización y disponibilidad. Un guardian es una cuenta o grupo con derechos especiales de emergencia. Si una parte así actúa de mala fe, no está disponible o bloquea transacciones, esa capa de seguridad puede convertirse en un punto débil.

Por tanto, la gobernanza no es una configuración que se ajusta una vez y luego se olvida. La distribución de tokens, las delegaciones, los derechos, los incentivos, el control de propuestas y los procedimientos de emergencia deben revisarse con regularidad.

Conclusión

Un ataque de gobernanza no solo consiste en hackers que encuentran un fallo técnico. También una parte que, según las reglas, acumula suficiente poder de voto puede poner en problemas a un protocolo si la gobernanza tiene demasiados derechos o ejecuta las propuestas demasiado rápido.

Una buena protección se basa en varias capas: instantáneas, un voting delay, umbrales adecuados, permisos limitados, control de las acciones de las propuestas y supervisión. Los timelocks y las multisigs pueden añadir tiempo y control adicionales. En última instancia, la pregunta más importante sigue siendo simple: ¿quién puede cambiar qué y cuánto tiempo tiene el resto para verlo y reaccionar?