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.
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:
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?
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.
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.
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, 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.
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:
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.
SUAVE se puede ver como compuesto por tres componentes: Entorno de Preferencia, Mercado de Ejecución y Construcción de Bloques Descentralizada.
△ 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.
△ Preferencia cuatro pasos desde el establecimiento hasta la ejecución hasta el arreglo. Fuente de la imagen:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
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.
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.
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:
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":
△ 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é 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.
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.
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:
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?
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.
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.
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, 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.
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:
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.
SUAVE se puede ver como compuesto por tres componentes: Entorno de Preferencia, Mercado de Ejecución y Construcción de Bloques Descentralizada.
△ 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.
△ Preferencia cuatro pasos desde el establecimiento hasta la ejecución hasta el arreglo. Fuente de la imagen:https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg
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.
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.
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:
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":
△ 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é 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.