¿Por qué hay tantos Prop AMM en Solana, mientras que en EVM sigue siendo un vacío?

Título original: dApps que debes ver después del lanzamiento de Monad Mainnet

Autor original: Optimus

Fuente original:

Reimpresión: Mars Finance

Los AMMs de Prop han ocupado rápidamente el 40% del volumen total de transacciones en Solana. ¿Por qué aún no han aparecido en EVM?

Los AMM propietarios (Proprietary AMMs, abreviados como Prop AMMs) se están convirtiendo rápidamente en una fuerza dominante en el ecosistema DeFi de Solana, y actualmente han contribuido con más del 40% del volumen de transacciones en los principales pares de negociación. Este tipo de lugares de liquidez especializados operados por creadores de mercado profesionales pueden ofrecer liquidez profunda y precios más competitivos, siendo la razón principal que reducen significativamente el riesgo de que los creadores de mercado sean explotados por “cotizaciones obsoletas” (stale quotes) para arbitrajes de adelantamiento (front-running).

Sin embargo, su éxito está casi completamente limitado a Solana. Incluso en redes Layer 2 rápidas y de bajo costo como Base u Optimism, la presencia de Prop AMM en el ecosistema EVM sigue siendo escasa. ¿Por qué no han echado raíces en EVM?

Este artículo explora tres cuestiones: ¿Qué son los Prop AMM?, ¿qué obstáculos técnicos y económicos enfrentan en las cadenas EVM?, y ¿cuáles son las nuevas arquitecturas prometedoras que podrían llevarlos a la vanguardia de DeFi en EVM?

¿Qué es Prop AMM?

Prop AMM es un creador de mercado automático gestionado activamente por un solo creador de mercado profesional que maneja la liquidez y los precios, en lugar de que sea proporcionado pasivamente por el público como en el AMM tradicional.

Los AMM tradicionales (como Uniswap v2) generalmente utilizan la fórmula x * y = k para determinar el precio, donde x e y representan respectivamente la cantidad de dos activos en el grupo, y k es un valor constante. Sin embargo, en los AMM Prop, la fórmula de precios no es fija, sino que se actualiza con alta frecuencia (generalmente varias veces por segundo). Dado que la mayoría de los mecanismos internos de los AMM Prop son “cajas negras”, el exterior no conoce el algoritmo exacto que utilizan. Sin embargo, el código del contrato inteligente del AMM Prop de Obric en la cadena Sui es público (gracias al descubrimiento de @markoggwp), y su invariante k depende de las variables internas mult_x, mult_y y concentración. La siguiente imagen muestra cómo los creadores de mercado actualizan continuamente estas variables.

Un punto que necesita aclaración es que la fórmula a la izquierda de la curva de precios de Obric es más compleja que simplemente x*y, pero la clave para entender Prop AMM es que siempre es igual a una invariante variable k, y los creadores de mercado actualizarán constantemente este k para ajustar la curva de precios.

Revisión: ¿Cómo determina el AMM los precios?

En este artículo, mencionaremos varias veces el concepto de “curva de precios”. La curva de precios determina el precio que los usuarios deben pagar al realizar transacciones en AMM, y también es una parte que los creadores de mercado actualizan constantemente en Prop AMM. Para entender mejor esto, primero podemos repasar el método de fijación de precios en AMM tradicional.

Tomando como ejemplo el pool WETH-USDC en Uniswap v2 (suponiendo que no hay tarifas). El precio se determina pasivamente por la fórmula x * y = k. Supongamos que hay 100 WETH y 400,000 USDC en el pool, el punto de la curva en este momento es x = 100, y = 400,000, lo que corresponde a un precio inicial de 400,000 / 100 = 4,000 USDC/WETH. De aquí se obtiene la constante k = 100 * 400,000 = 40,000,000.

