¿Por qué hay tantos Prop AMM en Solana, pero todavía no existen en EVM?

Título original: Must-Watch dApps After Monad Mainnet Launch

Autor original: Optimus, Fundador de Waterloo Blockchain

Traducción original: Dingdang, Odaily

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

Los Market Makers Automáticos Propietarios (Proprietary AMMs, o Prop AMMs) están convirtiéndose rápidamente en la fuerza dominante dentro del ecosistema DeFi de Solana, contribuyendo actualmente con más del 40% del volumen de trading en los principales pares. Estos lugares de liquidez especializados, operados por market makers profesionales, pueden ofrecer una liquidez profunda y precios más competitivos, principalmente porque reducen significativamente el riesgo de que los market makers sean explotados mediante “cotizaciones obsoletas” (stale quotes) para hacer front-running y arbitraje.

Fuente de la imagen: dune.com

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

Este artículo explora principalmente tres cuestiones: qué es un Prop AMM, qué barreras técnicas y económicas enfrentan en cadenas EVM, y qué nuevas arquitecturas prometedoras podrían finalmente llevarlos a la vanguardia de DeFi en EVM.

¿Qué es un Prop AMM?

Un Prop AMM es un market maker automático gestionado activamente por un único market maker profesional, que administra la liquidez y la fijación de precios, en lugar de que el público aporte fondos de manera pasiva como en los AMM tradicionales.

Los AMM tradicionales (como Uniswap v2) suelen usar la fórmula x * y = k para determinar el precio, donde x e y representan la cantidad de dos activos en el pool, y k es una constante. En los Prop AMM, la fórmula de precios no es fija, sino que se actualiza a alta frecuencia (normalmente varias veces por segundo). Dado que la mayoría de los mecanismos internos de los Prop AMM son una “caja negra”, el público no conoce el algoritmo exacto que utilizan. Sin embargo, el código del contrato inteligente del Prop AMM Obric en la cadena Sui es público (gracias a @markoggwp por el hallazgo), y su invariante k depende de las variables internas mult_x, mult_y y concentration. La siguiente imagen muestra cómo el market maker actualiza continuamente estas variables.

Es importante aclarar: la fórmula en el lado izquierdo de la curva de precios de Obric es más compleja que el simple x*y, pero la clave para entender los Prop AMM es que siempre es igual a una invariante k variable, y el market maker actualiza constantemente ese k para ajustar la curva de precios.

Repaso: ¿Cómo determina el precio un AMM?

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 operar en un AMM, y es la parte que el market maker actualiza constantemente en un Prop AMM. Para entenderlo mejor, repasemos cómo fijan los precios los AMM tradicionales.

Tomemos como ejemplo el pool WETH-USDC en Uniswap v2 (suponiendo sin comisiones). El precio se determina pasivamente por la fórmula x * y = k. Supongamos que el pool tiene 100 WETH y 400,000 USDC, el punto de la curva es x = 100, y = 400,000, lo que da un precio inicial de 400,000 / 100 = 4,000 USDC/WETH. Así, la constante k = 100 * 400,000 = 40,000,000.

Si un trader quiere comprar 1 WETH, debe añadir USDC al pool, haciendo que el WETH en el pool baje a 99. Para mantener el producto constante k, el nuevo punto (x, y) debe estar en la curva, así que y debe ser 40,000,000 / 99 ≈ 404,040.40. Es decir, el trader paga unos 4,040.40 USDC por 1 WETH, un poco más que el precio inicial. Este fenómeno se llama “slippage” o deslizamiento de precio. Por eso x*y=k se llama “curva de precios”: cualquier precio negociable debe estar en esa curva.

¿Por qué los market makers eligen el diseño AMM en vez de un libro de órdenes centralizado (CLOB)?

Expliquemos por qué los market makers quieren usar el diseño AMM para hacer market making. Imagina que eres un market maker cotizando en un libro de órdenes centralizado en cadena (CLOB). Si quieres actualizar tus cotizaciones, debes cancelar y reemplazar miles de órdenes limitadas. Si tienes N órdenes, el coste de actualización es O(N), lo que es lento y caro en cadena.

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

