¿Por qué hay tantos Prop AMM en Solana, pero sigue siendo un terreno vacío 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é todavía no han aparecido en EVM?

Los Automated Market Makers Propietarios (Proprietary AMMs, o Prop AMMs) están convirtiéndose rápidamente en la fuerza dominante dentro del ecosistema DeFi de Solana, aportando actualmente más del 40% del volumen de trading en los principales pares. Estos espacios de liquidez gestionados 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 víctimas de arbitraje por "cotizaciones expiradas" (stale quotes) y front-running.

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 costo 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é obstáculos técnicos y económicos enfrentan en cadenas EVM, y qué nuevas arquitecturas prometedoras podrían llevarlos finalmente a la vanguardia de DeFi en EVM.

¿Qué es un Prop AMM?

Un Prop AMM es un market maker automatizado donde la liquidez y la fijación de precios son gestionadas activamente por un único market maker profesional, en lugar de ser provistas de manera pasiva por el público 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 smart contract del Prop AMM Obric en la cadena Sui es público (gracias al hallazgo de @markoggwp), 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 simplemente x*y, pero la clave para entender los Prop AMM es que siempre equivale 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 un usuario debe 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 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 hay 100 WETH y 400,000 USDC en el pool; el punto en la curva es x = 100, y = 400,000, y el precio inicial es 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, de modo que el WETH en el pool baje a 99. Para mantener el producto constante k, el nuevo punto (x, y) debe seguir 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" (deslizamiento). 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)?

Veamos por qué los market makers prefieren usar el diseño AMM para hacer market making. Imaginá que sos un market maker cotizando en un libro de órdenes centralizado (CLOB) on-chain. Para actualizar tus cotizaciones, tenés que cancelar y reemplazar miles de órdenes límite. Si tenés N órdenes, el costo de actualización es de orden O(N), lo que es lento y caro on-chain.

¿Y si pudieras representar todas tus 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 ilustrar cómo la "curva de precios" corresponde a diferentes rangos de precios efectivos, podemos ver SolFi, creado por Ellipsis Labs, un Prop AMM basado en Solana. Aunque su curva de precios específica es desconocida y está oculta, Ghostlabs hizo un gráfico que muestra, en un slot de Solana (periodo de bloque), el precio efectivo de intercambiar diferentes cantidades de SOL por USDC. Cada línea representa un pool WSOL/USDC diferente, mostrando que pueden coexistir múltiples niveles de precios. 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, actualizando 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 modificar uno por uno los N órdenes. Ese es el 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 costo de actualización (cheap updates)

2. Ejecución prioritaria (priority execution)

En Solana, ambas van de la mano: un bajo costo 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, según cambios en su inventario o en el precio índice del activo (por ejemplo, el precio en exchanges centralizados), a la velocidad de la blockchain. En una cadena de alta frecuencia como Solana, si el costo de actualización es alto, es difícil hacer ajustes frecuentes.

Segundo, si el market maker no puede hacer que su actualización esté al tope del bloque, los arbitrajistas pueden "robarle" las cotizaciones viejas, generando pérdidas inevitables. Si faltan estas dos características, el market maker no puede operar eficientemente y los usuarios obtienen 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 precios varias veces dentro de un solo slot?"

La respuesta está en la arquitectura continua de Solana, que es fundamentalmente 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. Las actualizaciones enviadas a mitad de camino solo entran en vigor en el siguiente bloque.

