Este artículo presentará la función de "Privacidad Programable" que proporciona transacciones más avanzadas y un diseño de mercado MEV más abierto y justo, cruzado. -SUAVE. Antes de entrar en el tema principal de explicar SUAVE, por favor, primero entienda el concepto de Intención.

Intención

Experiencia actual utilizando transacciones de blockchain

Tomando las transacciones de Ethereum como ejemplo, suponiendo que un usuario quiere intercambiar sus USDT por ETH, puede ir a la página web de Uniswap para verificar el precio, y después de establecer el deslizamiento de precio permitido, firmar y enviar la transacción, y luego esperar el resultado de la transacción.

Su transacción probablemente se verá así: "Firmo y envío esta transacción, con un valor de Nonce de 23 y una tarifa de gas de 30 Gwei. Ejecutará el contrato Uniswap para intercambiar mis 1000 USDT por 0.5 ETH, con un deslizamiento máximo del 1%."

△ ¿Nonce? ¿Gwei? Fuente de la imagen:https://www.reddit.com/r/MemeRestoration/comments/ejcvd3/confused_math_lady_4080x2663px

Supongamos que Alice es una usuaria novata, y solo quiere intercambiar su USDT por ETH, pero tiene que cruzar muchos obstáculos para cumplir este pequeño deseo:

• Lo primero es encontrar el canal de intercambio. Supongamos que ella busca en Google y encuentra la página de Uniswap (al menos allí hay un menú claro de activos digitales y un botón de intercambio), y luego necesita comprender y configurar el deslizamiento (o usar el valor predeterminado).
• Después de hacer clic en el botón Swap, aparece la pantalla de firma de transacción, que contiene el Nonce y Gwei de la tarifa de gestión.
• Finalmente envía la transacción, pero probablemente no sucede nada y Alice solo puede esperar confundida y rezar para que la transacción se ejecute con éxito.

Cada nivel es una pregunta que los usuarios novatos realmente no necesitan entender pero se ven obligados a tomar una decisión: ¿Dónde canjear? ¿Quieres establecer un deslizamiento? ¿Qué porcentaje se debe establecer para el deslizamiento? ¿Quieres ajustar la tarifa de gas (tarifa de manejo)? ¿A cuántos Gwei necesita ajustarse? ¿Por qué falló la transacción? ¿Por qué la transacción está atascada allí durante tanto tiempo (tal vez sea un problema con el Nonce o la tarifa de manejo)? ¿Qué debo hacer?

Experiencia de uso de transacciones de intención

A diferencia de la Transacción, que requiere especificar varios detalles de una transacción, la Intención solo requiere que el usuario especifique los resultados que desea lograr y las condiciones de ejecución, y deje el resto a personas más profesionales.

En la intención, Alice especificó que 1000 USDT deberían ser intercambiados por 0.5 ETH, pero considerando la comisión de manejo, el precio se ajustó a 0.495 ETH, y luego la orden fue firmada y enviada. La transacción de Alice se verá así: “Firmo y envío esta orden. Quiero intercambiar 1000 USDT por 0.495 ETH. Esta orden es válida siempre y cuando pueda obtener 0.495 ETH.”

Es muy simple, ¿verdad? Esta es la experiencia de usar una orden limitada (Orden de límite), y también es la experiencia general de usar los Agregadores DEX (como 1inch y Tokenlon).

△ La diferencia entre Transacción (arriba) e Intención (abajo). Con Intención, los usuarios solo necesitan especificar las condiciones y no necesitan preocuparse por cómo lograrlas. Subtítulo:https://www.paradigm.xyz/2023/06/intents

A través de Intent, los usuarios ya no necesitan lidiar y preocuparse por varios detalles tediosos y confusos entre la generación, firma y ejecución de transacciones. Ni siquiera necesitan resolver el problema y seguir intentando cuando una transacción falla. ¡Además, diferentes cadenas tendrán diferentes procesos de transacción y obstáculos!

A través de Intent, el usuario solo necesita especificar las condiciones de ejecución y los resultados esperados de su Intención. El resto es para que el solucionador profesional se dé cuenta de la intención del usuario: cómo enviar transacciones, monitorear transacciones, acelerar transacciones, etc. El manejo de problemas problemáticos, como el error de transacción y la intención, solo se puede implementar cuando se cumplen las condiciones de ejecución y los resultados esperados, por lo que los usuarios no tienen que preocuparse por si un accidente hará que los activos desaparezcan.

La intención mejorará enormemente la experiencia blockchain.

