Introducción

Abordar el MEV (Valor Máximo Extraíble) ha sido un desafío continuo para Ethereum; La cadena de suministro de valor incentiva la actividad constante de los arbitrajistas con diversas estrategias de diferentes niveles de sofisticación, a menudo a expensas de los usuarios minoristas. Si bien muchos investigadores han tratado de abordar el MEV a través de cambios a nivel de protocolo, estos esfuerzos aún no han proporcionado una solución satisfactoria. La infraestructura canónica y los mecanismos de subasta actualmente en uso son capaces de capturar de manera competitiva el MEV de suma global en un bloque, pero la captura sin una redistribución justa es inadecuada: ¿por qué deberían acumular valor MEV para los validadores de la red cuando se puede capturar e internalizar de manera más efectiva aplicación por aplicación?

Ingrese la Secuenciación Específica de la Aplicación (ASS). En lugar de intentar reescribir las reglas a nivel del protocolo, ASS le otorga a las aplicaciones individuales el poder de tomar el control de cómo se secuencian sus transacciones. Al hacerlo, ASS permite a las aplicaciones onchain proteger a sus usuarios y liquidez de los efectos dañinos del MEV, al mismo tiempo que les brinda la oportunidad de capturar valor que de otra manera se perdería para los validadores de Ethereum.

Imagínese el potencial: en lugar de que los traders de alta frecuencia compitan para arbitrar al máximo a cada usuario (con casi todo el valor arbitrado filtrándose a los validadores y, por lo tanto, a las cadenas subyacentes), cada aplicación podría definir sus propias reglas para el orden de las transacciones, creando un sistema más personalizado, eficiente y justo para sus propios usuarios. Esto marca un cambio de tratar de resolver MEV a nivel de red a abordarlo donde más importa: la aplicación en sí.

Antecedentes

El concepto detrás de la Secuenciación Específica de la Aplicación (ASS) se originó a partir del trabajo de Matheus en el Regla de secuenciación verificable (VSR) para exchanges descentralizados (DEX). Matheus demostró que VSR podría mejorar la ejecución del comercio y mitiGate MEV al reducir la influencia de los mineros sobre el orden de las transacciones. Tarun más tarde expandió esta ideamostrando cómo las reglas de secuenciación específicas de la aplicación podrían afectar significativamente las funciones de pago para los participantes del protocolo, como usuarios, validadores y secuenciadores.

Aquí, la función de pago representa el valor económico de una orden de transacción en particular. Este valor refleja el beneficio o la utilidad obtenida por los participantes del protocolo, lo que muestra cómo el orden de las transacciones afecta a sus resultados financieros. Hay dos características críticas de las funciones de pago:

1. Resultados no suaves: Pequeños cambios en el orden pueden causar grandes cambios en MEV.
2. Pagos no monótonos: Pequeños cambios en el orden pueden aumentar o disminuir el MEV, pero no de manera consistente en una dirección.

Cuando las funciones de pago exhiben estas dos características, optimizar la estrategia de secuenciación se vuelve altamente complejo. En tales casos, se requieren enfoques más sofisticados y personalizados, a nivel de aplicación, para garantizar resultados equitativos para los usuarios y un ecosistema DeFi sostenible.

¿Cómo funciona ASS?

Para entender ASS, primero revisemos la cadena de suministro de transacciones existente.

En el sistema actual:

1. Las transacciones se envían a mempools públicos o privados.
2. Los mineros recopilan estas transacciones y las empaquetan en bloques.
3. Los constructores compiten en una subasta de bloques.
4. El bloque del constructor ganador se incluye en la cadena de bloques y el valor que ofrecen se paga al proponente elegido para el bloque dado.

La figura a continuación ilustra este proceso, mostrando cómo las transacciones fluyen desde las mempools hasta la cadena de bloques a través de los constructores y relés de confianza.

Diagrama de la cadena de suministro de transacciones actuales

