Lecciones de DAOv1

API3: El DAO y el Staking, Parte II

Desde su concepción, API3 ha sido gobernado por DAOv1, que ha asegurado los fondos de los inversores, los ingresos de la distribución pública y, lo más importante, la propiedad del contrato del token API3. Incluso ha liderado el gráfico de Deep DAO durante un tiempo

DAOv1 no solo ha sido un útil vehículo para mantener los activos del proyecto para el DAO autoritativo, sino que también ha servido como un campo de entrenamiento para la gobernanza descentralizada de API3. En este artículo, discutiremos lo que hemos aprendido de este proceso.

Las estructuras fractales son el camino a seguir

La escalabilidad de los DAOs a menudo se considera en el contexto de las tarifas de gas. Aunque emitir votos en Ethereum es ciertamente costoso, argumentaría que este no es el principal problema, especialmente para un proyecto con muchas operaciones como el nuestro. La atención de los stakers será un recurso mucho más escaso que su ETH. La escalabilidad organizacional también es otro punto a considerar: ¿cómo puede el DAO de API3 financiar un gran número de grupos que trabajan hacia el objetivo común de resolver el problema de la conectividad de API? La solución a todo esto es adoptar una estructura fractalizada, o dividir el DAO en fragmentos.

Comenzamos con un enfoque más plano en el primer ciclo de operaciones y rápidamente descubrimos que esto obstaculizaba la autonomía, ya que es mucho menos probable que los individuos tomen la iniciativa en grupos grandes (similar al efecto espectador). Migramos rápidamente a una estructura basada en equipos en el segundo ciclo de operaciones, donde un equipo propone un presupuesto para asumir la responsabilidad de una parte específica de las operaciones. Después de que se aprueba la propuesta, el equipo puede utilizar sus fondos como desee y se espera que informe sobre sus resultados. Este modelo se anticipó en el whitepaper, pero fue sorprendente que la necesidad de implementarlo surgiera tan rápidamente.

Estoy contento de decir que los equipos actuales están haciendo un trabajo increíble, y saber que hay múltiples equipos trabajando y entregando constantemente refuerza la confianza. Esto también es muy prometedor para nuestros planes de escalabilidad organizacional en forma de DAOs fractalizados, de los cuales hablaremos más en el próximo artículo.

Dirigir un equipo de DAO requiere emprendimiento

Además de hacer su trabajo, los equipos del DAO deben ser capaces de redactar propuestas convincentes, llevar registros diligentes de gastos y resultados, y cabildear para obtener lo que necesitan para hacer su trabajo. En resumen, dirigir un equipo de DAO requiere espíritu emprendedor. Esto se convierte en un problema si ninguno de los miembros de un equipo tiene esa inclinación y simplemente quieren hacer su trabajo (en lo cual pueden ser muy buenos).

Será interesante ver cuán exigentes serán los miembros del DAO autoritativo en términos de ser convencidos para financiar equipos, y si esto alguna vez obstaculizará las operaciones. Por supuesto, esto tiene dos lados, ya que revisar las operaciones de estos equipos y decidir la posición sobre propuestas similares tampoco será del gusto de todos.

La respuesta a incidentes en cadena por parte del DAO no es una opción confiable

En el contexto de los oráculos, un incidente es una interrupción del servicio o un informe incorrecto debido a un error de software, interrupción generalizada de la infraestructura, ataque, colusión o error humano/de gobernanza centralizada. Hay dos formas principales de responder a estos:

1. En cadena, mediante una transacción que resolverá el problema realizando una modificación o activando un mecanismo alternativo. Esto es rápido y fácil, ya que solo requiere una única transacción.
2. Fuera de cadena, solucionando la causa raíz. Esto requiere coordinar esfuerzos y hará que el problema persista durante al menos unas pocas horas.

La respuesta en cadena generalmente es ejecutada por una sola billetera o un multisig, aunque ambas opciones no son lo suficientemente descentralizadas (y, de hecho, esta centralización es la razón por la que esta opción es rápida y fácil). Además, cualquier falta de transparencia sobre quiénes son las partes autorizadas, en qué base se eligen y cómo los titulares de tokens pueden destituirlas (si pueden), degrada aún más la seguridad del sistema.

Esto plantea la pregunta: ¿no podemos confiar en el DAO para la respuesta a incidentes en cadena? Nuestra experiencia ha demostrado que incluso dentro del círculo más pequeño de DAOv1, es difícil coordinar y aprobar propuestas bajo presión de tiempo. Por lo tanto, en general, no se deben diseñar modelos que dependan de propuestas rápidas y precisas del DAO. Por lo tanto, la respuesta a incidentes en cadena a nivel del DAO autoritativo está descartada.

Cuando se trata de mantenimiento (por ejemplo, agregar un nuevo oráculo de primera parte al dAPI), en el whitepaper hemos especificado equipos de gestión de dAPIs (representados por subDAOs o multisigs) con autoridad programáticamente limitada que llevarían a cabo las interacciones necesarias en cadena. Los mantenedores delegados con autoridad limitada conservan la calidad descentralizada de los servicios proporcionados, sin sufrir los mismos problemas que se derivan de depender del DAO para la microgestión.

Conclusión

En este artículo, hemos discutido lo que hemos aprendido de DAOv1, que en su mayoría han sido validaciones de nuestras suposiciones. En el próximo artículo, hablaremos sobre la estructura organizativa del DAO de API3 de una manera más exhaustiva. Esto incluirá cómo planeamos escalar fractalmente y cuáles serán sus implicaciones tokenómicas.