Oráculos de Primera Parte vs. Oráculos de Tercera Parte

Esta es una entrada de reemplazo para la tercera parte de la serie de API3, "Conectando las APIs a la Blockchain". Las publicaciones anteriores introdujeron la definición y el contexto de las APIs contemporáneas.

El Problema del Oráculo

El problema de llevar datos que se encuentran fuera de la cadena dentro de la cadena de bloques se percibe de manera abstracta como dos sistemas generales que necesitan ser compatibles a través de interfaces técnicas. Debido a esta falta de especificidad en la definición del problema, una estructura completamente flexible se convierte en un requisito de la solución, algo que solo se puede lograr con oráculos de terceros.

Cuando un problema está subespecificado, cualquier solución será subóptima, ya que en la práctica el problema tendrá límites claros. Este es el caso actual de los oráculos: en lugar de iniciar el diseño considerando todas las posibles formas de descentralizar el acceso a los servicios de API tradicionales, la solución se preseleccionó siguiendo el mecanismo de consenso nativo de blockchain.

Hay varios problemas que surgen al intermediar datos en cadenas de bloques con redes de oráculos de terceros.

Vectores de Ataque

Usar una red de actores de terceros para retransmitir información introduce una nueva superficie de ataque en comparación con los datos proporcionados directamente desde la fuente. Los oráculos maliciosos que actúan juntos pueden manipular los resultados. Incluso fuera de una conspiración, un único actor puede suplantar a una gran parte de la red creando múltiples identidades de operadores de nodos oráculo, construir una reputación de operación honesta y luego realizar un ataque Sybil cuando lo desee.

Impuesto de Intermediación

Para incentivar la provisión confiable de servicios por parte de oráculos de terceros, los actos honestos deben ofrecer potencialmente más ganancias que los actos maliciosos. La teoría de juegos que rodea este argumento se detalla en la Sección 3.2 del whitepaper de API3. El "impuesto de intermediación" es un costo adicional que no está presente en los modelos de oráculos de primera parte.

Costos Adicionales

Para proteger contra los vectores de ataque adicionales, los archivos de datos presentados por los oráculos de terceros requieren un exceso de redundancia a nivel de oráculo; debe haber suficientes oráculos empleados para obtener un dato que sea improbable que haya un ataque Sybil en curso. Estas medidas no mejoran la seguridad en la fuente de datos. De hecho, solo minimizan las vulnerabilidades introducidas por los oráculos de terceros en lugar de rectificarlas o mejorar la seguridad del sistema. Además, estas redundancias multiplican el impuesto de intermediación e incrementan los costos operativos.

Descentralización Limitada

Como se explicó anteriormente en El Problema de Conectividad de las API, los x oráculos rara vez extraen datos de x fuentes al agregarse en un datafeed. Por lo tanto, aumentar la cantidad de oráculos utilizados para proporcionar datos no necesariamente significa que los datos agregados sean de mayor calidad o más confiables que los datos proporcionados por una única fuente de buena reputación.

Desafortunadamente, debido a que la comunidad asocia la descentralización de nodos validadores con la descentralización a nivel de cadena de bloques, es fácil confundir la descentralización de oráculos con la descentralización de datos.

Estos factores y suposiciones ocultan que el verdadero cuello de botella para la descentralización de datos en cadena de bloques está a nivel de la fuente.

Fuentes Confiables

Mientras que algunos proveedores de datos de API utilizan métodos simples, otros agregan múltiples fuentes aplicando filtros avanzados para garantizar datos de alta calidad para sus clientes. El algoritmo de detección de inflación de volumen de CoinMarketCap es un ejemplo de cómo la calidad de los datos puede afectar las decisiones de los inversores.

Con oráculos de terceros que oscurecen sus fuentes de datos y enfrentan incentivos para recopilar los datos más baratos y fácilmente accesibles, se vuelve crucial que los desarrolladores cuestionen la calidad de los archivos de datos que están utilizando.

Esto es especialmente cierto en un momento en que los exploits de oráculos en archivos de datos de precios han ocupado titulares con pérdidas impresionantes.

Prueba de Reputación

Los oráculos de primera parte tienen "algo en juego", ya que requieren que el proveedor de API ponga en riesgo su reputación para operar en el espacio Web3. La teoría de juegos establece que el éxito de su negocio en el mundo real está vinculado a su confiabilidad en Web3, y su confiabilidad en Web3 está vinculada al éxito de su negocio en el mundo real.

Aunque no tienen tokens asignados a su nodo oráculo que puedan ser penalizados en caso de comportamiento erróneo o malicioso, los oráculos de primera parte están poniendo en riesgo la reputación de sus negocios en cada punto de datos que proporcionan. Esta reputación sustenta los ingresos de los oráculos de primera parte tanto dentro como fuera de la cadena, y la posibilidad de dañarla actúa como un gran disuasivo contra el comportamiento malicioso.

Pensamientos Finales y el Próximo Blog

El punto de esta publicación es que si un proveedor de API está sirviendo sus datos a la blockchain operando un oráculo de primera parte, los oráculos de terceros no tienen ningún beneficio.

Esto no significa que los oráculos de primera parte sean completamente confiables, sino que las soluciones de terceros solo abstraen el problema e introducen nuevos vectores de ataque. Además, abordaremos problemas como el tiempo de inactividad y la calidad de los datos proporcionados por los oráculos de primera parte más adelante en la serie.

A continuación, exploraremos qué impide la integración de oráculos de primera parte, por qué no vemos más proveedores de API haciéndolo por su cuenta y cómo API3 está facilitando los cambios necesarios para que más proveedores de API ingresen al espacio blockchain.

[Continúe leyendo la parte 4 de nuestra serie]

Nota: parte del contenido de este artículo puede atribuirse a “First Party vs Third Party Oracles”, escrito inicialmente por Sasa Milic para la API3 DAO en la publicación de Medium de API3 (ver este enlace).