Consejo de lectura 1: De hecho, ya hay muchos ejemplos de uso de Intent, como la firma de una billetera multi-firma, el concepto de Clave de Sesión que otorga permisos específicos de ejecución y límites de tiempo a un tercero, o un mecanismo de transacción de emparejamiento por lotes como CowSwap. Incluso en el mundo Web2, hay rastros de Intent, como los motores de búsqueda (introduzco lo que quiero consultar, y el motor de búsqueda encuentra información relevante para mí a través de varios canales) o disparo en línea de comercio electrónico (introduzco lo que quiero comprar) Algo, la empresa de comercio electrónico lo encontró a través de varios canales y me lo entregó). Simplemente, la palabra Intent solo se ha vuelto popular recientemente en el mundo Web3.

Consejo de lectura 2: En inglés, la palabra Imperativo ("imperativo") se utiliza para describir la experiencia de usar Transacción, que consiste en emitir un comando completo para alcanzar el objetivo; mientras que la palabra "Declarativo" ("Declaración") se utiliza para describir la experiencia de usar Intención. Descriptivo, indicando que se utiliza mediante la declaración de condiciones de ejecución y resultados de ejecución.

Intención en el mundo interconectado

En aplicaciones de intercambio en cadena, como puentes entre cadenas y DEX entre cadenas, debido a la participación de dos o más cadenas, los usuarios tienen que lidiar con más transacciones en diferentes cadenas.

Excluyendo las aplicaciones entre cadenas a través de la firma múltiple del proyecto, puede proporcionar una mejor experiencia de usuario (por ejemplo, después de que el usuario envíe una transacción en la cadena de origen, la firma múltiple del proyecto enviará automáticamente los activos al usuario en la cadena de destino) La dirección especificada no requiere que el usuario realice ninguna operación en la cadena de destino). Otras aplicaciones entre cadenas más descentralizadas como Nomad y Succinct no tienen una experiencia tan buena. Es posible que los usuarios necesiten enviar transacciones a la cadena de destino para completar la operación.

Por lo tanto, la mejora de la experiencia del usuario que Intent puede aportar es aún más importante y urgente en el mundo de la cadena cruzada.

A través de Intent, las operaciones entre cadenas solo requerirán que los usuarios firmen, y ya no tendrán que preocuparse por las reglas de transacción y los detalles de cada cadena. Los usuarios podrán operar en diferentes cadenas con la misma experiencia de usuario, e incluso no percibirán el hecho de que hay diferentes cadenas.

SUAVE

El nombre completo de SUAVE es Single Unifying Auction for Value Expression, su propósito es convertirse en un mercado MEV unificado en varias cadenas. En este mercado, los usuarios pueden expresar las condiciones de cierre y recompensas de una transacción de manera eficiente. Al mismo tiempo, los ejecutores (Executors) competirán entre sí y cooperarán eficientemente para completar las solicitudes de los usuarios.

SUAVE puede servir como un grupo de transacciones para una cadena de bloques y también actuar como un rol de Constructor responsable de producir el contenido del bloque de esa cadena de bloques. Sin embargo, SUAVE no tiene la intención de reemplazar el grupo de transacciones existente y la funcionalidad de Constructor de una cadena de bloques, sino más bien conectarse de manera plug and play a una cadena de bloques existente.

Después de que SUAVE se conecta a una blockchain, la blockchain es equivalente a tener un Constructor descentralizado, muy profesional y poderoso que abarca múltiples fuentes de transacciones blockchain. Tener múltiples fuentes de transacciones blockchain al mismo tiempo proporcionará enormes ventajas en el mercado MEV interdominio que crecerá gradualmente en el futuro. Los Constructores con esta ventaja serán más competitivos que los constructores que operan en una sola cadena.

Desde Flashbot hasta MEV-Boost hasta SUAVE

Desde Flashbot hasta MEV-Boost, el espíritu que mantienen es reconocer la existencia de MEV y esforzarse por llevar a la luz las actividades económicas ocultas. Su objetivo es establecer un mercado público en el que cualquiera pueda participar, para evitar el escenario en el que unas pocas personas controlan y dominan silenciosamente este inmenso interés económico, lo que conduce gradualmente a la concentración de recursos en sus manos y finalmente afecta la descentralización y la seguridad de toda la red blockchain.