Las aplicaciones habilitadas por ASS, por otro lado, tienen las siguientes propiedades:

1. Derechos de secuenciación restringidos: Esta restricción garantiza que solo un secuenciador designado o validadores apostados puedan interactuar con el contrato de la aplicación en la cadena en la que se establece, lo que evita la elusión nefasta de la lógica de la aplicación para la redistribución interna del valor.
2. Mempools específicos de la aplicación: en lugar de enviar transacciones a un mempool público, los usuarios envían mensajes firmados que expresan su intención a un mempool específico de la aplicación. Estas intenciones son luego recopiladas y procesadas por el secuenciador específico de la aplicación.
3. Resultados agnósticos del orden: Para hacer cumplir la regla de secuenciación y ofrecer los beneficios económicos óptimos a los usuarios objetivo, las transacciones de ASS deben ser independientes del orden de las transacciones de los constructores para el resto del bloque. Esto se logra asegurándose de que el estado de la aplicación esté controlado por su mecanismo de consenso. Luego, los pedidos de ASS se consolidan en un solo paquete que se envía a los constructores para su inclusión. Dado que este paquete no es polémico con el estado al que acceden otras aplicaciones, es independiente de su posición en el bloque.

ASS permite que las aplicaciones en cualquier cadena recuperen la soberanía sobre su ejecución y estado de contrato, lo que permite aplicaciones soberanas.

Dado estos principios fundamentales, usemos Angstrom como un ejemplo práctico de una aplicación soberana. Angstrom es un enganche UniswapV4 que protege a sus proveedores de liquidez de la selección adversa por parte de los arbitrajistas CEX-DEX, al tiempo que protege a los intercambiadores de los ataques sandwich. Una red de nodos de Angstrom llega a un consenso, en paralelo a Ethereum, sobre el conjunto de transacciones que se ejecutarán en el siguiente bloque. El flujo general es el siguiente:

1. Los arbitrajistas de CEX-DEX pujan por el derecho de ser la primera transacción en intercambiar a través del AMM (sin una comisión). Mientras tanto, los usuarios envían sus intercambios previstos como órdenes límite firmadas a la mempool de Angstrom.
2. La red Angstrom ejecuta su protocolo de consenso y forma un paquete donde el primer intercambio es la transacción del arbitrajista con la oferta más alta. El monto de la oferta se distribuye posteriormente, de forma proporcional, a los LP subyacentes en el rango del intercambio. Todas las demás órdenes límite válidas, junto con la liquidez subyacente del AMM, se ejecutan al mismo precio uniforme de liquidación.
3. Este paquete se envía luego a los constructores de Ethereum y al mempool público por el nodo propuesto de Angstrom para la ranura.
4. Los constructores incluyen el paquete Angstrom en cualquier posición en el bloque. El paquete solo necesita pagar la tarifa base para su inclusión debido a su construcción agnóstica del orden.

El siguiente diagrama ilustra la aplicación soberana en acción.

La cadena de suministro de transacciones en Angstrom

Supervivencia y suposición de confianza

En su núcleo, ASS es una forma de construcción de bloques parcial en la que una aplicación soberana delega los derechos de secuenciación a una red descentralizada de operadores siguiendo una regla de secuenciación prescrita. En consecuencia, ASS inevitablemente implica partes externas que introducen suposiciones adicionales de vida y confianza.

Suposición de vivacidad

Las aplicaciones soberanas dependen de secuenciadores específicos de la aplicación para seguir el protocolo correctamente y proporcionar actualizaciones de estado oportunas. En caso de una violación de la operatividad, como una Partición de red, los usuarios pueden no poder interactuar con partes de la aplicación hasta que se restablezca un consenso válido.

Las aplicaciones soberanas también pueden limitar el alcance del estado del contrato cuyas actualizaciones dependen de sus secuenciadores. Esto ayuda a minimizar las dependencias externas del contrato de manera que los estados críticos, como la liquidez depositada, puedan seguir siendo accesibles incluso en caso de fallo del secuenciador.

