Escalamiento fractal de API3

API3: El DAO y el Staking, Parte III

En ausencia de un mecanismo de consenso, la inmutabilidad es necesaria para que los contratos inteligentes sean confiables. Los DAOs suelen utilizarse para proporcionar esta funcionalidad de consenso a nivel de contratos inteligentes, permitiendo actualizar parámetros de una aplicación descentralizada e incluso mejorar contratos completos sin recurrir a la centralización. Aunque esta es la razón principal de existencia para la mayoría de los DAOs, hoy estamos experimentando con un caso de uso mucho más impactante.

API3 es una solución de oráculos de primera parte, lo que requiere operaciones significativas de negocio e integración — en el mundo real, el "espacio físico", no en el espacio blockchain — además del desarrollo de software y marketing que los proyectos blockchain tienden a realizar. Para que API3 cumpla sus objetivos, esta amplia variedad de operaciones deberá ejecutarse a una escala masiva. Pocos entes en el espacio blockchain necesitan abarcar tanto terreno, pero paradójicamente, optan por medios centralizados para lograrlo. En contraste, la visión de API3 prevé que no sea una entidad centralizada, sino un conglomerado descentralizado, el que pueda alcanzar la escala necesaria para resolver el problema de conectividad de las API.

La segunda funcionalidad, mucho menos explorada, de un DAO es ser un bloque de construcción para una organización infinitamente escalable. Cuando el producto es uno que facilita la conectividad, su valor depende del número de desarrolladores de negocio que estén trabajando (no solo hablando con proyectos blockchain, sino, más importante, con empresas y negocios), las integraciones que los ingenieros implementen y los productos útiles que se construyan con estas. Una organización centralizada no puede alcanzar una escala que sirva a todas las cadenas, todas las API y todos los casos de uso. En ese caso, las ineficiencias de la descentralización serán ampliamente superadas por su escalabilidad hacia el dominio del mercado.

Escalabilidad de los DAOs

La escalabilidad de los DAOs a menudo se discute en términos de costos de gas. Sin embargo, cuando se trata de cooperación humana, la capacidad tribal y la escasez de atención son factores limitantes igualmente válidos. Independientemente de cuál se considere la causa raíz, los DAOs no son escalables por defecto. Nuestra solución propuesta es que el DAO autoritativo de API3 actúe como el órgano de gobierno más alto, con entidades adicionales fragmentandose hacia afuera.

Actualmente, el DAOv1 se escala en forma de equipos operativos. Por ejemplo, el equipo técnico central presenta una propuesta de presupuesto al DAO y recibe los fondos en un multisig controlado por tres miembros sénior. Este multisig se utiliza para financiar a los desarrolladores y los servicios técnicos que recibe el DAO, y los resultados se informan al público en forma de actualizaciones de desarrollo mensuales. Puede decirse que el equipo técnico central ya es un mini-DAO en el sentido de que recibe propuestas (o facturas) de partes externas, negocia precios/salarios y los acepta/niega sin tener que escalarlos al DAOv1.

Por las mismas razones por las que API3 está gobernado por un DAO, una subsidiaria cuyo presupuesto e influencia superen un cierto nivel debería estar gobernada por un DAO propio (al que nos referiremos como un subDAO). Por lo tanto, la estructura organizativa que estamos proponiendo no es de un único DAO, sino de múltiples DAOs con diferentes interrelaciones. Cabe mencionar que los DAOs existentes también pueden añadirse a este ecosistema mediante un intercambio de tokens u otras herramientas teóricas de juego.

¿Para qué sirve un subDAO?

Debemos aclarar que formar un DAO de desarrolladores principales de API3 no es el objetivo, ni creemos que sea productivo. El esquema de subDAO es adecuado para lograr un objetivo distintivo y de alto nivel, mientras que el equipo técnico principal es más una extensión del DAO de API3. Dicho esto, analicemos dos tipos potencialmente útiles de subDAOs de API3.

El objetivo de API3 es operar de manera nativa en todas y cada una de las plataformas de contratos inteligentes donde haya demanda de sus servicios. Esto presenta dos problemas:

1. Hay muchas plataformas de contratos inteligentes donde existe demanda de los servicios de API3. De hecho, la mayoría de estas plataformas carecen de cualquier tipo de servicio de oráculo, ya que las soluciones de oráculos tienen dificultades para escalar sus operaciones para cubrir completamente el servicio.
2. Es difícil para API3 justificar una inversión (en forma de fondos o recursos de desarrollo) en una cadena emergente. Además, debido a que no es nativa de esa cadena, los miembros del DAO de API3 no conocerán sus particularidades ni necesidades (qué personas son buenas para trabajar, qué proyectos/casos de uso tienen futuro, etc.).