Pero a medida que las personas aprenden más y más sobre MEV, gradualmente se dan cuenta de que además del mercado de MEV maduro en Ethereum, también existen mercados de MEV entre cadenas y transfronterizos. Este mercado transfronterizo de MEV será mucho más grande que el de Ethereum, y las transacciones entre cadenas tendrán más oportunidades de extraer MEV que las transacciones en la misma cadena.

Si no hubiera habido alguien como Flashbot para exponer el mercado MEV entre cadenas, sacarlo a la luz y permitir una participación justa para todos, las pocas personas que explotan el MEV entre cadenas tendrían aún más ventaja, afectando en última instancia la seguridad de toda la red blockchain.

Otro fenómeno que afectará a la centralización y seguridad es el Flujo de Órdenes Privadas: las transacciones de los usuarios ya no fluyen a la piscina de transacciones pública, sino directamente al Buscador o Constructor. El Flujo de Órdenes Privadas puede provenir de que el Buscador o Constructor compren el derecho a ganar ingresos de las transacciones de los usuarios, o de que el Constructor proporcione servicios atractivos, como (1) cancelación gratuita de transacciones u órdenes DEX enviadas por los usuarios, o (2) proporcionar Pre-Confirmación, antes de que se reciba la transacción, el usuario tiene la certeza de cuán rápido se recibirá la transacción, de modo que el usuario no necesita preocuparse por si la transacción se recibirá y cuánto tiempo tomará en recibirse.

Si bien el flujo de pedidos privados puede beneficiar inicialmente a los usuarios, a la larga resultará en centralización. Los Buscadores/Constructores con Flujo de Pedidos Privados tendrán una ventaja competitiva y obtendrán más beneficios en comparación con aquellos que no lo tienen, lo que llevará a un impacto perjudicial en la competencia. Además, dado que no hay incentivo para compartir el Flujo de Pedidos Privados con nuevos Buscadores/Constructores, estos recién llegados estarán en desventaja al comenzar el juego.

¿Por qué los bloques de las transacciones del usuario al Bundle creado por Searcher deben ser recopilados a través de Private Order Flow? Esto se debe a que el contenido de la transacción y del Bundle es público y no está encriptado. Si son vistos y obtenidos por otros, puede causar daño al usuario o al Searcher. Por ejemplo, otros pueden extraer el MEV de la transacción del usuario a través de un ataque de tenaza o desmontar el Bundle, arrebatando el MEV. Por eso, tanto los usuarios como los Searchers actualmente tienen que confiar en el Builder, ya que necesitan entregar el contenido original de la transacción y del Bundle al Builder y confiar en que el Builder no causará ningún daño.

La aparición de SUAVE es para resolver los riesgos de centralización causados por el MEV transfronterizo y el flujo de pedidos privados.

En primer lugar, al establecer un mercado público que atienda a MEV entre cadenas, los usuarios o buscadores pueden expresar sus condiciones de ingresos para transacciones o paquetes en este mercado. Por ejemplo, si un usuario tiene dos transacciones que deben enrutarse a Ethereum y Arbitrum respectivamente, y ambas transacciones deben incluirse y ejecutarse antes de un tiempo determinado, puede especificar estas condiciones en el mercado. Los Ejecutores en el mercado (que pueden ser Buscadores o Constructores) competirán para cumplir con estas solicitudes con el fin de ganar recompensas. Pero, ¿cómo pueden los usuarios o los buscadores confiar en lanzar sus transacciones o paquetes a este mercado público? Aquí es donde entra en juego la tecnología de privacidad. Al cifrar las transacciones, los usuarios o buscadores ya no tienen que preocuparse por el daño potencial causado por otros que ven sus transacciones. Solo con la privacidad de las transacciones puede ser posible un flujo de órdenes abiertas.

SUAVE propone además el concepto de Privacidad Programable, donde los usuarios o buscadores pueden elegir si revelar partes específicas de las transacciones o contenidos de paquetes (como la dirección del contrato de ejecución de la transacción) en lugar de verse limitados a elegir entre encriptación completa o ninguna encriptación.

En comparación con las transacciones completamente encriptadas, las transacciones que revelan información específica pueden incorporarse en paquetes o bloques de manera más efectiva y rápida, e incluso recibir recompensas, como se detalla en la sección MEV-Share del cuarto artículo. Al revelar información específica, los Buscadores incluso pueden colaborar entre sí. El Buscador B puede construir sobre el paquete del Buscador A: el paquete del Buscador A sigue la transacción del usuario para el arbitraje, y el paquete del Buscador B sigue el paquete del Buscador A para el arbitraje. La privacidad es esencial para un flujo de órdenes abierto. La privacidad permite a los Buscadores tener la oportunidad de cooperar entre sí, beneficiándose mutuamente en lugar de competir por oportunidades de MEV.