Para mostrar visualmente cómo la “curva de precios” corresponde a diferentes rangos de precios efectivos, podemos referirnos a SolFi, creado por Ellipsis Labs, un Prop AMM basado en Solana. Aunque su curva de precios exacta es desconocida y está oculta, Ghostlabs dibujó un gráfico que muestra, en un slot de Solana, el precio efectivo de intercambiar diferentes cantidades de SOL por USDC. Cada línea representa un pool diferente de WSOL/USDC, mostrando que pueden existir varios niveles de precios simultáneamente. A medida que el market maker actualiza la curva de precios, este gráfico de precios efectivos también cambia entre slots.

Fuente de la imagen: github

La clave aquí es que, al actualizar solo unos pocos parámetros de la curva de precios, el market maker puede cambiar la distribución de precios efectivos en cualquier momento, sin tener que modificar uno por uno los N órdenes. Esta es la propuesta de valor central de los Prop AMM: permiten a los market makers ofrecer liquidez dinámica y profunda con mayor eficiencia de capital y computacional.

¿Por qué la arquitectura de Solana es ideal para los Prop AMM?

Un Prop AMM es un sistema “gestionado activamente”, lo que significa que requiere dos condiciones clave:

1. Bajo coste de actualización (cheap updates)

2. Ejecución prioritaria (priority execution)

En Solana, estos dos factores se complementan: un bajo coste de actualización suele significar que la actualización obtiene prioridad de ejecución.

¿Por qué los market makers necesitan esto? Primero, actualizan la curva de precios constantemente, a la velocidad de la blockchain, según los cambios en el inventario o el precio índice del activo (por ejemplo, el precio en exchanges centralizados). En una cadena de alta frecuencia como Solana, si el coste de actualización es alto, será difícil hacer ajustes frecuentes.

Segundo, si el market maker no puede poner su actualización al principio del bloque, los arbitrajistas pueden aprovechar sus cotizaciones antiguas, causando pérdidas inevitables. Sin estas dos características, el market maker no puede operar eficientemente y los usuarios obtendrán peores precios.

Por ejemplo, en el Prop AMM HumidiFi de Solana, según datos de @SliceAnalytics, este market maker actualiza sus cotizaciones hasta 74 veces por segundo.

Los usuarios de EVM podrían preguntar: “El slot de Solana dura unos 400ms, ¿cómo puede un Prop AMM actualizar el precio varias veces en un solo slot?”

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

· EVM: Las transacciones suelen ejecutarse en orden después de que se propone y confirma un bloque completo. Esto significa que las actualizaciones enviadas a mitad de camino solo entran en vigor en el siguiente bloque.

· Solana: El nodo validador líder no espera a un bloque completo, sino que divide las transacciones en pequeños paquetes de datos (llamados “shred”) y los transmite continuamente por la red. Puede haber múltiples swaps en un slot, pero la actualización de precios en el shred #1 afecta al swap #1, la del shred #2 al swap #2, etc.

Nota: Los Flashblocks son similares a los shred de Solana. Según la presentación de @Ashwinningg de Anza Labs en la conferencia CBER, el límite superior de un slot de 400ms es de 32,000 shred, es decir, 80 shred por milisegundo. Si los Flashblocks de 200ms son lo suficientemente rápidos para los market makers, comparado con la arquitectura continua de Solana, sigue siendo una cuestión abierta.

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

Primero, aunque la implementación de Prop AMM en Solana es una caja negra, existen librerías como Pinocchio que permiten escribir programas de Solana optimizados para el uso de CU. El blog de Helius lo explica muy bien: usando esta librería, el consumo de CU de un programa de Solana puede bajar de unos 4000 CU a unos 100 CU.

Fuente de la imagen: github

Ahora la segunda parte. A un nivel más alto, Solana prioriza las transacciones que tienen la mayor relación Fee / Compute Units (Compute Units es similar al Gas de EVM), igual que EVM.

· Específicamente, si usas Jito, la fórmula es Jito Tip / Compute Units

· Si no: Priority = (tarifa prioritaria + tarifa base) / (1 + límite de CU + CU de firma + CU de bloqueo de escritura)

Comparando los Compute Units de una actualización de Prop AMM y un swap de Jupiter, se ve que la actualización es extremadamente barata, con una proporción de 1:1000.