· Solana: El nodo líder no espera un bloque completo, sino que divide las transacciones en pequeños paquetes de datos ("shred") y los transmite continuamente por la red. Puede haber varios 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 charla de @Ashwinningg de Anza Labs en la conferencia CBER, cada slot de 400ms tiene un límite 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 los Prop AMM en Solana es una caja negra, existen librerías como Pinocchio que permiten escribir programas de Solana optimizados para el uso de Compute Units (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 (las Compute Units son similares al Gas en EVM), igual que EVM.

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

· Si no: Priority = (tarifa prioritaria + tarifa base) / (1 + CU máximo + CU de firma + CU de bloqueo de escritura)

Comparando las Compute Units de una actualización de Prop AMM y un swap en 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 cuesta solo 109 CU, con un costo total de solo 0.000007506 SOL

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

Debido a esta enorme diferencia, el market maker solo necesita pagar una tarifa mínima por la transacción de actualización para lograr una relación Fee/CU mucho mayor que la de los swaps, asegurando que la actualización se ejecute al tope del bloque y protegiéndose del arbitraje.

¿Por qué los Prop AMM aún no se han implementado 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" porque los market makers quieren mantener su estrategia confidencial, podemos usar esta suposición para entender cómo Obric implementa Prop AMM en Sui: las variables que determinan la cotización del par se escriben en el smart contract mediante la función update.

¡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 basadas en 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, escribir un valor usando el opcode SSTORE en EVM es carísimo:

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

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

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

Nota: El Gas en EVM es similar a las Compute Units (CU) en Solana. Los números de gas para SSTORE asumen una sola escritura por transacción (escritura fría), 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 requerir varios 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 asegurar la prioridad de las actualizaciones, ya que una tarifa prioritaria baja no logra una alta relación tarifa/gas. Para asegurar que la actualización no sea adelantada y quede al tope del bloque, se requiere una tarifa prioritaria más alta, lo que aumenta el costo.

2. El riesgo de arbitraje es mayor en EVM, ya que la proporción de gas entre actualización y swap es solo 1:10, mientras que en Solana es 1:1000. Esto significa que un arbitrajista solo necesita subir la tarifa prioritaria 10 veces para adelantarse a la actualización del market maker, mientras que en Solana tendría que subirla 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 expiradas, porque el costo es bajo.

Algunas innovaciones (como TSTORE de EIP-1153, para almacenamiento temporal) ofrecen escrituras por unos 100 gas, pero ese almacenamiento es temporal y solo válido dentro de una transacción, por lo que no sirve para persistir actualizaciones de precios 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, operaciones más rentables. Los Prop AMM en Ethereum y Layer 2 pueden ofrecer a los usuarios precios competitivos 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 al tope del bloque: En Solana, las actualizaciones de Prop AMM están al tope del bloque, protegiendo al market maker del front-running. Esto es posible porque el consumo de CU es mínimo, así que incluso con tarifas bajas, se logra una alta relación tarifa/CU, especialmente comparado con los swaps.

Entonces, ¿cómo llevar las actualizaciones de Prop AMM al tope del bloque en blockchains Layer 2 EVM? Hay dos caminos: o se baja el costo de escritura, o se crea un canal prioritario para las actualizaciones de Prop AMM.

Debido al problema del crecimiento del estado en EVM, bajar el costo de escritura no es viable, porque escrituras SSTORE baratas permitirían ataques de spam al estado.

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

@MarkToda del equipo de Uniswap propuso un nuevo método usando un smart contract de almacenamiento global + una estrategia especial de block builder:

Así funciona:

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

· Estrategia del block builder: Este es el componente clave off-chain. El block builder 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.

Atención: las transacciones deben enviarse directamente a la dirección del almacenamiento global, de lo contrario no se garantiza que estén al tope del bloque.

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

Integración de Prop AMM: El smart contract del Prop AMM del market maker lee los datos de la curva de precios del contrato de almacenamiento global al hacer un swap, para cotizar precios.

Esta arquitectura resuelve ingeniosamente dos problemas:

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

2. Eficiencia de costos: El market maker ya no compite con todos los usuarios de DeFi por el gas alto para estar al tope del bloque, solo compite en el mercado local de tarifas reservado para las actualizaciones, bajando mucho el costo.

Las transacciones de los usuarios se ejecutarán según la curva de precios establecida por el market maker en la actualización inicial 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 para discusión al final del artículo.

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 riesgosas, los nuevos diseños ofrecen diferentes soluciones. Combinando smart contracts de almacenamiento global on-chain y estrategias de block builder off-chain, se puede crear un "canal rápido" dedicado que garantiza la ejecución al tope del bloque y establece un mercado de tarifas local y controlado. Esto no solo hace viables los Prop AMM en EVM, sino que también puede transformar todo DeFi en EVM que dependa de actualizaciones de oráculos al tope del bloque.

Preguntas abiertas

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

· En Solana, la mayoría del tráfico de AMM proviene de un solo agregador, Jupiter, que ofrece un SDK fácil para integrar AMM. Pero en Layer 2 EVM, el tráfico está disperso entre varios agregadores y no hay un SDK público. ¿Esto representa un desafío para los Prop AMM?

· En Solana, las actualizaciones de Prop AMM consumen solo unos 100 CU. ¿Cómo se logra esto?

· El modelo de canal rápido solo garantiza actualizaciones al tope del bloque. Si hay varios swaps en un Flashblock, ¿cómo actualiza el market maker los precios 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 comparan los Prop AMM con los RFQ?

· ¿Cómo evitar que un market maker ofrezca una buena cotización en el bloque N para atraer usuarios y luego la actualice a una mala 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 inocuo y ofrecer cotizaciones más ajustadas. ¿Qué tan importante es esta característica de los agregadores para los Prop AMM en EVM?

Enlace al artículo original