FTSOv2 es una actualización de Flare Time Series Oracle, que incluye actualizaciones más regulares, mejor rendimiento, una gama más amplia de fuentes de datos y actualizaciones de alta frecuencia. Es un paso más para hacer realidad la visión de Flare como la cadena de bloques de datos.

En esta entrada de blog presentamos las ventajas del nuevo protocolo y resumimos las optimizaciones técnicas que lo han hecho posible. Para una revisión más detallada, nuestro último libro blanco amplía este resumen, dando cuerpo a la mecánica y los beneficios del diseño del FTSOv2.

La cadena de bloques de datos amplía su alcance

El oráculo actualizado de Flare, FTSOv2, introduce un avance significativo en el acceso a los datos en la cadena para las empresas que operan dentro de las finanzas descentralizadas (DeFi), como las dapps de préstamos o comercio. Al mejorar la accesibilidad a los datos y reducir los costes de uso, los oráculos de Flare suponen una notable mejora con respecto a las tecnologías de oráculo existentes, estableciendo un nuevo punto de referencia para la descentralización y la asequibilidad en el intercambio de datos.

Flare se está centrando en oráculos totalmente descentralizados para apoyar aplicaciones construidas tanto en Flare como en otras cadenas. Al integrar los oráculos en la cadena de bloques de Flare, se benefician de la seguridad inherente que ofrece la descentralización total, lo que a su vez responde a la necesidad crítica de contar con fuentes de datos fiables y descentralizadas en DeFi y en el espacio web3 en general.

Tras desarrollar una base sólida, Flare está ampliando sus capacidades de datos para incluir un espectro más amplio de activos, como acciones y materias primas, y reducir la latencia con la que se pueden suministrar estos datos. Todo ello como preparación para nuevos avances en la conexión de datos entre blockchains y entre web2 y web3.

Estas iniciativas pretenden mejorar la seguridad, reducir los costes y simplificar los procesos de desarrollo, en consonancia con el objetivo de la red de facilitar un intercambio de datos entre cadenas seguro y eficaz.

Descentralización de Oracle Access

Los oráculos son un componente esencial de DeFi, ya que garantizan grandes cantidades de valor al proporcionar datos precisos y en tiempo real fuera de la cadena a los contratos inteligentes en la cadena. Los principales oráculos dependen de un número limitado de proveedores de datos y los más grandes operan en una red autorizada. Esto socava la visión central de las finanzas descentralizadas, ya que en casos extremos expone a los usuarios a pérdidas catastróficas, y a pérdidas más graduales pero igualmente malignas a través de la manipulación del mercado.

El FTSOv2 es la solución de Flare para crear un oráculo capaz de realizar actualizaciones de alta frecuencia, al tiempo que admite una amplia gama de fuentes de datos y mantiene la descentralización.

A diferencia de algunas soluciones disponibles actualmente en el mercado, en las que una fuente de datos puede estar asegurada con tan sólo 5 nodos, el FTSOv2 garantiza que cada fuente de datos estará asegurada por toda la red, formada por 100 nodos. Estas garantías hacen que sea mucho más seguro y fácil para los desarrolladores y usuarios confiar en los feeds de precios de FTSOv2, sin tener que entender la idiosincrasia específica del feed en cuestión.

A menudo, los oráculos siguen un enfoque basado en permisos y sólo admiten grandes instituciones y empresas comerciales como proveedores de datos en su red, comprometiendo la descentralización de la red en aras de la latencia. Flare no hace tales concesiones: el proceso de incorporación del variado conjunto de proveedores de datos se realiza sin ningún tipo de permiso y se apoya en delegaciones abiertas por parte de los usuarios de Flare Network. Además, otros oráculos, quizás viendo el potencial de utilizar una Prueba de Participación descentralizada (PoS) Capa 1 como Flare, se encuentran actualmente en las primeras etapas de cambio a PoS. Sin embargo, estas redes tienen un bajo porcentaje de tokens nativos apostados para la seguridad del oráculo en comparación con Flare; alrededor del 7% frente al 66% de Flare.

Actualización de Flare Time Series Oracle

La iteración actual de Flare Time Series Oracle, FTSOv1, actualiza una colección de 18 fuentes de precios cada 3 minutos. La nueva iteración de FTSO mejora este proceso ampliando tanto la frecuencia de las actualizaciones como el número de fuentes disponibles. Además, ahora se admiten dos tipos distintos de actualizaciones:

• Ancla las actualizaciones periódicas de los datos del FTSO que combinan estimaciones de múltiples proveedores como en el FTSOv1.
• Flujo updates, una nueva función que aprovecha una técnica de actualización rápida para publicar actualizaciones incrementales en los flujos de datos de cada bloque.

Las actualizaciones del anclaje se apoyan en una serie de mejoras del proceso de votación, que proporcionan un mejor rendimiento sin cambiar los conceptos clave del proceso. Las mejoras se han diseñado para mantener las características deseables del FTSO: descentralización, precisión y seguridad. Como en el diseño original, cada valor de alimentación de datos se sigue agregando a partir de estimaciones individuales de 100 proveedores de datos de la red Flare. La estructura modificada de incentivos y límites impide que los proveedores afecten maliciosamente a los valores agregados, al tiempo que les anima a determinar estimaciones precisas.