Otros beneficios de SUAVE

• A través de SUAVE, las transacciones DEX entre cadenas pueden obtener mejores precios y las Intenciones entre cadenas pueden ejecutarse de manera más eficiente.
• Si SUAVE es considerado como un Constructor enorme pero descentralizado, tendrá más ventajas que un Constructor centralizado porque reúne más Flujos de Órdenes, lo que también puede atraer a más Constructores a unirse a SUAVE, y además puede reducir los riesgos causados por la centralización del Constructor.
• A través de SUAVE, cada cadena no tiene que construir su propia piscina de transacciones privadas y su propio mercado de MEV de la cadena, y puede centrar sus recursos y energía en resolver otros problemas o proporcionar mejores servicios.

arquitectura SUAVE

Tablón de anuncios para preferencias de usuario

SUAVE se puede describir como un "tablón de anuncios de preferencias del usuario". El término "Usuario" aquí no se refiere necesariamente a los usuarios generales de blockchain, pero los Buscadores también pueden ser Usuarios de SUAVE. A continuación, "Usuario" se referirá a los usuarios generales de la cadena de bloques, y "Usuario SUAVE" se referirá a los usuarios de SUAVE.

La Preferencia del Usuario de SUAVE es como un Intento especializado que se centra en la clasificación de transacciones. No es como los Intents generales que los lectores pueden ver en otros lugares, que pueden especificar varias condiciones. Similar a cómo los usuarios especifican preferencias y condiciones en Intents, en Preferencia, los Usuarios de SUAVE especifican preferencias o condiciones para que "las transacciones o los ingresos del paquete entren en el bloque," como por ejemplo:

• “Quiero que mi transacción se clasifique antes de la transacción 0xabcd y se incluya antes del bloque 110050.” De hecho, es como las condiciones especificadas por el Bundle of Searcher al usar Flashbot.
• “Quiero que mi Bundle se incluya y me genere 0.05 ETH en ingresos.”
• “Quiero que la Intención A y la Intención B se incluyan en el bloque 1001 de la cadena X y el bloque 50900 de la cadena Y respectivamente.” \

Consejo de lectura: Los usuarios también pueden enviar transacciones generales de blockchain (sin especificar ninguna preferencia) a SUAVE, es decir, simplemente utilizar SUAVE como un grupo de trading general o Flashbot, como enviar directamente sus transacciones de transferencia de ETH o transacciones de Uniswap a SUAVE.

Por supuesto, si solo especificas condiciones, no es necesario diseñar una nueva arquitectura para hacer esto, simplemente usa el Flashbot original. Por lo tanto, de hecho, las Preferencias especificadas en SUAVE deben coincidir con las recompensas, de lo contrario nadie estará dispuesto a completar tus Preferencias incondicionalmente. Por supuesto, el requisito previo para el pago debe ser que se hayan logrado las Preferencias.

Al convertir la designación de preferencias y recompensas en contratos inteligentes para ser cumplidos, las partes demandantes (como usuarios o buscadores) podrán presentar requisitos de preferencias más detallados y diversos, y estos requisitos son cumplidos por incentivos económicos en lugar de depender de la bondad del Constructor.

• "Quiero que mi transacción se ordene antes de la transacción 0xabcd y se incluya antes del bloque 110050. Si se logra, te daré 3 ETH."
• “Quiero que mi Bundle se incluya y me genere 0.05 ETH de ingresos. Si se logra, te daré 0.02 ETH.”
• “Quiero que la Intención A y la Intención B se incluyan en el 1001er bloque de la cadena X y el 50900º bloque de la cadena Y respectivamente. Si se logra esto, te daré 1.8 ETH”.

Arquitectura

SUAVE se puede ver como compuesto por tres componentes: Entorno de Preferencia, Mercado de Ejecución y Construcción de Bloques Descentralizada.

• El Entorno de Preferencias es un lugar que aloja las Preferencias del Usuario y recompensas de varias cadenas, incluida la cadena SUAVE y su grupo de transacciones. El usuario de SUAVE puede ser un usuario general o un Buscador.
• El Mercado de Ejecución es un grupo de Ejecutores profesionales que encuentran y ejecutan las Preferencias del Usuario (ejecutando las Preferencias del Usuario empaquetándolas en Bundles) para ganar recompensas. El Ejecutor puede ser un Buscador o un Constructor
• La construcción descentralizada de bloques es el proceso de ensamblar múltiples paquetes en bloques para una o más cadenas.