Suposición de confianza

Para asegurar que los secuenciadores cumplan con las reglas de secuenciación prescritas, las aplicaciones soberanas pueden aprovechar soluciones criptoeconómicas (como PoS) o métodos criptográficos (como TEE o MPC). El enfoque específico puede variar significativamente dependiendo de las necesidades de la aplicación; algunas pueden requerir consenso sobre la optimalidad de la ejecución, mientras que otras pueden centrarse en garantizar la privacidad previa a la ejecución a través de mecanismos criptográficos. Existen numerosas herramientas disponibles para reducir la sobrecarga de confianza de los secuenciadores y cumplir con los objetivos únicos de cada aplicación soberana.

Resistencia a la censura

Existen varios tipos de censura que afectan al ecosistema de Ethereum:

1. Censura regulatoria: los constructores y relés censuran transacciones basándose en la lista de sanciones de la OFAC. Esta es una de las formas más prominentes de censura presentes en Ethereum hoy en día.predominantemente aplicado por relés.
2. Censura económica: Un atacante motivado puede Sobornar al proponente del bloqueo para censurar las transacciones de las víctimas.
3. Censura a nivel de nodo: los nodos en la red P2P pueden negarse a propagar transacciones entrantes. Esto puede ser un problema importante si el protocolo opera de manera óptima bajo el supuesto de que la mayoría de los nodos comparten la misma vista de las transacciones entrantes. Además, en dichos protocolos, un adversario puede estar incentivado a particionar las vistas locales de los nodos honestos (enviando una transacción solo a la mitad de los nodos al final de una ranura) y detener el protocolo como resultado.

Muchos investigadores han expresado la necesidad de un mejor mecanismo de resistencia a la censura en Ethereum. Algunas propuestas, como Multiple Concurrent Proposer (MCP) y Lista de Inclusión Forzada de Fork-Choice (FOCIL)han surgido y se han convertido en el centro de una discusión en curso.

La resistencia a la censura es también una preocupación importante para la aplicación soberana. Es probable que los secuenciadores específicos de la aplicación sean entidades externas con diversos intereses en recibir transacciones privadas y flujos de pedidos adicionales. Por ejemplo, un validador específico de una aplicación que es un creador de mercado tiene un incentivo para censurar las transacciones enviadas por los creadores de mercado de la competencia. Por lo tanto, la aplicación soberana en la parte superior puede sufrir censura local incluso si el protocolo base no censura.

Un ejemplo de un mecanismo de resistencia a la censura para ASS es Angstrom. Para asegurar que todas las órdenes válidas se incluyan en el próximo espacio, los nodos de Angstrom deben difundir todas las órdenes verificadas entrantes y alcanzar consenso sobre su inclusión dentro del paquete de transacciones propuesto. Si el paquete no contiene órdenes observadas por la mayoría de la red, el proponente será penalizado. Aquí se ilustra el mecanismo de resistencia a la censura para Angstrom.

Resistencia a la censura en una aplicación soberana descentralizada

El Dilema de la Composabilidad

Uno de los principales desafíos que enfrentan las aplicaciones soberanas es garantizar la composabilidad con transacciones que interactúan con estados de contratos externos. Simplemente agrupar transacciones específicas de la aplicación con otras externas arbitrarias socava la propiedad de agnosticismo de orden que es necesaria para proteger la aplicación soberana y sus usuarios. Una sola transacción no válida no-ASS, cuando se compone con una específica de la aplicación, puede tener el efecto de revertir todo el paquete. Cuando esto ocurre, la aplicación soberana no puede ejecutar las órdenes de sus usuarios durante el intervalo asignado (a pesar de haberse alcanzado un consenso válido), lo que perjudica la experiencia del usuario y el bienestar general.

