DsChief 1.2: Protección contra los Flash Loans para la Gobernanza Maker

Contexto

El diseño actual del contrato de gobernanza Maker (DsChief) permite utilizar MKR proveniente de flash loans para votar propuestas. Este diseño llevó a que se utilizara un flash loan para aprobar la propuesta ejecutiva del 23 de octubre de 2020. Ya se introdujeron varias mitigaciones a corto plazo para limitar el riesgo de flash loans en la gobernanza en el voto ejecutivo del 30 de octubre de 2020:

  • El retraso de gobernanza se incrementó a 72 horas, dando tiempo adicional para eliminar propuestas elegidas maliciosamente.
  • La gobernanza también ha eliminado la capacidad de congelar oráculos instantáneamente y deshabilitar liquidaciones. Esto evita que un atacante dañe el sistema con flash loans activando cualquiera de estos mecanismos de manera inapropiada.

A mediano plazo, el objetivo es evitar el uso de flash loans en las votaciones, al tiempo que se vuelve a habilitar la capacidad de congelar instantáneamente oráculos y deshabilitar liquidaciones, ya que estas protecciones se agregaron inicialmente como mecanismos de defensa contra otras amenazas. Esta publicación presenta una opción para lograr estos objetivos y describe un proceso de transición a un nuevo DsChief.

Solución Recomendada: DsChief 1.2

Al migrar el sistema a un nuevo DsChief, la votación a través de un flash loan sería imposible. Una vez en su lugar, volveríamos a habilitar de manera segura la capacidad de la gobernanza para votar sobre congelamientos instantáneos de oráculos y activación / desactivación de liquidaciones. Esta actualización se conoce como DsChief 1.2, ya que sería la segunda actualización del diseño original del DsChief. Actualizar el DsChief tiene una serie de beneficios.

Borrador de cambios en el código: https://github.com/makerdao/ds-chief/pull/1 9

Los Flash loans no pueden ser usados para aprobar propuestas

En cada llamada a lock() el MKR en el nuevo chief, registraríamos el número de bloque actual, mientras que al mismo tiempo nos aseguramos de que cualquier llamada correspondiente a free() ocurra en un bloque diferente. La capacidad de llamar a lock() y free() en el mismo bloque es lo que permite usar flash loans con el DsChief. Al evitar que estas llamadas sucedan en el mismo bloque, estamos a su vez evitando que los flash loans se usen con el DsChief .

Aumentar la barrera contra ataques de gobernanza

Al prevenir los flash loans, la gobernanza mitiga los ataques de gobernanza que no requieren jugarse el capital propio. Si bien esto no evita todos los tipos de ataques a la gobernanza, garantiza que existan ciertas barreras económicas que aumentan significativamente la dificultad de dichos ataques.

Cambios de código de bajo riesgo

Esta corrección es fácil de entender con solo 18 nuevas líneas de código en el DsChief. La baja complejidad y la falta de nuevas superficies de ataque eliminan la necesidad de auditorías que requieren mucho tiempo y aumentan la confianza en este enfoque.

Los ataques a la gobernanza a través de flash loans se resuelven por completo antes del DssGov

Cada vez que los equipos de ingeniería se asignan al azar a problemas de emergencia, se retrasa el resto de su hoja de ruta. Esto retrasa la incorporación de colaterales, las liquidaciones 2.0 y la futura actualización del DssGov. Hay una serie de funciones de gobernanza importantes que se incluirán en la futura actualización del DssGov, y dado que la prevención de flash loans es una de las nuevas funciones del DssGov, cualquier tiempo de ingeniería dedicado a backportear esa solución es trabajo duplicado. Algunas de las otras soluciones que exploramos fueron mitigaciones que finalmente también podrían entorpecer la hoja de ruta de ingeniería. Debido a que esta solución no es solo una reducción del riesgo de flash loans, como lo eran las soluciones anteriores, sino que evita los flash loans por completo, podemos estar seguros de que los equipos de ingeniería y otros no serán asignados aleatoriamente a otros vectores de ataque de préstamos flash a la gobernanza.

