Una publicación etiquetados con "SUAVE"

El Valor Máximo Extraíble (MEV) se refiere al beneficio que un "insider" de la blockchain (minero/validador u otro actor privilegiado) puede obtener al reordenar, incluir o excluir arbitrariamente transacciones en un bloque. La extracción de MEV sin control puede llevar a una ordenación injusta de transacciones, altas comisiones (debido a las subastas de gas prioritarias) y la centralización del poder en la producción de bloques. Han surgido varios protocolos para suprimir el MEV perjudicial o aplicar una ordenación justa de las transacciones. Este informe compara cuatro enfoques prominentes: Flashbots v2 (el sistema MEV-Boost de Flashbots post-Merge para Ethereum), SUAVE (la próxima Subasta Única Unificadora para la Expresión de Valor de Flashbots), Anoma (una arquitectura centrada en intenciones que reimagina cómo se emparejan y ordenan las transacciones) y Skip Protocol (un conjunto de herramientas basado en Cosmos para la gestión soberana de MEV dentro del protocolo). Examinamos cada uno en términos de sus algoritmos de encolado/ordenación de transacciones, mecanismos de mitigación o extracción de MEV, modelos de incentivos, características de cumplimiento y neutralidad, arquitectura técnica (consenso y criptografía) y progreso de desarrollo. Se proporcionan resúmenes estructurados y una tabla comparativa para destacar sus fortalezas y debilidades en la búsqueda de la equidad y la reducción de las externalidades negativas del MEV.

Flashbots v2 (MEV-Boost y BuilderNet en Ethereum)​

Flashbots v2 denota el ecosistema actual de Flashbots en Ethereum después de la transición a Proof-of-Stake, centrado en MEV-Boost e iniciativas recientes como BuilderNet. Flashbots v2 se basa en el paradigma de separación proponente/constructor (PBS) para abrir la construcción de bloques a un mercado competitivo de constructores mientras protege a los usuarios de Ethereum de los ataques de MEV en el mempool público.

• Ordenación de Transacciones (Encolado y Algoritmo): Flashbots MEV-Boost introduce un mercado de construcción de bloques fuera de la cadena. Los validadores (proponentes) externalizan la construcción de bloques a constructores especializados a través de un relay, en lugar de ordenar las transacciones localmente. Múltiples constructores compiten para proporcionar el bloque que más paga, y el validador firma a ciegas la cabecera del bloque con la oferta más alta (un enfoque PBS). Este diseño reemplaza eficazmente la ordenación de 'primero en llegar, primero en ser servido' del mempool público con una subasta a sobre cerrado para bloques enteros. Los constructores determinan internamente la ordenación de las transacciones para maximizar los pagos totales (incluidas las oportunidades de MEV), prefiriendo típicamente bundles con arbitrajes rentables o liquidaciones en la parte superior del bloque. Al usar MEV-Boost, Ethereum evitó las caóticas subastas de gas prioritarias (PGA) que anteriormente determinaban la ordenación; en lugar de que los usuarios y bots pujaran a través de las comisiones de gas en tiempo real (aumentando la congestión), MEV-Boost centraliza la ordenación por bloque al constructor más competitivo. Las colas de transacciones son, por lo tanto, gestionadas de forma privada por los constructores, quienes pueden ver los bundles o transacciones entrantes y organizarlos para obtener el máximo beneficio. Una desventaja es que esta ordenación impulsada por el beneficio no impone inherentemente la "equidad" para los usuarios; por ejemplo, los constructores aún pueden incluir flujos de órdenes tóxicos como los ataques sándwich si son rentables, pero sí optimiza la eficiencia al extraer MEV a través de una subasta controlada en lugar de guerras de gas ad-hoc. Desarrollos recientes han buscado hacer la ordenación más neutral: por ejemplo, la nueva BuilderNet de Flashbots (lanzada a finales de 2024) permite que múltiples constructores colaboradores compartan el flujo de órdenes y construyan bloques colectivamente en un Entorno de Ejecución Confiable (TEE), introduciendo reglas de ordenación verificables para mejorar la equidad. Esto aleja la ordenación de bloques de un único constructor centralizado hacia una red de construcción de bloques descentralizada con reglas que pueden ser auditadas para garantizar la neutralidad.

• Mecanismos de Supresión vs. Extracción de MEV: Flashbots v2 facilita principalmente la extracción de MEV en una forma más benigna en lugar de eliminarlo. El sistema original de Flashbots (v1) en 2021 permitía a los searchers enviar bundles (conjuntos de transacciones preferidas) directamente a los mineros, lo que suprimía las externalidades perjudiciales (sin front-running público, sin transacciones fallidas debido a la competencia) mientras seguía extrayendo MEV. En la era de MEV-Boost, el MEV es extraído por constructores que agrupan transacciones rentables, pero se reduce la competencia de suma negativa: los searchers ya no saturan el mempool con transacciones competidoras y comisiones de gas exorbitantes, lo que mitiga la congestión de la red y las comisiones excesivas para los usuarios. Flashbots v2 también proporciona herramientas de mitigación de MEV para los usuarios: por ejemplo, Flashbots Protect RPC permite a los usuarios enviar transacciones de forma privada a un relay, evitando el front-running en el mempool público (nadie puede ver o reordenar la transacción antes de su inclusión). Otra iniciativa, MEV-Share, permite a los usuarios compartir la información justa sobre sus transacciones para atraer ofertas de MEV mientras capturan una parte del valor para sí mismos. Sin embargo, Flashbots v2 no "previene" el MEV como los sándwiches o el arbitraje; canaliza estas actividades a través de una subasta eficiente que podría decirse que democratiza quién puede extraer el MEV. Recientemente, el diseño de BuilderNet tiene el objetivo explícito de "neutralizar los juegos de flujo de órdenes de suma negativa" y compartir el MEV con la comunidad a través de reglas de reembolso en la cadena. BuilderNet calcula los reembolsos pagados a los proveedores de flujo de órdenes de transacciones (como billeteras o DApps) en proporción al MEV que sus transacciones generaron, redistribuyendo el valor que de otro modo sería puro beneficio para los constructores. En resumen, Flashbots v2 maximiza la eficiencia de la extracción de MEV (asegurando que casi todo el valor extraíble en un bloque sea capturado) mientras introduce medidas para frenar las peores externalidades y devolver algo de valor a los usuarios. No llega a imponer una ordenación justa (las transacciones todavía se ordenan por el beneficio del constructor), pero a través del envío privado, la construcción multipartita y los reembolsos, suprime el daño negativo al usuario (como el slippage por front-running y los efectos de censura) tanto como sea posible dentro del modelo de subasta.

• Estructura de Incentivos Económicos: Flashbots v2 alinea los incentivos entre validadores, constructores y searchers a través de la subasta PBS. Los validadores se benefician al externalizar la producción de bloques: simplemente aceptan la oferta más alta y reciben el monto de la oferta (además de las recompensas de consenso), lo que aumentó drásticamente la parte del MEV que va a los validadores en comparación con la era en la que los mineros no tenían tales subastas. Los constructores están incentivados a competir entre sí encontrando la ordenación más rentable de las transacciones (a menudo incorporando estrategias de los searchers), y se quedan con cualquier beneficio de MEV que quede después de pagar la oferta del validador. En la práctica, la competencia obliga a los constructores a pagar la mayor parte del MEV a los validadores (a menudo >90% del beneficio), quedándose solo con un margen delgado. Los searchers (que ahora interactúan con los constructores a través de bundles o transacciones directas) todavía ganan al descubrir oportunidades de MEV (arbitraje, liquidación, etc.), pero deben ofrecer la mayor parte de su beneficio para ganar la inclusión; en efecto, los beneficios de los searchers se transfieren a los validadores a través de las ofertas de los constructores. Este equilibrio competitivo maximiza los ingresos totales de la red (beneficiando a los validadores/stakers) pero reduce los márgenes de los searchers individuales. Flashbots v2, por lo tanto, desincentiva los acuerdos exclusivos: cualquier searcher o constructor con una estrategia de MEV privada está incentivado a ofertarla a través del relay abierto para evitar ser superado, lo que conduce a un mercado más abierto. La introducción de BuilderNet añade un incentivo para los originadores de flujo de órdenes (como DEXs o billeteras): al darles reembolsos por el MEV que crean sus transacciones, anima a los usuarios y aplicaciones a enviar su flujo de órdenes al ecosistema de BuilderNet. Este mecanismo alinea a los usuarios con el sistema: en lugar de ser adversarios (usuarios vs. extractores de MEV), los usuarios comparten el MEV, por lo que están más dispuestos a participar en la subasta de manera justa. En general, la economía de Flashbots v2 favorece la colaboración sobre la competencia en la construcción de bloques: los validadores obtienen ingresos máximos sin riesgo, los constructores compiten en la calidad de la ejecución, y los searchers innovan para encontrar MEV pero renuncian a la mayoría de los beneficios para ganar las ofertas, mientras que los usuarios obtienen protección y posiblemente reembolsos.

• Cumplimiento y Resistencia a la Censura: El cumplimiento normativo se convirtió en un tema polémico para Flashbots después del Merge de Ethereum. El relay predeterminado de Flashbots implementó inicialmente el cumplimiento de las sanciones de la OFAC (censurando ciertas transacciones como las de Tornado Cash), lo que llevó a que aproximadamente el 80% de los bloques de Ethereum a finales de 2022 fueran "compatibles con la OFAC" y generó preocupaciones sobre centralización/censura en la comunidad. Flashbots v2 abordó esto fomentando un ecosistema de múltiples relays donde los validadores pueden elegir relays no censuradores (por ejemplo, UltraSound, Agnostic) o incluso ejecutar los suyos. Flashbots hizo público el código de su relay a mediados de 2022 para fomentar la competencia global de relays y la transparencia. Además, MEV-Boost v1.4 introdujo características como un ajuste de oferta mínima para que los proponentes pudieran rechazar ofertas bajas de constructores censuradores y recurrir a bloques locales, sacrificando algo de beneficio por la inclusión de todas las transacciones. Esta característica dio explícitamente a los validadores una forma de mejorar la resistencia a la censura de Ethereum a un pequeño costo. A finales de 2024, Flashbots dio un paso más al descontinuar su propio constructor centralizado en favor de BuilderNet, una red colaborativa destinada a ser "incensurable y neutral". BuilderNet utiliza TEEs (Intel SGX) para mantener el flujo de órdenes de transacciones encriptado y se compromete verificablemente a una regla de ordenación, lo que puede ayudar a evitar que los constructores individuales censuren transacciones específicas. Con múltiples participantes construyendo bloques conjuntamente dentro de enclaves seguros, ninguna parte puede excluir fácilmente una transacción sin ser detectada. En resumen, Flashbots v2 ha evolucionado de un único relay (e inicialmente censurador) a una infraestructura más descentralizada con participación abierta y objetivos explícitos de neutralidad. El cumplimiento se deja a las políticas de los relays/constructores individuales (y los validadores pueden elegir), en lugar de ser impuesto por el protocolo. La trayectoria es hacia la neutralidad creíble: eliminar cualquier punto de estrangulamiento controlado por Flashbots que pueda ser presionado por los reguladores. Flashbots se ha comprometido públicamente a eliminarse a sí mismo como operador central y a descentralizar todos los aspectos de la cadena de suministro de MEV a largo plazo.

• Arquitectura Técnica y Criptografía: Flashbots v2 opera de forma híbrida, fuera de la cadena y en el protocolo. La subasta principal (MEV-Boost) ocurre fuera de la cadena a través de la red de constructores y relays, pero se conecta directamente al consenso de Ethereum: los validadores ejecutan un cliente sidecar (mev-boost) que interactúa con los relays utilizando la API de Constructor estandarizada. En cuanto al consenso, Ethereum todavía utiliza PoS estándar (Casper/Hotstuff); MEV-Boost no altera las reglas de consenso de L1, solo cambia quién ensambla el bloque. Inicialmente, la subasta de Flashbots requería confiar en que el relay y el constructor no robarían transacciones ni censurarían; no había garantías criptográficas (el sistema se basaba en el incentivo económico de que los constructores deben entregar una carga útil válida que coincida con su oferta o pierden el espacio). Con el tiempo, Flashbots v2 ha integrado más tecnología de seguridad. La introducción de Entornos de Ejecución Confiable (TEE) a través de BuilderNet es un cambio arquitectónico notable: los constructores se ejecutan dentro de enclaves SGX para que incluso el operador del constructor no pueda ver el flujo de órdenes de transacciones en bruto (evitando que lo filtren o le hagan front-running). Estos enclaves siguen colectivamente un protocolo para producir bloques, lo que puede permitir una equidad verificable (por ejemplo, demostrar que las transacciones se ordenaron según una regla comprometida o que ninguna entidad no autorizada las vio antes de la inclusión). Aunque se utiliza SGX (un enfoque basado en hardware), la investigación de Flashbots también está explorando primitivas criptográficas puras, como el cifrado de umbral para la privacidad del mempool y la computación segura multipartita, para eventualmente reemplazar o complementar los TEEs y reducir aún más la confianza. La pila de software de Flashbots v2 incluye clientes personalizados como MEV-geth (ahora obsoleto) y constructores basados en Rust (por ejemplo, rbuilder), y se adhiere a las especificaciones de constructor de Ethereum para la interoperabilidad. En resumen, la arquitectura es modular: una red de relays, constructores y ahora enclaves, que se sitúa entre los usuarios y los proponentes de Ethereum. Prioriza el rendimiento (ofertas rápidas, entrega de bloques) y está añadiendo gradualmente garantías criptográficas de privacidad y ordenación justa. No se introduce ningún nuevo algoritmo de consenso; en su lugar, Flashbots v2 funciona junto con el consenso de Ethereum, evolucionando el pipeline de producción de bloques en lugar de las reglas de consenso.

• Hoja de Ruta de Desarrollo y Hitos: Flashbots ha progresado a través de fases iterativas. Flashbots v1 (2020–2021) implicó el lanzamiento de MEV-geth y las primeras subastas de bundles fuera de la cadena con mineros. A mediados de 2021, más del 80% del hashrate de Ethereum ejecutaba MEV-geth de Flashbots, confirmando la adopción del enfoque. Flashbots v2 (2022) fue concebido antes del Merge: en noviembre de 2021, Flashbots publicó la arquitectura MEV-Boost para Ethereum PoS. Después de que Ethereum cambiara a PoS (15 de septiembre de 2022), MEV-Boost se activó en cuestión de días y alcanzó rápidamente la adopción mayoritaria por parte de los validadores. Hitos posteriores incluyeron la publicación del código del relay (agosto de 2022) y del constructor de bloques interno de Flashbots (noviembre de 2022) para estimular la competencia. A finales de 2022, Flashbots también añadió características centradas en la resistencia a la censura y la resiliencia (por ejemplo, min-bid para proponentes) y escribió sobre el "Costo de la Resiliencia" para alentar a los validadores a preferir a veces la inclusión sobre el beneficio. A lo largo de 2023, mejorar la descentralización de los constructores se convirtió en un enfoque clave: Flashbots lanzó "rbuilder" (un constructor de Rust de alto rendimiento) en julio de 2024 como una implementación de referencia para reducir la barrera para nuevos constructores. Finalmente, a finales de 2024, Flashbots lanzó BuilderNet (alfa) en colaboración con socios (Beaverbuild, Nethermind). En diciembre de 2024, Flashbots cerró su constructor centralizado y migró todo el flujo de órdenes a BuilderNet, un paso significativo hacia la descentralización. A principios de 2025, se lanzó BuilderNet v1.2 con mejoras de seguridad e incorporación (incluidas compilaciones de enclaves reproducibles). Estos hitos marcan la transición de Flashbots de una solución centralizada conveniente a un protocolo más abierto y gestionado por la comunidad. Mirando hacia el futuro, Flashbots está convergiendo con su visión de próxima generación (SUAVE) para descentralizar completamente la capa de construcción de bloques e incorporar tecnología de privacidad avanzada. Muchas lecciones de Flashbots v2 (por ejemplo, la necesidad de neutralidad, el alcance multicadena y la inclusión de los usuarios en las recompensas de MEV) informan directamente la hoja de ruta de SUAVE.