Actualización de Prop AMM: Una actualización de curva simple es muy barata. La actualización de Wintermute es tan baja como 109 CU, con un coste total de solo 0.000007506 SOL

Jupiter Swap: Un swap en Jupiter puede llegar a ~100,000 CU, con un coste total de 0.000005 SOL

Debido a esta enorme diferencia, los market makers solo necesitan pagar una tarifa mínima por las transacciones de actualización para lograr una relación Fee/CU mucho mayor que la de los swaps, asegurando que sus actualizaciones se ejecuten en la parte superior del bloque y protegiéndose de ataques de arbitraje.

¿Por qué los Prop AMM aún no han aterrizado en EVM?

Supongamos que la actualización de un Prop AMM implica escribir variables que determinan la curva de precios del par. Aunque el código de los Prop AMM en Solana es una “caja negra” y los market makers quieren mantener su estrategia confidencial, podemos usar esta suposición para entender cómo Obric implementa un Prop AMM en Sui: las variables que determinan la cotización del par se escriben en el contrato inteligente mediante una función de actualización.

¡Gracias a @markoggwp por el hallazgo!

Con esta suposición, vemos que la arquitectura de EVM presenta obstáculos importantes que hacen inviable el modelo de Prop AMM de Solana en EVM.

Recordemos que en blockchains Layer 2 OP-Stack (como Base y Unichain), las transacciones se ordenan por tarifa prioritaria por Gas (similar a cómo Solana ordena por Fee / CU).

En EVM, las operaciones de escritura consumen mucho Gas. Comparado con Solana, donde la actualización es barata, en EVM el coste de escribir un valor con el opcode SSTORE es sorprendente:

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

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

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

Nota: El Gas en EVM es similar a los Compute Units en Solana. Los números de gas SSTORE anteriores suponen una sola escritura por transacción (escritura en frío), lo cual es razonable porque normalmente no se envían múltiples actualizaciones en una sola transacción.

Aunque la actualización sigue siendo más barata que el swap, el uso de gas es solo unas 10 veces menor (la actualización puede implicar múltiples SSTORE), mientras que en Solana la proporción es de unas 1000 veces.

Esto lleva a dos conclusiones que hacen que el mismo modelo de Prop AMM de Solana sea más riesgoso en EVM:

1. El alto consumo de gas dificulta que la tarifa prioritaria garantice la prioridad de la actualización, ya que una tarifa prioritaria baja no logra una alta relación tarifa/gas. Para asegurar que la actualización no sea adelantada y esté en la parte superior del bloque, se necesita una tarifa prioritaria más alta, lo que aumenta el coste.

2. El riesgo de arbitraje es mayor en EVM, ya que la proporción de gas de actualización frente a swap es solo de 1:10, mientras que en Solana es de 1:1000. Esto significa que un arbitrajista solo necesita aumentar la tarifa prioritaria 10 veces para adelantar la actualización del market maker, mientras que en Solana tendría que aumentarla 1000 veces. Con esta proporción más baja, es más probable que los arbitrajistas adelanten la actualización de precios para aprovechar cotizaciones obsoletas, ya que el coste es bajo.

Algunas innovaciones (como TSTORE de EIP-1153, para almacenamiento temporal) ofrecen escrituras por unos 100 gas, pero este almacenamiento es temporal y solo válido dentro de una transacción, por lo que no puede usarse para mantener actualizaciones de precios persistentes para swaps posteriores (por ejemplo, durante todo un bloque).

¿Cómo llevar los Prop AMM a EVM?

Antes de responder cómo, respondamos por qué: los usuarios siempre quieren mejores precios de trading, es decir, operar de forma más rentable. Los Prop AMM en Ethereum y Layer 2 pueden ofrecer a los usuarios cotizaciones competitivas que antes solo estaban disponibles en Solana o exchanges centralizados.

Para que los Prop AMM sean viables en EVM, recordemos una de las razones de su éxito en Solana:

· Protección de actualización en la parte superior del bloque: En Solana, las actualizaciones de Prop AMM están en la parte superior del bloque, protegiendo a los market makers del front-running. Esto es posible porque el consumo de Compute Units es muy bajo, logrando una alta relación tarifa/CU incluso con tarifas bajas, especialmente comparado con los swaps.

