La pila tecnológica de API3

Una breve introducción a la jerarquía de capas que componen la pila tecnológica de oráculos de primera parte de API3.

Como mencionó Burak en dAPIs: APIs para dApps, "el objetivo de API3 es construir, gestionar y monetizar dAPIs a gran escala", lo que implica "crear una economía de dAPIs comparable a Web3 en su conjunto". Para lograr este ambicioso objetivo, la tecnología de API3 está diseñada como una jerarquía de capas "para permitir al usuario elegir la herramienta más adecuada para la tarea".

La pila tecnológica de API3

dAPIs (servicios de API gestionados para dApps)

En la parte superior de la pila se encuentran las dAPIs. Estas son las herramientas de nivel más alto del conjunto de herramientas de API3. Las dAPIs son servicios de API gestionados diseñados para parecerse a las APIs web desde la perspectiva de un contrato inteligente. Las dAPIs tienen las siguientes características:

• La dApp paga por un servicio que la API3 DAO proporciona de manera transparente y transaccional. No hay compromiso de la dApp ni enredo con el proveedor de la API.
• Tienen una interfaz estandarizada y fácil de usar que abstrae la implementación técnica.
• Existen completamente en la cadena como contratos inteligentes y utilizan primitivas de oráculos de primera parte fuera de la cadena, como Beacons, en su funcionamiento interno.
• Son gestionadas de manera experta por la API3 DAO, por lo que la dApp no tiene que preocuparse por la disponibilidad o la longevidad del proveedor de API. Las dAPIs se adaptan dinámicamente a los cambios en la disponibilidad de las APIs.
• La dApp está cubierta por la API3 DAO contra pérdidas debido a fallos. Esta protección de riesgos de la API3 DAO hace que las dAPIs sean cuantificablemente seguras.

Las dAPIs son las herramientas más fáciles de usar y automatizadas de la pila tecnológica de API3. Al ser más resilientes frente a la incertidumbre de los proveedores de API, las dAPIs ofrecen mayor cobertura y, por ende, un mayor nivel de seguridad cuantificada.

Las dApps deberían usar dAPIs por defecto y recurrir a capas inferiores solo cuando tengan una buena razón.

Beacons (primitivas de oráculos de primera parte)

En el medio de la pila están los Beacons. Un Beacon es un flujo de datos de primera parte alojado y operado por el propio proveedor de la API, y es impulsado por Airnode. Los Beacons se utilizan principalmente como bloques de construcción para crear dAPIs, pero las dApps también pueden usarlos directamente cuando sea necesario. Cuando se usan directamente, los Beacons tienen las siguientes características:

• La dApp está entrelazada con el flujo de datos del proveedor de API. Si el proveedor de la API deja de proporcionar el flujo o la dApp quiere cambiar a un nuevo proveedor, la dApp debe realizar el cambio.
• La dApp sigue estando protegida contra riesgos por la API3 DAO frente a pérdidas debido a fallos, pero los Beacons ofrecen menos cobertura que las dAPIs. Los Beacons son menos resilientes frente a la incertidumbre del proveedor de API porque la dApp depende directamente de él.
• Los Beacons pueden accederse individualmente o combinarse en "conjuntos de Beacons" que agregan datos de múltiples fuentes. Un conjunto de Beacons es estático: sus fuentes de datos están fijadas de forma permanente.

Los Beacons suelen usarse como bloques de construcción para las dAPIs. Ejemplos de situaciones en las que una dApp podría preferir usar Beacons directamente en lugar de dAPIs incluyen:

• La dApp necesita un flujo de datos de un proveedor de API específico en una cadena específica, pero no hay una dAPI para ese flujo en esa cadena.
• La dApp o el proveedor de API son mucho más grandes que la API3 DAO y la cobertura proporcionada por la protección de riesgos de API3 es insuficiente, por lo que tiene más sentido que la dApp y el proveedor se conecten directamente.
• La dApp está obligada a trabajar directamente con el proveedor de API debido a razones contractuales o regulatorias, y una dAPI gestionada por API3 crearía un conflicto.

Las dApps pueden usar Beacons directamente, pero deberían preferir las dAPIs por defecto y usar Beacons solo cuando sea necesario.

Protocolos Airnode

En la base de la pila están los protocolos Airnode. Estos son las reglas y estándares de comunicación subyacentes que hacen posibles los Beacons y las dAPIs. Usar directamente los protocolos Airnode proporciona a las dApps el mayor control sobre sus interacciones con las APIs, pero también requiere más esfuerzo y experiencia.

Ejemplos de protocolos Airnode:

• Protocolo de Solicitud-Respuesta (RRP): Modela el paradigma tradicional de API web en el que un cliente hace una solicitud a un servidor y espera una respuesta. Con RRP, el "cliente" es tu contrato inteligente.
• Protocolo Publicar-Suscribirse (PSP): En lugar de esperar solicitudes del contrato inteligente, el proveedor de API inicia la comunicación y envía respuestas cuando corresponde.

Las dApps pueden usar los protocolos Airnode directamente, pero deberían preferir dAPIs o Beacons para flujos de datos típicos con parámetros de API fijos.

La visión general

La pila tecnológica de API3 es una jerarquía de capas que se construyen una sobre otra. Los desarrolladores de contratos inteligentes pueden trabajar con la capa más alta, las dAPIs, para obtener el acceso más fácil, resiliente y menos riesgoso a las APIs fuera de la cadena. O pueden elegir trabajar con las capas inferiores, Beacons y protocolos Airnode, si tienen necesidades específicas que las dAPIs no cubren.

La pila tecnológica de API3 está diseñada como una jerarquía de capas para atender fácilmente los casos más comunes mientras se escala de manera flexible hacia arriba y hacia abajo para atender casos menos comunes.