SUAVE (Subasta Única Unificadora para la Expresión de Valor de Flashbots)​

SUAVE es el ambicioso siguiente protocolo de Flashbots, diseñado como un mercado de MEV descentralizado y multidominio y una capa de secuenciación justa de transacciones. Su objetivo es desvincular los mempools y la construcción de bloques de las blockchains individuales y proporcionar una plataforma unificada donde los usuarios expresan preferencias, una red descentralizada ejecuta transacciones de manera óptima y los constructores de bloques producen bloques para muchas cadenas de una manera creíblemente neutral. En resumen, SUAVE busca maximizar la extracción total de valor mientras devuelve valor a los usuarios y preserva la descentralización de la blockchain. Flashbots introdujo SUAVE a finales de 2022 como "el futuro del MEV" y lo ha estado desarrollando de forma abierta desde entonces.

• Encolado y Ordenación de Transacciones: Desde un alto nivel, SUAVE funciona como una red de blockchain independiente que otras cadenas pueden usar como un mempool y constructor de bloques plug-and-play. En lugar de que las transacciones se pongan en cola en el mempool de cada cadena y sean ordenadas por mineros o validadores locales, los usuarios pueden enviar sus transacciones (o, más generalmente, preferencias) al mempool de la red SUAVE. El mempool de SUAVE sirve entonces como un pool de subasta global de preferencias de todas las cadenas participantes. La ordenación de las transacciones se determina a través de esta subasta y la posterior optimización de la ejecución. Específicamente, SUAVE introduce el concepto de preferencias: el envío de un usuario no es solo una transacción en bruto para una cadena, sino que puede codificar un objetivo o un intercambio condicional (posiblemente abarcando múltiples cadenas) y una oferta asociada que el usuario está dispuesto a pagar por su cumplimiento. El algoritmo de ordenación/encolado en SUAVE tiene múltiples etapas: Primero, los usuarios publican sus preferencias en el mempool de SUAVE (el "Entorno de Preferencia Universal"), que agrega todas las órdenes de forma privada y global. A continuación, nodos especializados llamados ejecutores (análogos a los searchers/solvers) monitorean este mempool y compiten en un Mercado de Ejecución Óptima para cumplir estas preferencias. Efectivamente, "ponen en cola" las transacciones encontrando coincidencias u ordenaciones de ejecución óptimas para ellas. Finalmente, SUAVE produce salidas de bloque para cada cadena conectada a través de una capa de Construcción de Bloques Descentralizada: muchos constructores (o ejecutores de SUAVE actuando como constructores) colaboran para construir bloques utilizando el orden de transacciones (ahora optimizado) derivado de las preferencias de los usuarios. En términos prácticos, la ordenación de SUAVE es flexible y dirigida por el usuario: un usuario puede especificar condiciones como "ejecutar mi operación solo si el precio < X" o incluso expresar una intención abstracta ("intercambiar token A por B a la mejor tasa en 1 minuto") en lugar de una transacción estricta. El sistema pone en cola estas intenciones hasta que un ejecutor encuentra una ordenación o coincidencia óptima (posiblemente agrupándola con otras). Debido a que SUAVE es agnóstico a la blockchain, puede coordinar la ordenación entre cadenas (evitando escenarios donde los arbitrajes entre cadenas se pierden debido a mempools separados y no coordinados). En esencia, SUAVE implementa una subasta global de MEV: todos los participantes comparten una capa de secuenciación, que ordena las transacciones basándose en preferencias y ofertas agregadas en lugar de un simple orden de llegada o precio del gas. Esto tiene el efecto de nivelar el campo de juego: todo el flujo de órdenes pasa por una cola transparente (aunque encriptada para la privacidad, como se discute a continuación) en lugar de acuerdos exclusivos o mempools privados. El algoritmo de ordenación de SUAVE todavía se está refinando, pero es probable que involucre subastas por lotes que preservan la privacidad y algoritmos de emparejamiento para que se puedan lograr resultados "justos" (como el máximo excedente total o precios óptimos para el usuario) en lugar de un puro "primero en llegar, primero en ser servido". Notablemente, SUAVE tiene la intención de evitar que cualquier actor único manipule la ordenación: es nativo de Ethereum y consciente del MEV, con un mempool encriptado que prioriza la privacidad y protege contra cualquier punto central de control. En resumen, la cola de SUAVE es un pool de flujo de órdenes unificado donde la ordenación está determinada por una combinación de ofertas de los usuarios, estrategia de los ejecutores y (eventualmente) restricciones de equidad criptográficas, en lugar de por proponentes de bloques compitiendo por la prioridad.

• Mecanismos de Supresión/Extracción de MEV: La filosofía de SUAVE es que el MEV puede ser aprovechado en beneficio de los usuarios y para la seguridad de la red si se hace de manera cooperativa y descentralizada. En lugar de ignorar el MEV o dejar que se concentre en unas pocas manos, SUAVE explícitamente saca a la luz las oportunidades de MEV y devuelve el valor a quienes lo crean (los usuarios) tanto como sea posible. El mecanismo principal es la subasta de flujo de órdenes: cada vez que la transacción (preferencia) de un usuario tiene MEV —por ejemplo, podría ser objeto de back-running para obtener un beneficio— SUAVE llevará a cabo una subasta entre los ejecutores (searchers) por el derecho a ejecutar esa oportunidad de MEV. Los searchers (ejecutores) pujan prometiendo una parte del beneficio de vuelta al usuario como pago (este es el campo de "oferta" del usuario en su preferencia, que va a quien la cumpla). El resultado es una extracción de MEV competitiva que dirige los ingresos hacia el usuario en lugar del extractor. Por ejemplo, si una gran operación DEX de un usuario crea una oportunidad de arbitraje de 100 $, los searchers en SUAVE podrían reducir el beneficio ofreciendo, digamos, 90$ de vuelta al usuario como reembolso, quedándose solo con 10 $. Esto suprime los aspectos negativos del MEV como la extracción de valor del usuario, y convierte el MEV en un beneficio para el usuario (los usuarios obtienen efectivamente una mejora de precio o reembolsos). El diseño de SUAVE también suprime el front-running y otros MEV maliciosos: las transacciones en el mempool de SUAVE pueden mantenerse encriptadas hasta que se esté construyendo un bloque (usando enclaves SGX inicialmente, y avanzando hacia la criptografía de umbral). Esto significa que ningún actor externo puede ver las transacciones pendientes para hacerles front-running; solo cuando se recopilan suficientes transacciones y se finaliza un bloque, se desencriptan y ejecutan, similar en espíritu a las subastas por lotes o mempools encriptados que eliminan la ventaja de prioridad temporal de los bots. Además, como los ejecutores optimizan la ejecución a través de muchas preferencias, SUAVE puede eliminar la competencia ineficiente (como dos bots luchando por el mismo arbitraje mediante spam). En su lugar, SUAVE selecciona al mejor ejecutor a través de la subasta y ese ejecutor realiza la operación una vez, con el resultado beneficiando al usuario y a la red. SUAVE actúa así como un agregador de MEV y una "hada madrina": no elimina el MEV (las oportunidades rentables todavía se aprovechan), pero esas oportunidades se realizan bajo reglas transparentes y con las ganancias distribuidas en gran medida a los usuarios y validadores (y no desperdiciadas en comisiones de gas o guerras de latencia). Al unificar los mempools, SUAVE también aborda el MEV multidominio de una manera fácil de usar; por ejemplo, un arbitraje entre Uniswap en Ethereum y un DEX en Arbitrum podría ser capturado por un ejecutor de SUAVE y una parte pagada a los usuarios de ambos lados, en lugar de perderse o requerir un arbitrajista centralizado. Es importante destacar que SUAVE suprime las fuerzas centralizadoras del MEV: los acuerdos de flujo de órdenes exclusivos (donde entidades privadas capturan MEV) se vuelven innecesarios si todos usan la subasta común. La visión final de SUAVE es reducir la extracción de MEV perjudicial (como los ataques sándwich que causan slippage) ya sea haciéndolos no rentables o reembolsando el slippage, y usar el "buen MEV" (arbitraje, liquidaciones) para fortalecer las redes (a través del reparto de ingresos y la ejecución óptima). En palabras de Flashbots, el objetivo de SUAVE es asegurar que "los usuarios realicen transacciones con la mejor ejecución y las mínimas comisiones" mientras que "los validadores obtienen los máximos ingresos", es decir, cualquier MEV presente se extrae de la manera más alineada con el usuario.

• Estructura de Incentivos Económicos: SUAVE introduce nuevos roles y flujos de incentivos en la cadena de suministro de MEV. Los principales participantes son los usuarios, los ejecutores, los constructores/validadores de bloques y los operadores de la red SUAVE (validadores de la cadena SUAVE). Los usuarios establecen una oferta (pago) en su preferencia, que se pagará si se cumplen sus condiciones. Esta oferta es el anzuelo para los ejecutores: un ejecutor que cumple la intención del usuario (por ejemplo, hace back-running a su operación para obtener un mejor precio) puede reclamar la oferta como recompensa. Por lo tanto, los usuarios están directamente pagando por la calidad de la ejecución, de forma similar a publicar una recompensa. Los ejecutores (Searchers) están motivados a tomar las preferencias de los usuarios del mempool de SUAVE y optimizarlas porque ganan la oferta del usuario más cualquier beneficio de arbitraje extra inherente a la transacción. Los ejecutores competirán para ofrecer el mejor resultado al usuario porque el usuario puede establecer su oferta de manera que solo pague si el ejecutor realmente logra el resultado deseado (la oferta puede ser condicional a los resultados en la cadena a través de oráculos). Por ejemplo, un usuario podría decir: "Pagaré 0.5 ETH a quien ejecute esta transacción de tal manera que obtenga al menos X de salida; si no, no hay pago". Esto alinea los incentivos de los ejecutores con el éxito del usuario. Validadores/Constructores de SUAVE: La propia cadena SUAVE probablemente será una red Proof-of-Stake (diseño por determinar), por lo que los validadores (que producen bloques en SUAVE) ganan comisiones de transacción en SUAVE (que provienen de los usuarios que publican ofertas y otras operaciones). Dado que SUAVE es una cadena compatible con EVM, también puede haber un token nativo o un sistema de comisiones de gas para esas transacciones. Estos validadores también desempeñan un papel en la secuenciación de bloques multidominio; sin embargo, la inclusión final del bloque en cada L1 todavía la realiza el validador de esa L1. En muchos casos, SUAVE producirá una plantilla de bloque parcial o completa que un proponente de Ethereum u otra cadena puede adoptar. Ese constructor podría pagar a SUAVE (o a los ejecutores de SUAVE) una parte del MEV. Flashbots ha mencionado que los validadores de SUAVE son incentivados por las comisiones normales de la red, mientras que los ejecutores son incentivados por las ofertas. Distribución de Valor: El enfoque de SUAVE tiende a empujar el valor hacia los extremos: los usuarios capturan valor (a través de mejores precios o reembolsos directos), y los validadores capturan valor (a través de mayores comisiones/ofertas). En teoría, si SUAVE cumple su misión, la mayor parte del MEV será devuelta a los usuarios o utilizada para compensar a los validadores por asegurar la red, en lugar de concentrarse en los searchers. Flashbots ha indicado que no planea buscar rentas de SUAVE y no tomará una parte más allá de lo necesario para arrancar; quieren diseñar el mercado, no monopolizarlo. Otra consideración de incentivos son los constructores entre cadenas: SUAVE permite a los constructores de bloques acceder al MEV multidominio, lo que significa que un constructor en una cadena puede ganar comisiones adicionales al incluir transacciones que completan un arbitraje con otra cadena. Esto anima a los constructores/validadores de diferentes cadenas a participar en SUAVE, porque quedarse fuera significa perder ingresos. En esencia, el diseño económico de SUAVE intenta alinear a todos los participantes para que se unan a la subasta común: los usuarios porque obtienen una mejor ejecución (y quizás reembolsos de MEV), los validadores porque obtienen los máximos ingresos, y los searchers porque ahí es donde se agrega el flujo de órdenes. Al concentrar el flujo de órdenes, SUAVE también obtiene una ventaja de información sobre cualquier actor aislado (todas las preferencias en un solo lugar), lo que presiona económicamente a todos a cooperar dentro de SUAVE en lugar de separarse. En resumen, los incentivos de SUAVE promueven un ciclo virtuoso: más flujo de órdenes → mejores oportunidades de MEV combinadas → ofertas más altas para usuarios/validadores → más flujo de órdenes. Esto contrasta con la competencia de suma cero y los acuerdos exclusivos del pasado, apuntando en cambio a la "coopetición" donde el MEV es un valor compartido para crecer y distribuir.

• Cumplimiento y Consideraciones Regulatorias: SUAVE se está construyendo con la neutralidad creíble y la resistencia a la censura como principios fundamentales. Por diseño, SUAVE elimina intermediarios centrales: no hay un único mempool o un único constructor para atacar o regular. Las transacciones (preferencias) en SUAVE pueden ser totalmente encriptadas y privadas hasta que se ejecutan, utilizando enclaves seguros y, eventualmente, técnicas criptográficas. Esto significa que la censura a nivel de contenido de la transacción es impracticable, ya que los validadores/constructores ni siquiera pueden leer los detalles de la transacción antes de finalizar el orden. SUAVE esencialmente fuerza un enfoque de "no confíes, verifica": los participantes no necesitan confiar en que una entidad no censure, porque la propia arquitectura del sistema (red descentralizada + encriptación) asegura que las preferencias de todos se incluyan de manera justa. Además, SUAVE está destinado a ser una red abierta y sin permisos: Flashbots invita explícitamente a todas las partes (usuarios, searchers, billeteras, otras blockchains) a participar. No hay KYC ni barreras de permiso en su diseño. Esto podría plantear preguntas a los reguladores (por ejemplo, el protocolo podría facilitar la extracción de MEV en transacciones sancionadas), pero como SUAVE es solo una plataforma descentralizada, la aplicación sería difícil y análoga a tratar de regular el mempool de una blockchain. El enfoque de SUAVE en la privacidad (a través de SGX y más tarde la criptografía) también protege los datos de los usuarios y el flujo de órdenes de un monitoreo no deseado, lo cual es positivo para la seguridad del usuario pero podría entrar en conflicto con los deseos regulatorios de transparencia. Por otro lado, el enfoque de SUAVE podría verse como más justo y conforme con el espíritu de los mercados abiertos: al crear un campo de juego nivelado y devolver valor a los usuarios, reduce los aspectos explotadores del MEV que podrían atraer la ira regulatoria (como hacer back-running a los usuarios sin su consentimiento). SUAVE también puede ayudar a eliminar los dark pools no regulados: una razón por la que los reguladores podrían estar preocupados por el MEV son las ventas de flujo de órdenes exclusivas (que se asemejan al uso de información privilegiada). SUAVE las reemplaza con una subasta pública transparente, una estructura de mercado posiblemente más compatible. En términos de características de cumplimiento explícitas, SUAVE podría permitir múltiples políticas de ordenación: por ejemplo, las comunidades o jurisdicciones podrían desplegar sus propios ejecutores con ciertos filtros o preferencias. Sin embargo, la base es que SUAVE intentará ser máximamente neutral: "eliminar cualquier punto central de control, incluido Flashbots" y evitar incrustar decisiones de política a nivel de protocolo. Flashbots ha enfatizado que no controlará el mercado de SUAVE a medida que madure, lo que significa que no habrá un interruptor de apagado central o un conmutador de censura. La gobernanza (si la hay) de SUAVE aún no está definida públicamente, pero se puede esperar que involucre a la comunidad en general y posiblemente a un token, en lugar de la decisión de una empresa. En resumen, SUAVE está diseñado para alinearse con los principios descentralizados, lo que por naturaleza resiste cierto control regulatorio (censura), mientras que potencialmente alivia algunas preocupaciones regulatorias al hacer que la extracción de MEV sea más equitativa y transparente.