Sin embargo, existen soluciones potenciales para el problema de la composabilidad, varias de las cuales están siendo exploradas por varios equipos. Estas incluyen conceptos como preconfirmaciones de inclusión, secuenciadores específicos de aplicaciones compartidas y compromisos de desarrolladores, cada uno ofreciendo compensaciones entre el grado de composabilidad y la sobrecarga de confianza.

Preconfirmaciones de inclusión

Para explicar las preconfirmaciones de inclusión, es importante comprender primero cómo funcionan las preconfirmaciones basadas. Las preconfirmaciones basadas aprovechan la seguridad criptoeconómica al garantizar que los proponentes hayan presentado un colateral apostado para garantizar la inclusión de un conjunto específico de transacciones antes de un espacio dentro de la época actual. Esta garantía está limitada por el tamaño del bono publicado por los proponentes participantes.

Las preconfirmaciones de inclusión son una forma especializada de preconfirmaciones basadas, donde la inclusión de la transacción es independiente de cualquier estado de contrato. Las transacciones que solicitan preconfirmaciones de inclusión deben ser agnósticas del estado y no conflictivas, lo que significa que su ejecución no se ve afectada por su posición dentro del bloque. Al utilizar las preconfirmaciones de inclusión, los proponentes pueden comprometerse a incluir una transacción no ASS solo si el paquete ASS se incluye en el mismo bloque. Este enfoque proporciona composabilidad criptoeconómicamente reforzada entre transacciones no conflictivas y paquetes ASS.

Ilustración de la inclusión de preconf con ASS

Sin embargo, dada la limitada composabilidad proporcionada por esta solución, la complejidad añadida y la sobrecarga de confianza pueden superar sus beneficios para ciertas aplicaciones soberanas. Por lo tanto, es importante explorar enfoques alternativos que podrían ofrecer un equilibrio más efectivo entre simplicidad y funcionalidad.

Secuenciadores específicos de aplicaciones compartidas y compromisos del constructor

En lugar de confiar en los compromisos del proponente, las aplicaciones soberanas pueden usar secuenciadores específicos de la aplicación para administrar el ordenamiento de transacciones en varias aplicaciones. Por ejemplo, un secuenciador que maneja transacciones para varias aplicaciones soberanas puede facilitar la composabilidad atómica entre ellas, siempre y cuando siga las reglas de secuenciación de cada una. Este enfoque de secuenciador específico de la aplicación compartida permite la composabilidad y coordinación sin problemas entre aplicaciones soberanas.

Sin embargo, para aplicaciones no soberanas se requiere una solución diferente. Los compromisos de inclusión de transacciones de los constructores de bloques que participan en la secuenciación de aplicaciones soberanas pueden crear una composabilidad atómica entre aplicaciones no soberanas y soberanas. El constructor garantiza el orden de transacción especificado en ambos tipos de aplicaciones. Este compromiso del constructor puede cerrar la brecha de composabilidad para ASS.

Ilustración del compromiso del constructor para la composabilidad atómica entre dApps soberanos y no soberanos (derecha) y secuenciador compartido específico de la aplicación para la composabilidad atómica entre aplicaciones soberanas (izquierda)

Si bien persisten preguntas sobre la dinámica económica de los compromisos de los constructores, la viabilidad de la preconfirmación de la inclusión y los posibles efectos de segundo orden, confiamos en que los desafíos de componibilidad de ASS se resolverán con el tiempo. Equipos como Astria y Primevestamos investigando y desarrollando activamente marcos mejorados para secuenciación compartida y compromisos de constructores. A medida que estos avances progresen, la composabilidad ya no será un problema para las aplicaciones soberanas.

ASS vs L2s y L1s específicos de la aplicación

Actualmente, las dApps tienen que construir cadenas específicas de la aplicación si desean tomar el control de la secuenciación de sus transacciones. Conceptos como Constructor de Protocolo Propio (PoB)permite que los L1 de Cosmos tengan reglas de secuenciación más expresivas que ayudan a capturar y redistribuir MEV a su aplicación. De manera similar, un secuenciador L2 con VSR también puede realizar dichas operaciones. Si bien ambas soluciones permiten una secuenciación más expresiva y la captura de MEV por parte de sus aplicaciones, ASS es único debido a las siguientes características.