△ El PE a la izquierda reúne Intents y transacciones de arbitraje en varias cadenas, luego los Executors en el medio intentan satisfacer estas Preferencias y empaquetarlas en Bundles, y entregan estos Bundles al rol a la derecha que tiene el derecho de producir bloques para ensamblar los bloques. Fuente de la imagen:https://writings.flashbots.net/the-future-of-mev-is-suave

SUAVE tendrá su propia cadena y piscina de transacciones. SUAVE llama a la cadena Capa de Liquidación y a la piscina de transacciones Capa de Mensajería.

Los contratos inteligentes pueden implementarse en la cadena para establecer contratos entre Preferencia y recompensas. La piscina de transacciones se llenará con transacciones en las que el Usuario SUAVE declara la Preferencia y el Ejecutor recibe recompensas.

El ciclo de vida de una transacción de SUAVE

1. Expresión de Preferencia: El Usuario de SUAVE especifica la Preferencia y puja por una o más de sus Intenciones/Transacciones.
2. Optimización de la ejecución: Executor encuentra una ruta de ejecución que satisface las preferencias del usuario e incluso puede encontrar la ruta óptima para ella.
3. Liquidación de preferencia: El/los conjunto(s) del ejecutor se incluyen con éxito en el bloque de la cadena objetivo y cumplen con la preferencia especificada por el usuario SUAVE.
4. Liquidación de pagos: Oracle devuelve el estado de la cadena objetivo a la Cadena SUAVE, y el Ejecutor ejecuta el contrato inteligente. Después de que el contrato confirma que la Preferencia ha sido satisfecha, la recompensa al Usuario SUAVE se le otorga al Ejecutor.

△ Preferencia cuatro pasos desde el establecimiento hasta la ejecución hasta el arreglo. Fuente de la imagen:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

MEVM

SUAVE necesita poder escribir la Preferencia en un lenguaje de programación y convertirla en un contrato inteligente para cumplir con el contrato entre el Usuario SUAVE y el Ejecutor. Se espera que SUAVE diseñe un EVM específico para MEV basado en EVM - MEVM.

MEVM agregará un nuevo contrato Precompile y un tipo de transacción específicamente para MEV. Las funciones de Preferencia de Usuario, Paquete de Empaquetado y Construcción de Bloques pueden completarse fácilmente en MEVM.

El código del programa de muestra en la figura siguiente escribe el algoritmo de Construcción de Bloques de Precio de Gas Efectivo (EGP) utilizando contratos de Solidity y contratos precompilados de MEVM.

EGP Block Building ordena los Paquetes según el Precio de Gas dado por cada Paquete. Los Paquetes con un Precio de Gas más alto se clasificarán al principio del bloque:

△ La función rosa en la imagen es la función de precompilación de MEVM, que está especialmente diseñada para su uso en MEV. Fuente de la imagen:https://writings.flashbots.net/mevm-suave-centauri-and-beyond

Consejo de lectura: La ejecución del algoritmo de construcción de bloques en realidad no ocurre en la cadena SUAVE Chain, sino que el Block Builder simula la ejecución fuera de la cadena (igual que el nodo simulará la ejecución de una transacción localmente), por lo que este proceso de ejecución no se convertirá realmente en una transacción que ocupe el espacio del bloque y los recursos informáticos de SUAVE Chain, ni estará limitado por el rendimiento de salida de SUAVE Chain.

A través de la composabilidad del contrato EVM, el Buscador y el Buscador o el Buscador y el Constructor podrán colaborar a través de contratos, reemplazando la relación de confianza unilateral original. La cooperación también mejorará aún más la eficiencia del Bundle y extraerá más MEV, lo que puede beneficiar a todos los participantes en la cadena de suministro de MEV. Además, los participantes pueden utilizar directamente herramientas de desarrollo basadas en EVM e infraestructura, como el Proveedor RPC, herramientas de prueba como Foundry, etc., y la experiencia de desarrollo será muy buena.

Además, MEVM proporcionará la función de privacidad de transacción, porque sin privacidad, no hay posibilidad de cooperación. Sin privacidad, los buscadores tienen que preocuparse de que les roben su MEV. En la etapa inicial, esta privacidad se logrará a través del hardware de confianza SGX. La transacción se cifrará y luego se enviará a SGX para su ejecución. Se cree que SGX ejecutará su código de programa designado sin robar MEV a voluntad. En el futuro, cuando otras tecnologías criptográficas avanzadas maduren gradualmente, la criptografía se podrá utilizar para reemplazar al hardware de confianza. Para más detalles, consulte el artículo anterior enMempools encriptados.

