Introducción

En la búsqueda continua de mejorar el rendimiento de la cadena de bloques para manejar la adopción masiva, Monad se destaca como una fuerza pionera para optimizar el modelo de Máquina Virtual Ethereum (EVM) con una serie de mejoras a nivel de bajo nivel: E/S asíncrona, un Patricia Trie optimizado, ejecución diferida y control de concurrencia optimista para procesamiento paralelo [2]. Estas mejoras abordan eficazmente los cuellos de botella de ejecución y el acceso ineficiente al estado que se observa en plataformas como Ethereum sin sacrificar la descentralización.

En esta publicación, exploramos posibles implementaciones de una infraestructura robusta de subasta de valor extraíble por minero (MEVA) en Monad. También describimos algunas lecciones transferibles y valiosas de enfoques existentes como Flashbots en Ethereum y Jito Network en Solana.

Queremos destacar algunas consideraciones clave:

1. MEV es inherente a cualquier red de blockchain. Una infraestructura MEVA robusta es crucial para evitar un proceso de producción de bloques desordenado con externalidades negativas e incentivos desalineados.
2. El diseño de MEVA está profundamente integrado con la mecánica subyacente de una cadena, especialmente su puesta en escena de consenso-ejecución. Las mejoras futuras dependerán de la evolución de estos factores y del rendimiento de la red bajo diferentes niveles de estrés.
3. Las tendencias históricas en la evolución de la producción de bloques, como se ve en Ethereum y Solana, pueden informar el diseño de MEVA en Monad.
4. La MEVA en blockchains de ejecución diferida y alto rendimiento como Monad probablemente requerirá estrategias de construcción y búsqueda de bloques probabilísticas, similares al trading de alta frecuencia, debido a sus restricciones de tiempo.

Al abordar estos puntos, esperamos proporcionar una visión de los desafíos y consideraciones involucrados en el diseño de una infraestructura MEVA adaptada a la arquitectura única y requisitos de rendimiento de Monad.

Paisaje de MEVA en Ethereum

MEVA bajo la puesta en escena de Consenso-Ejecución de Ethereum

En Ethereum, el consenso requiere una ejecución previa. Cuando los nodos están de acuerdo en un bloque, están de acuerdo tanto en la lista de transacciones en el bloque como en la raíz de Merkle que resume el estado posterior al hecho después de que se ha ejecutado el bloque. Por lo tanto, los líderes deben ejecutar todas las transacciones en el bloque propuesto antes de propagar la propuesta. Mientras tanto, los nodos validadores deben ejecutar las transacciones antes de votar.

Figura 1: El flujo de trabajo del Constructor en MEV-Boost bajo la separación EL-CL.

La Figura 1 ilustra un flujo de trabajo típico del constructor en MEV-Boost para la Separación Propositor-Constructor (PBS). Los constructores terminan de construir los bloques y los envían a un relé, que reenvía los bloques a un cliente de Capa de Ejecución (EL) para simulación y comprobaciones de validez.

Dado que la ejecución es un requisito previo para el consenso, cuando un creador construye un bloque, necesita enviar el bloque construido a un cliente de la Capa de Ejecución (EL) y simular el bloque para verificar su validez. Más allá de su papel necesario en la etapa de consenso-ejecución, la etapa de simulación también aporta beneficios tanto para los creadores como para los buscadores.

Perspectiva del constructor: los constructores pueden estimar con precisión el valor del bloque tanto para ellos mismos como para los validadores simulando cada transacción. También pueden experimentar con el reordenamiento de transacciones para minimizar las cancelaciones y maximizar la extracción de comisiones de gas o propinas base tanto de las transacciones en la mempool como de las transacciones en el paquete. Su estimación precisa permite realizar ofertas más altas a los validadores.

Perspectiva del buscador: Como resultado de los constructores que eliminan los paquetes potencialmente revertidos antes de que aterricen en la cadena, los buscadores también ven una ejecución de estrategia garantizada, lo que agrega determinismo. Además, los buscadores también obtienen acceso al estado de bloque más reciente. Cuando la capa de consenso (CL) propaga un nuevo bloque, los buscadores pueden usar el estado de ese bloque como punto de partida para construir paquetes rentables. Mientras tanto, hay indicios de más acuerdos o características fuera del protocolo ofrecidos por los constructores en este momento, lo que permite a los buscadores obtener información del estado incluso para el bloque actual por construir para agregar estrategias de retroceso a sus bloques por aterrizar.