Los nuevos valores del flujo se forman a partir de una secuencia de actualizaciones incrementales por bloque, lo que proporciona acceso a las actualizaciones a un ritmo más rápido con un mecanismo de agregación más sencillo. La alimentación del flujo se basa en un proceso conocido como actualizaciones rápidas, en el que proveedores rotatorios elegidos por sorteo envían cada uno actualizaciones incrementales de los datos. El tamaño de estos incrementos puede modificarse mediante la financiación de la comunidad, de modo que las actualizaciones de flujo funcionan bajo demanda: las dapps y otros usuarios pagan una cuota para acceder a flujos de datos cada vez más precisos.

Tanto las mejoras de las actualizaciones de anclaje como la introducción de actualizaciones de flujo se han diseñado para no perjudicar el consumo de gas del protocolo, lo que significa que el FTSO sigue siendo sostenible y no consume demasiado del caudal de gas disponible de la red de antorchas.

En resumen, la FTSOv2 mejora la iteración anterior en tres aspectos:

• Las actualizaciones de anclaje se proporcionan cada 90 segundos, lo que reduce a la mitad la latencia entre la publicación de valores de datos.
• El número de valoraciones admitidas ha aumentado drásticamente, con más de 50 fuentes de datos admitidas inicialmente y un diseño capaz de escalar hasta 1000 fuentes.
• Las actualizaciones de flujo se proporcionan entre las actualizaciones de anclaje, lo que permite el acceso opcional a actualizaciones con mayor frecuencia, con un posible coste en precisión.

Oracle Access en Flare a escala

El flujo general de una ronda del FTSO no cambia: 100 proveedores de datos estiman el valor de cada fuente de datos, cuyas estimaciones individuales se agregan después mediante un algoritmo de mediana ponderada en un conjunto de valores finalizados. Una vez más, el proceso mejorado no consume un gas insostenible, aunque admita más fuentes de datos y actualizaciones más rápidas. Entonces, ¿cómo funcionan estas mejoras de bajo coste? El secreto reside en trasladar los cálculos poco manejables fuera de la cadena, publicando en ella únicamente la información de verificación. De este modo, el trabajo duro necesario para realizar los cálculos se traslada a los proveedores, minimizando los cálculos en la cadena. A continuación, los proveedores suben los datos de verificación a la cadena, demostrando que los cálculos fuera de la cadena se han realizado correctamente. Así, una ronda de votación de la FTSOv2 se desarrolla de la siguiente manera:

• Cada proveedor calcula su estimación para cada una de las fuentes de datos FTSO admitidas y carga en la cadena un hash único que compromete sus estimaciones individuales.
• Cada proveedor revela su lista de presupuestos y carga la información en la cadena.
• Fuera de la cadena, los proveedores calculan el valor agregado de cada alimentación en la ronda de votación.
• Los proveedores empaquetan la lista de valores de la mediana en un único hash, cargando este hash en la cadena, junto con una firma sobre el hash.
• Una vez que se cargan suficientes firmas correspondientes al mismo hash, este hash determina los valores finales de los datos de la ronda, que ya están disponibles para su uso en, por ejemplo, contratos inteligentes.

En el diagrama de flujo podemos ver cómo el nuevo diseño del FTSO minimiza el consumo de gas: los cálculos más costosos se han descargado y son responsabilidad directa de los proveedores. Los costes de almacenamiento se minimizan haciendo que los resultados de estos cálculos se carguen en la cadena en forma de hash comprimido siempre que sea posible. Entre estas dos optimizaciones, el rediseño de FTSOv2 es capaz de soportar una mayor velocidad y una cobertura más amplia sin incurrir en costes de gas inasumibles.

Pesos y topes: Equilibrio entre descentralización y precisión

El FTSO toma datos de 100 proveedores y obtiene valores para cada ronda basados en la agregación de estas estimaciones en un valor medio ponderado. A efectos del FTSO, el peso de un proveedor corresponde a la cantidad de FLR envuelta (WFLR) que ha acumulado, ya sea por el propio proveedor o delegada en él por otros usuarios de la Red Flare. El valor agregado para cada alimentación es entonces una mediana ponderada de las estimaciones del proveedor: las estimaciones dadas por los proveedores con mayor peso tienen más impacto en el precio agregado que las de los proveedores más pequeños, ya que los proveedores con mayor peso tienen un historial de estimaciones de datos de mejor calidad.

Sin embargo, para evitar que los proveedores individuales tengan demasiada influencia en una ronda y perjudiquen la descentralización del protocolo, aplicamos un límite del 2,5% al peso máximo de un proveedor individual. Se considera que cualquier proveedor cuyo peso supere este límite tiene el 2,5% del peso a efectos del cálculo de la mediana, y el exceso de peso se distribuye entre todos los proveedores. Para el proceso de firma, se requiere un peso combinado igual o superior al 50% del peso del proveedor para que el resultado sea definitivo.