Consejo de lectura: Sin embargo, también existen desventajas basadas en EVM, como que EVM es demasiado expresivo: De hecho, para escribir las funciones requeridas por MEV, no se necesitan muchos Opcodes en EVM. Permitir el uso de estos Opcodes puede permitir a las personas que estén dispuestas a escribir ejecuciones muy complejas, y luego hacer que la transacción falle al final de la ejecución, lo que provoca que el nodo desperdicie un montón de recursos informáticos, lo cual es un ataque de DoS. El proyecto Anoma rediseña un lenguaje de programación y un entorno de ejecución específicamente para expresar y ejecutar Intenciones. En el futuro, SUAVE también puede utilizar la arquitectura de Anoma para reemplazar a MEVM.

Plug-N-Play SUAVE

Si el desarrollador de bloques o el validador de una cadena conoce la existencia de SUAVE y tiene la intención de usar SUAVE, entonces considerará a SUAVE como un Constructor de Bloques. Si SUAVE proporciona un precio de oferta más alto por los bloques que construye, entonces los mineros o validadores utilizarán los bloques de SUAVE. Tomando el actual MEV-Boost en Ethereum como ejemplo, los bloques compuestos por SUAVE se convertirán en un formato que cumple con el mecanismo de oferta MEV-Boost a través del complemento proporcionado por SUAVE. El proponente no necesita realizar ningún cambio para adoptar los bloques de SUAVE.

Si el desarrollador de bloques o el validador de una cadena no conoce la existencia de SUAVE, entonces el Ejecutor de SUAVE pujará para recibir su Bundle a través de las reglas de tarifas de la cadena.

Desafíos de MEV entre cadenas

Cada cadena tiene su propio desarrollador y validador de bloques. El hecho de que el bloque B1 de SUAVE sea recibido por la cadena X no significa que el bloque B2 también será recibido con éxito por el Validador de la cadena Y. Los mecanismos de producción de bloques y los mercados de la cadena X y la cadena Y son independientes. A menos que tanto la cadena X como la cadena Y usen un secuenciador compartido, y el mismo secuenciador produzca bloques para ambas cadenas al mismo tiempo, entonces solo combinando SUAVE podemos asegurar la inclusión atómica: las dos cadenas no deben "recopilar transacciones (o bloques) especificadas juntas". Yuan)", o "ningún ingreso en absoluto".

Incluso si Shared Sequencer puede garantizar la Inclusión Atómica, no significa que la transacción se ejecutará "exitosamente" después de ser incluida. Si ambas transacciones no se ejecutan "exitosamente", significa que el MEV entre cadenas ha fallado. Suponiendo que un usuario de SUAVE quiere completar un arbitraje entre cadenas, las transacciones en ambas cadenas deben generarse en tiempo real y ejecutarse con éxito antes de que él pueda beneficiarse:

• Si el Usuario SUAVE no está dispuesto a asumir el riesgo de fallo en la ejecución de la transacción, entonces su Preferencia requerirá que ambas transacciones se completen con éxito antes de que se finalicen, y luego el Executor será pagado y el Executor asumirá el riesgo. Puede restringir el “resultado de una ejecución exitosa” especificando el estado en la cadena, por ejemplo, especificando que un contrato debe emitir un Evento específico, o especificando cuánto debe ser mayor el saldo de tokens de una dirección determinada. A continuación, el Executor que esté dispuesto a asumir riesgos intentará hacer que ambas transacciones se ejecuten en tiempo real y con éxito. Si solo una de ellas se recibe o la ejecución de una de las transacciones “falla”, el Executor no recibirá la recompensa.
• Si el Usuario de SUAVE está dispuesto a asumir riesgos, entonces su Preferencia solo puede requerir que se reciban ambas transacciones, y también está bien si la ejecución de la transacción falla (es decir, la transacción Revierte). El albacea seguirá haciendo todo lo posible para ejecutar ambas transacciones con éxito (la ejecución exitosa puede resultar en una recompensa más alta), pero mientras haya ingresos, puede obtener la recompensa.