Si un comerciante desea comprar 1 WETH, necesita agregar USDC al fondo, lo que reduce la cantidad de WETH en el fondo a 99. Para mantener el producto constante k, el nuevo punto (x, y) todavía debe caer en la curva, por lo que y debe convertirse en 40,000,000 / 99 ≈ 404,040.40. Es decir, el comerciante pagó aproximadamente 4,040.40 USDC por 1 WETH, que es ligeramente más alto que el precio inicial. Este fenómeno se conoce como “deslizamiento de precios” (slippage). Esta es la razón por la cual x*y=k se llama “curva de precios”: cualquier precio negociable debe caer en esta curva.

¿Por qué los creadores de mercado elegirían un diseño AMM en lugar de un libro de órdenes centralizado (CLOB)?

Vamos a explicar por qué los creadores de mercado quieren usar un diseño de AMM para hacer mercado. Imagina que eres un creador de mercado que cotiza en un libro de órdenes centralizado (CLOB) en la cadena. Si deseas actualizar tu cotización, necesitas cancelar y reemplazar miles de órdenes limitadas. Si tienes N órdenes, entonces el costo de actualización es una operación de nivel O(N), lo cual es lento y costoso en la cadena.

¿Y si pudieras representar todas las cotizaciones con una curva matemática? Solo necesitas actualizar unos pocos parámetros que definen esa curva, transformando así la operación de O(N) en una complejidad constante de O(1).

Para mostrar de manera intuitiva cómo la “curva de precios” corresponde a diferentes rangos de precios efectivos, podemos referirnos a SolFi, creado por Ellipsis Labs, que es un Prop AMM basado en Solana. Aunque su curva de precios específica es desconocida y está oculta, Ghostlabs ha trazado un gráfico que muestra los precios efectivos al intercambiar diferentes cantidades de SOL por USDC dentro de un slot de Solana (período de tiempo de bloque). Cada línea representa un diferente pool de WSOL/USDC, indicando que múltiples niveles de precios pueden existir simultáneamente. A medida que los creadores de mercado actualizan la curva de precios, este gráfico de precios efectivos también variará entre diferentes slots.

El punto clave aquí es que, al actualizar solo unos pocos parámetros de la curva de precios, los creadores de mercado pueden cambiar la distribución de precios efectivos en cualquier momento, sin necesidad de modificar cada uno de los N pedidos. Este es precisamente el valor central de Prop AMM: permite a los creadores de mercado proporcionar liquidez dinámica y profunda con una mayor eficiencia de capital y cálculo.

¿Por qué la arquitectura de Solana es muy adecuada para Prop AMM?

Prop AMM es un sistema de «gestión activa», lo que significa que necesita dos condiciones clave:

1. Actualizaciones de bajo costo (cheap updates)

2. Derecho de ejecución prioritaria

En Solana, ambos son complementarios: las actualizaciones de bajo costo a menudo significan que las actualizaciones pueden obtener prioridad de ejecución.

¿Por qué necesitan los creadores de mercado estos dos puntos? Primero, actualizan continuamente la curva de precios según las fluctuaciones del inventario o el precio del índice de activos (como el precio en un intercambio centralizado) con la velocidad de funcionamiento de la blockchain. En cadenas de alta frecuencia como Solana, si el costo de actualización es demasiado alto, será difícil lograr ajustes de alta frecuencia.

En segundo lugar, si los creadores de mercado no pueden hacer que las actualizaciones se coloquen en la parte superior del bloque, sus ofertas antiguas serán “aprovechadas” por los arbitrajistas, lo que resultará en pérdidas inevitables. Si faltan estas dos características, los creadores de mercado no podrán operar de manera eficiente, y los usuarios también recibirán precios de transacción peores.

Tomando como ejemplo el Prop AMM HumidiFi en Solana, según los datos de @SliceAnalytics, este creador de mercado actualiza sus precios hasta 74 veces por segundo.

Los jugadores de EVM pueden preguntarse: “El slot de Solana es de aproximadamente 400 ms, ¿cómo puede Prop AMM actualizar el precio varias veces dentro de un solo slot?”

La respuesta radica en la arquitectura continua de Solana, que es esencialmente diferente del modelo de bloques discretos de EVM.

