Autores: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm; Traducción: Golden Finance 0xxz
Introducción
Las discusiones sobre las "intenciones" y sus aplicaciones se han convertido recientemente en un tema candente en la comunidad de Ethereum.
Cuando las transacciones se refieren específicamente a "cómo" se debe realizar una acción, las intenciones se refieren a "cuál" debería ser el resultado esperado de esa acción. Si una transacción dice "haga A primero, luego B, pague C en su totalidad para obtener X", las intenciones dicen "Quiero X y estoy dispuesto a pagar hasta C".
Este paradigma declarativo desbloquea una emocionante experiencia de usuario y mejoras en la eficiencia. A través de las intenciones, los usuarios pueden simplemente expresar un resultado deseado mientras subcontratan la tarea óptima de lograr ese resultado a un tercero experimentado. El concepto de intenciones contrasta con el paradigma de transacción imperativa actual, en el que el usuario especifica explícitamente cada parámetro.
Si bien estas promesas de mejoras brindan pasos muy necesarios para el ecosistema, el diseño basado en la intención en Ethereum también podría tener implicaciones significativas para la infraestructura fuera de la cadena. En particular, existen vínculos importantes con las actividades relacionadas con MEV y el control del mercado. Esta publicación tiene como objetivo proporcionar una breve definición de las intenciones y sus beneficios, una exploración de los riesgos involucrados en su implementación y una discusión de las posibles mitigaciones.
¿Qué son las intenciones?
La forma estándar actual para que los usuarios interactúen con Ethereum es crear y firmar una transacción, un mensaje en un formato específico que proporciona toda la información necesaria para que la máquina virtual de Ethereum (EVM) realice transiciones de estado. Sin embargo, crear transacciones puede ser un asunto complicado. Crear una transacción requiere razonar sobre detalles como una amplia red de contratos inteligentes y administración de nonce, mientras se mantienen activos específicos para pagar las tarifas de gas. Esta complejidad da como resultado una experiencia de usuario subóptima y una pérdida de eficiencia, ya que los usuarios se ven obligados a tomar decisiones sin un acceso adecuado a la información o políticas de cumplimiento complejas.
Las intenciones están diseñadas para aliviar estas cargas sobre el usuario. De manera informal, las intenciones firman un conjunto de restricciones declarativas que permiten a los usuarios externalizar la creación de transacciones a terceros sin ceder el control total de las partes de la transacción.
En los procesos estándar basados en transacciones, las firmas de transacciones permiten a los verificadores seguir exactamente una ruta computacional para un estado en particular y las sugerencias incentivan a los verificadores a hacerlo. Las intenciones, por otro lado, no especifican explícitamente la ruta computacional que debe tomarse, pero permiten cualquier ruta computacional que satisfaga ciertas restricciones. Al firmar y compartir intentos (intentos), los usuarios otorgan efectivamente a los destinatarios permiso para elegir rutas de cómputo en su nombre (consulte el diagrama a continuación). Esta distinción permite una definición algo más estricta de las intenciones como mensajes firmados que permiten un conjunto de transiciones de estado desde un estado inicial dado, con un caso especial de transacciones que permiten transiciones únicas. Dicho esto, seguiremos distinguiendo las "intenciones" de las transacciones.
*Figura 1: Al enviar una transacción, el usuario especifica la ruta de cálculo exacta. Al enviar intentos, el usuario especifica un objetivo y algunas restricciones, y el proceso de coincidencia determina la ruta computacional que se tomará. *
Es importante destacar que se pueden incluir muchos intentos (intentos) en una sola transacción, lo que permite la coincidencia de intentos superpuestos (intentos), aumentando la eficiencia económica y de gas, por ejemplo, en el libro de pedidos mantenido por el constructor, dos pedidos pueden intercambiarse mutuamente antes de ingresar al compensación de mercado. Otras aplicaciones incluyen intentos de dominios cruzados (intentos): firmar un mensaje en lugar de múltiples transacciones en diferentes dominios, usar diferentes esquemas de resistencia a la reproducción (resistencia a la reproducción) y pagos de gas de usuario más flexibles, como permitir que las primeras 3 partes patrocinen gas o paguen en diferentes fichas.
pasado y futuro de intentos
Se han creado intentos que subcontratan la complejidad de interactuar con la cadena de bloques, al tiempo que permiten a los usuarios mantener la custodia de sus activos e identidades criptográficas.
Puede notar que muchas de estas ideas corresponden a sistemas que han estado en funcionamiento durante muchos años:
Orden limitada: Puedo retirar 100X de mi cuenta si recibo al menos 200Y.
Subastas estilo CowSwap: Igual que el anterior, pero depende de un tercero o mecanismo para igualar muchas órdenes y maximizar la calidad de la ejecución.
**Patrocinio de gasolina: **Paga la gasolina en USDC en lugar de ETH. Los intentos (intenciones) solo se pueden realizar mediante intentos coincidentes, y la tarifa se paga en ETH.
Delegación: Solo permite la interacción con ciertas cuentas de ciertas formas preautorizadas. Las intenciones solo se pueden implementar si la transacción resultante respeta la lista de control de acceso especificada en la intención.
**Transacción por lotes: **Permite el procesamiento por lotes de intentos para mejorar la eficiencia del gas.
** Agregadores: ** Solo operan con el "mejor" precio/rendimiento. Esta intención se puede lograr demostrando que se realiza la agregación de múltiples lugares y se toma el mejor camino.
En el futuro, en el contexto de MEV de cadena cruzada (como SUAVE), abstracciones de cuentas de estilo ERC4337 e incluso órdenes de Seaport, ¡las intenciones de las personas se están revitalizando! Si bien ERC4337 avanza a toda velocidad, otras aplicaciones novedosas, como las intenciones entre dominios, aún requieren más investigación.
De manera crucial, en todas las aplicaciones basadas en la intención, antiguas y nuevas, debe haber al menos otra parte que comprenda la intención, esté motivada para ejecutar la intención y pueda hacerlo de manera oportuna. Se deben hacer preguntas sobre quiénes son estas partes, cómo se desempeñan y cuáles son sus motivaciones para determinar la eficacia, los supuestos de confianza y las implicaciones más amplias de los sistemas basados en la intención.
El intermediario y su mempool
El canal más obvio para intentar llegar a manos de intermediarios es el mempool de Ethereum. Lamentablemente, el diseño actual no admite la propagación de intenciones. Las preocupaciones sobre los ataques DoS pueden significar que el soporte universal para intenciones completamente genéricas en el mempool de Ethereum es imposible incluso a largo plazo. Como veremos a continuación, la naturaleza abierta y sin permiso de los mempools de Ethereum crea barreras adicionales para la adopción de intenciones.
En ausencia de un mempool de Ethereum, los diseñadores de sistemas de intenciones ahora enfrentan algunos problemas de diseño. Una decisión de alto nivel es si propagar los intentos al conjunto de permisos o proporcionarlos sin permiso para que cualquiera de las partes pueda ejecutar los intentos.
Figura 2: Los intentos fluyen de los usuarios a grupos de intentos autorizados/no autorizados y públicos/privados (intenciones), convertidos en transacciones por intermediarios, y finalmente ingresan al grupo de memoria pública o van directamente a la cadena a través de subastas de estilo MEVBoost
Mempool sin permiso
Un diseño por el que uno podría esforzarse es una API descentralizada que permita que los intentos se propaguen a través de los nodos del sistema, brindando acceso sin permiso a los actores. Esto se ha hecho antes. Por ejemplo, limite las órdenes de chismes entre repetidores de protocolo 0x y póngalas en cadena cuando coincidan. Esta idea también se explora en el contexto de un mempool ERC4337 compartido para combatir los riesgos de centralización y censura. Sin embargo, el diseño de un "grupo de intenciones" sin permiso enfrenta algunos desafíos importantes:
** Anti-DoS: ** Puede ser necesario limitar la funcionalidad de los intentos (intenciones) para evitar ataques.
Propagar incentivos: Para muchas aplicaciones, ejecutar intentos es una actividad rentable. Por lo tanto, los nodos que operan un conjunto de intentos tienen un incentivo para no propagarse, a fin de reducir la contención al ejecutar intentos.
**MEV: **las intenciones se basan en el buen comportamiento de los actores fuera de la cadena para mejorar la calidad de la ejecución, y el uso de un grupo de intenciones público y sin permiso puede tener dificultades. Si una ejecución deficiente es rentable, es probable que un grupo de intentos no autorizados conduzca a ese resultado. Esto es similar a estar atrapado en el mempool de Ethereum hoy y se espera que sea un problema común para las intenciones relacionadas con DeFi. Un posible camino a seguir podría ser grupos de intenciones sin permiso pero encriptados.
"Pool de memoria" permitido
Las API centralizadas de confianza son más resistentes a DoS y no necesitan propagar intenciones. Los modelos creíbles también brindan cierta base para los problemas de MEV. Mientras se mantenga el supuesto de confianza, la calidad de la ejecución debe estar garantizada. Un intermediario de confianza también puede tener una reputación asociada, lo que proporciona algún incentivo para brindar una buena ejecución. Debido a esto, los grupos de intenciones autorizados son atractivos para los desarrolladores de aplicaciones basadas en intenciones a corto plazo. Sin embargo, como todos sabemos, la suposición de confianza fuerte es defectuosa y algo antitética a gran parte del espíritu de blockchain. Estas cuestiones se tratarán a continuación.
solución mixta
Algunas soluciones son mezclas de las anteriores. Por ejemplo, puede haber permiso para propagar, pero no para ejecutar (suponiendo que se mantenga la suposición de confianza), y viceversa. Un ejemplo común de una solución híbrida es una subasta de flujo de pedidos.
La idea de alto nivel detrás de estos diseños es que un usuario que necesita una contraparte puede necesitar distinguir entre mejores y peores contrapartes (por ejemplo, la otra parte que acepta una operación a un precio favorable). El proceso de diseño generalmente incluye una parte confiable que recibe la intención (o las transacciones) del usuario y facilita la subasta en su nombre. Participar en subastas (a veces) no está autorizado.
Estos tipos de diseños tienen sus propios inconvenientes y es probable que sufran muchas de las preocupaciones que rodean a los grupos de intención autorizados, pero hay algunas distinciones importantes que se harán evidentes más adelante.
En pocas palabras: las aplicaciones basadas en intenciones no solo involucran nuevos formatos de mensajes para interactuar con contratos inteligentes, sino que también involucran mecanismos alternativos de propagación de estilo mempool y descubrimiento de contrapartes. Diseñar un mecanismo de descubrimiento y coincidencia de intenciones que sea compatible con incentivos y descentralizado no es trivial.
¿Dónde puedo equivocarme?
Si bien los intentos son un nuevo y emocionante paradigma de transacciones, su adopción generalizada podría significar que se está acelerando la tendencia más amplia de la actividad del usuario que cambia a mempools alternativos. Si no se gestiona adecuadamente, este cambio podría conducir a la centralización y el afianzamiento de los intermediarios que buscan rentas.
El flujo de órdenes
La migración desde el mempool público podría conducir a la centralización de la producción de bloques de Ethereum si los intentos se ejecutan con permiso, pero el conjunto de permisos no se elige con cuidado. *
La gran mayoría de la producción de bloques en Ethereum actualmente se realiza a través de MEV-Boost, una implementación fuera de protocolo de la separación entre proponente y constructor (PBS), y la hoja de ruta actual no da ninguna indicación de que esta interfaz cambie pronto. PBS se basa en la existencia de un mercado competitivo para que los constructores de bloques dirijan MEV al conjunto de validadores. Un problema importante en PBS es la capacidad de los constructores de bloques para obtener acceso exclusivo a las materias primas necesarias para producir bloques valiosos: transacciones e intenciones, también conocidas como "flujo de pedidos". En la jerga de PBS, el acceso autorizado a las intenciones se denominará "Flujo de pedidos exclusivo" (EOF). Como se analiza en este artículo, EOF en las manos equivocadas amenaza la estructura de mercado en la que se basa PBS, ya que la exclusividad en el flujo de pedidos significa un foso contra las fuerzas competitivas.
Los constructores de bloques (o entidades colaboradoras) que controlan la mayoría del flujo de pedidos de Ethereum podrán producir la mayoría de los bloques de la red principal, abriendo un vector para la censura. Dado que la red se basa en la competencia entre los constructores para pasar valor a los validadores (o ser destruida en el futuro), el dominio de un solo constructor constituirá una transferencia de valor de Ethereum a los constructores. La búsqueda de rentas y la censura son, sin duda, amenazas importantes para el protocolo.
confianza
Dado que muchas soluciones requieren confianza en los intermediarios, el desarrollo de nuevas arquitecturas basadas en intenciones se ve obstaculizado por altas barreras de entrada, lo que significa menores tasas de innovación y competencia para garantizar la calidad de la ejecución. *
En el peor de los casos, los usuarios pueden encontrarse en una posición en la que solo una de las partes ejecuta los intentos, como el monopolio de construcción de bloques en la sección anterior. En un mundo así, los monopolios de construcción de bloques podrían extraer rentas, y cualquier nueva propuesta sobre cómo manejar los intentos sería rechazada si los constructores no la adoptaran. Los usuarios individuales pierden poder de negociación frente a un monopolio, un efecto que se exacerba cuando los usuarios utilizan intenciones para proporcionar grados adicionales de libertad a los intermediarios.
Desafortunadamente, el estancamiento del mercado debido a la infraestructura centralizada no incluye preocupaciones sobre un mercado para constructores. Incluso para las empresas de construcción que no son de bloques, las altas barreras de entrada colocan a los intermediarios en una posición sólida, ya que enfrentan poca competencia. Por ejemplo, considere el estado actual del mercado de subastas de flujo de órdenes. Algunas entidades como Flashbots y CoWswap reciben la mayor parte del flujo de pedidos a OFA. El flujo de pedidos se distribuye en gran parte porque estas entidades han existido durante años o están asociadas con entidades acreditadas, lo que significa que han logrado ganar cierto nivel de confianza pública. Si un nuevo diseño de OFA intenta ingresar al mercado, quienquiera que esté ejecutando el nuevo OFA tendrá que dedicar mucho tiempo a convencer a los usuarios y billeteras de que tienen buena reputación y no abusarán de su poder. La necesidad de una campaña tan creíble ciertamente constituye una barrera de entrada sustancial.
El mercado de subastas de flujo de pedidos ha comenzado a ganar terreno recientemente, y queda por ver cómo se desarrollará la competencia, pero el mercado proporciona un ejemplo ilustrativo en el que los mempools autorizados y confiables pueden consagrar a un pequeño número de participantes poderosos, lo que perjudica el mejores intereses de los usuarios.
El formato de intención EIP4337 proporciona otro ejemplo de un mecanismo que es posible para nosotros. Considere un mundo donde ya existe una arquitectura confiable para admitir las intenciones 4337. Si se propone otro formato para las intenciones, tal vez sirviendo a casos de uso adicionales como la funcionalidad de origen cruzado, pero los intermediarios confiables establecidos no adoptan este nuevo formato (después de todo, no tiene mucha adopción y no es relevante para la competencia de su modelo comercial). ), la implementación de nuevos formatos requiere generar confianza en nuevas entidades. Asimismo, nos encontramos en condiciones de innovar y desafiar el statu quo, pero encontramos barreras de entrada basadas en la confianza.
Opacidad
Dado que muchas arquitecturas de intentos requieren que los usuarios renuncien a cierto control sobre sus activos en cadena, y los mempools autorizados implican un grado de impenetrabilidad externa, corremos el riesgo de construir un sistema opaco donde, no está claro cómo o si las expectativas del usuario serán cumplido, y la amenaza para el ecosistema sigue sin descubrirse. *
Las secciones anteriores se ocupan de los riesgos para los usuarios y los protocolos que plantean los desequilibrios de poder en el mercado de flujo de órdenes. Un problema relacionado es que el ecosistema de middleware y mempools que se desarrolla entre los usuarios y la cadena de bloques se vuelve opaco, incluso para los observadores astutos. Esta preocupación es especialmente relevante para las aplicaciones basadas en intenciones que buscan permitir a los usuarios subcontratar decisiones importantes como el enrutamiento de pedidos.
Las situaciones en las que MEV afecta negativamente la ejecución del usuario a menudo se deben a que los ejecutores renuncian a un alto grado de libertad en el comercio (por ejemplo, límites de deslizamiento). Por lo tanto, no es un gran salto de lógica afirmar que las aplicaciones basadas en intenciones que renuncian a mayores grados de libertad deberían diseñar sus sistemas de ejecución con más cuidado. El peor resultado en este sentido es un mundo donde el uso de una aplicación basada en intenciones requiere firmar una intención que desaparece (en un bosque oscuro, por así decirlo) y luego, de alguna manera, implementarlas como transacciones, pero no está claro cómo o por quién se crean las transacciones. Por supuesto, la capacidad de monitorear dichos ecosistemas también está relacionada con las preocupaciones sobre EOF y las defensas basadas en la confianza.
Mitigar el riesgo
El mempool de Ethereum es limitado. Para algunas aplicaciones esto se debe a su falta de privacidad (clips sándwich), para otras se debe a su incapacidad para admitir una gama más amplia de formatos de mensajes. Esto pone a los desarrolladores de billeteras y aplicaciones en un aprieto, ya que deben encontrar alguna forma de conectar a los usuarios a la cadena de bloques y evitar los peligros antes mencionados.
Al examinar las preguntas anteriores, podemos inferir ciertas propiedades de los sistemas ideales. Dicho sistema no debe tener permisos, para que cualquiera pueda hacer coincidir y ejecutar intentos sin sacrificar demasiada calidad de ejecución; genérico, para que la implementación de nuevas aplicaciones no requiera la creación de nuevos grupos de memoria; transparente, para que sea público Informe sobre el proceso de ejecución intenciones y, donde las garantías de privacidad lo permitan, proporcionar datos para realizar auditorías de calidad.
Si bien equipos como Flashbots y Anoma están trabajando en soluciones generales que cumplan con los requisitos anteriores al combinar privacidad y ausencia de permisos, es posible que el sistema ideal no esté listo en el corto plazo. Por lo tanto, las diferentes soluciones que hacen sus propias compensaciones pueden servir mejor para diferentes aplicaciones. Si bien los mecanismos como las listas de crs surgieron en respuesta a muchos de los mismos problemas relacionados con las aplicaciones basadas en transacciones, tal vez no con intención, los dispositivos que permiten a los usuarios recurrir a las transacciones siempre que sea posible serían buenos Mejorar los peores escenarios Una vez más, las aplicaciones que buscan iniciar grupos de intenciones es mejor buscar la generalidad cuando no están autorizados y elegir un intermediario cuidadosamente cuando están autorizados.
En términos generales, pedimos a los diseñadores de aplicaciones basadas en intenciones que consideren detenidamente el impacto fuera de la cadena de sus aplicaciones, ya que estas pueden afectar a comunidades más amplias que solo su base de usuarios. Le pedimos a la comunidad que preste mucha atención al ecosistema fuera de la cadena que lo rodea. Etéreo.
en conclusión
La adopción de intenciones representa un cambio de paradigmas imperativos a declarativos, lo que promete mejorar significativamente la experiencia del usuario y las pérdidas de eficiencia debido a MEV. La necesidad de estas aplicaciones es clara, y muchas aplicaciones basadas en la intención han tenido un uso generalizado durante muchos años.
La mayor adopción de intenciones, impulsada por ERC4337, puede acelerar el paso de los mempools de Ethereum a nuevos lugares. Si bien el movimiento es razonable e inevitable, los diseñadores de aplicaciones basadas en intenciones tienen buenas razones para tener cuidado al diseñar los componentes fuera de la cadena de sus sistemas al desarrollar una infraestructura robusta.
Todavía queda mucha investigación e ingeniería por hacer en este paradigma de transacción naciente y en áreas que no hemos cubierto en este artículo, como el diseño de un lenguaje de expresión para intents que permita la privacidad.
Muchas gracias a DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun y ElijahFox por sus comentarios sobre este artículo, y a AchalSrinivasan por el artículo.
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
Paradigma: El paradigma de las intenciones de las transacciones de Ethereum: arquitectura y riesgos
Autores: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm; Traducción: Golden Finance 0xxz
Introducción
Las discusiones sobre las "intenciones" y sus aplicaciones se han convertido recientemente en un tema candente en la comunidad de Ethereum.
Cuando las transacciones se refieren específicamente a "cómo" se debe realizar una acción, las intenciones se refieren a "cuál" debería ser el resultado esperado de esa acción. Si una transacción dice "haga A primero, luego B, pague C en su totalidad para obtener X", las intenciones dicen "Quiero X y estoy dispuesto a pagar hasta C".
Este paradigma declarativo desbloquea una emocionante experiencia de usuario y mejoras en la eficiencia. A través de las intenciones, los usuarios pueden simplemente expresar un resultado deseado mientras subcontratan la tarea óptima de lograr ese resultado a un tercero experimentado. El concepto de intenciones contrasta con el paradigma de transacción imperativa actual, en el que el usuario especifica explícitamente cada parámetro.
Si bien estas promesas de mejoras brindan pasos muy necesarios para el ecosistema, el diseño basado en la intención en Ethereum también podría tener implicaciones significativas para la infraestructura fuera de la cadena. En particular, existen vínculos importantes con las actividades relacionadas con MEV y el control del mercado. Esta publicación tiene como objetivo proporcionar una breve definición de las intenciones y sus beneficios, una exploración de los riesgos involucrados en su implementación y una discusión de las posibles mitigaciones.
¿Qué son las intenciones?
La forma estándar actual para que los usuarios interactúen con Ethereum es crear y firmar una transacción, un mensaje en un formato específico que proporciona toda la información necesaria para que la máquina virtual de Ethereum (EVM) realice transiciones de estado. Sin embargo, crear transacciones puede ser un asunto complicado. Crear una transacción requiere razonar sobre detalles como una amplia red de contratos inteligentes y administración de nonce, mientras se mantienen activos específicos para pagar las tarifas de gas. Esta complejidad da como resultado una experiencia de usuario subóptima y una pérdida de eficiencia, ya que los usuarios se ven obligados a tomar decisiones sin un acceso adecuado a la información o políticas de cumplimiento complejas.
Las intenciones están diseñadas para aliviar estas cargas sobre el usuario. De manera informal, las intenciones firman un conjunto de restricciones declarativas que permiten a los usuarios externalizar la creación de transacciones a terceros sin ceder el control total de las partes de la transacción.
En los procesos estándar basados en transacciones, las firmas de transacciones permiten a los verificadores seguir exactamente una ruta computacional para un estado en particular y las sugerencias incentivan a los verificadores a hacerlo. Las intenciones, por otro lado, no especifican explícitamente la ruta computacional que debe tomarse, pero permiten cualquier ruta computacional que satisfaga ciertas restricciones. Al firmar y compartir intentos (intentos), los usuarios otorgan efectivamente a los destinatarios permiso para elegir rutas de cómputo en su nombre (consulte el diagrama a continuación). Esta distinción permite una definición algo más estricta de las intenciones como mensajes firmados que permiten un conjunto de transiciones de estado desde un estado inicial dado, con un caso especial de transacciones que permiten transiciones únicas. Dicho esto, seguiremos distinguiendo las "intenciones" de las transacciones.
Es importante destacar que se pueden incluir muchos intentos (intentos) en una sola transacción, lo que permite la coincidencia de intentos superpuestos (intentos), aumentando la eficiencia económica y de gas, por ejemplo, en el libro de pedidos mantenido por el constructor, dos pedidos pueden intercambiarse mutuamente antes de ingresar al compensación de mercado. Otras aplicaciones incluyen intentos de dominios cruzados (intentos): firmar un mensaje en lugar de múltiples transacciones en diferentes dominios, usar diferentes esquemas de resistencia a la reproducción (resistencia a la reproducción) y pagos de gas de usuario más flexibles, como permitir que las primeras 3 partes patrocinen gas o paguen en diferentes fichas.
pasado y futuro de intentos
Se han creado intentos que subcontratan la complejidad de interactuar con la cadena de bloques, al tiempo que permiten a los usuarios mantener la custodia de sus activos e identidades criptográficas.
Puede notar que muchas de estas ideas corresponden a sistemas que han estado en funcionamiento durante muchos años:
En el futuro, en el contexto de MEV de cadena cruzada (como SUAVE), abstracciones de cuentas de estilo ERC4337 e incluso órdenes de Seaport, ¡las intenciones de las personas se están revitalizando! Si bien ERC4337 avanza a toda velocidad, otras aplicaciones novedosas, como las intenciones entre dominios, aún requieren más investigación.
De manera crucial, en todas las aplicaciones basadas en la intención, antiguas y nuevas, debe haber al menos otra parte que comprenda la intención, esté motivada para ejecutar la intención y pueda hacerlo de manera oportuna. Se deben hacer preguntas sobre quiénes son estas partes, cómo se desempeñan y cuáles son sus motivaciones para determinar la eficacia, los supuestos de confianza y las implicaciones más amplias de los sistemas basados en la intención.
El intermediario y su mempool
El canal más obvio para intentar llegar a manos de intermediarios es el mempool de Ethereum. Lamentablemente, el diseño actual no admite la propagación de intenciones. Las preocupaciones sobre los ataques DoS pueden significar que el soporte universal para intenciones completamente genéricas en el mempool de Ethereum es imposible incluso a largo plazo. Como veremos a continuación, la naturaleza abierta y sin permiso de los mempools de Ethereum crea barreras adicionales para la adopción de intenciones.
En ausencia de un mempool de Ethereum, los diseñadores de sistemas de intenciones ahora enfrentan algunos problemas de diseño. Una decisión de alto nivel es si propagar los intentos al conjunto de permisos o proporcionarlos sin permiso para que cualquiera de las partes pueda ejecutar los intentos.
Figura 2: Los intentos fluyen de los usuarios a grupos de intentos autorizados/no autorizados y públicos/privados (intenciones), convertidos en transacciones por intermediarios, y finalmente ingresan al grupo de memoria pública o van directamente a la cadena a través de subastas de estilo MEVBoost
Mempool sin permiso
Un diseño por el que uno podría esforzarse es una API descentralizada que permita que los intentos se propaguen a través de los nodos del sistema, brindando acceso sin permiso a los actores. Esto se ha hecho antes. Por ejemplo, limite las órdenes de chismes entre repetidores de protocolo 0x y póngalas en cadena cuando coincidan. Esta idea también se explora en el contexto de un mempool ERC4337 compartido para combatir los riesgos de centralización y censura. Sin embargo, el diseño de un "grupo de intenciones" sin permiso enfrenta algunos desafíos importantes:
"Pool de memoria" permitido
Las API centralizadas de confianza son más resistentes a DoS y no necesitan propagar intenciones. Los modelos creíbles también brindan cierta base para los problemas de MEV. Mientras se mantenga el supuesto de confianza, la calidad de la ejecución debe estar garantizada. Un intermediario de confianza también puede tener una reputación asociada, lo que proporciona algún incentivo para brindar una buena ejecución. Debido a esto, los grupos de intenciones autorizados son atractivos para los desarrolladores de aplicaciones basadas en intenciones a corto plazo. Sin embargo, como todos sabemos, la suposición de confianza fuerte es defectuosa y algo antitética a gran parte del espíritu de blockchain. Estas cuestiones se tratarán a continuación.
solución mixta
Algunas soluciones son mezclas de las anteriores. Por ejemplo, puede haber permiso para propagar, pero no para ejecutar (suponiendo que se mantenga la suposición de confianza), y viceversa. Un ejemplo común de una solución híbrida es una subasta de flujo de pedidos.
La idea de alto nivel detrás de estos diseños es que un usuario que necesita una contraparte puede necesitar distinguir entre mejores y peores contrapartes (por ejemplo, la otra parte que acepta una operación a un precio favorable). El proceso de diseño generalmente incluye una parte confiable que recibe la intención (o las transacciones) del usuario y facilita la subasta en su nombre. Participar en subastas (a veces) no está autorizado.
Estos tipos de diseños tienen sus propios inconvenientes y es probable que sufran muchas de las preocupaciones que rodean a los grupos de intención autorizados, pero hay algunas distinciones importantes que se harán evidentes más adelante.
En pocas palabras: las aplicaciones basadas en intenciones no solo involucran nuevos formatos de mensajes para interactuar con contratos inteligentes, sino que también involucran mecanismos alternativos de propagación de estilo mempool y descubrimiento de contrapartes. Diseñar un mecanismo de descubrimiento y coincidencia de intenciones que sea compatible con incentivos y descentralizado no es trivial.
¿Dónde puedo equivocarme?
Si bien los intentos son un nuevo y emocionante paradigma de transacciones, su adopción generalizada podría significar que se está acelerando la tendencia más amplia de la actividad del usuario que cambia a mempools alternativos. Si no se gestiona adecuadamente, este cambio podría conducir a la centralización y el afianzamiento de los intermediarios que buscan rentas.
El flujo de órdenes
La gran mayoría de la producción de bloques en Ethereum actualmente se realiza a través de MEV-Boost, una implementación fuera de protocolo de la separación entre proponente y constructor (PBS), y la hoja de ruta actual no da ninguna indicación de que esta interfaz cambie pronto. PBS se basa en la existencia de un mercado competitivo para que los constructores de bloques dirijan MEV al conjunto de validadores. Un problema importante en PBS es la capacidad de los constructores de bloques para obtener acceso exclusivo a las materias primas necesarias para producir bloques valiosos: transacciones e intenciones, también conocidas como "flujo de pedidos". En la jerga de PBS, el acceso autorizado a las intenciones se denominará "Flujo de pedidos exclusivo" (EOF). Como se analiza en este artículo, EOF en las manos equivocadas amenaza la estructura de mercado en la que se basa PBS, ya que la exclusividad en el flujo de pedidos significa un foso contra las fuerzas competitivas.
Los constructores de bloques (o entidades colaboradoras) que controlan la mayoría del flujo de pedidos de Ethereum podrán producir la mayoría de los bloques de la red principal, abriendo un vector para la censura. Dado que la red se basa en la competencia entre los constructores para pasar valor a los validadores (o ser destruida en el futuro), el dominio de un solo constructor constituirá una transferencia de valor de Ethereum a los constructores. La búsqueda de rentas y la censura son, sin duda, amenazas importantes para el protocolo.
confianza
En el peor de los casos, los usuarios pueden encontrarse en una posición en la que solo una de las partes ejecuta los intentos, como el monopolio de construcción de bloques en la sección anterior. En un mundo así, los monopolios de construcción de bloques podrían extraer rentas, y cualquier nueva propuesta sobre cómo manejar los intentos sería rechazada si los constructores no la adoptaran. Los usuarios individuales pierden poder de negociación frente a un monopolio, un efecto que se exacerba cuando los usuarios utilizan intenciones para proporcionar grados adicionales de libertad a los intermediarios.
Desafortunadamente, el estancamiento del mercado debido a la infraestructura centralizada no incluye preocupaciones sobre un mercado para constructores. Incluso para las empresas de construcción que no son de bloques, las altas barreras de entrada colocan a los intermediarios en una posición sólida, ya que enfrentan poca competencia. Por ejemplo, considere el estado actual del mercado de subastas de flujo de órdenes. Algunas entidades como Flashbots y CoWswap reciben la mayor parte del flujo de pedidos a OFA. El flujo de pedidos se distribuye en gran parte porque estas entidades han existido durante años o están asociadas con entidades acreditadas, lo que significa que han logrado ganar cierto nivel de confianza pública. Si un nuevo diseño de OFA intenta ingresar al mercado, quienquiera que esté ejecutando el nuevo OFA tendrá que dedicar mucho tiempo a convencer a los usuarios y billeteras de que tienen buena reputación y no abusarán de su poder. La necesidad de una campaña tan creíble ciertamente constituye una barrera de entrada sustancial.
El mercado de subastas de flujo de pedidos ha comenzado a ganar terreno recientemente, y queda por ver cómo se desarrollará la competencia, pero el mercado proporciona un ejemplo ilustrativo en el que los mempools autorizados y confiables pueden consagrar a un pequeño número de participantes poderosos, lo que perjudica el mejores intereses de los usuarios.
El formato de intención EIP4337 proporciona otro ejemplo de un mecanismo que es posible para nosotros. Considere un mundo donde ya existe una arquitectura confiable para admitir las intenciones 4337. Si se propone otro formato para las intenciones, tal vez sirviendo a casos de uso adicionales como la funcionalidad de origen cruzado, pero los intermediarios confiables establecidos no adoptan este nuevo formato (después de todo, no tiene mucha adopción y no es relevante para la competencia de su modelo comercial). ), la implementación de nuevos formatos requiere generar confianza en nuevas entidades. Asimismo, nos encontramos en condiciones de innovar y desafiar el statu quo, pero encontramos barreras de entrada basadas en la confianza.
Opacidad
Las secciones anteriores se ocupan de los riesgos para los usuarios y los protocolos que plantean los desequilibrios de poder en el mercado de flujo de órdenes. Un problema relacionado es que el ecosistema de middleware y mempools que se desarrolla entre los usuarios y la cadena de bloques se vuelve opaco, incluso para los observadores astutos. Esta preocupación es especialmente relevante para las aplicaciones basadas en intenciones que buscan permitir a los usuarios subcontratar decisiones importantes como el enrutamiento de pedidos.
Las situaciones en las que MEV afecta negativamente la ejecución del usuario a menudo se deben a que los ejecutores renuncian a un alto grado de libertad en el comercio (por ejemplo, límites de deslizamiento). Por lo tanto, no es un gran salto de lógica afirmar que las aplicaciones basadas en intenciones que renuncian a mayores grados de libertad deberían diseñar sus sistemas de ejecución con más cuidado. El peor resultado en este sentido es un mundo donde el uso de una aplicación basada en intenciones requiere firmar una intención que desaparece (en un bosque oscuro, por así decirlo) y luego, de alguna manera, implementarlas como transacciones, pero no está claro cómo o por quién se crean las transacciones. Por supuesto, la capacidad de monitorear dichos ecosistemas también está relacionada con las preocupaciones sobre EOF y las defensas basadas en la confianza.
Mitigar el riesgo
El mempool de Ethereum es limitado. Para algunas aplicaciones esto se debe a su falta de privacidad (clips sándwich), para otras se debe a su incapacidad para admitir una gama más amplia de formatos de mensajes. Esto pone a los desarrolladores de billeteras y aplicaciones en un aprieto, ya que deben encontrar alguna forma de conectar a los usuarios a la cadena de bloques y evitar los peligros antes mencionados.
Al examinar las preguntas anteriores, podemos inferir ciertas propiedades de los sistemas ideales. Dicho sistema no debe tener permisos, para que cualquiera pueda hacer coincidir y ejecutar intentos sin sacrificar demasiada calidad de ejecución; genérico, para que la implementación de nuevas aplicaciones no requiera la creación de nuevos grupos de memoria; transparente, para que sea público Informe sobre el proceso de ejecución intenciones y, donde las garantías de privacidad lo permitan, proporcionar datos para realizar auditorías de calidad.
Si bien equipos como Flashbots y Anoma están trabajando en soluciones generales que cumplan con los requisitos anteriores al combinar privacidad y ausencia de permisos, es posible que el sistema ideal no esté listo en el corto plazo. Por lo tanto, las diferentes soluciones que hacen sus propias compensaciones pueden servir mejor para diferentes aplicaciones. Si bien los mecanismos como las listas de crs surgieron en respuesta a muchos de los mismos problemas relacionados con las aplicaciones basadas en transacciones, tal vez no con intención, los dispositivos que permiten a los usuarios recurrir a las transacciones siempre que sea posible serían buenos Mejorar los peores escenarios Una vez más, las aplicaciones que buscan iniciar grupos de intenciones es mejor buscar la generalidad cuando no están autorizados y elegir un intermediario cuidadosamente cuando están autorizados.
En términos generales, pedimos a los diseñadores de aplicaciones basadas en intenciones que consideren detenidamente el impacto fuera de la cadena de sus aplicaciones, ya que estas pueden afectar a comunidades más amplias que solo su base de usuarios. Le pedimos a la comunidad que preste mucha atención al ecosistema fuera de la cadena que lo rodea. Etéreo.
en conclusión
La adopción de intenciones representa un cambio de paradigmas imperativos a declarativos, lo que promete mejorar significativamente la experiencia del usuario y las pérdidas de eficiencia debido a MEV. La necesidad de estas aplicaciones es clara, y muchas aplicaciones basadas en la intención han tenido un uso generalizado durante muchos años.
La mayor adopción de intenciones, impulsada por ERC4337, puede acelerar el paso de los mempools de Ethereum a nuevos lugares. Si bien el movimiento es razonable e inevitable, los diseñadores de aplicaciones basadas en intenciones tienen buenas razones para tener cuidado al diseñar los componentes fuera de la cadena de sus sistemas al desarrollar una infraestructura robusta.
Todavía queda mucha investigación e ingeniería por hacer en este paradigma de transacción naciente y en áreas que no hemos cubierto en este artículo, como el diseño de un lenguaje de expresión para intents que permita la privacidad.
Muchas gracias a DanRobinson, CharlieNoyes, MattHuang, JohnGuibas, XinyuanSun y ElijahFox por sus comentarios sobre este artículo, y a AchalSrinivasan por el artículo.