• Arquitectura Técnica (Consenso y Criptografía): SUAVE operará su propio entorno de blockchain, al menos inicialmente. Se describe como una cadena compatible con EVM especializada en preferencias y MEV. La arquitectura tiene tres componentes principales: (1) el Entorno de Preferencia Universal (la cadena SUAVE + mempool, donde se publican y agregan las preferencias), (2) el Mercado de Ejecución (ejecutores fuera o dentro de la cadena que resuelven/optimizan las preferencias, similar a un "motor de emparejamiento de órdenes" descentralizado), y (3) la Construcción de Bloques Descentralizada (una red de participantes de SUAVE que ensamblan bloques para varios dominios). En su núcleo, el consenso de SUAVE probablemente será un consenso BFT de Prueba de Participación (similar a Ethereum o Cosmos) para operar la propia cadena SUAVE, aunque todavía se está decidiendo si SUAVE se convertirá en una L1, una L2 de Ethereum o un conjunto de contratos de "restaking". Una posibilidad es que SUAVE pueda comenzar como una capa 2 o sidechain que utiliza Ethereum para la finalidad, o aprovechar conjuntos de validadores existentes. El modelo de seguridad está por determinar, pero las discusiones han incluido convertirlo en una L3 de Ethereum o una cadena de Cosmos. Criptográficamente, SUAVE se apoya fuertemente en Hardware Confiable y encriptación en su hoja de ruta inicial. La fase SUAVE Centauri implementa una "subasta de flujo de órdenes consciente de la privacidad" en la que Flashbots (de forma centralizada) opera enclaves SGX para mantener privados los flujos de órdenes de los searchers y usuarios. En SUAVE Andromeda, planean usar subastas y construcción de bloques basadas en SGX sin confiar en Flashbots (los enclaves proporcionan confidencialidad para que ni siquiera Flashbots pueda espiar). Para SUAVE Helios, el objetivo es tener una red de construcción descentralizada basada en SGX, lo que significa que muchas partes independientes ejecutan enclaves que construyen bloques colectivamente, logrando tanto privacidad como descentralización. A largo plazo, Flashbots está investigando enclaves seguros personalizados y reemplazos criptográficos como el descifrado de umbral y la computación multipartita para reducir la dependencia del SGX de Intel. Por ejemplo, podrían usar un esquema de cifrado de umbral donde los validadores de SUAVE mantienen conjuntamente una clave para descifrar transacciones solo después de que se decide la ordenación (asegurando que nadie pueda hacer front-running). Este concepto es similar a Ferveo de Anoma u otras ideas de "ordenación justa a través de cifrado de umbral". Además, SUAVE trata las preferencias del usuario como contratos inteligentes en su cadena. La preferencia de un usuario podría contener un predicado de validez y una condición de pago; esto es esencialmente un fragmento de código que dice "si se logra el resultado X en la cadena Y, entonces paga al ejecutor Z esta cantidad". La cadena SUAVE necesita manejar oráculos y verificación entre cadenas para saber cuándo se ha cumplido una preferencia (por ejemplo, leyendo el estado de Ethereum para ver si ocurrió un intercambio). Esto implica que la arquitectura de SUAVE involucrará clientes ligeros en cadena o sistemas de oráculos para las cadenas conectadas, así como potencialmente liquidación atómica entre cadenas (para asegurar, por ejemplo, que un ejecutor pueda ejecutar en Ethereum y Arbitrum y reclamar la oferta atómicamente). SUAVE planea ser altamente extensible: al ser compatible con EVM, contratos arbitrarios (preferencias nativas de SUAVE o incluso dapps normales) podrían ejecutarse en él, aunque la intención es mantenerlo enfocado en la coordinación del flujo de órdenes. En cuanto al consenso, SUAVE podría innovar al ser una cadena centrada en intenciones en lugar de una centrada en transacciones, pero en última instancia debe ordenar mensajes (preferencias) y producir bloques como cualquier cadena. Uno puede imaginar que SUAVE adopte un algoritmo de consenso optimizado para rendimiento y finalidad de baja latencia, ya que se situará en la ruta crítica de las transacciones para muchas cadenas. Quizás se podría usar una finalidad instantánea al estilo de Tendermint o incluso un consenso basado en DAG para confirmar rápidamente las preferencias. Independientemente, las características distintivas de SUAVE están en la capa de transacción, no en la capa de consenso: el uso de tecnología de privacidad (SGX, cifrado de umbral) para la ordenación, la comunicación multidominio y la lógica de enrutamiento de órdenes inteligentes integrada en el protocolo. Esto lo convierte en una especie de "meta-capa" sobre las blockchains existentes. Técnicamente, cada cadena participante necesitará confiar en las salidas de SUAVE hasta cierto punto (por ejemplo, un proponente de Ethereum necesitaría aceptar un bloque construido por SUAVE o incluir sugerencias de SUAVE). Flashbots ha indicado que SUAVE se introducirá gradualmente y será opcional: los dominios pueden elegir adoptar la secuenciación de SUAVE para sus bloques. Si se adopta ampliamente, SUAVE podría convertirse en una red de enrutamiento de transacciones consciente del MEV de facto para Web3. En resumen, la arquitectura de SUAVE es un matrimonio entre blockchain y subasta fuera de la cadena: una cadena especializada para la coordinación, casada con la computación segura fuera de la cadena entre ejecutores, todo anclado por garantías criptográficas de equidad y privacidad.

• Hoja de Ruta de Desarrollo y Hitos: Flashbots delineó la hoja de ruta de SUAVE en tres hitos principales, nombrados como sistemas estelares: Centauri, Andromeda y Helios. Centauri (la primera fase, en desarrollo en 2023) se enfoca en construir una subasta de flujo de órdenes centralizada pero que preserva la privacidad. En esta fase, Flashbots ejecuta el servicio de subasta (probablemente en SGX) que permite a los searchers pujar para hacer back-running a las transacciones de los usuarios, devolviendo el MEV a los usuarios de forma privada. También incluye el lanzamiento de una devnet de SUAVE para pruebas iniciales. De hecho, en agosto de 2023, Flashbots publicó un cliente temprano de SUAVE (suave-geth) y lanzó Toliman, la primera testnet pública de SUAVE. Esta testnet se ha utilizado para experimentar con la expresión de preferencias y la lógica básica de subastas. Andromeda (la siguiente fase) lanzará la primera mainnet de SUAVE. Aquí, los usuarios podrán expresar preferencias en una red en vivo, y el Mercado de Ejecución operará (ejecutores cumpliendo intenciones). Andromeda también introduce subastas y construcción de bloques basadas en SGX de una manera más distribuida, eliminando la necesidad de confiar en Flashbots como operador y haciendo el sistema verdaderamente sin permisos para searchers y constructores. Un entregable en esta fase es usar SGX para encriptar el flujo de órdenes de manera que incluso los constructores de bloques no puedan espiar pero aún puedan construir bloques (es decir, un flujo de órdenes "abierto pero privado"). Helios es la ambiciosa tercera fase donde SUAVE alcanza la descentralización total y la funcionalidad entre cadenas. En Helios, una red descentralizada de constructores en SGX produce bloques de forma colaborativa (sin dominio de un solo constructor). Además, SUAVE "incorporará un segundo dominio" más allá de Ethereum, lo que significa que manejará el MEV para al menos dos cadenas, demostrando subastas de MEV entre cadenas. Adicionalmente, se habilitará la expresión y ejecución de MEV multidominio (los usuarios pueden publicar intenciones verdaderamente multicadena y hacer que se ejecuten atómicamente). Más allá de Helios, Flashbots anticipa explorar hardware personalizado y criptografía avanzada (como pruebas zk o MPC) para endurecer aún más las garantías de confianza. Actualizaciones y hitos clave hasta ahora: Noviembre de 2022 – se anuncia SUAVE; Agosto de 2023 – primer lanzamiento de código de SUAVE y testnet (Toliman); en curso en 2024 – fase Centauri de subasta de flujo de órdenes en ejecución (Flashbots ha insinuado que esto se está probando con transacciones de usuarios en un entorno cerrado). Un hito notable será el lanzamiento de la mainnet de SUAVE (Andromeda), que a mediados de 2025 está en el horizonte. Flashbots se ha comprometido a construir SUAVE de forma abierta e invitar a la colaboración de todo el ecosistema. Esto se refleja en la investigación y las discusiones del foro, como las publicaciones de la serie "Stargazing" que actualizan sobre la evolución del diseño de SUAVE. El objetivo final de SUAVE es que se convierta en una pieza de infraestructura propiedad de la comunidad: la "capa de secuenciación descentralizada" para todo el mundo cripto. Lograr esto marcará un hito importante en la lucha por la ordenación justa: si SUAVE tiene éxito, el MEV ya no sería un bosque oscuro sino una fuente de valor transparente y compartida, y ninguna cadena tendría que sufrir por sí sola los efectos centralizadores del MEV.

Anoma (Arquitectura Centrada en Intenciones para el Descubrimiento Justo de Contrapartes)​

Anoma es un enfoque radicalmente diferente para permitir la ordenación justa y la mitigación de MEV: es una arquitectura completa para una infraestructura de blockchain basada en intenciones. En lugar de añadir una subasta a las cadenas existentes, Anoma replantea el paradigma de las transacciones desde cero. En Anoma, los usuarios no transmiten transacciones concretas; transmiten intenciones, declaraciones del estado final que desean, y la propia red descubre contrapartes y forma transacciones que cumplen estas intenciones. Al integrar el descubrimiento de contrapartes, la ordenación justa y la privacidad a nivel de protocolo, Anoma tiene como objetivo eliminar virtualmente ciertas formas de MEV (como el front-running) y permitir un intercambio y liquidación descentralizados "libres de front-runners". Anoma es más un marco que una sola cadena: cualquier blockchain puede ser una "instancia fractal" de Anoma adoptando su arquitectura de gossip de intenciones y emparejamiento. Para esta discusión, nos centramos en la primera implementación de Anoma (a veces llamada Anoma L1) y sus características de protocolo principales, en lo que respecta a la equidad y el MEV.

• Encolado y Ordenación de Transacciones: Anoma descarta el mempool convencional de transacciones; en su lugar, tiene una red de gossip de intenciones. Los usuarios transmiten una intención, por ejemplo, "Quiero cambiar 100 DAI por al menos 1 ETH" o "Quiero pedir prestado contra colateral a la mejor tasa". Estas intenciones son órdenes parciales: no especifican rutas de ejecución exactas, solo el resultado deseado y las restricciones. Todas las intenciones se transmiten por toda la red y se recopilan. Ahora, la ordenación en Anoma funciona en dos etapas: (1) Descubrimiento/Emparejamiento de Contrapartes, y (2) Ejecución de Transacciones con Ordenación Justa. En la etapa 1, nodos especializados llamados solvers monitorean continuamente el pool de intenciones e intentan encontrar conjuntos de intenciones que se complementen entre sí para formar una transacción válida. Por ejemplo, si Alice tiene la intención de cambiar DAI por ETH y Bob tiene la intención de cambiar ETH por DAI, un solver puede emparejarlos. Si múltiples intenciones son compatibles (como un libro de órdenes de ofertas y demandas), los solvers pueden encontrar un emparejamiento o precio de compensación óptimo. Es importante destacar que esto sucede fuera de la cadena en la red de solvers, efectivamente un emparejamiento algorítmico. Una vez que un solver (o grupo de solvers) ha construido una transacción completa (o un conjunto de transacciones) que cumple algunas intenciones, la envía a la cadena para su ejecución. Aquí es donde entra la etapa 2: el consenso de Anoma entonces ordenará estas transacciones enviadas por los solvers en bloques. Sin embargo, el consenso de Anoma está diseñado para ser justo en el orden: utiliza técnicas criptográficas (cifrado de umbral) para asegurar que las transacciones se ordenen sin ser influenciadas por su contenido o el momento preciso de su envío. Específicamente, Anoma planea usar Ferveo, un esquema de cifrado de umbral, a nivel de mempool. La forma en que funciona es: los solvers encriptan las transacciones que quieren proponer usando una clave pública colectiva de los validadores. Los validadores incluyen estas transacciones encriptadas en los bloques sin conocer sus detalles. Solo después de que una transacción se finaliza en un bloque, los validadores la desencriptan colectivamente (cada uno contribuyendo con una parte de la clave de descifrado). Esto asegura que ningún validador pueda hacer front-running selectivamente o reordenar basándose en el contenido de una transacción; se comprometen a una ordenación a ciegas. El algoritmo de consenso ordena efectivamente las transacciones (en realidad, las intenciones) de una manera más cercana a un orden de primera vista o por lotes, ya que todas las transacciones en un "lote" dado (bloque) se encriptan y revelan simultáneamente. En la práctica, Anoma puede implementar subastas por lotes para ciertas aplicaciones: por ejemplo, una intención de comerciar puede recopilarse durante N bloques (manteniéndose encriptada), luego todas se desencriptan juntas después de N bloques y son emparejadas por los solvers en un solo lote. Esto evita que los actores rápidos vean las órdenes de otros y reaccionen dentro de ese lote, una gran ventaja para la equidad (esta técnica está inspirada en las Subastas por Lotes Frecuentes y se ha propuesto para eliminar las ventajas del trading de alta frecuencia). Además, los predicados de validez de Anoma (contratos inteligentes a nivel de aplicación) pueden imponer restricciones de equidad en el resultado de la ordenación. Por ejemplo, una aplicación DEX de Anoma podría tener una regla: "todas las operaciones en un lote obtienen el mismo precio de compensación, y los solvers no pueden insertar transacciones adicionales para explotar a los usuarios". Debido a que estas reglas son parte de la validez del estado, cualquier bloque que contenga un emparejamiento injusto (digamos, un solver intentó colar una operación propia a un mejor precio) sería inválido y rechazado por los validadores. En resumen, la ordenación en Anoma ocurre como emparejar y luego encriptar+ordenar: las intenciones se ponen conceptualmente en cola hasta que un solver forma una transacción, y luego esa transacción es ordenada por un consenso de ordenación justa (evitando el MEV típico). Efectivamente, no hay una carrera en el mempool, ya que las intenciones de los usuarios no compiten directamente por el precio del gas o la prioridad temporal. En cambio, la competencia es para que los solvers encuentren coincidencias, y luego esas coincidencias se ejecutan de una manera que nadie puede cambiar el orden o interceptarlas mientras están en tránsito. Esta arquitectura promete neutralizar muchos vectores de MEV: no existe el concepto de hacer front-running a una intención porque las intenciones no son accionables hasta que el solver las ensambla, y para entonces ya están encriptadas en el bloque. Es un modelo de encolado fundamentalmente diferente destinado a eliminar las explotaciones de prioridad basadas en el tiempo.