Sin embargo, el desarrollo de la PBS ha experimentado un aumento en la centralización en la construcción de bloques, reflejando el comercio tradicional en el que las empresas compiten por canales dedicados de red de microondas para obtener prioridad en la ejecución de estrategias de arbitraje.

Iteración del producto a medida que la red madura

Ahora exploramos cómo MEV ha evolucionado a medida que Ethereum progresó, ilustrado cronológicamente en la Figura 2.

Figura 2: Una vista cronológica de cómo MEVA itera a medida que avanza la Red Ethereum. La figura está ligeramente adaptada de [4].

Era de Subasta de Gas Prioritario (PGA)

Como se muestra en la Figura 3, los buscadores identificaron oportunidades de MEV rentables y enviaron sus transacciones habilitadas para contratos inteligentes al mempool público. Esta visibilidad pública llevó a un formato de subasta de primer precio de oferta abierta en la cadena, donde incluso las transacciones fallidas incurrieron en costos de gas.

Este período presenció actividades de MEV no estructuradas competitivas y costosas, como transacciones con el mismo par (cuenta, número de nonce) y ofertas crecientes [6], lo que aumenta la congestión de la red o la inestabilidad del consenso.

Figura 3: Subasta de gas de prioridad simple. La figura ha sido ligeramente adaptada de [6].

Flashbots y EIP-1559

Para abordar estos problemas, Flashbots introdujo relays, casas de subastas intermedias entre los buscadores y los productores de bloques (mineros en la era PoW). Esta iniciativa transforma el mercado de MEV de una subasta de precio de oferta abierta a una de precio de oferta cerrada. La figura 4 muestra cómo los relays ayudan a prevenir la escalada de ofertas en el mempool público y establecen un proceso de producción de bloques más ordenado y seguro.

La estructura de tarifas de EIP-1559 también juega un papel aquí [7]. Simplificó la oferta al introducir precios parcialmente publicados a través de tarifas base, pero no abordó el orden de las transacciones dentro de los bloques, lo que sigue impulsando MEV a través de tarifas prioritarias. En realidad, muchos buscadores anteriormente expresaban ofertas a los mineros directamente a través de transferencias de coinbase. Terminaron teniendo más quejas sobre las tarifas de coinbase, porque ya no podían enviar paquetes de 0 gas.

Figura 4: MEV con Relés. La figura está ligeramente adaptada de [6].

Separación de Proponente-Constructor (PBS)

Después de la transición de Ethereum a Prueba de Participación (PoS) después de la fusión, se implementó la Separación de Constructores y Proponentes (PBS) para refinar aún más la separación de roles en el proceso de producción de bloques. Como se describió anteriormente, los relés ahora actúan como intermediarios entre los constructores de bloques y los proponentes, actuando como custodios que garantizan la disponibilidad de datos y la validez del bloque. Debido a que un proponente puede conectarse a varios constructores para transacciones privadas diferentes, los constructores deben competir ofreciendo pagos al proponente. Esta dinámica se ilustra en la Figura 5.

Figura 5: MEVA en la era de la PBS. Esta figura está ligeramente adaptada de [6].

Riesgos de Concentración

A pesar de estos avances históricos, es importante destacar las crecientes preocupaciones sobre los riesgos de concentración en el mercado de los constructores. En el último año, una oligarquía de los 9 principales constructores ha mantenido consistentemente >50% del mercado, lo que apunta a un alto grado de concentración del mercado, como se indica en la Figura 6. El estado de la concentración es aún más pronunciado actualmente, con los tres principales constructores cubriendo más del >90% de los bloques.

Figura 6: Cuota de mercado de los constructores. El gráfico indica la alta concentración predominante en el mercado de constructores. El gráfico está adoptado de https://arxiv.org/pdf/2405.01329

Jito en Solana

Arquitectura de Jito

Como el MEV canónico en Solana, Jito fue creado para abordar la alta tasa de spamming de Solana debido a los bajos costos de transacción. El spamming de operaciones se incentiva efectivamente siempre y cuando el costo de una transacción fallida (aproximadamente 0.000005 SOL) no supere la ganancia esperada.

