¿Por qué Solana está llena de Prop AMM mientras que EVM permanece en blanco?

Título original del artículo: DApps imprescindibles tras el lanzamiento de Monad Mainnet

Autor del artículo original: @0xOptimus

Traducción del artículo original: Dingdang, Odaily Planet Daily

Los AMM propietarios han captado rápidamente el 40% del volumen total de operaciones de Solana. ¿Por qué no han aparecido aún en el EVM?

Los Creadores de Mercado Automatizados Propietarios (Prop AMM) se están convirtiendo rápidamente en la fuerza dominante del ecosistema DeFi de Solana, contribuyendo actualmente a más del 40% del volumen de negociación en los pares principales. Estos centros de liquidez, operados por creadores de mercado profesionales, pueden proporcionar una liquidez profunda y precios más competitivos. La razón principal es que reducen significativamente el riesgo de que los creadores de mercado sean explotados por cotizaciones obsoletas para realizar arbitraje anticipado.

Fuente de la imagen: dune.com

Sin embargo, su éxito se ha limitado casi por completo a Solana. Incluso en redes de Capa 2 rápidas y de bajo coste como Base u Optimism, la presencia de AMM Prop en el ecosistema EVM es escasa. ¿Por qué no se han consolidado en el EVM?

Este artículo explora principalmente tres cuestiones: qué son los Prop AMM, las barreras técnicas y económicas que enfrentan en la cadena EVM y las nuevas arquitecturas prometedoras que eventualmente pueden llevarlos a la vanguardia de EVM DeFi.

¿Qué son los Prop AMM?

Los AMM propietarios son un tipo de creador de mercado automatizado donde un único creador de mercado profesional gestiona activamente la liquidez y los precios, en lugar de tener fondos proporcionados pasivamente por el público como en los AMM tradicionales.

Los AMM tradicionales (como Uniswap v2) suelen utilizar la fórmula x * y = k para determinar el precio, donde x e y representan las cantidades de los dos activos en el pool, y k es una constante. En los AMM Prop, la fórmula de fijación de precios no es fija, sino que se actualiza con frecuencia (a menudo varias veces por segundo). Dado que la mecánica interna de la mayoría de los AMM Prop se considera una "caja negra", el mundo exterior desconoce el algoritmo exacto que utilizan. Sin embargo, el código del contrato inteligente de los AMM Prop en la cadena Sui de Obric es público (gracias al descubrimiento de @markoggwp), donde la invariante k depende de las variables internas mult_x, mult_y y concentración. La imagen a continuación muestra cómo el creador de mercado actualiza continuamente estas variables.

Un punto que debe aclararse es que la fórmula del lado izquierdo de la curva de precios de Obric es más compleja que una simple x*y. Sin embargo, la clave para comprender el Pro-AMM es que siempre es igual a una variable invariante k, y los proveedores de liquidez actualizan continuamente esta k para ajustar la curva de precios.

Reseña: ¿Cómo determina AMM los precios?

En este artículo, mencionaremos el concepto de "curva de precios" en repetidas ocasiones. Esta curva determina el precio que los usuarios deben pagar al operar con un AMM y es la parte que los proveedores de liquidez actualizan continuamente en el Prop AMM. Para comprenderlo mejor, primero podemos revisar el mecanismo de fijación de precios de un AMM tradicional.

Tomando como ejemplo el pool WETH-USDC en Uniswap v2 (sin comisiones), el precio se determina pasivamente mediante la fórmula x * y = k. Suponiendo que hay 100 WETH y 400 000 USDC en el pool, el punto actual de la curva es x = 100, y = 400 000, lo que corresponde a un precio inicial de 400 000 / 100 = 4000 USDC/WETH. Esto da una constante k = 100 * 400 000 = 40 000 000.

Si un operador desea comprar 1 WETH, debe añadir USDC al fondo común, lo que reduce el total de WETH a 99. Para mantener el producto k constante, el nuevo punto (x, y) debe seguir estando en la curva, por lo que y debe ser 40 000 000 / 99 ≈ 404 040,40. Esto significa que el operador pagó aproximadamente 4040,40 USDC por 1 WETH, un precio ligeramente superior al inicial. Este fenómeno se conoce como "deslizamiento de precio". Por eso, x*y=k se denomina "curva de precios": cualquier precio negociable debe estar en esta curva.

¿Por qué los proveedores de liquidez eligen el diseño AMM en lugar del libro de órdenes centralizado (CLOB)?

Expliquemos por qué los proveedores de liquidez querrían usar el diseño AMM para proporcionar liquidez. Imagine que es un creador de mercado que cotiza en un Libro Central de Órdenes Limitadas (CLOB) en cadena. Si desea actualizar su cotización, deberá cancelar y reemplazar miles de órdenes limitadas. Si tiene N órdenes, el costo de actualización es una operación O(N), lo cual es lento y costoso en cadena.