• Mecanismos de Supresión/Extracción de MEV: Anoma está diseñado para minimizar el "mal MEV" por construcción. Al resolver las operaciones a través de la resolución por lotes y el cifrado de umbral, los ataques de MEV típicos como el sándwich son imposibles: nadie ve una intención y puede insertar la suya antes, porque las intenciones no son transacciones que viven en un mempool transparente. Los solvers solo emiten transacciones emparejadas finales después de que la oportunidad de inserción ha pasado (debido a la encriptación y el procesamiento por lotes). En un DEX basado en Anoma, los usuarios no serían objeto de front-running o back-running en el sentido tradicional, porque todas las operaciones en un lote se ejecutan juntas a un precio uniforme (evitando que un atacante explote el cambio de precio entre ellas). Esto esencialmente suprime el MEV depredador como el arbitraje DEX o el sándwich; el valor que habría sido tomado por un bot es retenido por los usuarios (obtienen un precio justo). El enfoque de Anoma sobre el arbitraje también es notable: en muchos casos, si múltiples intenciones crean una oportunidad de arbitraje, el solver que las empareja incorporará ese beneficio en el emparejamiento (por ejemplo, emparejar diferentes precios y obtener un beneficio neto). Pero como múltiples solvers pueden competir para proporcionar el mejor emparejamiento, la competencia puede forzar a los solvers a devolver la mayor parte de esa ventaja a los usuarios en forma de mejores términos de llenado. Por ejemplo, si un usuario quiere vender al precio A y otro quiere comprar al precio B (B > A implica una brecha), un solver podría cumplir ambos a un precio intermedio y capturar la diferencia como beneficio, pero si otro solver ofrece a los usuarios un precio aún más cercano entre sí (dejando menos beneficio), ganará la intención. Así, los solvers compiten para reducir los márgenes de MEV en beneficio de los usuarios, de manera similar a cómo los searchers en Flashbots compiten a través de las comisiones. La diferencia es que esto sucede algorítmicamente a través del emparejamiento de intenciones en lugar de la puja por el gas. Todavía puede haber "MEV extraído" en Anoma, pero es probable que se limite a que los solvers ganen comisiones modestas por su servicio. Notablemente, Anoma espera que la mayor parte del flujo de órdenes sea internalizado por el protocolo o la lógica de la aplicación. En algunos casos, esto significa que lo que sería una oportunidad de MEV se convierte simplemente en una comisión normal del protocolo. Por ejemplo, la primera instancia fractal de Anoma (Namada) implementa un AMM de curva de enlace en la cadena; el arbitraje en ese AMM es capturado por el mecanismo del AMM (como un reequilibrador incorporado) en lugar de por arbitrajistas externos. Otro ejemplo: una intención de préstamo que ofrece un alto interés podría ser emparejada con una intención de préstamo; no se necesita un liquidador de terceros si el colateral cae, porque las propias intenciones podrían manejar el reequilibrio o el protocolo podría autoliquidar a un precio justo. Al eliminar a los extractores de terceros, Anoma reduce la prevalencia de la extracción de MEV fuera de la cadena. Además, Anoma enfatiza la privacidad (a través del subsistema Taiga de circuitos ZK). Los usuarios pueden optar por mantener sus intenciones parcial o totalmente protegidas (por ejemplo, ocultando cantidades o tipos de activos). Esto suprime aún más el MEV: si los detalles de una orden grande están ocultos, nadie puede apuntar a ella para la extracción de valor. Solo después del emparejamiento y la ejecución podrían surgir los detalles, momento en el cual es demasiado tarde para explotar. En resumen, el mecanismo de Anoma se trata en gran medida de prevenir el MEV en lugar de extraerlo: al agrupar transacciones, encriptar el mempool y incorporar la alineación económica en el emparejamiento, intenta asegurar que haya pocas oportunidades para el arbitraje malicioso o el front-running. El MEV necesario (como el arbitraje para igualar precios entre mercados) es manejado por solvers o la lógica del protocolo de una manera con confianza minimizada. Se podría decir que Anoma apunta a la "minimización del MEV", esforzándose por obtener resultados como si cada usuario tuviera acceso a la contraparte perfecta al instante y sin fugas. Cualquier valor extraído para facilitar eso (la recompensa del solver) es similar a una pequeña comisión de servicio, no una ganancia inesperada por explotar la asimetría.

• Estructura de Incentivos Económicos: En Anoma, los solvers asumen el papel análogo tanto a los intermediarios como a los constructores de bloques. Incurren en costos (computación, quizás depositar colateral) para encontrar coincidencias de intenciones, y son recompensados cuando proponen con éxito transacciones que se incluyen. Los solvers pueden ganar de varias maneras: podrían cobrar una comisión o un diferencial dentro de la transacción que construyen (por ejemplo, dando a los usuarios términos ligeramente menos favorables y quedándose con la diferencia, similar a cómo un agregador de DEX podría tomar una pequeña parte). O bien, ciertas intenciones podrían incluir explícitamente una recompensa para el solver (como "estoy dispuesto a pagar hasta 0.01 ETH para que esto se haga"). El modelo de compensación exacto es flexible, pero la clave es que los solvers compiten. Si un solver intenta tomar una comisión demasiado alta, otro puede proponer una solución con un mejor resultado para el usuario y ganar la inclusión. Esta dinámica competitiva tiene como objetivo mantener los beneficios de los solvers bajo control y alineados con la provisión de valor. Validadores (Productores de Bloques): Los validadores de Anoma ejecutan el consenso que ordena y ejecuta las transacciones. Son incentivados por recompensas de bloque y comisiones, como en cualquier blockchain. Notablemente, si las intenciones se emparejan entre múltiples usuarios, la transacción resultante podría tener múltiples fuentes de comisiones (cada usuario podría contribuir con una comisión o una porción de los activos). Es posible que el modelo de comisiones de Anoma permita la división de comisiones, pero típicicamente los validadores obtendrán las comisiones de gas estándar por procesar transacciones. En fases futuras, Anoma planea un "consenso bajo demanda" y un token nativo. La idea es que muchas instancias de Anoma (o shards) podrían existir, y algunas podrían activarse temporalmente para tareas específicas ("consenso ad-hoc" para necesidades particulares de la aplicación). El token probablemente se usaría para hacer staking y asegurar estas instancias. Los incentivos aquí aseguran que la red tenga suficientes validadores para procesar todas las transacciones emparejadas de manera confiable y que se comporten honestamente en el proceso de descifrado de umbral (quizás con condiciones de slashing si intentan descifrar antes de tiempo o censurar). Usuarios: Los usuarios en Anoma potencialmente ahorran dinero y obtienen mejores resultados en lugar de pagar MEV implícitamente. Por ejemplo, podrían obtener consistentemente mejores precios de operación que en una cadena tradicional, lo que significa que el valor se queda con ellos. En algunos casos, los usuarios también podrían pagar comisiones explícitas para incentivar a los solvers, especialmente para intenciones complejas o cuando desean un emparejamiento más rápido. Pero como los usuarios pueden expresar intenciones sin especificar cómo hacerlo, delegan el trabajo pesado a los solvers y solo pagan si vale la pena. También existe la noción de que "los propietarios de intenciones pueden definir sus propios compromisos de seguridad/rendimiento": por ejemplo, un usuario podría decir "esperaré más tiempo por un mejor precio" o "pagaré más por una ejecución inmediata". Esta flexibilidad permite a los propios usuarios decidir cuánto ofrecer a los solvers o validadores, alineando los incentivos económicos con sus necesidades. Redistribución de MEV: Si ocurre algún MEV (como ARB entre cadenas), la arquitectura de Anoma podría permitir capturarlo en el sistema. Por ejemplo, múltiples shards o instancias de Anoma podrían coordinarse para liquidar un arbitraje atómico multicadena, y el beneficio podría ser compartido o quemado (dependiendo del diseño) en lugar de dejar que un arbitrajista externo se lo quede todo. En general, como Anoma da a las aplicaciones control sobre el flujo de transacciones, es posible implementar estrategias de MEV propiedad del protocolo (similar a la filosofía de Skip) a nivel de aplicación. Por ejemplo, una aplicación DeFi en Anoma podría enrutar automáticamente todas las operaciones de los usuarios a través de un solver dentro del protocolo que garantice la mejor ejecución y comparta cualquier beneficio adicional con los usuarios o los proveedores de liquidez. El efecto neto es que los extractores de MEV de terceros son desintermediados. Económicamente, esto es de suma positiva para los participantes honestos (usuarios, LPs, etc.), pero podría reducir las oportunidades para los searchers clásicos. Sin embargo, surgirán nuevos roles como solvers especializados (quizás uno se centre en el emparejamiento de NFT, otro en swaps de divisas, etc.). Estos solvers son análogos a los searchers de MEV de hoy, pero operan dentro de las reglas del sistema y probablemente tengan márgenes de beneficio menos descabellados debido a la competencia y las restricciones del protocolo. Por último, la visión de la Fundación Anoma sugiere que Anoma será una infraestructura de bien público. Habrá un token nativo, presumiblemente ANOMA, que podría capturar valor a través de comisiones o ser requerido para el staking. Se pueden prever incentivos de token (recompensas inflacionarias, etc.) para validadores y quizás incluso para solvers para impulsar la actividad. En el momento de escribir esto, los detalles sobre la economía del token no son finales, pero la hoja de ruta confirma que un token Anoma y un consenso nativo bajo demanda están planeados en fases futuras. Para resumir, el modelo de incentivos de Anoma fomenta el comportamiento cooperativo: los solvers ganan ayudando a los usuarios a obtener lo que quieren, no explotándolos; los validadores ganan asegurando la red y ordenando de manera justa; y los usuarios "pagan" principalmente cediendo algo de MEV a los solvers o comisiones, pero idealmente mucho menos que el MEV implícito que perderían en otros sistemas.

• Cumplimiento y Neutralidad: Anoma, al ser un marco, no una red única, puede ser instanciado de varias maneras; algunas podrían ser permisionadas, pero la L1 de Anoma y otras instancias similares están destinadas a ser sin permisos y con privacidad mejorada. Al incorporar fuertes características de privacidad (como intenciones protegidas usando pruebas de conocimiento cero en Taiga), Anoma se alinea con la visión de que la privacidad financiera es un derecho. Esto podría ponerlo en conflicto con ciertos regímenes regulatorios que exigen una visibilidad abierta de las transacciones. Sin embargo, el diseño de Anoma también podría evitar ciertos escollos regulatorios. Por ejemplo, si se eliminan el front-running y la selección injusta de órdenes, se mitigan las preocupaciones sobre la manipulación del mercado; un regulador podría apreciar que los usuarios no están siendo explotados sistemáticamente por insiders. Además, el concepto de "modelos de seguridad definidos por el usuario" implica que los usuarios o las comunidades podrían optar por diferentes supuestos de confianza. Potencialmente, una aplicación regulada podría construirse sobre Anoma donde, por ejemplo, el solver o un subconjunto de validadores sean entidades con KYC que garanticen el cumplimiento para ese dominio de intención particular. Anoma como capa base no impondría KYC a todos, pero se podrían implementar predicados de validez que requieran (por ejemplo) una prueba de elegibilidad para ciertas transacciones (como una prueba de no ser una dirección sancionada, o una verificación de credenciales) si una aplicación lo necesitara. La arquitectura es lo suficientemente flexible como para soportar el cumplimiento a nivel de aplicación sin comprometer la neutralidad de la capa base. En cuanto a la censura: el cifrado de umbral de Anoma significa que incluso si los validadores quisieran censurar, no pueden apuntar a intenciones específicas porque no las ven en texto plano. Lo único que podrían hacer es negarse a incluir transacciones encriptadas de ciertos solvers o usuarios, pero eso sería obvio (y en contra de las reglas del protocolo si se hace arbitrariamente). La expectativa es que las reglas de consenso desalienten la censura; por ejemplo, quizás si un bloque no incluye todas las intenciones desencriptadas disponibles del último lote, podría considerarse inválido o menos preferible. En cualquier caso, la descentralización de los validadores y la naturaleza encriptada de las cargas útiles aseguran un alto grado de resistencia a la censura. Sobre la neutralidad: Anoma aspira a ser una plataforma general no controlada por ninguna entidad única. La investigación y el desarrollo están liderados por Heliax (el equipo detrás de Anoma y Namada), pero una vez en vivo, una red Anoma sería gestionada por la comunidad. Es probable que haya una gobernanza en cadena para las actualizaciones, etc., lo que podría plantear cuestiones de cumplimiento (por ejemplo, ¿podría un gobierno subvertir la gobernanza para cambiar las reglas?), pero ese es un problema general de las blockchains. Una característica interesante relacionada con el cumplimiento es que Anoma admite múltiples instancias paralelas, lo que significa que se podría tener un pool de intenciones o shard aislado para ciertos tipos de activos o jurisdicciones. Esto no es explícitamente para la regulación, pero podría permitir, por ejemplo, un pool de intenciones de CBDC donde solo los bancos autorizados ejecuten solvers, coexistiendo con un pool DeFi libre. La modularidad de la arquitectura proporciona flexibilidad para segregar si es necesario, al tiempo que permite la interoperabilidad a través de puentes de intenciones. Finalmente, en términos de compatibilidad legal, todo el concepto de intenciones de Anoma podría evitar algunas clasificaciones que acosan a las criptomonedas tradicionales: dado que una intención no es una transacción vinculante hasta que se empareja, se podría argumentar que los usuarios mantienen más control (es como publicar una orden en un exchange, que tiene un precedente legal más claro, en lugar de ejecutar directamente una operación). Esto podría ayudar con cosas como el tratamiento fiscal (el sistema podría potencialmente dar un recibo unificado de una operación de varios pasos en lugar de muchas transacciones), aunque esto es especulativo. En general, Anoma prioriza la descentralización, la privacidad y la autonomía del usuario, lo que históricamente puede chocar con las expectativas regulatorias, pero las ganancias en equidad y transparencia podrían ganar favor. Esencialmente, trae la sofisticación de los motores de emparejamiento financiero tradicionales a la cadena, pero sin operadores centralizados. Si los reguladores llegan a entender ese modelo, podrían verlo como una estructura de mercado más ordenada y justa que el caos de los mempools.

