dAPIs: APIs para dApps

Como se discutió en el whitepaper, el objetivo de API3 es “construir, gestionar y monetizar dAPIs a gran escala”. En este sentido, todo el desarrollo que hemos estado realizando se debe a que las herramientas existentes no son capaces de admitir dAPIs tal como las imaginamos. Entonces, ¿qué son exactamente estas dAPIs?

Una dApp es una aplicación que se implementa como un contrato inteligente que se ejecuta en una blockchain descentralizada. De la misma forma, una dAPI es un servicio similar a una API que se entrega a contratos inteligentes. En términos más simples, así como las aplicaciones usan APIs, las dApps usarán dAPIs.

Las dAPIs están diseñadas para parecerse a las APIs desde la perspectiva del usuario:

• La relación con el usuario es transaccional. El usuario paga de acuerdo con un modelo de precios transparente para recibir un servicio bien especificado, sin necesidad de compromisos adicionales.
• Tienen una interfaz estandarizada y fácil de usar que busca abstraer la implementación técnica.
• Es un servicio gestionado, lo que significa que las complejidades operativas están abstraídas. La única responsabilidad del usuario es no omitir los pagos.

Además de lo anterior, las dAPIs son cuantificablemente seguras porque están cubiertas contra pérdidas debido a fallos (aunque esto también puede compararse con los SLA de las APIs). Aquí, el hecho de que sean de primera parte o la descentralización a nivel de API de la dAPI sirve estrictamente como una herramienta para optimizar el riesgo del seguro. Además, una dAPI no es necesariamente un flujo de datos en vivo, sino que representa un tipo aún más general de servicio de oráculo.

Tras esta definición general, investiguemos la primera generación de dAPIs que construiremos y cómo se relacionan con los Beacons. Como se presentó en la reciente charla de ETHDenver, nuestras soluciones están diseñadas como una jerarquía:

1. El nivel más bajo está compuesto por los protocolos de Airnode (RRP, PSP, RRP retransmitido, PSP retransmitido, datos firmados por API). Un usuario autorizado puede hacer solicitudes al respectivo Airnode a nivel de protocolo. El caso de uso de Kassandra/Heimdall es un buen ejemplo de este tipo de uso. Típicamente, implementar estos casos de uso requiere un fuerte entendimiento del protocolo Airnode.
2. El nivel intermedio está compuesto por primitivas de oráculo como los Beacons. Un usuario que esté en la lista blanca puede leer el Beacon correspondiente. Los Beacons de Amberdata creados para ETHDenver son un buen ejemplo. Aunque los Beacons se construyen sobre los protocolos Airnode, este hecho está abstraído para el usuario, lo que significa que no necesitan saber nada sobre el protocolo Airnode específico que impulsa el Beacon que están utilizando.
3. El nivel más alto está compuesto por las dAPIs. En el caso de uso de un flujo de datos en vivo, una dAPI es un Beacon o un conjunto de Beacons envuelto en una interfaz de nivel superior. Un usuario que esté en la lista blanca puede leer la dAPI correspondiente sin necesidad de especificar qué el Beacon debe utilizarse en segundo plano. En otras palabras, al usar una dAPI, el usuario delega la responsabilidad de seleccionar los Beacons individuales en un flujo de datos.

El objetivo de esta arquitectura modular es permitir al usuario elegir la herramienta más adecuada para el trabajo. Si alguien necesita una solución de oráculo lista para usar, debe usar una dAPI. Si quieren control total sobre las fuentes de datos, deben usar uno o un conjunto de Beacons. Si la solución que necesitan es muy específica, puede construirse directamente sobre el protocolo Airnode. Los mecanismos de control de acceso y monetización están implementados en cada uno de estos niveles, lo que significa que un proveedor de API puede productivizar sus servicios de manera realista para cubrir todo este espectro.

Dado que la mayoría de los lectores estarán familiarizados con los Beacons, comparemos el flujo de usuario de las dAPIs con estos para mayor claridad. Un Beacon está identificado por un ID derivado de la dirección de Airnode respectiva y los parámetros de solicitud. Esto significa que el Beacon con el ID 0x49e889871813b16854fd7faecad16b5ba59d33a9669b47f927501136840c021b siempre será el precio BTC/USD informado por Amberdata. Del mismo modo, los conjuntos de Beacons están identificados por el hash de la lista de IDs de Beacons que los componen, lo que significa que un ID de conjunto de Beacons siempre se referirá a una combinación específica de Beacons. Esto es genial porque permite al usuario especificar las fuentes de datos exactas hasta los parámetros de solicitud, lo que elimina cualquier posibilidad de errores del lado de API3, como transmutar plata en oro, y permite a API3 servir de manera factible a un proyecto con x100 de su capitalización de mercado. Esto no es tan genial porque el usuario requerirá un mecanismo robusto de gobernanza descentralizada que pueda elegir los Beacons específicos que se usarán y actualizarlos cuando sea necesario, lo que típicamente no es aplicable a proyectos que no están bien establecidos.

Aquí entran las dAPIs. Una dAPI es esencialmente un nombre, asignado a un ID de Beacon o un ID de conjunto de Beacons. El usuario direcciona la dAPI por su nombre, y el contrato enruta esto al Beacon o conjunto de Beacons correspondiente. El equipo técnico central de API3 tendrá multisigs en todas las cadenas que API3 sirve, lo que tomará decisiones expertas para mantener las garantías de seguridad dadas por las políticas de cobertura. Una vez que este proceso haya madurado, la gestión de las dAPIs se transferirá a DAOs nativas de cada cadena, como se describe en nuestro plan de escalamiento fractal. No es críticamente importante para el usuario quién gestiona la dAPI, ya que estarán asegurados contra errores de gobernanza, independientemente de quién los cause. Por lo tanto, cualquier riesgo causado por el esquema de gestión de dAPIs se considera parte del riesgo del seguro y es responsabilidad de la DAO de API3 gestionarlo.

Estamos avanzando rápidamente hacia cumplir con la razón de ser de API3, las dAPIs, lo que nos llena de orgullo. Sin embargo, como dice la cita del whitepaper, el objetivo también es hacerlo “a escala”, lo que significa crear una economía de dAPIs comparable a Web3 en su conjunto. Nuestras soluciones están diseñadas para superar los cuellos de botella que podrían limitar el crecimiento del ecosistema, por lo que el camino para lograr esto simplemente será hacer más de lo que hemos estado haciendo y permitir que el espacio Web3 avance al mismo ritmo.