1. No hay sobrecarga de confianza en la ejecución de transacciones - ASS no ejecuta ni liquida la transacción secuenciada. Solo se delega la secuencia. La suposición de confianza básica se extiende desde el entorno de ejecución nativo, como Ethereum u otros L2s.
2. Acceso a liquidez y flujo de órdenes - Los usuarios no necesitan interconectar. Las dApps pueden aprovechar directamente el flujo y la liquidez en la cadena.
3. El activo permanece en el entorno de ejecución nativo y no se puede congelar - A diferencia de los L2, la mayoría de los ASS no requieren que los usuarios bloqueen sus fondos en contratos de puente. Esta elección de diseño ofrece una mejor seguridad: si un secuenciador específico de la aplicación falla, el daño potencial se limita ya que el secuenciador solo puede controlar transacciones dentro de los límites establecidos por el contrato inteligente. Si bien algunas soluciones L2 implementan funciones de seguridad, como escapes de emergencia y inclusión forzadaEstas medidas a menudo son difíciles de usar en la práctica. Los usuarios podrían necesitar esperar varios días antes de poder activar una salida de emergencia después de perder la conexión con las actualizaciones de L2. Del mismo modo, la inclusión forzada a través de L1 normalmente implica al menos un díaretraso. Quizás lo más importante es que estas medidas de seguridad suelen requerir conocimientos técnicos que la mayoría de los usuarios no tienen, lo que las hace impracticables para la persona promedio.
4. Fuerte suposición de vivacidad: la vivacidad del L2 depende de los nodos de ejecución, que generalmente es el secuenciador de rollup, a menos que se base en la secuencia. La vivacidad del L1 depende de la mayoría honesta de los nodos que vuelven a ejecutar las funciones de transición de estado correspondientes. La vivacidad de una aplicación soberana depende en su mayoría del entorno de ejecución subyacente, y los contratos inteligentes pueden especificar partes que deben confiar en secuenciadores específicos de la aplicación.

Tabla que compara aplicaciones soberanas, L2, basadas en L2 y L1

Conclusión

ASS capacita a las aplicaciones con plena soberanía sobre la secuencia de transacciones, lo que les permite definir reglas personalizadas sin la complejidad de gestionar la ejecución. Esta soberanía permite a las aplicaciones controlar su ejecución para optimizar los resultados para sus usuarios. Por ejemplo, en Angstrom, los LP y los intercambiadores se tratan como participantes de primera clase, con su recompensa económica mejorada directamente a través de reglas de secuenciación personalizadas.

Además, ASS puede aprovechar una serie de herramientas criptoeconómicas y criptográficas para hacer cumplir la optimalidad de los pagos a los usuarios e implementar sólidos mecanismos de resistencia a la censura. Las soluciones criptoeconómicas, como el staking y el slashing, pueden incentivar el comportamiento honesto entre los secuenciadores, mientras que los métodos criptográficos como TEE y MPC mejoran la privacidad y la seguridad. Con estas herramientas, el potencial de diseño de ASS es enorme, lo que permite la creación de aplicaciones soberanas más seguras, eficientes y centradas en el usuario.

A pesar de las oportunidades que ofrece ASS, siguen existiendo desafíos como la falta de componibilidad nativa. Sin embargo, soluciones como la preconfirmación de inclusión, el ASS compartido y el compromiso del constructor presentan formas prometedoras de superar estos obstáculos. Si bien quedan algunas preguntas, nos comprometemos a refinar estos enfoques para ofrecer una experiencia de ASS más fluida y componible.

Estamos aquí para hacer que DeFi sea más sostenible, un ASS a la vez.

Descargo de responsabilidad:

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