• Arquitectura Técnica (Consenso y Criptografía): La arquitectura de Anoma es compleja y comprende varios componentes: Typhon (red, mempool, consenso, ejecución) y Taiga (la capa de privacidad de conocimiento cero). El núcleo de Typhon es la capa de gossip de intenciones y un enfoque novedoso para el consenso + emparejamiento combinados. El protocolo de consenso de Anoma extiende el consenso BFT típico con el concepto de "Predicados de Validez" y "Prueba de Emparejamiento de Órdenes". Esencialmente, cada aplicación en Anoma puede definir un predicado de validez que debe satisfacerse para las transacciones (piense en ello como condiciones de contrato inteligente que se aplican a nivel de bloque, no solo a nivel de transacción). Esto permite imponer propiedades como los precios de compensación de subastas por lotes, etc., como se describió. El algoritmo de consenso en sí mismo probablemente se basa en BFT al estilo de Tendermint o HotStuff (ya que Anoma está en el ámbito de Cosmos y admite IBC). De hecho, la testnet inicial de Anoma (Feigenbaum en 2021) y Namada usan un consenso al estilo de Tendermint con modificaciones. Una modificación importante es la integración del cifrado de umbral (Ferveo) en el pipeline del mempool. Típicamente, Tendermint selecciona un proponente que ordena las transacciones. En Anoma, el proponente ordenaría intenciones/transacciones encriptadas. Ferveo probablemente funciona haciendo que los validadores acuerden periódicamente una clave pública de umbral, y cada intención enviada por los solvers se encripta con esa clave. Durante la propuesta de bloque, se incluyen todas las transacciones encriptadas; después de la propuesta, los validadores ejecutan un protocolo para desencriptarlas (quizás el siguiente bloque contiene las salidas desencriptadas o algún esquema similar). Esto añade una fase al consenso pero asegura la equidad en el orden. Criptográficamente, esto utiliza la generación de claves distribuidas y el descifrado de umbral (por lo que se basa en supuestos como que al menos 2/3 de los validadores son honestos para no filtrar o descifrar datos antes de tiempo). En el lado de la privacidad, Taiga proporciona pruebas zkSNARK o zk-STARK que permiten que las intenciones permanezcan parcial o totalmente protegidas. Por ejemplo, un usuario podría enviar una intención de intercambio sin revelar el tipo de activo o la cantidad; proporciona una prueba ZK de que tiene saldo suficiente y que la transacción será válida si se empareja, sin revelar detalles específicos. Esto es análogo a cómo funcionan las transacciones protegidas en Zcash, pero extendido a las intenciones. Se menciona el uso de pruebas recursivas, lo que significa que múltiples pasos de una transacción (o múltiples intenciones) pueden probarse en una sola prueba sucinta para mayor eficiencia. La interacción de Taiga y Typhon significa que algunos solvers y validadores podrían estar operando con texto cifrado o compromisos en lugar de valores en texto plano. Por ejemplo, un solver podría emparejar intenciones que se expresan de manera confidencial, resolviendo una ecuación de compromisos. Esto es criptografía de vanguardia y va más allá de lo que hacen la mayoría de las blockchains actuales. Otra pieza clave es la integración de IBC: las instancias de Anoma pueden comunicarse con otras cadenas (especialmente las cadenas de Cosmos) a través del protocolo de Comunicación Inter-Blockchain. Esto significa que una intención en Anoma podría potencialmente desencadenar una acción en otra cadena (a través de un mensaje IBC) o consumir datos del estado de otra cadena. La Fase 1 de la Mainnet en la hoja de ruta de Anoma menciona específicamente un "adaptador" en Ethereum y rollups para permitir que las intenciones de Anoma aprovechen la liquidez de EVM. Probablemente, un solver de Anoma podría componer una transacción que, por ejemplo, use Uniswap en Ethereum, creando una intención que, al ser emparejada, envíe un mensaje a Ethereum para ejecutar un intercambio (quizás a través de un relayer o algo como un puente IBC). El consenso debe garantizar la atomicidad: presumiblemente, la salida de Anoma podría ser como una única transacción que abarca múltiples cadenas (algo como iniciar una transacción en la cadena A y esperar un resultado en la cadena B). Lograr una liquidación atómica entre cadenas es difícil; posiblemente Anoma comenzará liquidando en una cadena a la vez (la Fase 1 se centra en el ecosistema de Ethereum, lo que probablemente significa que las intenciones de Anoma se liquidarán en la L1 o L2 de Ethereum de una sola vez). Más tarde, las "cadenas Quimera" y el consenso bajo demanda podrían permitir que sidechains personalizadas se activen para manejar emparejamientos particulares entre cadenas. En cuanto al rendimiento, el enfoque de Anoma podría ser más intensivo computacionalmente (solvers resolviendo problemas de emparejamiento NP-difíciles, validadores haciendo criptografía pesada). Pero la compensación es una experiencia de usuario enormemente mejorada (sin transacciones fallidas, mejores precios, etc.). El desarrollo de Anoma requiere construir estos componentes novedosos casi desde cero: Heliax ha estado creando Juvix, un nuevo lenguaje para escribir predicados de validez e intenciones, y mucha investigación (algunas referencias del sitio de Anoma hablan de estos conceptos en detalle). Hitos principales: La primera testnet pública de Anoma, Feigenbaum, se lanzó en noviembre de 2021 como una demostración del gossip básico de intenciones. Posteriormente, Heliax cambió su enfoque al lanzamiento de Namada (una L1 centrada en la privacidad que puede verse como una instancia de Anoma centrada en las transferencias de activos); Namada se lanzó en 2023 e incluye características como transferencias protegidas y cifrado de umbral Ferveo para su mempool. Esto muestra la tecnología en acción en un caso de uso más limitado. Mientras tanto, las testnets de la visión completa de Anoma se han estado implementando por etapas ("testnet de verano de 2023" mencionada en la comunidad también). La hoja de ruta indica que la mainnet de la Fase 1 integrará Ethereum, la Fase 2 añadirá más cadenas y criptografía avanzada, y eventualmente llegarán el consenso nativo y el token. La separación de "consenso y token en una fase futura" sugiere que la mainnet inicial de Anoma podría depender de Ethereum (por ejemplo, aprovechando la seguridad de Ethereum o los tokens existentes en lugar de tener uno propio desde el primer día). Posiblemente lancen una L2 o una sidechain que publique en Ethereum. Y más tarde activen su propia red PoS con un token. Este enfoque por fases es interesante: podría ser para reducir la barrera de adopción (usar el capital existente en Ethereum en lugar de lanzar una nueva moneda inicialmente). En conclusión, la arquitectura de Anoma es novedosa y completa: combina la equidad criptográfica (cifrado de umbral, pruebas ZK) con un nuevo paradigma de transacciones (emparejamiento basado en intenciones) y capacidades entre cadenas. Es posiblemente el intento más agresivo de erradicar el MEV tradicional a nivel de protocolo, haciendo lo que ninguna cadena heredada hace: motores de emparejamiento justo incorporados. La complejidad es alta, pero si tiene éxito, una cadena Anoma podría proporcionar a los usuarios garantías de ejecución casi similares a las de un CEX en un entorno descentralizado, lo cual es un santo grial en la UX y la equidad de la blockchain.

Skip Protocol (Control Soberano de MEV y Conjunto de Herramientas de Ordenación Justa en Cosmos)​

Skip Protocol es una solución líder de MEV en el ecosistema de Cosmos, enfocada en dar a cada blockchain ("app-chain") las herramientas para gestionar la ordenación de transacciones y la captura de MEV en sus propios términos. A diferencia de Flashbots o Anoma, que proponen sistemas que abarcan toda la red, Skip se alinea con la filosofía de soberanía de Cosmos: cada cadena puede integrar los módulos de Skip para aplicar reglas de ordenación justa personalizadas, ejecutar subastas de espacio de bloque dentro del protocolo y capturar MEV para los stakeholders o usuarios de la cadena. Skip puede considerarse como un conjunto de módulos del SDK de Cosmos e infraestructura que juntos permiten la Construcción de Bloques Propiedad del Protocolo (POB) y una secuenciación de transacciones flexible. Ha sido adoptado en cadenas como Osmosis, Juno, Terra y otras en Cosmos, y también está colaborando con proyectos como la próxima cadena de dYdX para la mitigación de MEV. Los elementos clave incluyen un mecanismo de subasta en cadena para transacciones prioritarias, lógica de ordenación de transacciones a nivel de consenso y mecanismos dentro de la aplicación para reciclar el MEV ("buen MEV") en beneficio del protocolo.

• Algoritmos de Encolado y Ordenación de Transacciones: En una cadena típica de Cosmos (usando consenso Tendermint/BFT), el mempool ordena las transacciones aproximadamente por comisión y hora de llegada, y el proponente del bloque puede elegir cualquier ordenación al crear un bloque (sin restricciones algorítmicas más allá de incluir transacciones válidas). Skip cambia esto introduciendo reglas de ordenación impuestas por consenso y mempools de múltiples carriles. Usando la nueva interfaz ABCI++ de Cosmos (que permite personalizar la propuesta y el procesamiento de bloques), el módulo Protocol-Owned Builder (POB) de Skip puede particionar el bloque en carriles distintos con diferentes políticas de ordenación. Por ejemplo, un carril podría ser un carril de subasta de la parte superior del bloque donde las transacciones con la oferta más alta (quizás de bots de arbitraje o operaciones urgentes) se colocan primero en el bloque en un orden fijo, otro carril podría ser un carril gratuito para transacciones de usuarios ordinarios sin comisiones, y un carril predeterminado para transacciones normales con comisiones. El componente BlockBuster del módulo de Skip permite a los desarrolladores definir estos carriles y su lógica de ordenación de manera modular. Crucialmente, estas reglas son impuestas por todos los validadores: cuando un proponente construye un bloque, los otros validadores verificarán que las transacciones del bloque se adhieran a las reglas de ordenación acordadas (a través de las comprobaciones de ProcessProposal ABCI). Si no es así, pueden rechazar el bloque. Esto significa que incluso un proponente malicioso o que busca beneficios no puede desviarse (por ejemplo, no puede colar su propia transacción de front-running antes de un postor ganador de la subasta, porque eso violaría la regla de ordenación). Algunos ejemplos de reglas de ordenación que Skip permite: (a) Ordenar transacciones por precio de gas descendente (comisión), asegurando que la transacción con la comisión más alta siempre tenga prioridad. Esto formaliza un esquema justo de "pago por prioridad" en lugar de uno aleatorio o basado en el tiempo. (b) Debe incluir al menos una transacción de actualización de precios de oráculo antes de cualquier operación, asegurando que las fuentes de datos se actualicen, lo que evita escenarios en los que un proponente podría ignorar las actualizaciones de oráculos para explotar precios obsoletos. (c) Limitar el número de transacciones especiales en la parte superior del bloque, por ejemplo, solo un bundle ganador de la subasta puede ocupar la parte superior, para evitar el spam de muchas pequeñas capturas de MEV. (d) Ninguna transacción que viole una propiedad del estado: Skip permite reglas de ordenación con estado, como "después de construir el bloque, asegurar que ninguna operación DEX se ejecutó a un precio peor que si estuviera al final del bloque" (una forma de asegurar que no ocurrió un ataque sándwich). Una regla concreta descrita es una "condición de cero front-running en todos los DEXs", lo que podría significar que si alguna transacción se hubiera visto afectada por otras posteriores de una manera que indique front-running, el bloque es inválido. Esto es poderoso: es esencialmente hacer que la equidad sea parte de la validez del bloque. Las cadenas de Cosmos pueden implementar tales reglas porque controlan su pila completa. El marco de Skip proporciona una forma estructurada de hacerlo a través del AuctionDecorator en el SDK, que puede verificar cada transacción contra las reglas configuradas. Además, Skip proporciona mejoras en el mempool: el mempool del nodo puede simular bloques con antelación, filtrar transacciones fallidas, etc., para ayudar a los proponentes a seguir las reglas de manera eficiente. Por ejemplo, si el carril de subasta de un bloque debe tener las ofertas más altas, el mempool puede ordenarse por ofertas para ese carril. Si un bloque debe incluir solo transacciones que resulten en una cierta condición de estado, el nodo del proponente puede simular las transacciones a medida que las elige para asegurar que la condición se cumpla. En resumen, Skip permite una ordenación determinista y definida por la cadena en lugar de dejarla completamente al capricho del proponente o a la simple prioridad del precio del gas. Las cadenas adoptan el módulo de constructor de Skip para efectivamente codificar su política de ordenación de transacciones en el protocolo. Esto fomenta la equidad porque todos los validadores imponen las mismas reglas, eliminando la oportunidad de que un solo proponente realice una reordenación arbitraria para MEV a menos que esté dentro del mecanismo permitido (como la subasta, donde es transparente y competitivo). El encolado de transacciones en el modelo de Skip podría implicar colas separadas por carril. Por ejemplo, un carril de subasta podría encolar transacciones de oferta especiales (Skip usa un tipo especial MsgAuctionBid para pujar por la inclusión en la parte superior del bloque). Esas ofertas se recopilan en cada bloque y se selecciona la más alta. Mientras tanto, las transacciones normales se encolan en el mempool predeterminado. Esencialmente, Skip introduce una cola estructurada: una para ofertas prioritarias, otra para gratuitas u otras, etc., cada una con sus propios criterios de ordenación. Este enfoque modular significa que cada cadena puede personalizar cómo equilibra la equidad y los ingresos; por ejemplo, Osmosis podría decir "no queremos ninguna subasta de MEV, pero imponemos la equidad en el orden a través del cifrado de umbral" (implementaron el cifrado de umbral con la ayuda de Skip y otros), mientras que otra cadena podría decir "permitimos subastas para MEV pero requerimos que parte de las ganancias se quemen". Skip admite ambos. Esta configurabilidad de la ordenación es el sello distintivo de Skip.

• Mecanismos de Mitigación y Extracción de MEV: El enfoque de Skip hacia el MEV a menudo se describe como "MEV propiedad del protocolo" y "multiplicidad". El MEV propiedad del protocolo significa que el propio protocolo de la blockchain, a través de su código y gobernanza, captura o redistribuye el MEV en lugar de dejarlo en manos de validadores individuales o externos. La multiplicidad se refiere a asegurar que se incluyan las transacciones "correctas" (múltiples), esencialmente no excluyendo transacciones legítimas de usuarios en favor de solo transacciones de MEV, y quizás incluyendo múltiples oportunidades de MEV en un bloque si es posible (para que ningún searcher monopolice). Concretamente, Skip proporciona herramientas para capturar MEV de maneras que benefician a la red: una es Skip Select, un sistema de subasta de espacio de bloque para la inclusión en la parte superior del bloque. En Skip Select, los searchers (como los bots de arbitraje) envían bundles con propinas a los validadores, de forma similar a los bundles de Flashbots, excepto que se hace de forma nativa en la cadena a través de los módulos de Skip. El bundle (o bundles) que más paga se inserta automáticamente en la parte superior del bloque en el orden especificado. Esto garantiza que esas transacciones se ejecuten como se pretende, y el validador (o la cadena) cobra la propina. Este mecanismo toma lo que era un proceso OTC fuera de la cadena (en Ethereum) y lo convierte en una subasta abierta y en la cadena, mejorando la transparencia y el acceso. Otro mecanismo es ProtoRev (Módulo de Ingresos Prototipo), que Skip desarrolló para Osmosis. ProtoRev es un módulo de arbitraje en la cadena que detecta y ejecuta automáticamente arbitrajes cíclicos (como los que involucran múltiples pools) dentro de la ejecución del bloque y acumula el beneficio en la tesorería de la cadena o en el pool comunitario. Esencialmente, Osmosis decidió que cierto "buen MEV" (como el arbitraje que mantiene los precios alineados) debería seguir ocurriendo (por eficiencia del mercado) pero el propio protocolo realiza el arbitraje y captura el beneficio, para luego distribuirlo (por ejemplo, a los stakers o como incentivos de minería de liquidez). Esto elimina la necesidad de bots de arbitraje externos en esas oportunidades y asegura que el valor permanezca en el ecosistema. ProtoRev fue el primero de su tipo en una cadena importante y demuestra cómo la integración profunda puede mitigar las externalidades del MEV: los usuarios que operan en Osmosis enfrentan menos slippage porque si existe un arbitraje después de su operación, el protocolo lo cerrará y esencialmente reembolsará el valor a Osmosis (lo que podría beneficiar indirectamente a los usuarios a través de comisiones más bajas o recompras de tokens, etc.). Además, Skip capacita a las cadenas para implementar medidas anti-MEV como el cifrado de umbral para el mempool. Por ejemplo, Osmosis, en colaboración con Skip y otros, está implementando la encriptación del mempool donde las transacciones se envían encriptadas y solo se revelan después de un tiempo fijo (similar a la idea de Anoma, pero a nivel de cadena). Aunque no es un producto de Skip per se, la arquitectura de Skip es compatible: la subasta de Skip puede ejecutarse en transacciones encriptadas basando la subasta en las ofertas declaradas en lugar de leer el contenido de la transacción. En términos de suprimir el MEV perjudicial: las reglas de consenso de Skip como "no se permite el front-running" (impuestas por verificaciones de estado) son una medida directa para detener el comportamiento malicioso. Si un validador intenta incluir un ataque sándwich, otros validadores detectarían que el resultado del estado viola la regla de no front-running (por ejemplo, podrían verificar que ninguna operación fue inmediatamente precedida y seguida por otra de la misma dirección de una manera que se aprovechó). Ese bloque sería rechazado. Sabiendo esto, los validadores ni siquiera intentarán incluir tales patrones, por lo que los usuarios están protegidos por la ley del protocolo. Skip también fomenta la quema o redistribución de los ingresos de MEV para evitar incentivos perversos. Por ejemplo, una cadena podría optar por quemar todas las ganancias de la subasta o ponerlas en un fondo comunitario en lugar de dárselas todas al proponente del bloque. Esto reduce el incentivo para que los validadores reordenen las transacciones ellos mismos, ya que podrían no beneficiarse personalmente de ello (dependiendo de la elección de la cadena). En resumen, el conjunto de herramientas de Skip permite a cada cadena extraer quirúrgicamente el MEV donde es beneficioso (por ejemplo, arbitraje para mantener la eficiencia del mercado, liquidaciones para mantener saludables los mercados de préstamos) y asegurar que ese valor sea capturado por el protocolo o los usuarios, mientras prohíbe y previene estrictamente el MEV malicioso (como el front-running perjudicial para el usuario). Es una mezcla pragmática de extracción y supresión, adaptada por la gobernanza: en lugar de una solución única para todos, Skip capacita a las comunidades para decidir qué MEV es "bueno" (y automatizar su captura) y cuál es "malo" (y prohibirlo a través de reglas de consenso). El resultado es un entorno de trading más justo en las cadenas habilitadas por Skip y una fuente de ingresos adicional que puede financiar bienes públicos o reducir costos (una de las publicaciones del blog de Skip señala que la captura justa de MEV puede usarse para "distribuir ingresos de manera justa entre todos los participantes de la red").