Un subDAO compuesto parcialmente por nativos de la plataforma de contratos inteligentes objetivo resolvería ambos problemas. Los miembros del subDAO podrían asumir los esfuerzos de desarrollo comercial e integración, y al ser nativos de la cadena, serían mucho más efectivos en la ejecución y mantenimiento de estos. Además, un subDAO desplegado en la plataforma de contratos inteligentes objetivo podría interactuar directamente con los contratos desplegados en esa cadena, asegurando la gobernanza descentralizada de la integración.

Se puede concebir un tipo alternativo de subDAO cuyo objetivo sea que los servicios de API3 sean adoptados por un proyecto específico. Este subDAO realizaría marketing y desarrollo comercial enfocados en el proyecto, identificaría los requisitos necesarios e incluso podría implementar un fork (bifurcación de la cadena de bloque) de prueba de concepto que funcione con los servicios de API3. Una vez alcanzado el objetivo final, el subDAO continuaría existiendo para mantener la integración, capturando al mismo tiempo parte del valor generado.

Alineación de incentivos del subDAO

Dado que el DAO autoritativo y los subDAOs no estarán necesariamente integrados de manera programática, sus incentivos deben estar alineados de forma teórica para que cooperen. Aquí, la carga recae principalmente en el subDAO, es decir, el subDAO debe convencer al DAO de API3 para financiar sus operaciones y apoyarlo con sus productos, conocimiento y red de socios comerciales (por ejemplo, proveedores de API). En otras palabras, el subDAO debe hacer lobby para que sus propuestas al DAO de API3 sean aprobadas.

Aquí, lo que llamamos el DAO de API3 son en realidad los stakers de API3, ya que poseen el poder de voto. Por lo tanto, si un subDAO necesita agradar al DAO de API3, debe pagar tributo a los stakers. Por ejemplo, una fracción del suministro total del token de gobernanza del subDAO podría ser distribuida entre los stakers de API3 (esta funcionalidad ya está implementada en el contrato del pool de API3), lo que resultaría en que algunos de los beneficiarios voten a favor del subDAO (si el beneficio combinado para el DAO de API3 y el subDAO les parece un neto positivo). Este airdrop también haría que el token de gobernanza del subDAO tenga un precio de mercado (no nulo), ya que el subDAO sería inútil si no cuenta con el respaldo del DAO de API3, o más bien, sería solo un fork oscuro. Esto permite que el subDAO no dependa completamente del DAO de API3, pero también pueda financiarse a sí mismo utilizando su token.

Escalamiento sin permisos

La descentralización solo proporciona confianza cuando es transparente. De manera similar, la descentralización solo proporciona escalabilidad cuando no requiere permisos. En un entorno con permisos, la innovación o se sofoca o se libera y causa una división. Por lo tanto, la ausencia de permisos debe estar incorporada en el diseño, tanto para poder beneficiarse de la innovación como para superar a la competencia.

Supongamos que tenemos un equipo de plataforma de contratos inteligentes que tiene prohibido, por contrato, publicitar el uso de los servicios de API3 en su plataforma, y el consenso interno general (entre los equipos operativos) es que no vale la pena trabajar con ellos por esta razón. Por otro lado, hay un equipo externo que son expertos en una solución de oráculo existente que ya está integrada en esa plataforma. Proponen servir al catálogo de API3 utilizando la integración existente bajo marca blanca, lo cual no entusiasma al equipo técnico principal porque consideran que Airnode es insuperable. Incluso en estas circunstancias, donde no hay permiso de la plataforma de contratos inteligentes objetivo, los equipos de API3 o la solución de marca blanca, el equipo externo de expertos mencionado podría lanzar un subDAO, distribuir tokens entre los stakers del DAO de API3, presentar su caso y pedir apoyo al DAO autoritativo. Por lo tanto, los externos no necesitan agradar a los internos, y el escalamiento no solo será ilimitado, sino también sin permisos.

Conclusión

En publicaciones anteriores aludimos al uso de DAOs para el escalamiento organizacional, pero hasta ahora no habíamos descrito las mecánicas exactas. En este artículo, hemos presentado el esquema de red fractalizado de subDAOs y equipos, las mecánicas de alineación de incentivos y sus implicaciones para la economia del token de API3 como un incentivo adicional para el staking. Como se mencionó en el artículo, el modelo es sin permisos y está abierto a tu interpretación como potencial fundador/patrocinador de un subDAO (o como un maximalista del DAO autoritativo). En el próximo artículo, abordaremos un tema muy esperado: el staking.