· EVM: Las transacciones generalmente se ejecutan en orden después de que se propone y confirma un bloque completo. Esto significa que las actualizaciones enviadas a mitad de camino no se verán afectadas hasta el siguiente bloque.

· Solana: Los nodos validados de Leader no esperan un bloque completo, sino que dividen las transacciones en pequeños paquetes de datos (llamados “shred”) y los transmiten continuamente a la red. Puede haber múltiples intercambios dentro de un slot, pero shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.

Nota: Flashblocks es similar a los shreds de Solana. Según la presentación de @Ashwinningg de Anza Labs en la conferencia CBER, el límite por slot de 400 ms es de 32,000 shreds, lo que equivale a 80 shreds por milisegundo. En cuanto a si los Flashblocks de 200 ms son lo suficientemente rápidos para satisfacer las necesidades de los creadores de mercado, sigue siendo una pregunta abierta en comparación con la arquitectura continua de Solana.

Entonces, ¿por qué las actualizaciones en Solana son tan baratas? ¿Y cómo conducen a la ejecución prioritaria?

Primero, aunque la implementación de Prop AMM en Solana es una caja negra, existen bibliotecas como Pinocchio que permiten optimizar la forma de escribir programas en Solana. El blog de Helius tiene una excelente introducción sobre esto, a través de esta biblioteca, el consumo de CU de un programa de Solana puede reducirse de aproximadamente 4000 CU a alrededor de 100 CU.

Ahora veamos la segunda parte. A un nivel más alto, Solana prioriza las transacciones seleccionando aquellas con la mejor relación entre tarifas y unidades de cómputo (las unidades de cómputo son similares al gas de EVM), de manera similar a EVM.

· En concreto, si se utiliza Jito, la fórmula es Jito Tip / Compute Units

· No utilizar: Prioridad = ( tarifa preferencial + tarifa básica ) / (1 + límite CU + firma CU + bloqueo de escritura CU )

Al comparar las unidades de cómputo de la actualización de Prop AMM con las de Jupiter Swap, se puede ver que la actualización es extremadamente barata, con una proporción de 1:1000.

Actualización de Prop AMM: la actualización de la curva simple es extremadamente económica. La actualización de Wintermute es de solo 109 CU, con un costo total de solo 0.000007506 SOL.

Jupiter Swap: el swap a través del enrutador de Jupiter puede alcanzar ~100,000 CU, con un costo total de 0.000005 SOL

Debido a esta enorme diferencia, los creadores de mercado solo necesitan pagar una pequeña tarifa por las actualizaciones de transacciones, lo que les permite lograr una tasa de Fee/CU muy superior a la del intercambio, garantizando así que las actualizaciones se ejecuten en la parte superior del bloque y se protejan de ataques de arbitraje.

¿Por qué Prop AMM aún no se ha implementado en EVM?

Supongamos que la actualización de Prop AMM implica la escritura de variables que determinan la curva de precios del par de negociación. Aunque el código de Prop AMM en Solana es una “caja negra”, los creadores de mercado desean mantener en secreto su estrategia, pero podemos usar esta suposición para entender cómo Obric implementa Prop AMM en Sui: las variables que determinan las cotizaciones del par de negociación se escriben en el contrato inteligente a través de la función update.

¡Gracias @markoggwp por descubrirlo!

Utilizando esta suposición, descubrimos que la arquitectura de EVM presenta obstáculos significativos que hacen que el modelo Prop AMM de Solana no sea viable en EVM.

Recapitulando, en las blockchains de capa 2 de OP-Stack (como Base y Unichain), las transacciones se ordenan según la tarifa de prioridad de gas (similar a cómo Solana ordena según tarifa / CU).

En EVM, el consumo de Gas para las operaciones de escritura es muy alto. En comparación con las actualizaciones de Solana, el costo de escribir un valor en EVM a través del opcode SSTORE es asombroso:

· SSTORE (0 → no 0): ~22,100 gas

· SSTORE (no 0 → no 0): ~5,000 gas

· Intercambio AMM típico: ~200,000–300,000 gas