Según un informe de Jito Labs en 2022 [8], más del 96% de los intentos de arbitraje y liquidación fallaron ese año, con bloques que contenían más del 50% de transacciones relacionadas con MEV. El informe también destaca que los bots de liquidación han inundado la red con millones de paquetes duplicados solo para lograr varias miles de liquidaciones exitosas, lo que resulta en una tasa de falla superior al 99% [8].

Figura 7: Una vista aérea del MEVA de Jito en Solana.

La gravedad de las externalidades de MEV en Solana llevó a Jito a desarrollar una capa MEVA con el objetivo de traer orden y determinismo al proceso de producción de bloques. Veamos la arquitectura original de MEVA propuesta por Jito, como se ilustra en la Figura 7.

Jito tiene los siguientes componentes:

Relay - actúa como un proxy para recibir transacciones y enviarlas tanto al Motor de Bloques (o la cadena de suministro MEVA) como a los validadores.

Block Engine: recibe transacciones del relayer, coordina con los searchers, acepta bundles, realiza simulaciones de bundles y envía las mejores transacciones y bundles al validador para su procesamiento. Es importante destacar que Jito realiza una subasta parcial de bloques para la inclusión de bundles en lugar de una subasta completa de bloques, procesando históricamente más del 80% de los bundles en dos slots [9].

Pseudo Mempool: crea una ventana de tiempo operativa de aproximadamente 200 milisegundos a través del cliente Jito-Solana, induciendo una subasta discretizada para el flujo de órdenes [10]. Jito cerró este mempool el 9 de marzo de 2024.

Las elecciones de diseño de Jito

Exploremos los componentes específicos del diseño del sistema de Jito y consideremos cómo estas elecciones de diseño provienen del proceso de producción de bloques de Solana.

Jito solo admite subastas de bloques parciales en lugar de la construcción completa de bloques, probablemente debido al modelo de ejecución multi-hilo de Solana, que carece de programación global. Específicamente, la Figura 8 muestra hilos paralelos que ejecutan transacciones, cada uno manteniendo su propia cola de transacciones esperando ser ejecutadas. Las transacciones se asignan aleatoriamente a los hilos y se ordenan localmente por tarifa de prioridad y tiempo. Sin un ordenamiento global en el lado del programador (antes de la actualización 1.18.x), las transacciones de Solana experimentan inherentemente no determinismo debido a la variabilidad del programador [11]. En consecuencia, en el MEVA, los buscadores o validadores no pueden determinar de manera confiable el estado actual.

Figura 8: El modelo de ejecución multi-threaded para el cliente de Solana. Tenga en cuenta que la Etapa de Bundle de MEV se agrega como un hilo separado dentro de la cola multi-threaded.

Desde una perspectiva de ingeniería, integrar el feed del motor de bloques de Jito como un hilo adicional que se ejecuta en paralelo a los existentes encaja bien con la arquitectura multi-hilo de Solana. Mientras que las subastas de paquetes garantizan un orden basado en tarifas de prioridad dentro del hilo del motor de bloques de Jito, no hay garantía de que los paquetes siempre se coloquen antes de las transacciones de usuario a nivel global.

Para abordar esto, Jito preasigna parte del espacio de bloque para el hilo del paquete, garantizando paquetes con espacio en el bloque. Aunque el indeterminismo persiste, este enfoque aumenta la probabilidad de una ejecución exitosa de la estrategia. También incentiva a los buscadores a participar en la subasta en lugar de inundar la red. Al reservar espacio de bloque para los paquetes, Jito logra un equilibrio, promoviendo subastas ordenadas y mitigando los efectos caóticos del spam de transacciones.

Eliminando el Pseudo-Mempool

La amplia adopción de Jito ha dado resultados positivos en la mitigación del problema de spam en Solana. La investigación realizada por p2p [12] y los datos mostrados en la Figura 9 revelan una mejora estadísticamente significativa en la tasa de producción de bloques relativa después de adoptar el cliente Jito. Esto indica que el procesamiento de transacciones se ha vuelto más eficiente, gracias al motor de bloques optimizado de Jito introducido en 2023.

Figura 9: Evidencia de la efectividad de Jito para mitigar el problema de spam en Solana. El gráfico se extrajo de un estudio en [12] realizado por el equipo p2p.

Si bien se ha logrado un progreso significativo, aún quedan muchos desafíos. Dado que los paquetes Jito solo llenan parcialmente los bloques, las transacciones que inducen MEV todavía pueden evitar el canal de subasta Jito. Este problema está al menos parcialmente evidenciado por el Panel de control de Dune en la Figura 10 [13], que muestra que la red todavía experimenta un promedio de más del 50% de transacciones fallidas debido al spam de bots desde 2024.