Actualizaciones rápidas: Actualizaciones de baja latencia bajo demanda

Además de admitir actualizaciones de hasta 1.000 fuentes de datos cada 90 segundos, el diseño de FTSOv2 admite una nueva función denominada actualizaciones rápidas, un flujo de datos auxiliar con un diseño ligero que se actualiza con mayor regularidad. El flujo de datos que funciona con actualizaciones rápidas admite los mismos flujos de datos que el flujo FTSO de anclaje, pero los actualiza de forma diferente: un flujo de actualización continua, en lugar de valoraciones periódicas. Cada bloque, se elige una selección aleatoria de proveedores para dar actualizaciones rápidas, con proveedores seleccionados con probabilidad proporcional a su peso. Cada proveedor seleccionado envía un incremento para cada flujo, que representa un pequeño cambio en su valor; la suma de estos incrementos determina el valor del siguiente flujo. El tamaño de un único incremento y el número de actualizaciones son parámetros que pueden cambiarse para reflejar la volatilidad del activo subyacente en un momento dado, ya sea por la gobernanza o por la financiación de la comunidad. De este modo, una dapp u otros usuarios interesados en actualizaciones de datos más rápidas pueden financiar el protocolo de actualizaciones rápidas para aumentar la fidelidad de la alimentación del flujo.

El gráfico ilustra cómo un aumento fundado de los parámetros de actualización rápida del número esperado de actualizaciones por bloque (e) y la precisión de los incrementos (p) puede permitir que los valores de flujo sigan el comportamiento volátil de los valores reales más de cerca de lo que lo haría el comportamiento por defecto.

La principal ventaja de este mecanismo es su rapidez, ya que las actualizaciones pueden proporcionarse esencialmente cada bloque. Sin embargo, las garantías de seguridad y precisión del flujo rápido de actualizaciones son menos sólidas que las de los valores de anclaje, ya que el proceso de agregación es más sencillo. Así pues, las actualizaciones de flujo se destinan principalmente a aplicaciones en las que es crucial disponer de información actualizada.

Recompensa para el FTSO

Al igual que en la FTSOv1, se recompensa a los proveedores por sus estimaciones precisas y su participación activa. Los proveedores son recompensados de las siguientes maneras, con el tamaño de las recompensas en relación con el peso del proveedor y la importancia del proceso:

• Los proveedores que envían datos precisos a las fuentes de datos de anclaje son recompensados por enviar valores cercanos a la mediana ponderada - y como esto es de importancia primordial, alrededor del 80% de las recompensas por las actualizaciones de anclaje se reservan para los buenos envíos.
• Las recompensas restantes por las actualizaciones de los anclajes se asignan a la participación activa en la firma y finalización de las rondas de FTSO. De este modo se garantiza que el sistema funcione correctamente y con prontitud.
• Los proveedores que han enviado actualizaciones rápidas reciben una parte de las recompensas por precisión del flujo al final de cada ventana de 90 segundos, siempre que el flujo se ajuste al valor de anclaje de esa ronda.
• Toda participación en actualizaciones rápidas se recompensa para fomentar la inversión inicial en infraestructura de actualización rápida, independientemente de la precisión. Estas recompensas podrán eliminarse más adelante, una vez que la alimentación de flujo esté más firmemente establecida.

Además de las recompensas para los proveedores, los usuarios que han delegado su WFLR en un proveedor reciben recompensas por delegar en proveedores que han tenido éxito. A cada proveedor se le asignan recompensas en función de su peso, y una parte de estas recompensas se transfiere a los delegantes en función de la fracción del peso del proveedor que cada delegación ha proporcionado, menos un porcentaje de la tarifa que cobran los proveedores por sus servicios.

Conclusión

El despliegue de FTSOv2 es un componente integral de la ambición de la red de democratizar los datos haciéndolos más accesibles, rentables y descentralizados. En esta entrada de blog hemos resumido las mejoras introducidas en el diseño de la v2 de FTSO, que facilitan una mayor variedad de fuentes de datos, acortan el intervalo entre actualizaciones y mantienen las características de seguridad y descentralización deseables de FTSO. Las mejoras se centran principalmente en trasladar las cargas computacionales fuera de la cadena, de modo que se minimicen el consumo de gas y la latencia. Además, examinamos la novedosa función de actualizaciones rápidas, que proporciona una fuente de datos secundaria como complemento de la fuente de datos principal, para ayudar a los usuarios que necesitan actualizar rápidamente sus fuentes de datos.

Estas mejoras no sólo mejoran el acceso a datos en tiempo real y de alta seguridad para las plataformas financieras descentralizadas, sino que también sientan las bases para un marco integral en el que los datos se pueden intercambiar sin problemas a través de diversas arquitecturas blockchain. En esencia, la FTSOv2 encarna la dedicación de Flare a facilitar una integración simbiótica entre los ecosistemas de datos convencionales y los basados en blockchain, permitiendo así a las empresas utilizar el potencial transformador de la tecnología blockchain para la innovación, la optimización operativa y la expansión.