Tomando la imagen de abajo como ejemplo, el usuario de SUAVE quiere realizar arbitraje de transacciones entre cadenas cruzadas entre Rollup 1 y Rollup 2: comprar un ETH a un precio más bajo en Rollup 1, y vender un ETH a un precio más alto en Rollup 2.

Si ambos intercambios se pagan en tiempo real y se ejecutan con éxito, el Usuario SUAVE puede ganar la diferencia de precio. Los Escenarios 1 y 2 en la tabla de la imagen son "El Usuario SUAVE está dispuesto a asumir el riesgo por sí mismo" y "El Executor está dispuesto a asumir el riesgo" respectivamente.

Las tres columnas inferiores de la tabla son "recompensas por ambos éxitos", "recompensas por solo un éxito" y "resultado final por solo un éxito":

• Recompensas por ambas transacciones exitosas (el usuario de SUAVE gana la diferencia de precio):
  • Escenario 1: El usuario de SUAVE paga una tarifa de manejo de $50 al Ejecutor.
  • Escenario 2: El usuario de SUAVE paga una tarifa de manejo de $70 al Ejecutor (más cara porque el Ejecutor asume el riesgo).
• Solo hay una recompensa por el éxito (el usuario SUAVE no obtuvo el spread):
  • Escenario 1: El usuario de SUAVE paga una tarifa de manejo de $25 al Executor. Los usuarios de SUAVE asumen los riesgos por sí mismos.
  • Escenario 2: El Usuario de SUAVE no tiene que pagar tarifas ni asumir riesgos.
• Solo hay un resultado exitoso (el usuario de SUAVE no obtuvo el spread):
  • Escenario 1: El usuario SUAVE paga una tarifa de manipulación de $25 al Executor y tiene un ETH extra en mano.
  • Escenario 2: El usuario de SUAVE no tiene que pagar tarifas de manejo al Executor y no tendrá un ETH extra en mano. Y el Executor tiene un ETH más en su mano.

△ Diferentes resultados de ejecución bajo diferentes situaciones. Fuente de la imagen:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg

El MEV entre cadenas requiere que los ejecutores tengan capital, estén dispuestos a correr riesgos y tengan la tecnología suficiente para garantizar ingresos atómicos en tiempo real y una ejecución exitosa. Esto puede ser un trabajo lucrativo pero relativamente exigente.

¿Por qué SUAVE necesita su propia cadena?

¿Por qué no podemos simplemente transferir y compartir Preferencias a través de la red P2P? Porque una red P2P pura no puede evitar que la red se llene de innumerables Preferencias (es decir, ataques DoS). Si se trata de una cadena, los ataques DoS pueden prevenirse a través de las tarifas de gestión.

¿Por qué SUAVE no utiliza la cadena existente? Porque SUAVE necesita su propia función de (MEV) y su propia configuración de cadena, como el tiempo de bloque y el tamaño de bloque. Si lo construyes directamente en Ethereum, te encontrarás con problemas como un costo demasiado alto, un tiempo de bloque demasiado largo y funciones limitadas.

Además, debido a que SUAVE necesita obtener información de otras cadenas para verificar si se satisface la Preferencia, una Cadena SUAVE independiente puede mantener la neutralidad al recopilar información de todas las demás cadenas.

Sin embargo, SUAVE tiene su propia cadena, lo que también significa que (1) el usuario de SUAVE puede necesitar transferir activos de otras cadenas a la cadena de SUAVE para usar SUAVE, y (2) SUAVE necesita depender de Oracle para reportar información de otras cadenas. Esto significa que SUAVE mismo tiene un requisito de confianza adicional para Oracle. Si Oracle no es seguro, afectará la seguridad del contrato en SUAVE.

Consejo de lectura: Todavía no hay muchos detalles sobre si SUAVE tendrá su propio token, si los activos deben transferirse a la Cadena SUAVE para su uso, o cómo transferir a la Cadena SUAVE. Solo se menciona en el video y en el artículo 'El usuario de SUAVE primero debe transferir activos de otras cadenas a la Cadena SUAVE antes de poder usarla'.

El diseño y el modelo de seguridad de SUAVE Chain aún están en discusión. Si SUAVE Chain es un Rollup en Ethereum, entonces puede usar directamente el mecanismo propio del Rollup para transferir activos y leer otra información del Rollup. Esto será mejor que depender de otros rollups. La tecnología cross-chain y los servicios de Oracle aportan mucha seguridad.