Pero ¿qué pasaría si se pudieran representar todas las cotizaciones con una curva matemática? Con solo actualizar algunos parámetros clave que definen esta curva, se puede transformar una operación O(N) en una complejidad constante O(1).

Para ilustrar visualmente cómo la "Curva de Precios" se corresponde con diferentes rangos de precios efectivos, podemos consultar SolFi, creado por Ellipsis Labs, un AMM Prop basado en Solana. Aunque su curva de precios específica es desconocida y está oculta, Ghostlabs ha creado un gráfico que muestra el precio efectivo al intercambiar diferentes cantidades de SOL por USDC dentro de un intervalo de Solana determinado (periodo de bloque). Cada línea representa un pool diferente de WSOL/USDC, lo que ilustra la coexistencia de múltiples niveles de precios. A medida que el proveedor de liquidez actualiza la curva de precios, este gráfico de precio efectivo también cambia entre los diferentes intervalos.

Fuente de la imagen: GitHub

La clave radica en que, al actualizar solo unos pocos parámetros de la curva de precios, los proveedores de liquidez pueden alterar dinámicamente la distribución efectiva de precios en cualquier momento sin tener que modificar cada una de las N órdenes individualmente. Esta es precisamente la principal propuesta de valor de Prop AMM: permite a los proveedores de liquidez ofrecer liquidez dinámica y profunda con mayor capital y eficiencia computacional.

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

Prop AMM es un sistema de "gestión activa", lo que significa que requiere dos condiciones clave:

1. Bajos costos de actualización

2. Ejecución prioritaria

En Solana, estos dos aspectos están entrelazados: las actualizaciones de bajo costo a menudo significan que las actualizaciones pueden tener ejecución prioritaria.

Pero ¿por qué los proveedores de liquidez necesitan estos dos puntos? En primer lugar, actualizarán continuamente la curva de precios en función de los cambios de inventario o las fluctuaciones en los precios de los índices de activos (por ejemplo, precios de intercambio centralizados) a la velocidad de la cadena de bloques. En una cadena de alta frecuencia como Solana, si los costos de actualización son demasiado altos, lograr ajustes de alta frecuencia sería un desafío.

En segundo lugar, si un proveedor de liquidez no logra que su actualización se incluya al inicio de un bloque, los arbitrajistas aprovecharán su cotización anterior, lo que resultará en pérdidas inevitables. Sin estas dos características, los proveedores de liquidez no pueden operar eficientemente y los usuarios recibirían peores precios de transacción.

Usando el ejemplo de Prop AMM HumidiFi en Solana, según datos de @SliceAnalytics, el proveedor de liquidez actualiza su cotización hasta 74 veces por segundo.

Los jugadores que vienen de EVM pueden preguntar: "El espacio de Solana es de aproximadamente 400 ms, ¿cómo puede Prop AMM actualizar el precio varias veces dentro de un solo espacio?"

La respuesta está en la arquitectura continua de Solana, que es fundamentalmente diferente del modelo de bloque discreto de EVM.

· EVM: Las transacciones suelen ejecutarse secuencialmente tras la propuesta y confirmación final de un bloque completo. Esto significa que las actualizaciones enviadas a mitad de camino surten efecto en el siguiente bloque.

· Solana: Los nodos Validadores Líder no esperan a que se complete un bloque; en su lugar, dividen las transacciones en pequeños paquetes de datos (llamados "fragmentos") y los transmiten continuamente a la red. Dentro de una ranura, puede haber múltiples intercambios, pero la actualización de precio en el fragmento n.° 1 afecta al swap n.° 1, y la actualización de precio en el fragmento n.° 2 afecta al swap n.° 2.

Nota: Los Flashblocks son similares a los shreds de Solana. Según @Ashwinningg de Anza Labs en la conferencia CBER, el límite de la ranura de 32 000 shreds cada 400 ms equivale a 80 shreds por milisegundo. Si los Flashblocks de 200 ms son lo suficientemente rápidos para cumplir con los requisitos del proveedor de liquidez sigue siendo una incógnita en comparación con la arquitectura continua de Solana.

Entonces, ¿por qué las actualizaciones de Solana son tan baratas? ¿Y qué lleva a su ejecución prioritaria?

En primer lugar, aunque la implementación de Prop AMM en Solana es compleja, existe una biblioteca como Pinocchio que optimiza la escritura de CU en los programas de Solana. El blog de Helius ofrece una excelente explicación. Con esta biblioteca, el consumo de CU de los programas de Solana se puede reducir de aproximadamente 4000 CU a aproximadamente 100 CU.

Fuente de la imagen: github

Ahora veamos la segunda parte. A un nivel superior, Solana prioriza las transacciones seleccionando aquellas con la mayor relación tarifa/unidades de cómputo (las unidades de cómputo son similares al gas de EVM), similar a la EVM.

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

