¿Dónde están los oráculos de primera parte?

En la emision de la semana pasada de “Getting APIs on the Blockchain”, se realizó una comparación exhaustiva entre oráculos de primera y tercera parte. Esta semana me encargaré de establecer el escenario para una serie derivada: “Airnode: The first-party oracle node”.

De acuerdo, los oráculos de primera parte son lo mejor desde el pan de molde, pero ¿dónde están? Tiene todo el sentido del mundo que los proveedores de API configuren sus propios nodos de oráculo, eliminen a los intermediarios y sirvan directamente a los consumidores de datos en la cadena. Parece haber suficientes incentivos financieros para hacerlo, y los consumidores de datos preferirían esa opción de todos modos. Sin embargo, existen obstáculos mayores que frenan la adopción de los oráculos de primera parte.

La hipótesis del Gran Filtro

La hipótesis del Gran Filtro plantea que la razón por la cual aún no hemos encontrado vida extraterrestre (ver la paradoja de Fermi) es porque existe un obstáculo absoluto que impide que las civilizaciones (incluida la nuestra, en la Tierra) logren el colonialismo interestelar. La naturaleza exacta de este obstáculo puede ir desde una guerra nuclear inevitable hasta un colapso social impulsado por la realidad virtual, pero lo que (supuestamente) es seguro es que está allí, y ninguna civilización antes ha podido superarlo. Entonces, ¿cuál es el gran filtro de los oráculos de primera parte?

Nuestra experiencia

Para apreciar realmente la dificultad de implementar oráculos de primera parte, necesitas haber hecho lo siguiente:

• Operar un nodo de oráculo en un contexto profesional.
• Hablar con proveedores de APIs sobre operar nodos de oráculo.

Decir que hemos hecho esto sería subestimarlo. Construimos el Honeycomb API Marketplace utilizando Chainlink como infraestructura subyacente (esto es especialmente significativo porque nada te enseña más sobre un software que intentar construir un negocio sobre él), operamos 6 nodos de Chainlink simultáneamente, sin contar las redundancias (4 para Honeycomb, 2 para Chainlink) y mantuvimos la tasa de respuesta más alta en reputation.link (lo que significa que teníamos un monitoreo y respuesta a incidentes sobresalientes) hasta que solicitamos ser eliminados de los archvos de datos para centrar toda nuestra atención en API3.

Hablar con proveedores de APIs es esencialmente nuestra especialidad. Durante nuestro trabajo de más de un año en Honeycomb API Marketplace, educamos a una gran cantidad de proveedores de APIs sobre cómo monetizar sus servicios a través de oráculos y aprendimos muchísimo sobre sus requisitos y limitaciones al hacerlo. Hacia el final de nuestros esfuerzos, nos enfocamos en lograr que los proveedores de APIs operaran sus propios oráculos (recordemos que no los llamábamos oráculos de primera parte en ese entonces), lo que nos dio una mayor visión de por qué este es un problema tan difícil.

Lista de impedimentos

A través de todo este trabajo de campo, logramos identificar una lista de características de soluciones de oráculos, donde cada elemento es un impedimento definitivo para la adopción de oráculos de primera parte de manera confiable y financieramente viable.

1. Un nodo de oráculo inestableNadie querría trabajar con un software inestable, pero esto es especialmente cierto en el caso de los oráculos de primera parte porque un nodo inestable requiere:
   • Atención constante para detectar incidentes.
   • Conocimientos técnicos para poder responder a los incidentes.Un proveedor de APIs típico no puede permitirse ninguna de estas cosas, lo que hace que un nodo de oráculo inestable no sea una opción.
2. Un nodo de oráculo que no pueda recuperarse por sí mismoIncluso si un nodo falla muy raramente, si no puede recuperarse de manera autónoma, requerirá intervención humana. Por lo tanto, el nodo no solo debe ser estable, sino también capaz de recuperarse de errores o condiciones adversas de la red por sí solo, en lugar de quedar incapacitado permanentemente.
3. Recomendaciones de configuración vagasNo se puede esperar que un proveedor de APIs investigue la arquitectura del nodo, los casos de uso y experimente para encontrar la configuración óptima del nodo (dónde alojarlo, cuánta redundancia implementar, cómo determinar los parámetros, etc.). Un “¡Es tu decisión!” Es una salida demasiado común que realmente significa: “Estás solo”.
4. Un nodo que requiera software auxiliar para funcionarNo es razonable esperar que el proveedor de APIs descubra qué software de monitoreo, integración de API y despliegue/configuración de nodos necesita usar (o incluso desarrollarlo ellos mismos si no está disponible). Todo lo necesario debe estar incluido en la solución.
5. Cobros en criptomonedasCobrar en criptomonedas es fácil; lidiar con los problemas legales, de cumplimiento y contables no lo es. Es muy común que negocios reales dejen ingresos potenciales en criptomonedas sobre la mesa porque aceptarlos les costaría más. Este no es un problema que se pueda solucionar educándose más. Si el proveedor de APIs no tiene infraestructura legal para generar ingresos en criptomonedas, simplemente no lo hará.
6. Tener costos en criptomonedasLas soluciones actuales requieren que el operador del nodo de oráculo pague por las transacciones del nodo en criptomonedas. Esto no es una opción para la mayoría de los negocios reales y menos aún si consideramos que estos oráculos operarían en múltiples cadenas y necesitan diversos tipos de criptomonedas.
7. Que el proveedor de APIs deba hacer stakingEsto es un problema aún mayor que manejar ingresos o costos en criptomonedas. Para la mayoría de las empresas, es muy difícil informar sobre posibles ganancias o pérdidas de staking sin caer en problemas de AML (prevención de lavado de dinero), lo que hace que evitar participar sea la mejor opción.

Conclusión y próximo artículo

Los obstáculos actuales para la adopción de oráculos de primera parte están tan arraigados que superarlos requiere un enfoque completamente nuevo: debemos diseñar tanto el protocolo como el nodo de oráculo para abordar directamente las necesidades del proveedor de APIs.

Aquí es donde nuestra serie de blogs se ramifica. Para comprender y apreciar plenamente el diseño de Airnode de API3, comenzaremos una nueva serie la próxima semana: “Airnode: The first-party oracle node”. Esta serie (“Getting APIs on the Blockchain”) continuará con por qué es difícil implementar el staking para oráculos (y por qué, por lo tanto, elegimos un modelo de seguridad diferente). ¡Estén atentos para estas publicaciones la próxima semana!