• Estructura de Incentivos Económicos: La introducción de Skip cambia fundamentalmente los incentivos, especialmente para los validadores y las comunidades de la cadena en Cosmos. Tradicionalmente, un validador en Cosmos podría extraer MEV reordenando privadamente las transacciones en su bloque (ya que Cosmos carece de una subasta de MEV por defecto). Con Skip, los validadores acuerdan un protocolo donde el MEV se captura a través de subastas o módulos y a menudo se comparte. Los validadores todavía se benefician: pueden recibir una parte de las ganancias de la subasta o comisiones adicionales de los mecanismos de Skip, pero es importante destacar que todos los validadores (no solo el proponente) pueden beneficiarse si se diseña de esa manera. Por ejemplo, algunas subastas de Skip pueden configurarse para que los ingresos se dividan entre todos los stakers o según las decisiones de la gobernanza, en lugar de que el proponente se lo lleve todo. Esto alinea a los validadores colectivamente para ejecutar el software de Skip porque incluso los no proponentes obtienen seguridad (sabiendo que si alguien intenta un bloque inválido, no valdrá la pena) y posiblemente ingresos. Algunas cadenas aún podrían dar al proponente la mayor parte de la comisión de la subasta de MEV (para maximizar el incentivo inmediato de incluirla), pero incluso entonces es transparente y competitivo, lo que podría decirse que reduce la posibilidad de acuerdos bajo la mesa. Cadena/Comunidad: El concepto de MEV propiedad del protocolo significa que la blockchain y sus stakeholders capturan el MEV. Por ejemplo, Osmosis dirige las ganancias de ProtoRev a su pool comunitario, convirtiendo efectivamente el MEV en un ingreso adicional del protocolo que podría financiar el desarrollo o distribuirse a los stakers de OSMO. Esto convierte a la comunidad en general en "propietaria" de ese MEV, alineando el interés de todos en extraer MEV de manera saludable. Si los usuarios saben que el MEV se destina a mejorar la cadena o la tokenómica, podrían aceptarlo más que si va a un bot aleatorio. Searchers: En el modelo de Skip, los searchers/bots independientes pueden tener menos que hacer en la cadena porque algunas oportunidades son tomadas por la lógica del protocolo (como ProtoRev) y otras se canalizan a través de subastas. Sin embargo, Skip no elimina a los searchers, sino que los canaliza para que pujen a través de las rutas adecuadas. Un searcher todavía puede intentar una estrategia compleja, pero para garantizar la inclusión en un lugar particular, debe participar en la subasta de Skip (Skip Select) enviando su bundle con una oferta. Si no lo hacen, corren el riesgo de que un validador los ignore en favor de alguien que sí pujó o que el propio mecanismo de la cadena aproveche la oportunidad. Así que los searchers en Cosmos están evolucionando para trabajar con Skip: por ejemplo, muchos arbitrajistas en Osmosis ahora envían sus arbitrajes a través del sistema de Skip. Pagan una parte a la cadena, quedándose con menos beneficio, pero es el precio a pagar. Con el tiempo, algunos roles de "searcher" podrían ser completamente absorbidos (como el arbitraje de back-running: ProtoRev lo maneja, por lo que ningún searcher externo puede competir). Esto podría reducir el spam y el esfuerzo desperdiciado en la red (no más múltiples bots compitiendo; solo una ejecución del protocolo). Usuarios: Los usuarios finales salen ganando porque tienen un entorno más justo (sin ataques de MEV sorpresa). Además, algunas configuraciones de Skip recompensan explícitamente a los usuarios: la redistribución de MEV a los usuarios es posible. Por ejemplo, una cadena podría decidir reembolsar parte de los ingresos de la subasta de MEV a los usuarios cuyas operaciones crearon ese MEV (similar a la idea de reembolso de Flashbots). Astroport, un DEX en Terra, integró Skip para compartir los ingresos de MEV con los swappers, lo que significa que si la operación de un usuario tenía MEV, parte de ese valor se le devuelve por defecto. Esto se alinea con la ética de que el MEV debe ir a los usuarios. Aunque no todas las cadenas hacen esto, la opción existe a través de la infraestructura de Skip para implementar tales esquemas. El propio Skip Protocol (la empresa/equipo) tiene un modelo de negocio en el que proporcionan estas herramientas a menudo de forma gratuita a los validadores (para fomentar la adopción), y monetizan asociándose con cadenas (B2B). Por ejemplo, Skip podría tomar una pequeña comisión del MEV capturado o cobrar a las cadenas por características avanzadas/soporte. Se menciona que Skip es gratuito para los validadores pero utiliza un modelo B2B con las cadenas. Esto significa que Skip tiene un incentivo para maximizar el MEV capturado por la cadena y la comunidad (para que la cadena esté contenta y quizás comparta una parte según el acuerdo). Pero como la gobernanza está involucrada, cualquier comisión que Skip tome suele ser acordada por la comunidad. El efecto económico es interesante: profesionaliza la extracción de MEV como un servicio proporcionado a las cadenas. Al hacerlo, desincentiva el comportamiento deshonesto: los validadores no necesitan hacer tratos turbios individualmente, pueden simplemente usar Skip y obtener un flujo fiable de ingresos adicionales que es socialmente aceptado. El comportamiento honesto (seguir las reglas del protocolo) rinde casi tanto o más beneficio que intentar hacer trampa, porque si haces trampa, tu bloque podría ser inválido o podrías ser sancionado socialmente, etc. La gobernanza juega un papel significativo: adoptar el módulo de Skip o establecer los parámetros (como el porcentaje de la subasta, la distribución de las ganancias) se hace a través de propuestas en la cadena. Esto significa que los resultados económicos (quién obtiene el MEV) son determinados en última instancia por el voto de la comunidad. Por ejemplo, el Cosmos Hub está debatiendo la adopción del SDK de constructor de Skip para posiblemente redirigir el MEV a la tesorería o a los stakers del Hub. Esta alineación a través de la gobernanza asegura que el uso del MEV sea visto como legítimo por la comunidad. Convierte el MEV de un subproducto tóxico en un recurso público que puede ser asignado (a la seguridad, usuarios, desarrolladores, etc.). En resumen, Skip remodela los incentivos de tal manera que los validadores colectivamente y los usuarios/comunidad se benefician, mientras que los tomadores de MEV oportunistas son cooptados en el sistema (como postores) o eliminados por diseño. En teoría, todos están mejor: los usuarios pierden menos valor por el MEV, los validadores siguen siendo compensados (incluso posiblemente más en total, debido a las subastas), y la red en su conjunto puede usar el MEV para fortalecerse (financieramente o a través de una experiencia más justa). Los únicos perdedores son aquellos que prosperaron con la extracción de suma cero sin devolver valor.

• Compatibilidad con Cumplimiento y Regulaciones: El marco de Skip, al empoderar la gobernanza de la cadena, en realidad facilita que las cadenas aseguren el cumplimiento o políticas específicas si lo desean. Debido a que Skip opera a nivel de protocolo, una cadena podría optar por imponer ciertas reglas de filtrado u ordenación de transacciones para cumplir con las regulaciones. Por ejemplo, si una cadena quisiera bloquear direcciones sancionadas, podría integrar una regla AnteHandler o AuctionDecorator en el módulo de Skip que invalide los bloques que contengan direcciones en la lista negra. Esto es posiblemente más simple que en Ethereum, donde la censura es una elección fuera de la cadena por parte de validadores individuales; en Cosmos con Skip, podría ser una regla para toda la cadena (aunque sería controvertido y va en contra de los ideales de descentralización para muchos). Alternativamente, una cadena podría imponer algo como "las transacciones de rampa de entrada de FIAT deben aparecer antes que otras" si así lo exige alguna ley. El conjunto de herramientas de Skip no viene con reglas de cumplimiento preestablecidas, pero es lo suficientemente flexible como para implementarlas si una comunidad se ve obligada a hacerlo (a través de la gobernanza). Por otro lado, Skip puede reforzar la resistencia a la censura: al distribuir los ingresos de MEV y dar acceso igualitario, reduce la ventaja de cualquier validador único que podría censurar para obtener beneficios. Además, si los mempools con cifrado de umbral (como el que Osmosis está añadiendo) se vuelven estándar con Skip, eso ocultará el contenido de las transacciones, dificultando la censura (como en Anoma). Skip es una infraestructura neutral: puede usarse para cumplir o resistir, dependiendo de la gobernanza. Dado que las cadenas de Cosmos a menudo son específicas de una jurisdicción (la comunidad de Terra podría preocuparse por las leyes coreanas, Kava podría preocuparse por las leyes de EE. UU., etc.), tener la opción de configurar el cumplimiento es valioso. Por ejemplo, una cadena de Cosmos permisionada (como una cadena institucional) aún podría usar el módulo de constructor de Skip, pero quizás requerir que solo las direcciones en la lista blanca puedan pujar en las subastas, etc., alineándose con sus regulaciones. La compatibilidad regulatoria también se trata de transparencia: las subastas en cadena de Skip producen un registro público de las transacciones de MEV y quién pagó qué. Esto podría satisfacer algunas preocupaciones regulatorias sobre la equidad (todos tuvieron la oportunidad de pujar, y es auditable). Es más transparente que los pagos bajo la mesa a los validadores. Además, al capturar el MEV en la cadena, Skip reduce la probabilidad de cárteles fuera de la cadena o dark pools, que los reguladores temen debido a la opacidad. Por ejemplo, sin Skip, los validadores podrían hacer tratos privados con los searchers (como se vio con los problemas de censura de los relays). Con Skip, la expectativa es que uses la subasta oficial, que es abierta y registrada, para obtener prioridad. Esto fomenta un mercado abierto accesible a todos los bots por igual, lo que es posiblemente más justo y menos propenso a la colusión (la colusión es posible, pero existe la supervisión de la gobernanza). Otro ángulo de cumplimiento: dado que Skip se ocupa de la captura de valor, si los ingresos de MEV van a un pool comunitario o tesorería, eso podría plantear preguntas (¿es una comisión, es imponible, etc.?). Pero son similares a cómo se manejan las comisiones de transacción, por lo que no hay nada fundamentalmente nuevo legalmente. En Cosmos, las comunidades de la cadena también pueden decidir cómo usar ese fondo (quemar, distribuir, etc.), lo que pueden alinear con cualquier guía legal si es necesario (por ejemplo, podrían evitar enviarlo a una fundación si eso desencadena problemas fiscales y en su lugar quemarlo). En términos de resistencia a la censura, una nota interesante: al imponer reglas de validez de bloque, Skip evita que los validadores censuren ciertas transacciones si eso rompiera las reglas. Por ejemplo, si una cadena tuviera una regla "debe incluir al menos una actualización de oráculo", un validador censor no podría simplemente omitir todas las transacciones de oráculo (que podrían provenir de ciertas fuentes) porque su bloque sería inválido. Así que, irónicamente, las reglas de Skip pueden forzar la inclusión de transacciones críticas (anti-censura) de la misma manera que podrían usarse para forzar la exclusión de las no permitidas. Todo depende de lo que establezca la comunidad. Neutralidad: La postura predeterminada de Skip es empoderar a las cadenas para "proteger a los usuarios del MEV negativo y mejorar la experiencia del usuario", lo que implica neutralidad y amigabilidad con el usuario. No hay una red central de Skip tomando decisiones; cada cadena es soberana. Skip como empresa podría asesorar o proporcionar valores predeterminados (como un formato de subasta recomendado), pero en última instancia, los poseedores de tokens de la cadena deciden. Esta descentralización de la política de MEV a la gobernanza de cada cadena puede verse como más compatible con la diversidad regulatoria: por ejemplo, una cadena con sede en EE. UU. podría implementar el cumplimiento de la OFAC si se ve presionada legalmente, sin afectar a otras cadenas. No es un solo relay censurando a través de muchas cadenas; es una elección por cadena. Desde la perspectiva de un regulador, Skip no introduce ninguna actividad ilícita adicional, simplemente reorganiza cómo se ordenan las transacciones. En todo caso, podría reducir la volatilidad (menos guerras de gas) y crear una ejecución más predecible, lo que podría ser una ventaja. En resumen, la arquitectura de Skip es altamente adaptable a las necesidades de cumplimiento mientras preserva la opción de una máxima resistencia a la censura si las comunidades priorizan eso. Mantiene el MEV a la luz del día y bajo control colectivo, lo que probablemente hace que los ecosistemas de blockchain sean más robustos contra actores maliciosos y represiones regulatorias, ya que la autogobernanza puede abordar proactivamente los peores abusos.