Nota: El gas en EVM es similar a la unidad de cómputo (CU) en Solana. El número de gas SSTORE anterior asume que cada transacción tiene solo una escritura (escritura en frío), lo cual es razonable, ya que generalmente no se envían múltiples actualizaciones en una sola transacción.

Aunque las actualizaciones siguen siendo más baratas que el intercambio, la tasa de uso de gas es solo aproximadamente 10 veces (las actualizaciones pueden involucrar múltiples SSTORE), mientras que en Solana esta proporción es de aproximadamente 1000 veces.

Esto trae dos conclusiones, lo que hace que el mismo modelo de Solana Prop AMM tenga un mayor riesgo en EVM:

1. Un alto consumo de Gas dificulta garantizar que las tarifas prioritarias se actualicen, y unas tarifas prioritarias más bajas no pueden lograr una alta relación de tarifas/Gas. Para asegurar que las actualizaciones no sean ejecutadas anticipadamente y se ubiquen en la parte superior del bloque, se requieren tarifas prioritarias más altas, lo que incrementa los costos.

2. El riesgo de arbitraje en EVM es mayor, la actualización de Gas y la proporción de intercambio de Gas en EVM es solo de 1:10, mientras que en Solana es de 1:1000. Esto significa que los arbitrajistas solo necesitan aumentar la tarifa de prioridad 10 veces para adelantar la actualización de los creadores de mercado, mientras que en Solana deben aumentarla 1000 veces. Con esta proporción más baja, es más probable que los arbitrajistas realicen transacciones anticipadas para obtener precios desactualizados, ya que el costo es bajo.

Algunas innovaciones (como TSTORE de EIP-1153, utilizado para almacenamiento temporal) ofrecen aproximadamente 100 gas para escritura, pero este almacenamiento es efímero, válido solo en una transacción única, y no se puede utilizar para persistir actualizaciones de precios para su uso en intercambios posteriores (por ejemplo, durante todo el período del bloque).

¿Cómo introducir Prop AMM en EVM?

Antes de responder, primero responde "¿por qué hacerlo?: los usuarios siempre buscan obtener mejores ofertas de trading, lo que significa que las transacciones son más rentables. Prop AMM de Ethereum y Layer 2 puede ofrecer a los usuarios precios competitivos que originalmente solo se podían obtener en Solana o en intercambios centralizados.

Para hacer que Prop AMM sea viable en EVM, revisamos una de las razones de su éxito en Solana:

· Protección de actualización en la parte superior del bloque: en Solana, la actualización de Prop AMM se encuentra en la parte superior del bloque, lo que puede proteger a los creadores de mercado de las transacciones front-running. La actualización se sitúa en la parte superior porque el consumo de unidades de cálculo es muy bajo, lo que permite una alta relación de tarifas/CU incluso con tarifas bajas, especialmente en comparación con las transacciones de intercambio.

Entonces, ¿cómo introducir la actualización de Prop AMM en la parte superior del bloque en una blockchain EVM de Layer 2? Hay dos métodos: reducir el costo de escritura o crear un canal prioritario para la actualización de Prop AMM.

Debido al problema de crecimiento del estado de EVM, reducir el costo de escritura no es un método muy viable, ya que un SSTORE barato puede resultar en ataques de estado basura.

Proponemos crear un canal prioritario para la actualización de Prop AMM. Esta es una solución viable y también es el enfoque principal de este artículo.

El equipo de Uniswap, @MarkToda, propuso un nuevo método para lograrlo a través de contratos inteligentes de almacenamiento global + una estrategia de constructor de bloques dedicada:

Su funcionamiento es el siguiente:

· Contratos de almacenamiento global: despliegue de contratos inteligentes simples como almacenamiento de clave-valor público. Los creadores de mercado escriben los parámetros de la curva de precios en este contrato (por ejemplo, set(ETH-USDC_CONCENTRATION, 4000)).