El retraso de la gobernanza se puede evitar de forma segura según sea necesario

De vez en cuando, la gobernanza puede requerir acceso instantáneo, aunque limitado, para cambiar el Protocolo Maker. Esto se logra a través de módulos de acceso de emergencia que pueden evitar la demora GSM (Módulo de Seguridad de Gobernanza), llamados Moms. Reemplazar el Chief conserva la máxima flexibilidad para congelar subconjuntos de oráculos o activar subconjuntos de cortacircuitos. El OsmMom y FlipperMom existentes se pueden volver a habilitar de manera segura una vez que se reemplaza el Chief, restaurando la funcionalidad completa del módulo de emergencia que se había deshabilitado debido a los problemas de flash loans. Además, esta solución nos permite seguir la misma metodología en el futuro, creando nuevos Moms según sea necesario.

La actualización de DsChief también conlleva una serie de preocupaciones

Todas las soluciones tienen algunos inconvenientes. La actualización del DsChief no es una excepción y viene con las siguientes consideraciones de riesgo:

  • El DsChief debe incluir un umbral de activación (se debe depositar una cantidad mínima de MKR a una dirección en particular para permitir que el Chief ejerza autoridad sobre el sistema; esto es para que la migración sea más segura).
  • La gobernanza Maker debe migrar del DsChief actual al nuevo DsChief; esto implica un período de tiempo durante el cual no se pueden tomar medidas de gobernanza (debido al umbral de activación en el nuevo Chief).
  • Requiere trabajo de UI/UX.
  • Los poseedores de MKR deben tomar medidas (se requieren varias TXs para la migración).

Consideraciones de la migración

Debido al umbral de activación antes mencionado, habrá un período de tiempo durante el cual no se podrán tomar acciones de gobernanza (entre lanzar el spell para cambiar al nuevo Chief y suficiente MKR migrando a él). A continuación, se describe la secuencia exacta de pasos y se consideran los posibles riesgos de la migración (y sus mitigaciones).

Pasos de la migración

  1. Ejecutar el nuevo DsChief.
  2. Escribir y ejecutar un spell que cambie la autoridad para todos los contratos relevantes (Pause, MkrAuthority, OsmMom y FlipperMom) del antiguo DsChief al nuevo DsChief.
  3. Los poseedores de MKR votan el spell como el hat.
  4. El MKR se mantiene en el hat durante el período de retraso de la gobernanza. Esto asegura que no se programen otros spells antes de que se deshabilite el antiguo DsChief, ya sea mediante flash loans o votación normal.
  5. El spell se ejecuta, cambiando la autoridad al nuevo DsChief y dejando al antiguo DsChief impotente.
  6. Los poseedores de MKR migran al nuevo Chief y votan por un hat de activación predesignado (probablemente 0x0). Al realizar este paso después de que se haya desactivado el DsChief actual, se evita el riesgo de una reducción peligrosa de MKR en el hat activo.
  7. Una vez que se ha migrado suficiente MKR, el nuevo DsChief se activa y comienza a gobernar el sistema.

Línea de tiempo

  • revisión de código completa: 13 de noviembre de 2020 (viernes 13)
  • spell completo en la red de kovan: 19 de noviembre del 2020
  • ejecución del DsChief 1.2en la red de kovan: 20 de noviembre del 2020
  • prueba en la red de kovan : 20 de noviembre del 2020
  • encuesta de gobernanza: 23 de noviembre del 2020
  • spell completo en la mainnet: 24 de noviembre del 2020
  • voto ejecutivo del DsChief 1.2en la mainnet: 27 de noviembre del 2020
  • ejecución y migración al DsChief 1.2: del 27 de noviembre del 2020 al 3 de diciembre del 2020

Esto es una traducción libre del artículo original en inglés, gracias a @Lozadaluis12 y @Blimpa por la traducción.

1 Like