· De lo contrario: Prioridad = (Propina + Tarifa base) / (1 + Límite de CU + Firma CU + Bloqueo de escritura CU)

Al comparar las unidades de cómputo de una actualización de Prop AMM con Jupiter Swap, es evidente 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 muy económica. La actualización de Wintermute cuesta tan solo 109 CU, con un costo total de tan solo 0.000007506 SOL.

Intercambio de Júpiter: un intercambio a través de la ruta de Júpiter puede alcanzar ~100.000 CU, con un costo total de 0,000005 SOL

Debido a esta diferencia significativa, los proveedores de liquidez solo necesitan pagar una tarifa mínima por las transacciones de actualización, logrando una relación tarifa/CU mucho más alta que los intercambios, lo que garantiza que las actualizaciones se ejecuten en la parte superior del bloque, protegiéndose de ataques de arbitraje.

¿Por qué la Proposición AMM aún no ha llegado al EVM?

Suponiendo que una actualización de Prop AMM implica escribir en una variable que determina la curva de precios del par de activos. Si bien el código de Prop AMM en Solana es una "caja negra", ya que los proveedores de liquidez desean mantener la confidencialidad de sus estrategias, podemos usar esta suposición para comprender cómo Obric implementó Prop AMM en Sui: la variable que determina el precio del par de activos se escribe en el contrato inteligente mediante una función de actualización.

¡Gracias a @markoggwp por el descubrimiento!

Con este supuesto, encontramos una barrera significativa en la arquitectura del EVM que hace que el modelo Prop AMM de Solana sea inviable en el EVM.

Recuerde que en las cadenas de bloques de capa 2 de OP-Stack (como Base y Unichain), las transacciones se priorizan en función de las tarifas por gas (similar a la clasificación de tarifas/CU de Solana).

En la EVM, el coste de gas de las operaciones de escritura es extremadamente alto. En comparación con las actualizaciones de Solana, el coste de escribir un valor en la EVM mediante el código de operación SSTORE es asombroso:

· SSTORE (0 → distinto de 0): ~22 100 de gas

· SSTORE (no 0 → no 0): ~5000 gas

· Swap típico de AMM: ~200.000–300.000 de gas

Nota: El gas en la EVM es similar a las unidades computacionales (UC) en Solana. Las cifras de gas de SSTORE anteriores suponen que cada transacción solo tiene una escritura (escritura en frío), lo cual es razonable, ya que no se suelen enviar varias actualizaciones en una misma transacción.

Si bien las actualizaciones siguen siendo más económicas que los intercambios, la eficiencia del gas es solo de alrededor de 10x (las actualizaciones pueden involucrar múltiples SSTORE), mientras que en Solana, esta relación es de alrededor de 1000x.

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

1. Los altos costos del gas dificultan asegurar la prioridad de las actualizaciones: Las tarifas de gas más bajas no garantizan una alta relación tarifa/gas. Para garantizar que las actualizaciones no se adelanten y se coloquen al principio de un bloque, se requieren tarifas de gas más altas, lo que incrementa los costos.

2. Mayor riesgo de arbitraje en el EVM: La relación entre la actualización de gas y el swap de gas en el EVM es de tan solo 1:10, mientras que en Solana es de 1:1000. Esto significa que los arbitrajistas solo necesitan aumentar las comisiones 10 veces para adelantarse a la actualización de un proveedor de liquidez, en comparación con 1000 veces en Solana. En este escenario de menor relación, es más probable que los arbitrajistas se adelanten a las actualizaciones de precios para capturar cotizaciones obsoletas debido al bajo coste.

Algunas innovaciones (como TSTORE de EIP-1153 para almacenamiento temporal) proporcionan un costo de escritura de alrededor de 100 gas, pero este almacenamiento es efímero, solo válido dentro de una única transacción y no se puede usar para persistir actualizaciones de precios para su uso posterior en operaciones de derivados (por ejemplo, durante un período de bloque completo).

¿Cómo introducir Prop AMM en el EVM?

Antes de responder, abordemos el "¿por qué hacerlo?": Los usuarios siempre buscan mejores cotizaciones de intercambio, lo que significa mayor rentabilidad. Ethereum y Prop AMM de Capa 2 pueden ofrecer a los usuarios cotizaciones competitivas que antes solo estaban disponibles en Solana o exchanges centralizados.

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

Protección de actualización en la cima del bloque: En Solana, las actualizaciones Prop AMM se realizan en la cima del bloque para proteger a los proveedores de liquidez de la especulación. Las actualizaciones en la cima son posibles gracias a que el coste unitario computacional es mínimo, lo que permite que incluso con comisiones bajas se alcance una alta relación comisión/CU, especialmente en comparación con las operaciones con derivados.