Figura 10: Un panel de control de Dune (https://dune.com/queries/3537204/5951285ilustrando las actividades de spam de bots en Solana desde mayo de 2022.

El 9 de marzo de 2024, Jito tomó la decisión de suspender su mempool principal. Esta decisión fue motivada por el crecimiento en transacciones de memecoin y un aumento correspondiente en ataques de sandwich (un tipo de front-running donde los buscadores colocan transacciones antes y después de la transacción objetivo), lo que finalmente degradó la experiencia del usuario. Similar a las tendencias observadas en Ethereum con canales de flujo de pedidos privados en MEVA, cerrar el mempool público puede fomentar el crecimiento del flujo de pedidos privados a través de asociaciones con servicios de front-end como proveedores de billeteras y bots de Telegram. Los buscadores pueden formar asociaciones directamente con validadores para una ejecución preferida, inclusión, exclusión. De hecho, se puede ver evidencia de esto en la Figura 11, que ilustra el perfil de beneficio del bot de sandwich por hora para el buscador de mempool privado más grande (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) después del cierre del mempool.

Figura 11: La ganancia por hora para el bot Sandwich con Mempool privado para el buscador “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

La decisión de Jito de cerrar la mempool subraya el fuerte compromiso del equipo para abordar problemas fundamentales dentro del ecosistema de Solana. Más allá de iterar en MEVA o ajustar el mecanismo de tarifas de gas de Solana, Jito también ayuda a educar a los protocolos sobre la mitigación de vectores de ataque a través de elecciones de diseño de producto de UI, como limitar los parámetros de deslizamiento predeterminados. Ya sea a través de ajustes en la estructura de tarifas que hagan más costoso el envío de spam o a través de la modificación de protocolos de comunicación, la infraestructura de Jito seguirá siendo esencial para mantener la salud y estabilidad de la red de Solana.

Diseño MEVA en Monad

Ejecución Diferida y Implicaciones en MEV

A diferencia de Ethereum, donde ponerse de acuerdo en un bloque requiere tanto la lista de transacciones (con orden) como la raíz de Merkle que resume todos los estados posteriores al hecho, Monad separa la ejecución previa del consenso. El acuerdo del nodo solo requiere establecer el orden oficial. Como se muestra en la Figura 12, cada nodo ejecuta las transacciones en el bloque N de forma independiente mientras se realiza el consenso en el bloque N+1. Esta disposición permite un presupuesto de gas correspondiente al tiempo completo de bloque ya que la ejecución solo necesita mantenerse al ritmo del consenso. [15] Sin la necesidad de que el nodo líder calcule la raíz de estado de facto, la ejecución puede utilizar todo el período de consenso para el siguiente bloque.

Figura 12: Ejecución Diferida de Mónada comparada con la puesta en escena de Ejecución-Consenso de Ethereum. La Ventana de Tiempo Operativo también se ilustra desde la perspectiva del diseño MEVA.

Definimos la ventana de tiempo operativo como el marco de tiempo permitido para que MEVA en Monad complete una propuesta de construcción de bloques que sea factible y rentable en comparación con el método de construcción de bloques predeterminado. Hay dos consecuencias inmediatas del modelo de ejecución diferida:

1. Cuando MEVA construye para el enésimo bloque dentro de la ventana de tiempo operativa, los validadores están acordando simultáneamente la lista de transacciones para el enésimo bloque mientras intentan completar la ejecución para el bloque enésimo - 1. Por lo tanto, dentro de la ventana de tiempo operativa en N, es muy posible que el estado disponible aún esté en N-2. Esto significa que no hay un “estado más reciente” garantizado para el relay o el builder bajo esta arquitectura de ejecución aplazada. Por lo tanto, es imposible simular el último bloque antes de que se produzca el siguiente, lo que resulta en indeterminismo.
2. Dado el tiempo de bloque de 1 segundo de Monad, la ventana de tiempo operativo para MEVA es extremadamente limitada. Esto significa que los constructores pueden no tener suficiente tiempo para simular secuencialmente bloques completos de transacciones y paquetes como suelen hacer en Ethereum. Muchas variables pueden afectar el tiempo necesario para la simulación de transacciones en EVM. Sin embargo, asumiendo que la simulación de una transacción lleva entre 10^1 y 10^2 microsegundos (una suposición aproximada), y con el objetivo de Monad de 10^4 transacciones por segundo, podría tomar aproximadamente 1 segundo completo solo para simular el bloque completo dentro de la ventana de tiempo operativo. Teniendo en cuenta el tiempo de bloque de 1 segundo de Monad, sería un desafío para los constructores o relés completar múltiples simulaciones de bloques completos para optimizar el bloque construido.

Estrategia de Constructor y Buscador Probabilístico

Dadas las limitaciones, completar una simulación completa de bloque dentro de la ventana de tiempo operativa y simular frente al estado más reciente es impráctico. Dado que los constructores ahora carecen tanto del tiempo como del estado más reciente para conocer la punta exacta de cada transacción, deben inferir la punta del buscador en función de la probabilidad de reversión de la transacción, confiando en la reputación o simulando contra (posiblemente en el mejor de los casos) el estado N-2. Esto hace que la valoración del bloque sea menos determinista.

Los buscadores enfrentan una mayor incertidumbre de ejecución debido a la falta de garantía teórica contra las reversiones de transacciones una vez que el validador acepta el bloque construido por el constructor. Esto contrasta con Ethereum, donde los buscadores compiten por canales de flujo de pedidos privados dedicados al constructor para ejecuciones de estrategias relativamente deterministas. En este entorno relativamente probabilístico en Monad, los buscadores ahora enfrentan un mayor riesgo de reversión de paquetes en cadena, lo que lleva a un perfil de ejecución de PnL más incierto. Esto refleja a los operadores de alta frecuencia que ejecutan señales probabilísticas con retornos esperados ligeramente positivos a lo largo del tiempo.

Figura 13: Un diagrama conceptual del espectro que ilustra diferentes paradigmas de diseño de MEVA categorizados por el grado de verificación o simulación de bloque propuesto.

Como se muestra en la Figura 13, el grado de verificación previa del paquete / bloque por parte del constructor crea un espectro de incertidumbre con respecto al precio o la valoración del bloque propuesto. En un extremo está el modelo PBS al estilo Ethereum con precios precisos, donde los constructores deben usar el cliente de capa de ejecución (EL) para simular la transacción en el bloque propuesto. Tienen que navegar a través de una amplia gama de combinatorias entre los paquetes enviados. En el otro extremo está el Modelo de Constructor Optimista [16] con comprobación de bloques asíncronos. En este modelo, los constructores evitan el tiempo requerido para cualquier simulación durante la ventana de tiempo operativo y respetan los consejos que se muestran a los validadores o al relé depositando garantías sujetas a recortes. La comprobación probabilística o el enfoque de simulación parcial propuesto aquí en Monad se encuentra en el medio, lo que aumenta la probabilidad de ejecución exitosa de la estrategia para los buscadores a pesar de cierto indeterminismo.

Por ejemplo, un market maker en un DEX con libro de órdenes on-chain podría pagar para pre-mover sus posiciones a través del MEVA cuando detecta un importante movimiento de precios uni-direccional, para evitar selección adversa. Esta estrategia probabilística les permite actuar rápidamente, incluso sin la información más reciente del estado, equilibrando el riesgo y la recompensa en un entorno de negociación dinámico.

Palabras de clausura

MEVA juega un papel crucial en la optimización de la producción de bloques mediante la mitigación de externalidades y la mejora de la estabilidad general del sistema. La evolución continua de los marcos de MEVA, ejemplificada por Jito en Solana y varias implementaciones en Ethereum, es de gran ayuda para abordar los desafíos de escalabilidad y alinear los incentivos de los participantes de la red.

Monad es una red prometedora en sus inicios, que presenta una oportunidad única para que la comunidad moldee el diseño óptimo de MEVA. Considerando la singularidad de la ejecución-consenso de Monad, invitamos a investigadores, desarrolladores y validadores a colaborar y compartir conocimientos. Esta colaboración será fundamental para crear un proceso de producción de bloques robusto y eficiente, permitiendo que Monad alcance su potencial como red blockchain de alto rendimiento.

Aviso legal:

1. Este artículo es una reimpresión de [ 0xapr]. Todos los derechos de autor pertenecen al autor original [APRIORI ⌘]. Si hay objeciones a esta reimpresión, por favor contacte alGate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.