Entonces, ¿cómo llevar las actualizaciones de Prop AMM en la parte superior del bloque a blockchains EVM Layer 2? Hay dos formas: reducir el coste de escritura o crear un canal prioritario para las actualizaciones de Prop AMM.

Debido al problema de crecimiento del estado en EVM, reducir el coste de escritura no es viable, ya que escrituras SSTORE baratas llevarían a ataques de spam de estado.

Proponemos crear un canal prioritario para las actualizaciones de Prop AMM. Esta es una solución viable y el enfoque de este artículo.

@MarkToda del equipo de Uniswap propuso un nuevo método, usando contratos inteligentes de almacenamiento global + una estrategia especial de construcción de bloques:

Funciona así:

· Contrato de almacenamiento global: Se despliega un contrato inteligente simple como almacenamiento público de clave-valor. El market maker escribe los parámetros de la curva de precios en este contrato (por ejemplo, set(ETH-USDC_CONCENTRATION, 4000)).

· Estrategia del constructor: Este es el componente clave off-chain. El constructor de bloques identifica las transacciones enviadas al contrato de almacenamiento global, reserva el 5–10% del gas del bloque para estas transacciones de actualización y las ordena por tarifa, evitando spam.

Nota: Las transacciones deben enviarse directamente a la dirección de almacenamiento global, de lo contrario no se garantiza que estén en la parte superior del bloque.

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

Integración de Prop AMM: El contrato Prop AMM del market maker lee los datos de la curva de precios del contrato de almacenamiento global al hacer swaps, para ofrecer cotizaciones.

Esta arquitectura resuelve ingeniosamente dos problemas:

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

2. Rentabilidad: Los market makers ya no compiten con todos los usuarios DeFi por el gas más alto para estar en la parte superior del bloque, solo compiten localmente por el canal reservado, reduciendo enormemente los costes.

Las transacciones de los usuarios se ejecutarán según la curva de precios establecida por el market maker al inicio del bloque, asegurando la frescura y seguridad de la cotización. Este modelo recrea en EVM el entorno de actualizaciones baratas y prioritarias de Solana, allanando el camino para los Prop AMM en EVM.

Sin embargo, este modelo también tiene algunas desventajas, que dejo al final del artículo para discusión.

Conclusión

La viabilidad de los Prop AMM depende de resolver el problema económico central: actualizaciones baratas y ejecución prioritaria para evitar el front-running.

Aunque la arquitectura estándar de EVM hace que estas operaciones sean costosas y arriesgadas, los nuevos diseños ofrecen diferentes enfoques para resolver este problema. Combinando contratos inteligentes de almacenamiento global on-chain y estrategias de construcción de bloques off-chain, se puede crear un “canal rápido” dedicado que garantice la ejecución de actualizaciones en la parte superior del bloque y establezca un mercado de tarifas local y controlado. Esto no solo hace posible los Prop AMM en EVM, sino que también podría transformar todo DeFi en EVM que dependa de actualizaciones de oráculos en la parte superior del bloque.

Preguntas abiertas

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

· En Solana, la mayor parte del tráfico de AMM proviene de un solo agregador, Jupiter, que ofrece un SDK para facilitar la integración de AMM. Pero en Layer 2 EVM, el tráfico está disperso entre varios agregadores y no hay un SDK público, ¿esto supone un reto para los Prop AMM?

· En Solana, la actualización de Prop AMM consume solo unos 100 CU, ¿cómo se implementa esto?

· El modelo de canal rápido solo garantiza la actualización en la parte superior del bloque. Si hay varios swaps en un Flashblock, ¿cómo puede el market maker actualizar el precio entre esos swaps?

· ¿Se pueden escribir programas EVM optimizados usando lenguajes como Yul o Huff, similar a la optimización Pinocchio en Solana?

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

· ¿Cómo evitar que un market maker ofrezca una cotización atractiva en el bloque N para atraer usuarios y luego la actualice a una mala cotización en el bloque N+1? ¿Cómo lo previene Jupiter?

· La función Ultra Signaling de Jupiter Ultra V3 permite a los Prop AMM distinguir entre tráfico dañino e inofensivo y ofrecer cotizaciones más ajustadas. ¿Qué importancia tienen estas características de agregadores para los Prop AMM en EVM?

Enlace al artículo original