Entonces, ¿cómo podemos introducir actualizaciones de Prop AMM en la parte superior del bloque en una blockchain EVM de Capa 2? Hay dos enfoques: reducir el coste de escritura o crear un canal prioritario para las actualizaciones de Prop AMM.

Debido al problema de crecimiento del estado de EVM, reducir el costo de escritura es menos viable, ya que los SSTORE baratos provocarían ataques de hinchazón del estado.

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

@MarkToda de Uniswap ha propuesto un nuevo enfoque, aprovechando una estrategia de contrato inteligente de almacenamiento global + generador de bloques dedicado:

Así es como funciona:

Contrato de Almacenamiento Global: Implemente un contrato inteligente simple como almacén de clave-valor público. Los proveedores de liquidez escriben parámetros de la curva de precios en este contrato (p. ej., 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 entre el 5 % y el 10 % del gas del bloque a estas transacciones de actualización, las prioriza por tarifa y las clasifica para evitar transacciones no deseadas.

Tenga en cuenta: las transacciones deben enviarse directamente a la dirección de almacenamiento global para garantizar la ubicación en la parte superior del bloque.

Se pueden encontrar ejemplos de algoritmos de construcción de bloques personalizados en rblib.

Integración de Prop AMM: el contrato Prop AMM de los proveedores de liquidez lee los datos de la curva de precios del contrato de almacenamiento global durante los swaps para proporcionar cotizaciones.

Esta arquitectura aborda hábilmente dos cuestiones:

1. Protección: La estrategia del constructor crea un "carril rápido" para garantizar que todas las actualizaciones de precios en el bloque se ejecuten antes de las transacciones, eliminando así el riesgo de ejecución anticipada.

2. Eficiencia de costos: Los proveedores de liquidez ya no compiten con todos los usuarios de DeFi por precios de gas altos para ingresar a la parte superior del bloque; en cambio, solo necesitan competir por el bloque superior reservado para transacciones de actualización en el mercado de tarifas local, lo que reduce significativamente los costos.

Las transacciones de usuario se ejecutarán según la curva de precios establecida por el proveedor de liquidez al inicio del mismo bloque, lo que garantiza la frescura y seguridad de las cotizaciones. Este modelo replica el entorno de actualización de bajo costo y alta prioridad de Solana en el EVM, allanando el camino para Prop AMM en el EVM.

Sin embargo, este modelo también tiene algunos inconvenientes, que dejaré al final de este artículo para su discusión.

Conclusión

La viabilidad de la Proposición AMM depende de que se aborde una cuestión económica central: una ejecución barata y prioritaria para evitar la inversión anticipada.

Si bien 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. Al combinar contratos inteligentes de almacenamiento global en cadena y una estrategia de construcción fuera de cadena en el nuevo diseño, se puede crear una vía rápida dedicada para garantizar la ejecución de actualizaciones en la parte superior del bloque, a la vez que se establece un mercado de tarifas local y controlado. Esto no solo hace viable Prop AMM en EVM, sino que también podría revolucionar todas las DeFi de EVM que dependen de las actualizaciones de oráculos en la parte superior del bloque.

Preguntas abiertas

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

En Solana, la mayor parte del tráfico de AMM proviene de un único agregador llamado Jupiter, que proporciona un SDK para facilitar la integración de AMM. Sin embargo, en EVM de Capa 2, el tráfico se distribuye entre varios agregadores sin un SDK público. ¿Supone esto un desafío para Prop AMM?

En Solana, las actualizaciones de Prop AMM consumen solo unas 100 CU. ¿Cuál es el mecanismo de implementación que sustenta esta eficiencia?

El modelo de ruta rápida solo garantiza actualizaciones en la cima de un bloque. Si hay varias plataformas dentro de un Flashblock, ¿cómo actualizan los proveedores de liquidez los precios entre estas plataformas?

· ¿Es posible escribir programas EVM optimizados utilizando lenguajes como Yul o Huff, similar al enfoque de optimización Pinocho de Solana?

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

¿Cómo podemos evitar que los proveedores de liquidez ofrezcan cotizaciones competitivas en el Bloque N para atraer usuarios y luego las actualicen a cotizaciones no competitivas en el Bloque N+1? ¿Cómo mitiga Jupiter este riesgo?

La función de Ultra Signaling de Jupiter Ultra V3 permite a Prop AMM diferenciar entre tráfico perjudicial y benigno, ofreciendo cotizaciones más ajustadas. ¿Qué tan cruciales son estas funciones de agregación para Prop AMM en EVM?

Enlace a la publicación original

Bienvenido a unirte a la comunidad oficial de BlockBeats:

Grupo de suscripción de Telegram: https://t.me/theblockbeats

Grupo de discusión de Telegram: https://t.me/BlockBeats_App

Cuenta oficial de Twitter: https://twitter.com/BlockBeatsAsia