La mayor parte del material de este artículo está tomado de "Exploración del espacio de diseño y los desafíos para las implementaciones de Oracle en protocolos DeFi", con muchos cambios basados en esto.
Resumen: Los oráculos siempre han desempeñado un papel indispensable en el ecosistema DeFi. Dado que los contratos inteligentes solo pueden acceder a datos dentro de la cadena y no pueden obtener información directamente desde fuera de la cadena, los oráculos deben actuar como mediadores para introducir datos fuera de la cadena. Los contratos inteligentes pueden automatizar el procesamiento de transacciones basándose en datos fuera de la cadena. La mayoría de los protocolos DeFi se basan en precios de Oracle para procesar contratos de derivados, liquidar activos improductivos, etc.
La cantidad actual de fondos en el ecosistema DeFi supera los 80 mil millones de dólares estadounidenses, la mayoría de los cuales están relacionados de alguna manera con oráculos. Sin embargo, los oráculos tradicionales tienen un retraso en las actualizaciones de precios, lo que ha llevado a un MEV especial para los oráculos: OEV. Los escenarios comunes para OEV incluyen ganancias anticipadas, arbitraje y liquidación de Oracle. Cada vez se proponen más soluciones para mitigar el impacto negativo de OEV.
Este artículo presentará varias soluciones OEV existentes, discutirá sus ventajas y desventajas respectivamente y propondrá dos nuevas ideas para desarrollar sus valores, problemas a resolver y factores limitantes.
MEV (OEV) generado por oráculos
Para que sea más fácil para todos comprender el contenido principal de este artículo, primero presentamos brevemente los oráculos push y pull. Los oráculos de tipo push se refieren a que las máquinas Oracle envían activamente datos a contratos inteligentes en la cadena. Por ejemplo, Chainlink es principalmente de tipo push; . datos.
La diferencia entre estos dos modos es que el oráculo push tiene una mayor efectividad de los datos y es adecuado para escenarios que son más sensibles a los datos en tiempo real. Sin embargo, en este modo, el oráculo debe enviar datos a la cadena con frecuencia, lo que consumirá más. gas. El oráculo de extracción es más flexible y solo proporciona nuevos datos cuando la DApp los necesita. Esto consume menos gas, pero los datos tienen histéresis.
Dado que la plataforma Defi requiere que los oráculos proporcionen datos de precios, si las actualizaciones de los precios están retrasadas, los robots de arbitraje pueden capturar MEV. Este MEV que depende de oráculos se llama OEV. Los principales escenarios de ganancias relacionados con OEV incluyen la ejecución anticipada, el arbitraje y la liquidación. En la siguiente discusión, describiremos los diversos escenarios de ganancias causados por OEV y exploraremos diferentes soluciones de OEV, así como sus ventajas y desventajas.
Cómo se genera y captura el OEV
Según los resultados observados en la práctica, existen tres formas principales de lograr el OEV:
1. Acuerdos de vanguardia. Por ejemplo, el buscador MEV en la red Ethereum monitoreará los datos de las transacciones que se cargarán en la cadena en tiempo real y buscará oportunidades MEV. La máquina Oracle necesita enviar datos a la cadena para actualizar el precio. Estos datos se acumularán en el grupo de transacciones antes de cargarse en la cadena. El buscador monitoreará estas transacciones pendientes y predecirá las próximas fluctuaciones de precios de los activos en la cadena. cadena, y emboscar preventivamente algunas órdenes de compra y venta antes de que se actualice el precio.
Muchas plataformas de derivados han sufrido el impacto negativo de las transacciones anticipadas. Por ejemplo, GMX encontró con frecuencia transacciones anticipadas y sus ganancias se redujeron en un 10%. Hasta que se actualizó el protocolo, GMX entregó los oráculos conectados a KeeperDAO. programación unificada OEV capturado El problema se alivió. Más adelante explicaremos brevemente la solución adoptada por GMX.
2. Arbitraje: aprovechar el retraso en las actualizaciones de datos de Oracle para realizar arbitrajes sin riesgos entre diferentes mercados. Por ejemplo, hay un retraso de 10 segundos en las actualizaciones del precio de los activos en una determinada plataforma de derivados en cadena. Si el precio al contado de ETH de Binance aumenta repentinamente y el precio de ETH en cadena no cambia a tiempo, el robot de arbitraje puede abrir inmediatamente en largo. contratos en la cadena, espere a que se actualice el precio de Chainlink y luego cierre la posición para obtener ganancias.
El caso anterior simplifica la situación real, pero ilustra las oportunidades de arbitraje creadas por las actualizaciones retrasadas de precios. El arbitraje puede capturar OEV de la plataforma Defi. Por supuesto, estos OEV capturados eventualmente generarán pérdidas para LP (la lana proviene de las ovejas). .
El fenómeno del arbitraje y la ejecución anticipada de Oracle a menudo se denomina "flujo tóxico" en los protocolos de derivados porque existe una asimetría de información detrás de estas transacciones, y los arbitrajistas pueden capturar ganancias sin riesgo, pero dañarán los intereses de Defi de los LP/proveedores de liquidez en el acuerdo. . Los protocolos DeFi establecidos, como Synthetix, se han visto afectados por este tipo de ataques OEV desde 2018 y han probado muchos métodos para mitigar sus efectos negativos. Más adelante explicaremos brevemente dichas contramedidas.
3. Liquidación: para los protocolos de préstamos, si las actualizaciones de los precios de los activos se retrasan, será rentable para algunos liquidadores que reaccionan rápidamente para capturar la liquidación ineficiente causada por las actualizaciones inoportunas de los precios y obtener ingresos adicionales. Estos comportamientos debilitarán la eficiencia del mercado y tendrán un impacto negativo en la equidad de la plataforma Defi.
El componente de liquidación es central en cualquier protocolo DeFi que implique apalancamiento, y la granularidad de las actualizaciones de precios juega un papel clave en la eficiencia de la liquidación. Si el oráculo de empuje se basa en un umbral, es decir, el precio se actualiza solo cuando los cambios de precio alcanzan un cierto nivel, puede afectar el proceso de liquidación. Supongamos que el precio de ETH fuera de la cadena cae y la posición en un determinado acuerdo de préstamo ha alcanzado la línea de liquidación, pero la volatilidad del precio no alcanza el umbral para que el oráculo actualice el precio, por lo que el oráculo no actualiza los datos, lo que afectará a la ejecución de los trabajos de liquidación, lo que podría tener consecuencias negativas adicionales.
Para dar un ejemplo simple, una determinada posición de garantía se enfrenta a la liquidación debido a una caída de emergencia del precio, pero debido a que el oráculo no actualiza los datos de manera oportuna, el precio en la cadena aún no ha cambiado. Durante este período de ventana, Searcher envía una solicitud de transacción de compensación por adelantado y paga Gas más alto para obtener la ventaja de prioridad para el empaquetado en cadena. Cuando se actualiza el precio en la cadena, Searcher se convierte directamente en liquidador y obtiene ganancias. Al mismo tiempo, debido al retraso en las actualizaciones de precios, los titulares de garantías originales no tienen tiempo para cubrir sus posiciones y sufren pérdidas adicionales.
Por lo general, los protocolos DeFi dan parte de la garantía liquidada como recompensa a los liquidadores. Los grandes protocolos DeFi como Aave distribuyeron más de $38 millones en incentivos de liquidación solo en Ethereum en 2022, lo que no solo compensa en exceso a los liquidadores externos, sino que también causa daño a los usuarios. Además, las guerras del gas extenderán las oportunidades de captura de MEV desde donde hay efectos MEV a toda la cadena de suministro de MEV.
Entre ellos, el OEV capturado en ataques frontales y comportamientos de arbitraje dañará los intereses de los proveedores de liquidez de DeFi, mientras que el OEV capturado en la liquidación, para los prestatarios, perderán fondos considerables durante el proceso de liquidación, y para los prestamistas, los oráculos provocaron retrasos en las cotizaciones; en la recepción de valores de garantía inferiores a los esperados.
En general, no importa cómo se capture OEV, causará pérdidas a otros en el mercado. Al final, solo el propio capturador de OEV se beneficia, lo que tiene un impacto negativo en la equidad y la UX de DeFi.
Soluciones OEV actuales
A continuación, analizaremos los oráculos push, pull y otros modos en el contexto antes mencionado, así como las soluciones OEV que existen actualmente en el mercado y se basan en ellas, analizaremos su efectividad y exploraremos en profundidad cómo estas soluciones pueden resolver el OEV. Las ventajas obtenidas incluyen aumentar el grado de centralización o suposiciones de confianza, o sacrificar la UX.
¿Qué pasa si solo usamos oráculos de extracción?
Mencionamos anteriormente la máquina pull Oracle, y su característica es que Dapp necesita solicitar activamente datos de la máquina Oracle. Como representante de los oráculos de extracción, una de las ventajas de Pyth es que puede utilizar el alto TPS y la baja latencia de la arquitectura Solana para crear una red Pythnet para recopilar, agregar y distribuir datos. Los editores en Pythnet actualizarán la información de precios cada 300 ms. Las DApps que lo necesiten pueden consultar los datos más recientes a través de la API y publicarlos en la cadena.
Cabe señalar aquí que el editor actualiza la información de precios cada 300 ms, lo que parece la lógica de un oráculo push. Sin embargo, la lógica de Pyth es "actualización push, consulta pull", es decir, aunque los datos ingresan a Pythnet a través de la actualización push, las aplicaciones en cadena u otras redes blockchain pueden usar la API de Pyth o la capa de mensajería de puente entre cadenas. para "extraer" los datos más recientes.
Sin embargo, el uso exclusivo de oráculos de tipo pull no puede resolver completamente el front-running y el arbitraje. Los usuarios aún pueden elegir un precio que cumpla con condiciones específicas para operar, lo que genera el problema de la "selección de oponente". Específicamente en el escenario de las máquinas Oracle, debido al retraso en la actualización de precios de las máquinas Oracle, el buscador puede elegir proactivamente un nodo de tiempo que sea beneficioso para sí mismo para el comercio al monitorear la diferencia horaria de las actualizaciones de precios en la cadena. Esta vez el nodo suele estar caducado, pero no estará disponible en el futuro. Precios no exactos actualizados. Este comportamiento conduce a precios de mercado injustos, lo que permite a los buscadores aprovechar la asimetría de la información para obtener ganancias sin riesgo, pero perjudica los intereses de otros participantes del mercado.
En otras palabras, en los oráculos de atracción, todavía existen ataques de arbitraje causados por retrasos en los precios. En la documentación de Pyth, se propone prevenir este ataque mediante una "verificación de obsolescencia". Una “verificación de obsolescencia” es un mecanismo utilizado para garantizar la inmediatez de los datos o la información de precios utilizados en las transacciones.
Específicamente, la verificación de obsolescencia verifica si los datos de precios utilizados se generaron dentro de un período de tiempo razonable para evitar que los comerciantes utilicen información de precios obsoleta para comerciar, reduciendo así el arbitraje y las prácticas comerciales desleales.
Sin embargo, en la implementación real, es difícil determinar el umbral de tiempo óptimo. Podemos volver a mirar el ejemplo anterior para comprender la verificación de obsolescencia. Supongamos que el intercambio de contrato perpetuo utiliza la fuente de precios ETH/USD de Pyth y establece un umbral de verificación de obsolescencia de 20 segundos. Esto significa que la marca de tiempo del precio de Pyth es diferente de. la ejecución en sentido descendente. La marca de tiempo del bloque de una transacción solo puede diferir en 20 segundos. Si se excede este plazo, el precio se considerará obsoleto y no disponible. Este diseño tiene como objetivo evitar el arbitraje sobre precios vencidos.
Acortar el umbral de tiempo de verificación de obsolescencia parece ser una buena solución, pero esto puede provocar una reversión de transacciones en una red con un tiempo de bloqueo incierto, afectando así la experiencia del usuario. La fuente de precios de Pyth se basa en puentes entre cadenas. Wormhole todavía se utiliza como ejemplo. Su nodo Guardian se llama "Wormhole Keeper". El oráculo debe tener suficiente tiempo de reserva para permitir que Wormhole Keeper confirme el precio y permita que la cadena objetivo lo procese. la transacción y registrarla en el bloque.
Subasta de flujo de pedidos de Oracle (OFA)
Para hacer frente al impacto negativo provocado por MEV, ha surgido gradualmente una nueva solución: la subasta de flujo de órdenes exclusiva (OFA) de Oracle, y el efecto es muy significativo. OFA es un servicio general de subastas de terceros que permite a Oracle sellar la información de precios más reciente con una firma y enviarla a la plataforma de subastas fuera de la cadena, y otros pueden enviar la información de precios a la cadena en su nombre. Una vez que dichas operaciones de actualización de precios se coloquen en la cadena, aparecerán oportunidades MEV, por lo que MEV Searcher monitoreará la información de precios enviada por la máquina Oracle a la plataforma de subasta y aprovechará al máximo las oportunidades.
El buscador a menudo está dispuesto a ofertar y postularse para enviar el mensaje de alimentación de precios a la cadena en lugar del oráculo. Luego, el buscador aprovecha esta oportunidad para construir una transacción MEV y convertirse en el que obtiene mayores ganancias. Por supuesto, el buscador debe participar en la subasta. Durante el proceso de oferta, pagará algunos fondos, que la plataforma de subasta distribuirá al oráculo o a más personas. Esto equivale a distribuir parte de las ganancias de los jugadores MEV a otros. Aliviar los problemas de OEV.
El proceso específico de OFA es el siguiente:
1. Envío de transacciones
Todo el flujo de transacciones pendientes se enrutará a un grupo de transacciones OFA privado en lugar de enviarse directamente a la cadena. Para garantizar la equidad, el grupo de negociación sigue siendo privado y accesible sólo para los participantes de la subasta.
2. Subasta
El pool de negociación es la plataforma donde OFA realiza subastas, donde Searcher participa en la subasta y obtiene el derecho a ejecutar órdenes. El precio de la subasta se basa en el valor que se espera extraer de la orden, incluidos factores como el tipo de transacción, el precio actual del gas y la ganancia MEV esperada.
3. Selección y ejecución
El buscador ganador paga el monto de la oferta y obtiene el derecho de ejecutar la transacción. Por interés propio, organizará la transacción de manera que pueda extraer el MEV máximo y enviar la transacción a la cadena.
4. Distribución del ingreso
Este paso es el núcleo de OFA Para obtener oportunidades MEV, Searcher pagará un monto de oferta adicional. Este monto se depositará en el contrato inteligente y se distribuirá de acuerdo con una cierta proporción para compensar al protocolo y a los usuarios por el valor perdido. OFA.
Desde el punto de vista de los datos, OFA ha aliviado significativamente los problemas de MEV y OEV. La tasa de adopción de dichas soluciones ha mostrado una rápida tendencia ascendente. Actualmente, más del 10% de las transacciones de Ethereum se realizan a través de canales privados (incluidos RPC y OFA privados). . conducta. Es previsible que OFA tenga un gran potencial de desarrollo en el futuro.
Sin embargo, existe un problema al implementar una solución OFA general, es decir, Oracle no puede predecir si la actualización generará OEV, y si no se genera OEV, OFA introducirá retrasos adicionales porque Oracle necesita realizar operaciones adicionales para enviar el transacción a la plataforma de subasta media. Por otro lado, la forma más sencilla de optimizar el OEV y reducir la latencia es entregar todos los flujos de pedidos de Oracle a un buscador dominante, pero hacerlo obviamente traerá importantes riesgos de centralización y fomentará la extracción de rentas disfrazadas, la censura y, en última instancia, al usuario. la experiencia está comprometida.
Las actualizaciones de OFA a través de precios de subasta no incluyen las actualizaciones basadas en reglas existentes, que aún pasan por el grupo de memoria pública. Este mecanismo garantiza que las actualizaciones de precios de Oracle y cualquier ingreso adicional generado a partir de ellas permanezcan dentro de la capa de aplicación. Al mismo tiempo, este mecanismo también mejora la granularidad de los datos, lo que permite al buscador solicitar actualizaciones de la fuente de datos sin que el nodo de Oracle soporte el costo adicional de actualizaciones más frecuentes.
OFA es particularmente eficaz durante las liquidaciones porque proporciona actualizaciones de precios más granulares, maximiza el capital devuelto a los apostadores liquidados, reduce las recompensas pagadas por el protocolo a los liquidadores y elimina las ganancias adicionales de los liquidadores que ofertan para devolver a los usuarios.
Sin embargo, aunque la OFA ha resuelto hasta cierto punto el front-running y el arbitraje, todavía deja algunos problemas sin resolver. En el escenario de competencia perfecta y subasta sellada de precio único, la subasta debería hacer que los ingresos adicionales de las transacciones anticipadas se acerquen al costo del espacio de bloque requerido para realizar esta operación MEV. Al mismo tiempo, la mayor granularidad de las actualizaciones de precios aumentará. También reducir el arbitraje. La generación de oportunidades.
Actualmente, para implementar OFA exclusivo de Oracle, puede optar por integrarse con un servicio de subasta de terceros (como OEV-Share) o utilizar directamente el servicio de subasta como una aplicación DeFi y dejar que lo construya usted mismo.
API3 utiliza un relé OEV basado en el concepto Flashbots como API para proporcionar servicios de protección DoS al realizar subastas. Los retransmisores son responsables de recopilar metatransacciones de oráculos, filtrar y agregar ofertas de búsqueda y distribuir las ganancias en un entorno sin confianza. El ganador de la oferta debe transferir el monto de la oferta al contrato de proxy controlado por el protocolo, y luego los datos de firma proporcionados por el retransmisor actualizarán la fuente del precio.
Otra opción es que el protocolo cree su propio servicio de subasta nativo sin depender de un intermediario para capturar y eliminar todos los ingresos adicionales extraídos de OEV. El proyecto BBOX planea incorporar subastas en su mecanismo de liquidación para capturar OEV y devolverlo a las aplicaciones y usuarios. De esta manera, el protocolo puede distribuir mejor el valor y reducir la dependencia de servicios de terceros, mejorando así la autonomía del sistema y aumentando los beneficios para el usuario.
Ejecute un nodo centralizado o Keeper
En los primeros días de Web3, para abordar el problema de OEV a través de intercambios de contratos perpetuos impulsados por oráculos, se propuso la idea de ejecutar una red Keeper centralizada (nodo o entidad dedicada a transacciones). para comenzar desde intercambios centralizados, etc. Los precios se agregan a partir de fuentes de terceros, y los datos de Chainlink se utilizan como respaldo. Este patrón fue popularizado por GMX v1 y utilizado en muchas ramas posteriores. Su principal valor radica en la red Keeper gestionada por un único operador, lo que evita por completo el problema del front-run.
Por supuesto, este enfoque conlleva riesgos obvios de centralización. El sistema Keeper centralizado puede determinar el precio de ejecución sin verificar la fuente del precio. Keeper en GMX v1 no es un mecanismo transparente en la cadena, sino un programa que se ejecuta en un servidor centralizado por la dirección de su equipo y no puede verificar la autenticidad y la fuente del precio de ejecución.
Para la extracción de OEV, los buscadores monitorearán las "instrucciones de actualización de datos de Oracle" en el grupo de memoria y, a través de la infraestructura MEV, agruparán las instrucciones de transacción de actualización de datos de Oracle con las instrucciones de transacción iniciadas por ellos mismos y finalmente las ejecutarán para obtener ganancias. . Por supuesto, para las transacciones de arbitraje y compensación, OEV Searcher solo necesita monitorear la desviación entre el precio dentro de la cadena y el precio fuera de la cadena, y finalmente asegurarse de que las transacciones iniciadas por él se ejecuten primero en la cadena a través de la infraestructura MEV.
Independientemente del proceso que utilice el buscador, podemos ver que los ingresos de OEV se distribuyen entre la infraestructura MEV y el buscador de OEV, y el protocolo que "captura" el valor de OEV no recibe los ingresos correspondientes. (Según algunos datos, el problema de OEV anteriormente provocó que se quitaran casi el 10% de las ganancias de la plataforma GMX). Para resolver este problema, GMX, que ha contribuido con una gran cantidad de valor de OEV y es un -Plataforma de negociación de derivados en cadena, adoptó un método simple: permita que algunas personas que usted designe capturen el valor OEV y luego devuelvan estos valores OEV a la plataforma GMX tanto como sea posible.
En este sentido, GMX presentó Rook y la lista blanca. En pocas palabras, la actualización del oráculo de GMX se ejecuta a través de Rook, y Rook realizará una operación de extracción de OEV basada en las condiciones actuales del mercado para obtener OEV en el mercado. El 80% de estos OEV volverán al protocolo GMX.
En resumen, GMX le da a Rooks el derecho de actualizar el oráculo a través de la lista blanca, extraer OEV a través de Rook para evitar ser extraído por otros buscadores y, al mismo tiempo, devolver el 80% de OEV al sistema GMX. Esta rutina es en realidad un poco simple y tosca.
En vista de los riesgos de centralización causados por la red Keeper de un solo operador mencionada anteriormente, se pueden introducir proveedores de servicios externos para construir una red de automatización más descentralizada. El producto representativo es Chainlink Automation. Chainlink Automation funciona con Chainlink Data Streams, el nuevo servicio Oracle de baja latencia basado en pull de Chainlink. Se anunció que estaría en versión beta cerrada a finales de 2023, pero se puso en uso práctico en GMX v2.
Podemos consultar la lógica del sistema GMX v2 para explorar cómo integrar el diseño de Chainlink Data Streams en aplicaciones DeFi reales.
En general, Chainlink Data Streams consta de tres componentes principales: DON de datos, DON automatizado y contratos de verificación en cadena. Data DON es una red de datos fuera de la cadena cuya arquitectura para el mantenimiento y la agregación de datos es similar a Python. El DON automatizado es una red Keeper mantenida por el mismo operador de nodo que el DON de datos, que se utiliza para incorporar el precio del DON de datos a la cadena. Finalmente, el contrato de verificación dentro de la cadena se utiliza para garantizar la exactitud de la firma fuera de la cadena.
La figura anterior muestra el proceso de llamar a la función de transacción abierta, en la que el DON automatizado es responsable de obtener el precio de los datos DON y actualizar el almacenamiento en cadena. Actualmente, solo los usuarios de la lista blanca tienen permiso para consultar directamente los datos DON, por lo que el protocolo puede optar por transferir las tareas de mantenimiento al procesamiento automatizado de DON o ejecutar Keeper por sí mismo. Sin embargo, se espera que el producto pase gradualmente a una estructura sin permisos a medida que avanza el ciclo de desarrollo.
A nivel de seguridad, confiar en DON automatizado tiene los mismos supuestos de confianza que usar DON de datos solo, lo cual es una mejora muy obvia en comparación con el diseño de un único Keeper. Sin embargo, otorgar el derecho a actualizaciones de precios al DON automatizado también significa que OEV será exclusivo de los nodos de la red Keeper. Esta suposición de confianza es similar a la actitud de Ethereum hacia los operadores de nodos Lido. Los operadores de nodos de Lido suelen ser instituciones con mayor reputación social. Ocupan una mayor proporción del mercado de compromisos de Ethereum. Ethereum utiliza las limitaciones del consenso social para evitar que Lido se confabule con un cártel y forme un efecto de monopolio.
Oráculos de atracción: liquidación retrasada
El intercambio descentralizado de contratos perpetuos Synthetix v2 introduce datos de precios de Pyth para la liquidación de contratos, lo cual es una gran mejora. Las órdenes de los usuarios pueden elegir entre precios Chainlink o Pyth, siempre que la desviación del precio no exceda un umbral predeterminado y la marca de tiempo pase la verificación de obsolescencia. Sin embargo, simplemente cambiar a un oráculo basado en extracción no resuelve todos los problemas relacionados con OEV. Para hacer frente a las transacciones anticipadas, muchos protocolos DeFi han introducido mecanismos de fijación de precios de "última vista". Esta orden retrasada divide las órdenes de mercado de los usuarios en dos partes:
1. Los usuarios envían una "intención" de abrir una orden de mercado a la cadena, junto con parámetros de la orden como tamaño, apalancamiento, garantía y tolerancia al deslizamiento, y pagan tarifas adicionales de mantenimiento.
2.keeper recibe la orden, solicita los datos más recientes del precio de Pyth y llama a Synthetix en la transacción para ejecutar el contrato. El contrato verifica los parámetros predefinidos. Si todos pasan, se ejecuta la orden, se actualiza el almacenamiento de precios en la cadena y se abre la posición. El poseedor recibe tarifas pagadas por los usuarios para compensar las tarifas del gas y los costos de mantenimiento de la red que utilizan.
Este método evita que se envíen a la cadena precios que son desfavorables para los usuarios, resolviendo efectivamente el problema del front-running y el arbitraje en el protocolo. Sin embargo, este diseño implica ciertas compensaciones en la experiencia del usuario: ejecutar dichas órdenes de mercado requiere dos transacciones. Además de pagar las tarifas del gas, los usuarios también deben pagar por la actualización del almacenamiento en la cadena de Oracle.
Anteriormente, la tarifa para actualizar el almacenamiento de la cadena Oracle era fija de $ 2, pero recientemente se cambió a una tarifa dinámica basada en Optimism gas oracle + premium, que cambia según la actividad de la Capa 2. En resumen, esta solución mejora las ganancias de los proveedores de liquidez al tiempo que sacrifica cierta experiencia de usuario para los comerciantes.
Perspectivas para futuras ideas de soluciones OEV
Pull Oracle: mecanismo de liquidación optimista
A medida que los pedidos retrasados introducen tarifas adicionales para los usuarios, y estas tarifas aumentan en proporción a las tarifas de DA de L2, se concibió un modelo de liquidación de órdenes alternativo llamado "liquidación optimista" para reducir los costos de los usuarios manteniendo la descentralización y la seguridad del protocolo. Como sugiere el nombre, el mecanismo de liquidación optimista permite a los comerciantes ejecutar transacciones de mercado de manera atómica, donde el sistema acepta todos los precios de manera optimista y proporciona una ventana de tiempo para que los buscadores presenten pruebas que revelen si la orden existe con intenciones maliciosas.
Este artículo describirá varias iteraciones de esta idea, demostrará el proceso de pensamiento a lo largo del camino y describirá las cuestiones que quedan por abordar con esta línea de pensamiento.
La idea original era que los usuarios enviaran precios a través de parsePriceFeedUpdates al abrir una orden de mercado y luego permitir a los usuarios o a cualquier tercero enviar transacciones de liquidación y utilizar datos de precios para completar la confirmación de la transacción. En el momento de la liquidación, si hay una diferencia negativa entre los dos precios, esta diferencia actuará como un deslizamiento en las pérdidas y ganancias del usuario.
La ventaja de este enfoque es que reduce la carga de costos para los usuarios y mitiga el riesgo de transacciones anticipadas. Sin embargo, este método también introduce un proceso de liquidación de dos pasos, que es una deficiencia que encontramos en el modelo de liquidación retrasada de Synthetix. Las transacciones de liquidación adicionales pueden ser redundantes en la mayoría de los casos, especialmente cuando las fluctuaciones entre la colocación de órdenes y la liquidación no exceden el umbral inicial definido por el sistema.
Otra solución para evitar el problema anterior es permitir que el sistema acepte pedidos de manera optimista y luego abra un período de desafío sin permiso. Durante este período, cualquiera puede presentar pruebas que demuestren las desviaciones de precios entre las marcas de tiempo de precios y las marcas de tiempo de bloque, creando una oportunidad rentable de avance. Al introducir un período de desafío, el mecanismo de optimismo reduce efectivamente el posible arbitraje en el sistema y aumenta la transparencia y equidad del proceso de transacción.
El proceso específico es el siguiente:
1. El usuario crea una orden de mercado al precio de mercado actual y envía este precio junto con los datos de precio Pyth integrados como una transacción de creación de orden.
2. El contrato inteligente verifica y almacena de manera optimista esta información.
3. Una vez confirmada y cargada la orden en la cadena, habrá un período de impugnación, durante el cual el buscador puede presentar pruebas de que el comerciante tiene intenciones maliciosas. Esta prueba debe incluir evidencia de que el comerciante utilizó precios pasados con la intención de realizar un arbitraje. Si el sistema acepta la prueba, el diferencial se aplicará al precio de ejecución del comerciante como deslizamiento, y los ingresos originales del OEV se entregarán al Keeper como recompensa.
4. Una vez finalizado el período de desafío, el sistema considerará válidos todos los precios.
Este modelo optimista tiene dos ventajas: primero, reduce la carga de costos para los usuarios. Los usuarios solo necesitan pagar las tarifas de gas para la creación de pedidos y la actualización de Oracle en la misma transacción, sin tarifas de liquidación de transacciones adicionales. En segundo lugar, inhibe las transacciones anticipadas y utiliza un mecanismo de incentivo económico para presentar pruebas de las transacciones anticipadas bajo una red de guardianes saludable, protegiendo así la integridad del fondo de liquidez.
Aunque esta idea tiene un gran potencial, si se quiere implementar, todavía quedan algunos problemas abiertos que deben resolverse:
Definir el problema de la “selección del adversario”: cómo el sistema distingue entre los usuarios que envían precios vencidos debido a retrasos en la red y los usuarios que explotan deliberadamente el arbitraje retrasado. Una idea preliminar es medir la volatilidad dentro del tiempo de la verificación de obsolescencia (por ejemplo, 15 segundos). Si la volatilidad excede la tarifa de ejecución neta, la orden puede marcarse como un posible comportamiento de arbitraje.
Establezca un período de impugnación adecuado: teniendo en cuenta que el tiempo de apertura del flujo de órdenes maliciosas puede ser corto, el poseedor debe tener un período de tiempo razonable para impugnar el precio. Aunque la verificación por lotes puede ahorrar gasolina, la imprevisibilidad del flujo de pedidos dificulta garantizar que todos los datos de precios puedan verificarse o cuestionarse de manera oportuna.
Incentivos económicos para Keeper: el costo del gas para enviar la verificación no es bajo. Para garantizar que Keeper tenga un efecto positivo en el sistema, la recompensa por enviar la verificación debe ser mayor que el costo de la presentación. Sin embargo, las diferencias en el tamaño del pedido pueden hacer que esta suposición no sea necesariamente cierta en todos los casos.
¿Es necesario crear un mecanismo similar para cerrar órdenes? ¿Qué impacto, si alguno, podría tener en la experiencia del usuario?
Asegúrese de que los usuarios no se vean afectados por un deslizamiento "irrazonable": en caso de una caída repentina del mercado, puede haber una enorme diferencia de precio entre la creación de la orden y la confirmación en la cadena, lo que requerirá algún tipo de medida de limitación de pérdidas o mecanismo de disyuntor. Aquí consideramos utilizar el precio EMA proporcionado por Pyth para garantizar la estabilidad de la fuente de precios.
Coprocesador ZK: otra forma de consumo de datos
Otra dirección que vale la pena explorar es el uso de coprocesadores ZK. Estos procesadores están diseñados para procesar cálculos complejos fuera de la cadena y poder acceder al estado dentro de la cadena mientras proporcionan pruebas para garantizar que los resultados de los cálculos se puedan verificar sin permiso. Proyectos como Axiom permiten que los contratos consulten datos históricos de blockchain, realicen cálculos fuera de la cadena y envíen pruebas ZK para garantizar que los resultados se calculen correctamente en función de datos válidos en la cadena. El coprocesador hace posible construir un oráculo TWAP personalizado resistente a la manipulación basado en múltiples fuentes de liquidez nativas de DeFi (como Uniswap+Curve).
En comparación con los oráculos tradicionales, los coprocesadores ZK ampliarán la gama de datos que se pueden proporcionar de forma segura a las dApps. Actualmente, los oráculos tradicionales proporcionan principalmente los datos más recientes sobre los precios de los activos (como el precio EMA proporcionado por Pyth). A través del coprocesador ZK, las aplicaciones pueden introducir más lógica empresarial basada en datos históricos de blockchain para mejorar la seguridad del protocolo o mejorar la experiencia del usuario.
Sin embargo, el coprocesador ZK aún se encuentra en las primeras etapas de desarrollo y enfrentará algunos cuellos de botella, tales como:
El proceso puede resultar demasiado largo cuando se trata de grandes cantidades de datos de blockchain.
Limitarse a los datos de blockchain no aborda la necesidad de una comunicación segura con aplicaciones que no sean Web3.
De-oracle: ¿el futuro de DeFi?
Una nueva idea es que el problema de la dependencia de Oracle en DeFi se puede resolver diseñando una primitiva que elimine fundamentalmente la necesidad de datos de precios externos. Recientemente, también han surgido diseños que utilizan varios tokens AMM LP como herramientas de fijación de precios. Esto se basa en un concepto central: en un creador de mercado de función constante, la posición LP representa el peso preestablecido de dos activos en el grupo de negociación, y la transacción sigue una fórmula de fijación de precios automática (como xy=k). Al utilizar tokens LP, el protocolo puede obtener directamente información que normalmente requeriría un oráculo, permitiendo así soluciones sin oráculo. Este tipo de solución reduce la dependencia del protocolo DeFi de los oráculos y algunos proyectos están creando aplicaciones en esta dirección.
en conclusión
Los datos de precios siguen siendo un componente central de muchas aplicaciones descentralizadas en la actualidad, y el valor total de los activos protegidos a través de oráculos continúa aumentando, lo que demuestra aún más la importancia de los oráculos en el mercado. Este artículo tiene como objetivo llamar la atención sobre los riesgos asociados con los ingresos adicionales (OEV) actuales de Oracle y explora el potencial de soluciones de diseño alternativas como push, pull y el uso de AMM LP o coprocesadores fuera de la cadena.