• Arquitectura Técnica e Implementación: Skip Protocol está estrechamente integrado en la pila del SDK de Cosmos. La entrega principal es un conjunto de módulos (por ejemplo, x/builder) y modificaciones como la implementación del mempool BlockBuster. Las cadenas de Cosmos ejecutan un consenso (Tendermint/CometBFT) que ofrece ganchos ABCI para preparar y procesar propuestas. Skip aprovecha las extensiones ABCI++ que permiten ejecutar código entre la propuesta de bloque y la finalización. Así es como impone la ordenación: PrepareProposal puede reordenar las transacciones del bloque según las reglas de los carriles antes de transmitir la propuesta, y ProcessProposal en los validadores receptores puede verificar que la ordenación y la validez del estado coincidan con las expectativas. Esta es una característica moderna (SDK de Cosmos v0.47+), y el POB de Skip es compatible con las versiones recientes del SDK. Internamente, los módulos de Skip mantienen estructuras de datos para las subastas (por ejemplo, un libro de órdenes en cadena de ofertas para la parte superior del bloque). También es probable que usen tipos de transacciones prioritarias. El README muestra un MsgAuctionBid especial y lógica personalizada para manejarlo. Así que los searchers interactúan enviando estos mensajes a través de transacciones normales de Cosmos, que luego el módulo intercepta y coloca en consecuencia. El AnteHandler del módulo de constructor (el AuctionDecorator) puede consumir ofertas de subasta y decidir los ganadores en la fase de ensamblaje del bloque. Criptográficamente, Skip no añade inherentemente nuevos requisitos criptográficos (aparte de lo que la cadena elija, como la criptografía de umbral para el mempool, que es independiente). Se basa en la honestidad de >2/3 de los validadores para hacer cumplir las reglas y no coludir para romperlas. Si una mayoría coludiera, técnicamente podrían cambiar las reglas a través de la gobernanza o ignorarlas convirtiéndola en la nueva regla de facto. Pero ese es el caso con cualquier lógica de cadena. El diseño de Skip intenta que sea mecánicamente imposible que un solo validador haga trampa a pequeña escala. Por ejemplo, cualquier intento de desviar la ordenación será detectado por otros porque es objetivo. Por lo tanto, reduce la confianza en los proponentes individuales. En términos de rendimiento, ejecutar subastas y verificaciones adicionales añade sobrecarga. Sin embargo, los bloques de Cosmos son relativamente pequeños y el tiempo entre bloques suele ser de un par de segundos, lo que es suficiente para estas operaciones en la mayoría de los casos. La simulación (pre-ejecutar transacciones para asegurar que no fallen y se cumplan las restricciones de ordenación) podría ser la parte más pesada, pero los validadores ya ejecutan los bloques normalmente, por lo que esto es similar. La presencia de múltiples carriles significa la separación del mempool: por ejemplo, una transacción podría necesitar especificar a qué carril se dirige (subasta vs. gratuito vs. predeterminado). El diseño de Skip BlockBuster de hecho tenía carriles separados como lanes/auction, lanes/free, etc., probablemente colas de mempool separadas. Eso asegura, por ejemplo, que las transacciones gratuitas no retrasen ni interfieran con las de la subasta. Es un poco como tener múltiples clases de prioridad en la programación. Otro aspecto es la seguridad y el mal comportamiento: si un proponente intenta manipular la subasta (por ejemplo, incluir su propia transacción pero afirmar que siguió las reglas), otros validadores rechazarán el bloque. El consenso de Cosmos entonces probablemente pasará al siguiente proponente, sancionando al anterior por doble firma o simplemente por fallar (dependiendo del escenario). Así que el modelo de seguridad de la cadena se encarga de eso, no se necesita una sanción especial por parte de Skip más allá del consenso existente. Se podría extender Skip para sancionar por ordenación maliciosa, pero probablemente sea innecesario si el bloque simplemente falla. Desarrollo y Herramientas: El código de Skip ha sido de código abierto (inicialmente en skip-mev/pob y ahora probablemente movido a un nuevo repositorio después de lanzamientos estables). Han pasado por testnets e iteraciones con cadenas asociadas. En la hoja de ruta, hemos visto: la Propuesta 341 de Osmosis (aprobada en otoño de 2022) para integrar ProtoRev y subastas con Skip, entregada a principios de 2023. Astroport de Terra integró el reparto de MEV con Skip en 2023. El Cosmos Hub está evaluando el "Block SDK" de Skip, que traería características similares al Hub. Otra frontera interesante es el MEV entre cadenas a través del Interchain Scheduler: la comunidad del Cosmos Hub está explorando una subasta de MEV entre cadenas donde el MEV de muchas cadenas podría negociarse en el Hub, y Skip está involucrado en esas discusiones (la investigación de Zerocap señaló el planificado programador entre cadenas de IBC). La tecnología de Skip podría servir como la columna vertebral para tales subastas entre cadenas porque ya está haciendo subastas en cadenas individuales. Eso sería análogo al objetivo multidominio de SUAVE pero dentro de Cosmos. En cuanto a las actualizaciones clave: Skip se lanzó a mediados de 2022. A mediados de 2023, tenían un lanzamiento estable de POB para el SDK v0.47+ (al que muchas cadenas se están actualizando). También recaudaron financiación inicial, lo que indica un desarrollo activo. Otro competidor en Cosmos, Mekatek, ofrece una funcionalidad similar. Esto quizás ha acelerado la hoja de ruta de Skip para mantenerse a la vanguardia. Skip continúa refinando características como carriles de transacciones privadas (quizás para ocultar tu transacción hasta que se incluya) y reglas de validez más complejas a medida que surgen casos de uso. Debido a que es modular, una cadena como dYdX (que tendrá un libro de órdenes) podría usar Skip para asegurar la equidad en el emparejamiento de órdenes en la cadena, etc., por lo que las herramientas de Skip podrían adaptarse a diferentes lógicas de aplicación. Técnicamente, la solución de Skip es más simple que construir una cadena completamente nueva: está actualizando las capacidades de las cadenas existentes. Este enfoque incremental y opcional ha permitido una adopción bastante rápida; por ejemplo, habilitar subastas en Osmosis no requirió un nuevo algoritmo de consenso, solo añadir un módulo y coordinar a los validadores para que ejecuten el software actualizado (lo cual hicieron, ya que era beneficioso y fue aprobado por la gobernanza). En resumen, la arquitectura de Skip está incrustada en el software de nodo de cada cadena, personalizando el mempool y el pipeline de propuesta de bloques. Es un enfoque de ingeniería pragmático para la ordenación justa: usar lo que ya existe (Tendermint BFT), añadir lógica para guiarlo. El trabajo pesado (como encontrar arbitrajes) puede incluso ser realizado por el propio módulo de la cadena (ProtoRev usa el código Wasm y Rust incorporado de Osmosis para escanear los pools). Así que gran parte del manejo de MEV se traslada a la cadena. Este enfoque en la cadena debe ser codificado cuidadosamente para la eficiencia y la seguridad, pero está bajo el escrutinio de la comunidad. Si alguna regla es problemática (demasiado estricta, etc.), la gobernanza puede ajustarla. Por lo tanto, técnica y socialmente, Skip convierte el MEV en solo otro parámetro de la cadena para ser optimizado y gobernado, en lugar de un salvaje oeste. Esta es una postura única habilitada por la flexibilidad de Cosmos.

Análisis Comparativo de SUAVE, Anoma, Skip y Flashbots v2​

Estos cuatro protocolos abordan el problema del MEV y la ordenación justa desde diferentes ángulos, adaptados a sus respectivos ecosistemas y filosofías de diseño. Flashbots v2 es una solución incremental y pragmática para la arquitectura actual de Ethereum: adopta las subastas de MEV pero intenta democratizar y suavizar su impacto (a través de la coordinación fuera de la cadena, la privacidad de SGX y los mecanismos de reparto). SUAVE es el plan a futuro de Flashbots para crear una plataforma de MEV entre cadenas que maximice el valor total y los beneficios para el usuario, esencialmente escalando el modelo de subasta a una red global descentralizada y que preserva la privacidad. Anoma es una reimaginación desde cero de cómo se formulan y ejecutan las transacciones, con el objetivo de eliminar las causas raíz de la ordenación injusta mediante el uso de intenciones, emparejamiento mediado por solvers y equidad criptográfica en el consenso. Skip es un enfoque de cadena soberana, que integra la equidad y la captura de MEV a nivel de protocolo por cadena, especialmente en Cosmos, a través de reglas y subastas configurables.

Cada uno tiene fortalezas y debilidades:

• Equidad y Garantías de Ordenación: Anoma ofrece la equidad teórica más fuerte (sin front-running por diseño, lotes encriptados), pero requiere un nuevo paradigma y una tecnología compleja que aún se está probando. Skip puede imponer reglas de equidad concretas en las cadenas existentes (evitando el front-running o imponiendo el primero en entrar, primero en salir dentro de los carriles), pero está limitado por lo que cada comunidad elige imponer. SUAVE y Flashbots v2 mejoran la equidad en términos de acceso (subastas abiertas en lugar de acuerdos secretos, protección contra el sniping en el mempool público), pero no evitan inherentemente que se ejecute una estrategia de MEV determinada; solo se aseguran de que pague a los usuarios o se haga de manera neutral.
• Redistribución de MEV: SUAVE y Flashbots tienen como objetivo explícito devolver el MEV a los usuarios/validadores: SUAVE a través de ofertas/reembolsos de los usuarios, Flashbots a través de competiciones de constructores y reembolsos. Skip puede canalizar el MEV a los usuarios (según se configure, por ejemplo, el caso de Astroport) o a fondos comunitarios. Anoma evita la redistribución explícita porque el objetivo es evitar la extracción en primer lugar; idealmente, los usuarios simplemente obtienen precios justos, lo que equivale a no perder valor por el MEV.
• Alcance (Dominio Único vs. Múltiple): Flashbots v2 y Skip se centran en sus propios dominios (Ethereum y cadenas individuales de Cosmos, respectivamente). SUAVE es inherentemente multidominio: ve el MEV entre cadenas como una motivación principal. Anoma también considera eventualmente intenciones multicadena, pero en las fases iniciales podría ser dentro de una instancia fractal a la vez, y luego conectarse a través de adaptadores. La subasta entre cadenas de SUAVE podría desbloquear arbitrajes y coordinación que otros no pueden hacer tan fácilmente (excepto quizás un Interchain Scheduler con la ayuda de Skip en Cosmos).
• Complejidad y Adopción: Flashbots v2 fue relativamente fácil de adoptar (un sidecar de cliente) y capturó rápidamente la mayoría de los bloques de Ethereum. Skip también aprovecha la tecnología existente y está viendo adopción en Cosmos con propuestas de gobernanza sencillas. SUAVE y Anoma son más revolucionarios: requieren nuevas redes o cambios importantes. El desafío de SUAVE será conseguir que muchas cadenas y usuarios opten por una nueva capa; el desafío de Anoma es crear un nuevo ecosistema y convencer a los desarrolladores de construir en un modelo centrado en intenciones.
• Cumplimiento y Neutralidad: Los cuatro ofrecen mejoras en la transparencia. Flashbots v2/SUAVE eliminan los elementos del bosque oscuro pero han tenido que gestionar problemas de censura; SUAVE se está construyendo explícitamente para evitar esos puntos centrales. Anoma, con privacidad por defecto, protege al máximo a los usuarios (pero podría preocupar a los reguladores debido a la actividad encriptada). El modelo de Skip da a cada cadena autonomía para encontrar un equilibrio en el cumplimiento. Si un regulador exigiera "no subastas de MEV" o "no privacidad", un Ethereum usando Flashbots podría enfrentar un conflicto, mientras que una cadena de Cosmos usando Skip podría simplemente no implementar esas características o ajustarlas. En términos de neutralidad: SUAVE y Anoma aspiran a la neutralidad creíble (todos acceden a un sistema en igualdad de condiciones; ambos son esencialmente redes de bienes públicos). Flashbots v2 es neutral al ofrecer acceso abierto, pero existe cierta centralización en el mercado de constructores (aunque mitigada por los esfuerzos de buildernet). La neutralidad de Skip depende de la gobernanza; idealmente, hace que el MEV no favorezca a ningún insider, pero podría configurarse mal y dañar la neutralidad (aunque es poco probable, ya que requeriría un consenso de gobernanza para hacerlo).
• Diferencias en la Arquitectura Técnica: Flashbots v2 y SUAVE son mercados fuera de la cadena superpuestos a la cadena: introducen roles especializados (constructores, relays, ejecutores) y usan hardware o criptografía para asegurarlos. Anoma y Skip se integran directamente en el consenso o la máquina de estados. Anoma altera el ciclo de vida de la transacción y el propio consenso (con cifrado de umbral e intenciones unificadas). Skip se engancha al consenso de Tendermint a través de ABCI++, pero no cambia el algoritmo fundamental; es un ajuste a nivel de aplicación. Esta diferencia significa que SUAVE/Flashbots pueden teóricamente servir a muchas cadenas sin que cada una se actualice (funcionan en paralelo a ellas), mientras que Anoma/Skip requieren que cada cadena o instancia use el nuevo software. SUAVE está en un punto intermedio: es una cadena separada, pero para usarla eficazmente, otras cadenas necesitan ajustes menores (para aceptar bloques construidos por SUAVE o enviar salidas a SUAVE). La sofisticación criptográfica es más alta en Anoma (ZK, MPC, criptografía de umbral, todo en uno), moderada en SUAVE (criptografía de umbral y SGX, más criptografía normal para puentes), y relativamente baja en Flashbots v2 (SGX, firmas estándar) y Skip (principalmente firmas estándar, más lo que la cadena use, como el descifrado de umbral si se opta por él).
• Etapa de Desarrollo: Flashbots v2 está en producción en Ethereum (desde septiembre de 2022). Skip está en producción en múltiples cadenas de Cosmos (desde 2022-2023 en adelante). SUAVE está en fase de testnet/devnet con partes implementándose (alguna funcionalidad de subasta en pruebas, testnet Toliman en vivo). Anoma también está en fase de testnet (un documento de visión, implementaciones parciales como la mainnet de Namada, y probablemente una testnet de Anoma que requiere códigos de invitación en 2023). Así que, en términos de datos del mundo real: Flashbots v2 y Skip han demostrado resultados (por ejemplo, Flashbots v2 entregó millones a los validadores y redujo los precios promedio del gas durante períodos de alto MEV; ProtoRev de Skip generó fondos significativos para la comunidad de Osmosis y evitó muchos ataques sándwich a medida que comenzó el cifrado de umbral). SUAVE y Anoma son prometedores pero tienen que demostrar su valía operativa y económica.

Para cristalizar estas comparaciones, la siguiente tabla resume los aspectos clave de cada protocolo lado a lado:

Protocolo	Ordenación de Transacciones	Mecanismo de MEV (Suprimir vs. Extraer)	Incentivos Económicos (Alineación)	Cumplimiento y Neutralidad	Arquitectura y Tecnología	Estado de Desarrollo
Flashbots v2 (Ethereum)	Subastas de constructores fuera de la cadena deciden la ordenación de bloques (PBS a través de MEV-Boost). Las transacciones del mempool público se omiten en favor de bundles privados. La ordenación se basa en el beneficio (el bundle que paga más va primero).	Extrae MEV a través de subastas de bloques a sobre cerrado, pero mitiga los efectos secundarios perjudiciales (sin guerras de gas, sin front-running público). Proporciona envío de transacciones privadas (Flashbots Protect) para suprimir el MEV visible para el usuario, como el front-running directo. La resistencia a la censura mejora a través de múltiples relays y la descentralización de constructores.	Los validadores maximizan los ingresos externalizando bloques (ganan las ofertas más altas). Los searchers compiten reduciendo sus beneficios para ganar la inclusión (la mayor parte del MEV se paga a los validadores). Los constructores ganan un margen si lo hay. Los reembolsos emergentes comparten el MEV con los usuarios (a través de BuilderNet). Los incentivos favorecen la competencia abierta sobre los acuerdos exclusivos.	Inicialmente enfrentó censura de la OFAC (relay central) pero pasó a múltiples relays y constructores de código abierto. Ahora persigue la neutralidad creíble: la red TEE de BuilderNet asegura que ningún constructor único pueda censurar. En general, es más transparente que el mempool, pero todavía depende de entidades fuera de la cadena (relays).	Mercado fuera de la cadena integrado con Ethereum PoS. Utiliza Hardware Confiable (SGX) para el flujo de órdenes privado en BuilderNet. Sin cambios de consenso en L1; utiliza la API de constructor estándar. Fuerte en ingeniería (clientes sidecar, relays) pero ligero en nueva criptografía.	En producción en la mainnet de Ethereum (desde septiembre de 2022). >90% de los bloques a través de MEV-Boost. Actualizaciones continuas: constructor de código abierto, BuilderNet alfa en vivo (finales de 2024). Probado y estable, con esfuerzos de descentralización en curso.
SUAVE (próxima generación de Flashbots)	Mempool unificado entre cadenas de preferencias (intenciones de usuario + ofertas). Los ejecutores forman bundles de transacciones óptimos a partir de estas. Secuenciación descentralizada: SUAVE emite fragmentos de bloques ordenados a los dominios. La ordenación se basa en las ofertas de los usuarios y el bienestar global (no en un simple FIFO o gas). La privacidad (encriptación) evita la manipulación del orden hasta la ejecución.	Suprime el "mal MEV" al devolver el MEV a los usuarios: por ejemplo, las subastas de flujo de órdenes pagan a los usuarios por ser objeto de back-running. Agrega el "buen MEV" (como los arbitrajes entre dominios) para una extracción máxima, pero lo redistribuye a usuarios/validadores. Utiliza un mempool encriptado y construcción de bloques colaborativa para prevenir el front-running y el acceso exclusivo.	Los usuarios publican preferencias con ofertas pagables; los ejecutores competidores ganan la oferta al cumplir el objetivo del usuario. Los validadores de cada cadena obtienen comisiones más altas debido a bloques óptimos y la captura de MEV entre cadenas. Los propios validadores de SUAVE ganan comisiones de red. El diseño empuja el beneficio del MEV hacia los usuarios y validadores, minimizando la renta de los searchers. Flashbots aspira a seguir siendo solo un facilitador.	Construido para la neutralidad creíble: una plataforma pública neutral no controlada por ningún actor único. Prioridad a la privacidad (transacciones encriptadas en SGX o mediante criptografía) significa que ninguna entidad puede censurar basándose en el contenido. Espera evitar cualquier requisito de confianza en Flashbots mediante la descentralización progresiva. El cumplimiento no está explícitamente incorporado, pero se prioriza la neutralidad y el alcance global (podría enfrentar preguntas regulatorias sobre la privacidad).	Cadena independiente (compatible con EVM) para preferencias y subastas. Utiliza enclaves Intel SGX extensivamente (para el mempool privado y la construcción de bloques colaborativa). Planea introducir el cifrado de umbral y MPC para eliminar el hardware confiable. Esencialmente una capa de blockchain + computación segura sobre otras.	En desarrollo: fase de testnet Centauri activa (devnet, subastas básicas). Cliente de SUAVE de código abierto (agosto de 2023); testnet Toliman lanzada para pruebas comunitarias. La mainnet aún no está en vivo (se espera en fases: Andromeda, Helios). Hoja de ruta ambiciosa, aún no probada a escala.
Anoma (protocolo centrado en intenciones)	Sin mempool convencional; los usuarios transmiten intenciones (resultados deseados). Los solvers recopilan intenciones y producen transacciones emparejadas. Utiliza el cifrado de umbral de las transacciones para que los validadores las ordenen sin ver el contenido, evitando el MEV reactivo. A menudo emplea el procesamiento por lotes (por ejemplo, desencriptar y emparejar intenciones en lotes cada N bloques) para precios justos. El consenso asegura los compromisos de orden antes de la revelación, logrando la equidad en el orden.	Fuerte mitigación de MEV por diseño: el front-running es imposible (las transacciones se revelan solo después de que la ordenación es final). Las subastas por lotes eliminan las ventajas de prioridad (por ejemplo, todas las operaciones en un lote comparten el precio de compensación). Los solvers compiten para cumplir las intenciones, lo que lleva los precios hacia el óptimo para el usuario, dejando poco MEV. Esencialmente minimiza el valor extraíble: cualquier arbitraje necesario se realiza como parte del emparejamiento, no por externos.	Los solvers ganan comisiones o diferenciales por encontrar coincidencias (similar a los agregadores de DEX), pero la competencia los obliga a ofrecer los mejores tratos a los usuarios. Los validadores obtienen comisiones y recompensas de staking; también aseguran una ejecución justa (sin MEV extra a través del consenso). Los usuarios ganan a través de una mejor ejecución (solo operan a precios justos, sin perder valor por el MEV). El valor que sería MEV es retenido por los usuarios o el protocolo (o compartido mínimamente con los solvers como una comisión de servicio). La arquitectura alinea los incentivos para la participación honesta (los solvers y validadores son recompensados por facilitar las operaciones, no por explotarlas).	La privacidad y la equidad son fundamentales: las intenciones pueden ser parcial o totalmente protegidas (con pruebas ZK), protegiendo los datos del usuario. Resistencia a la censura: los validadores no pueden censurar selectivamente lo que no pueden ver (transacciones encriptadas) y deben seguir reglas de emparejamiento algorítmicas. Altamente neutral: todas las intenciones son tratadas por la misma lógica de emparejamiento. El cumplimiento regulatorio no está incorporado (la fuerte privacidad podría ser un desafío para el KYC), pero el marco de intenciones podría permitir diseños compatibles a nivel de aplicación.	Nueva arquitectura de blockchain. Utiliza consenso BFT con una capa integrada de gossip de intenciones y solvers. Se basa en la criptografía de umbral (Ferveo) para la privacidad del mempool y ZK SNARKs (Taiga) para la privacidad de los datos. La ejecución se guía por predicados de validez (lógica específica de la aplicación que impone resultados justos). Interoperable a través de IBC (intenciones multicadena posibles en el futuro). Muy avanzado criptográficamente (encriptación, ZK, conceptos de MPC combinados).	Testnets y lanzamientos parciales. La primera testnet de Anoma, Feigenbaum (noviembre de 2021), demostró el emparejamiento básico de intenciones. Muchos conceptos se implementan por etapas; por ejemplo, Namada (2023) se lanzó con la tecnología de privacidad de Anoma y Ferveo en un caso de uso de una sola cadena. La L1 completa de Anoma con intenciones está en testnet (pruebas solo por invitación a mediados de 2023). La Fase 1 de la Mainnet (planeada) se centrará en la integración con Ethereum; el token nativo y el consenso completo vendrán después. Todavía bajo intensa I+D, aún no probado en batalla.
Skip Protocol (Cosmos)	Reglas de ordenación de transacciones dentro del protocolo y carriles de bloque configurados por la gobernanza de cada cadena. Por ejemplo, las subastas determinan el orden de la parte superior del bloque, luego las transacciones predeterminadas, etc. Impuesto por consenso: los validadores rechazan los bloques que violan la ordenación (como una secuencia de transacciones inválida). Permite políticas personalizadas (ordenar por precio de gas, incluir primero transacciones de oráculo, no permitir ciertos patrones), efectivamente algoritmos de ordenación deterministas elegidos por la cadena.	Enfoque híbrido: extrae MEV de formas controladas (a través de subastas en cadena y arbitraje propiedad del protocolo) mientras suprime el MEV malicioso (a través de la imposición de reglas). El front-running puede ser prohibido por las reglas de la cadena. El back-running/arbitraje puede ser internalizado: por ejemplo, la cadena hace su propio arbitraje (ProtoRev) y comparte los ingresos. Las subastas de espacio de bloque (Skip Select) permiten a los searchers pujar por prioridad, por lo que el MEV se captura de forma transparente y a menudo se redistribuye. En general, el MEV negativo (sándwiches, etc.) se reduce, mientras que el "MEV positivo" (arbitrajes, liquidaciones) se aprovecha en beneficio de la cadena.	Los validadores obtienen una nueva fuente de ingresos de las comisiones de subasta o del MEV capturado por el protocolo sin romper las reglas de consenso. El riesgo de MEV deshonesto individual se reduce (deben seguir las reglas o el bloque es inválido), alineando a los validadores colectivamente. La cadena/comunidad puede dirigir los ingresos de MEV (por ejemplo, a los stakers o a un fondo comunitario). Los searchers deben competir a través de subastas, a menudo cediendo parte del beneficio a la cadena/validadores. Algunos roles de MEV son subsumidos por módulos en cadena (por lo que los searchers tienen menos ganancias fáciles). Los usuarios se benefician de menos ataques e incluso pueden recibir reembolsos de MEV (por ejemplo, Astroport comparte el MEV con los traders). Los incentivos se vuelven alineados con la comunidad: el MEV se trata como un ingreso público o no se permite en absoluto si es perjudicial, en lugar de un beneficio privado.	Cumplimiento soberano: cada cadena elige su política. Esto significa que una cadena podría imponer un estricto anti-MEV, o incluir requisitos de KYC si es necesario, a través de la configuración del módulo. La transparencia de Skip (ofertas en cadena) y el control de la gobernanza mejoran la legitimidad. Aumenta inherentemente la resistencia a la censura dentro de las reglas elegidas por cada cadena: por ejemplo, si la regla dice "siempre incluir transacciones de Oráculo", un validador censor no puede omitirla. Pero si una cadena decidiera censurar (por regla), Skip también podría imponerlo. Generalmente, Skip promueve la transparencia y la equidad según lo determine la comunidad. Ninguna entidad única (como un relay) controla la ordenación; está en el protocolo y es de código abierto.	Módulos del SDK de Cosmos (Protocol-Owned Builder) añadidos al software del nodo. Utiliza ganchos ABCI++ para el ensamblaje y la validación de bloques personalizados. Implementa subastas en cadena (contratos o módulos manejan las ofertas y los pagos). Sin criptografía especializada por defecto (más allá de la tecnología estándar de Cosmos), pero compatible con el cifrado de umbral, por ejemplo, Osmosis añadió un mempool encriptado pensando en Skip. Esencialmente, una extensión de Tendermint BFT que añade lógica consciente del MEV en la propuesta de bloques. Ligero para que las cadenas lo adopten (solo integración de módulos, sin nuevo protocolo de consenso).	En vivo en múltiples cadenas. El módulo de subasta y constructor de Skip se desplegó en Osmosis (2023): el módulo ProtoRev generó ingresos para el protocolo y las subastas están en vivo para la parte superior del bloque. Usado en Terra/Astroport, Juno, etc., y siendo considerado por el Cosmos Hub. El código es de código abierto y está en evolución (v1 de POB para SDK 0.47+). Probado en producción con MEV real capturado y distribuido. Continúa implementando características (por ejemplo, nuevos tipos de carriles) e incorporando cadenas.

Cada solución aborda el problema del MEV desde una capa diferente: Flashbots v2 funciona alrededor del consenso L1, SUAVE propone una nueva capa L1.5, Anoma rediseña la propia L1, y Skip aprovecha la personalización modular de L1. En la práctica, estos enfoques no son mutuamente excluyentes e incluso podrían complementarse (por ejemplo, una cadena de Cosmos podría usar Skip internamente y también enviar intenciones a SUAVE para el MEV entre cadenas, o Ethereum podría implementar alguna equidad de orden tipo Anoma en el futuro mientras sigue usando Flashbots para los mercados de constructores). La tabla ilustra sus propiedades comparativas: Flashbots v2 ya está ofreciendo mejoras en Ethereum pero todavía extrae MEV (solo que de manera más equitativa y eficiente); SUAVE apunta a un resultado de sinergia máxima donde todos cooperan a través de una red; su éxito dependerá de la adopción generalizada y la entrega técnica de la privacidad y descentralización prometidas; Anoma ofrece quizás la represión de MEV más poderosa al cambiar completamente cómo funcionan las transacciones, pero enfrenta el gran desafío de arrancar un nuevo ecosistema y probar su complejo protocolo; Skip logra un equilibrio pragmático para Cosmos, permitiendo a las comunidades gobernar activamente el MEV y la equidad en sus propios términos; es menos radical que Anoma pero más integrado que Flashbots, y ya está mostrando resultados tangibles en Cosmos.

Conclusión y Perspectivas​

La supresión de MEV y la ordenación justa siguen siendo uno de los "Problemas del Milenio de las criptomonedas". Los cuatro protocolos analizados —Flashbots v2, SUAVE, Anoma y Skip— representan un espectro de soluciones: desde mitigaciones inmediatas en marcos existentes hasta cambios de paradigma totales en el procesamiento de transacciones. Flashbots v2 ha demostrado el poder de los mercados de MEV abiertos para reducir el caos y redistribuir el valor, aunque navegando por compromisos como la censura, que se están abordando a través de la descentralización. Muestra que los cambios incrementales (como las subastas PBS y los mempools privados) pueden reducir significativamente el dolor del MEV a corto plazo. SUAVE, el siguiente paso de Flashbots, lleva esa ética hacia un escenario unificado entre cadenas; si tiene éxito, podríamos ver un futuro en el que los usuarios reciban pagos rutinariamente por el MEV que crean sus operaciones y donde la producción de bloques en muchas redes sea colaborativa y encriptada para la equidad. Anoma apunta a una evolución más fundamental: al eliminar el concepto de transacciones prioritarias y reemplazarlo con un sistema de emparejamiento de intenciones, podría eliminar clases enteras de MEV y desbloquear dApps financieras más expresivas. Su ordenación justa a nivel de consenso (a través de cifrado de umbral y subastas por lotes) es un vistazo de cómo las propias blockchains pueden proporcionar garantías de equidad, no solo complementos fuera de la cadena. Skip Protocol, mientras tanto, ejemplifica un término medio en un contexto multicadena: da a las cadenas individuales la agencia para decidir cómo equilibrar los ingresos de MEV y la protección del usuario. Su adopción temprana en Cosmos muestra que muchos de los efectos nocivos del MEV pueden abordarse hoy con una ingeniería de protocolo reflexiva y el consentimiento de la comunidad.

De cara al futuro, podemos esperar una polinización cruzada de ideas: los investigadores de Ethereum están estudiando el consenso de ordenación justa y el cifrado de umbral (inspirados por proyectos como Anoma y el mempool encriptado de Osmo) para su posible inclusión en soluciones L1 o L2. SUAVE de Flashbots podría interactuar con las cadenas de Cosmos (quizás incluso a través de Skip) mientras busca ser agnóstico a la cadena. El concepto de intención de Anoma podría influir en el diseño de aplicaciones incluso en plataformas tradicionales (por ejemplo, CoW Swap en Ethereum ya utiliza un modelo de solver; se puede ver como una dApp "tipo Anoma"). El éxito de Skip puede alentar a otros ecosistemas (Polkadot, Solana, etc.) a adoptar controles de MEV similares dentro del protocolo. Un tema clave es la alineación económica: todos estos protocolos se esfuerzan por alinear los incentivos de quienes aseguran la red con el bienestar de los usuarios, de modo que explotar a los usuarios no sea rentable o no sea posible. Esto es crucial para la salud a largo plazo de los ecosistemas de blockchain y para evitar la centralización.

En resumen, SUAVE, Anoma, Skip y Flashbots v2 contribuyen cada uno con piezas del rompecabezas hacia la ordenación justa y la mitigación de MEV. Flashbots v2 ha establecido una plantilla para las subastas de MEV que otros emulan, Skip ha demostrado que la imposición en la cadena es viable, Anoma ha expandido la imaginación de lo que es posible al reconstruir el modelo de transacción, y SUAVE busca unificar y descentralizar las ganancias de los últimos años. La solución definitiva puede implicar elementos de todos: subastas globales que preservan la privacidad, interfaces de usuario centradas en intenciones, reglas de equidad a nivel de cadena y construcción de bloques colaborativa. A partir de 2025, la lucha contra la injusticia inducida por el MEV está en pleno apogeo: estos protocolos están convirtiendo el MEV de una inevitabilidad oscura en una parte gestionada, incluso productiva, de la economía cripto, mientras se acercan cada vez más al ideal de "la mejor ejecución para los usuarios con la infraestructura más descentralizada".