· Estrategia del constructor: Este es un componente clave fuera de la cadena. El constructor de bloques identifica las transacciones enviadas al contrato de almacenamiento global, asigna el 5-10% de Gas del bloque a estas transacciones de actualización y las ordena por prioridad de tarifas para prevenir transacciones basura.

Por favor, ten en cuenta: las transacciones deben enviarse directamente a la dirección de almacenamiento global, de lo contrario, no se puede garantizar que estén en la parte superior del bloque.

Un ejemplo de algoritmo de construcción de bloques personalizado se puede consultar en rblib.

Integración de Prop AMM: El contrato Prop AMM del creador de mercado lee los datos de la curva de precios del contrato de almacenamiento global al intercambiar, proporcionando así las cotizaciones.

Esta arquitectura resuelve ingeniosamente dos problemas:

1. Protección: La estrategia del constructor crea un “canal rápido”, asegurando que todas las actualizaciones de precios dentro del bloque se ejecuten antes de la transacción, eliminando el riesgo de front-running.

2. Rentabilidad: los creadores de mercado ya no compiten con todos los usuarios de DeFi por las transacciones en la parte superior de los bloques con altos precios de Gas, sino que solo compiten en el mercado de tarifas local para actualizar las transacciones reservadas en la parte superior de los bloques, lo que reduce significativamente los costos.

Las transacciones de los usuarios se ejecutarán de acuerdo con la curva de precios establecida por el creador de mercado en el mismo bloque inicial, asegurando la frescura y seguridad de las cotizaciones. Este modelo reproduce en EVM un entorno de actualizaciones de bajo costo y alta prioridad similar al de Solana, allanando el camino para Prop AMM en EVM.

Sin embargo, este modelo también tiene algunas desventajas, que dejaré al final de este artículo para discutir.

Conclusión

La viabilidad del AMM de Prop depende de resolver problemas económicos fundamentales: ejecución prioritaria y a bajo costo para prevenir el front-running.

Aunque la arquitectura estándar de EVM hace que estas operaciones sean costosas y arriesgadas, el nuevo diseño ofrece un enfoque diferente para resolver este problema. La combinación de contratos inteligentes de almacenamiento global en cadena y estrategias de constructores fuera de la cadena en el nuevo diseño permite crear “canales rápidos” dedicados, garantizando la ejecución de actualizaciones en la parte superior del bloque, al mismo tiempo que se establece un mercado de tarifas local y controlado. Esto no solo hace que Prop AMM sea factible en EVM, sino que también podría revolucionar todo el DeFi de EVM que depende de las actualizaciones de oráculos en la parte superior del bloque.

preguntas abiertas

· ¿La velocidad de 200 ms de Flashblock en EVM de Prop AMM es suficiente para competir con la arquitectura continua de Solana?

· La mayor parte del tráfico de AMM en Solana proviene de un único agregador, Jupiter, que ofrece un SDK que facilita la integración de AMM. Sin embargo, en Layer 2 EVM, el tráfico se distribuye entre varios agregadores y no hay un SDK público, ¿esto representa un desafío para Prop AMM?

· ¿Cómo funciona el mecanismo de implementación de Prop AMM en Solana, que solo consume aproximadamente 100 CU?

· El modelo de canal rápido solo garantiza la actualización de la parte superior del bloque. Si hay múltiples intercambios dentro de un Flashblock, ¿cómo actualizará el creador de mercado los precios entre estos intercambios?

· ¿Es posible escribir programas EVM optimizados en lenguajes como Yul o Huff, similar a la solución de optimización Pinocchio en Solana?

· ¿Cómo se compara Prop AMM con RFQ?

· ¿Cómo prevenir que los creadores de mercado ofrezcan cotizaciones de alta calidad en el bloque N para inducir a los usuarios y luego actualizar a cotizaciones malas en el bloque N+1? ¿Cómo se protege Jupiter?

· La función de Ultra Signaling de Jupiter Ultra V3 permite a Prop AMM distinguir entre tráfico dañino y no dañino, y ofrece cotizaciones más ajustadas. ¿Cuál es la importancia de estas características de agregador para Prop AMM en EVM?