Si el Validador de la Cadena SUAVE se puede combinar con Eigenlayer, será más seguro y fiable utilizar directamente el Validador de Ethereum como Validador de la Cadena SUAVE que generar un conjunto de Validadores por la propia SUAVE. Pero, por supuesto, estos diseños también tienen sus correspondientes deficiencias. Para obtener más información sobre el diseño de la cadena SUAVE, consulte este artículo.

Resumen de los desafíos de SUAVE

• Tiempo de bloque de la cadena SUAVE: El tiempo de bloque de la cadena SUAVE debe ser lo suficientemente corto para que el Usuario SUAVE declare su Preferencia para que el Ejecutor SUAVE la vea. Si el tiempo de la cadena SUAVE es más largo que la cadena a la que está conectada (como Solana u otros Rollup), es fácil para el Usuario SUAVE no tener tiempo para que el Ejecutor SUAVE sepa que quiere que la transacción se incluya en el próximo bloque de una cadena determinada. Se ha producido un bloque.
• Riesgo de Oracle: Oracle es responsable de proporcionar información sobre otras cadenas, y también puede ser responsable de transferir los activos de los usuarios de SUAVE a la cadena SUAVE, por lo que la importancia de Oracle no es un asunto menor.
• Experiencia de uso entre cadenas: El usuario de SUAVE necesita transferir activos a SUAVE Chain, lo que también es una deficiencia en la experiencia de uso.
• Modelo económico: ¿Necesita SUAVE emitir sus propios activos, cómo incentivar al Validador de SUAVE, cómo prevenir que el mecanismo de incentivos económicos de SUAVE afecte la seguridad económica de otras cadenas, etc.
• Tecnología de privacidad: A corto plazo, SUAVE tendrá que depender de hardware de confianza como SGX para proporcionar funciones de privacidad de las transacciones, pero a largo plazo tendrá que cambiar a un enfoque más descentralizado y seguro para reducir los riesgos.
• ¿Es adecuado el lenguaje de preferencias: ¿Es EVM adecuado como medio para expresar y ejecutar preferencias?

Resumen y aspectos destacados

• La aparición de SUAVE es para (1) abordar el riesgo de centralización causado por la diferencia en ventajas de los Constructores que pueden resultar de MEV de Dominio Cruzado, y (2) abrir la puerta para la colaboración entre Buscadores/Constructores a través de la introducción de privacidad programable, reduciendo el riesgo de centralización que pueda surgir del Flujo de Órdenes Privadas.
• Las transacciones totalmente privadas dificultan el trabajo de los Buscadores, ya que no pueden Back-Run efectivamente las transacciones de los usuarios, lo que conduce a una disminución de la eficiencia en cadena. Sin embargo, los usuarios no tienen que elegir entre "privacidad" y "eficiencia". En cambio, pueden utilizar la privacidad programable para optar por revelar información parcial, facilitando el trabajo de los Buscadores y mejorando la eficiencia en cadena y las recompensas de Back-run.
• Con SUAVE, los usuarios de SUAVE pueden especificar sus preferencias y diversas condiciones de intención/ transacciones, mientras que el resto es manejado por Ejecutores profesionales para lograr las condiciones y reclamar las recompensas prometidas por los usuarios de SUAVE al cumplirse.
• SUAVE tendrá su propia cadena porque el P2P puro no puede prevenir los ataques DoS, y SUAVE tendrá sus propias características y configuraciones únicas para la cadena (MEV), por lo que las cadenas existentes no pueden ser utilizadas directamente. Esta cadena estará basada en una modificación de EVM, agregando las funcionalidades necesarias para MEV, llamada MEVM.
• La MEV entre cadenas es una operación muy desafiante, ya que requiere asegurar la inclusión atómica y garantizar la "ejecución exitosa" de transacciones. Los usuarios de SUAVE pueden especificar estados para requerir que las transacciones se ejecuten con éxito antes de recompensar al Ejecutor, transfiriendo así el riesgo al Ejecutor. El Secuenciador Compartido puede asegurar la Inclusión Atómica pero no garantiza que las transacciones se ejecuten "exitosamente".
• El hecho de que SUAVE tenga su propia cadena también significa que los usuarios de SUAVE deben transferir activos a la cadena SUAVE antes de poder usar SUAVE. Además, se requiere un Oráculo seguro para reportar información de otras cadenas a la Cadena SUAVE para verificar si se satisfacen las Preferencias.
• SUAVE todavía enfrenta muchos desafíos técnicos y de diseño, como Oracle seguro, técnicas de privacidad segura, lenguaje de preferencia y modelos económicos, entre otros.

Descargo de responsabilidad：

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