Paradigma: arquitectura basada en intenciones y sus riesgos

Escrito por: Quintus Kilbourn, Georgios Konstantopoulos Compilado por: Kate, Marsbit

introducir

Las discusiones sobre las "intenciones" y sus aplicaciones se han convertido recientemente en un tema candente en la comunidad Ethereum.

Cuando las transacciones se refieren explícitamente a "cómo" se debe realizar una acción, la intención se refiere a cuál debería ser el resultado esperado de esa acción. Si el contenido de la transacción es "hacer A primero, luego B, pagar C para obtener X", entonces la intención es "Quiero X y estoy dispuesto a pagar C".

Este paradigma declarativo aporta mejoras interesantes en la experiencia y la eficiencia del usuario. Con las intenciones, los usuarios pueden simplemente expresar un resultado deseado mientras subcontratan la tarea de lograr de manera óptima ese resultado a un tercero con experiencia. El concepto de intención contrasta con el paradigma de transacción imperativo actual, donde cada parámetro es especificado explícitamente por el usuario.

Si bien la promesa de estas mejoras proporciona un paso adelante muy necesario para el ecosistema, el diseño basado en intenciones en Ethereum también podría tener implicaciones importantes para la infraestructura fuera de la cadena. En particular, existen vínculos importantes entre las actividades relacionadas con los MEV y el control del mercado. Este artículo tiene como objetivo proporcionar una breve definición de intención y sus beneficios, explorar los riesgos involucrados en su implementación y discutir posibles mitigaciones.

¿Qué es una intención?

La forma estándar actual para que los usuarios interactúen con Ethereum es crear y firmar transacciones que proporcionen toda la información necesaria en un formato específico para que la Máquina Virtual 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 vasta red de contratos inteligentes y gestión nonce, mientras se mantiene un activo específico para pagar las tarifas del 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 aplicación complejas.

Existe la intención de aliviar estas cargas. De manera informal, las intenciones se firman como un conjunto de restricciones declarativas que permiten a los usuarios subcontratar la creación de transacciones a terceros sin renunciar al control total de las partes de la transacción.

En los procesos estándar basados en transacciones, las firmas de transacciones permiten a los validadores seguir exactamente una ruta computacional para un estado, y las sugerencias incentivan a los validadores a hacerlo. Las intenciones, por otro lado, no especifican la ruta computacional que se debe tomar, pero permiten cualquier ruta computacional que satisfaga ciertas restricciones. Al firmar y compartir intenciones, los usuarios otorgan efectivamente permisos a los destinatarios para elegir rutas de cálculo en su nombre (consulte el diagrama a continuación). Esta distinción permite una definición ligeramente más estricta de intenciones como mensajes firmados, lo que permite un conjunto de transiciones de estado desde un estado inicial determinado; un caso especial son las transacciones que permiten transiciones únicas. Dicho esto, seguiremos distinguiendo la "intención" de las transacciones.

*Figura 1: Al enviar una transacción, el usuario especifica la ruta de cálculo exacta. Al enviar una intención, el usuario especifica un objetivo y algunas restricciones, y luego el proceso de comparación decide la ruta computacional a seguir. *

Es importante destacar que se pueden incluir muchas intenciones en una sola transacción, lo que permite igualar intenciones superpuestas, lo que aumenta la eficiencia económica y del gas; por ejemplo, en una cartera de pedidos mantenida por un constructor, dos órdenes pueden cancelarse entre sí antes de ingresar al mercado. Otras aplicaciones incluyen intenciones entre dominios (firmar un solo mensaje, en lugar de múltiples transacciones en diferentes dominios), usar diferentes esquemas de resistencia a la repetición y pagos de gas de usuario más flexibles, como permitir que terceros patrocinen el gas o paguen el gas en diferentes pagos de Token. .

pasado y futuro son intenciones

Se creó la intención de subcontratar la complejidad de interactuar con la cadena de bloques, al tiempo que se permite a los usuarios mantener la custodia de sus activos e identidades criptográficas.

Podrás notar que muchas de estas ideas corresponden a sistemas que llevan muchos años en funcionamiento:

• Orden límite: 100X se pueden debitar de mi cuenta si recibo al menos 200Y.
• Subastas estilo CowSwap: Igual que el anterior, pero dependen de un tercero o mecanismo para igualar muchas órdenes y maximizar la calidad de la ejecución.
• Patrocinio de Gas: Pague el Gas con USDC en lugar de ETH. Esta intención solo puede cumplirse mediante una intención coincidente que pague una tarifa a ETH.
• Autorización: solo permita la interacción con determinadas cuentas de determinadas formas previamente autorizadas. Una intención sólo se puede cumplir si la transacción resultante obedece la lista de control de acceso especificada en la intención.
• Lotes de transacciones: permite el procesamiento por lotes de intenciones para mejorar la eficiencia y reducir las tarifas del gas.
• Agregadores: operan utilizando sólo 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, la intención se está revitalizando en el contexto de MEV de cadena cruzada (como SUAVE), abstracciones de cuentas estilo ERC4337 e incluso pedidos en puertos marítimos. Si bien ERC4337 avanza a toda velocidad, otras aplicaciones novedosas, como las intenciones entre dominios, aún requieren más investigación. En esta charla se puede encontrar más información sobre los intentos y sus aplicaciones.

Fundamentalmente, en todas las aplicaciones basadas en intenciones, antiguas y nuevas, es necesario que haya al menos otra parte que comprenda la intención, esté motivada para ejecutarla y sea capaz de ejecutarla de manera oportuna. Quiénes son estas partes, cómo se lleva a cabo la ejecución y cuáles son sus motivaciones son preguntas que deben plantearse para determinar la eficacia, los supuestos de confianza y las implicaciones más amplias de los sistemas basados en intenciones.

El intermediario y su mempool

El canal más obvio es el mempool de Ethereum. Desafortunadamente, el diseño actual no admite la propagación de intenciones. Las preocupaciones sobre los ataques DoS pueden significar que el soporte general para una intención totalmente general en el mempool de Ethereum sea imposible, incluso a largo plazo. Como veremos a continuación, la naturaleza abierta y sin permisos del mempool de Ethereum presenta una barrera adicional para las intenciones de adopción.

En ausencia de un mempool de Ethereum, los diseñadores de sistemas de intención ahora enfrentan algunos problemas de diseño. Una decisión de alto nivel es si propagar la intención a un conjunto autorizado o proporcionarla sin permiso para que cualquiera de las partes pueda ejecutar la intención.

Figura 2: Las intenciones fluyen de los usuarios a los grupos de intenciones con permiso/sin permiso y públicos/privados, convertidas por los casamenteros en transacciones y, finalmente, en grupos de memoria pública o directamente en la cadena a través de subastas de estilo MEV boost

Grupo de memoria sin licencia

Un diseño por el que se podría aspirar es una API descentralizada que permita propagar la intención a través de los nodos del sistema, proporcionando a los ejecutores acceso sin permiso. Esto se ha hecho antes. Por ejemplo, en el protocolo 0x, los retransmisores limitan las órdenes entre ellos y las colocan en la cadena cuando hay una coincidencia. Esta idea también se exploró 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:

• Resistencia DoS: puede ser necesario limitar la funcionalidad de los intents para evitar vectores de ataque (consulte la propuesta ER C4337 para mayor discusión)
• Propagar incentivos: para muchas aplicaciones, hacer cumplir la intención es una actividad rentable. Por lo tanto, los nodos que operan el grupo de intenciones tienen un incentivo para no propagar las intenciones para reducir la contención al ejecutar las intenciones.
• MEV: Los intentos dependen del buen comportamiento de los actores fuera de la cadena para mejorar la calidad de la ejecución, lo que puede resultar difícil cuando se utilizan grupos de intentos públicos y sin permiso. Si una mala ejecución es rentable, es probable que los grupos de intenciones sin permiso conduzcan a ese resultado. Esto es similar a los mempools de Ethereum actuales y se espera que se convierta en un problema común relacionado con DeFi. Un posible camino a seguir aquí podrían ser grupos de intenciones sin permiso pero cifrados.

"grupos de memoria" permitidos

Las API centralizadas confiables son más resistentes a los ataques DoS y no necesitan propagar la intención. Los modelos de confianza también proporcionan cierta base para los problemas de MEV. Mientras se mantenga el supuesto de confianza, se debe garantizar la calidad de la ejecución. Los intermediarios confiables también pueden tener una reputación asociada, lo que les proporciona un incentivo para ejecutar bien. Por lo tanto, los grupos de intenciones autorizados resultan atractivos a corto plazo para los desarrolladores de aplicaciones basadas en intenciones. Sin embargo, todos somos conscientes de que la suposición de una fuerte confianza es errónea y algo antitética para gran parte del espíritu de las cadenas de bloques. Estas cuestiones se analizan a continuación.

Solución híbrida

Algunas soluciones son mezclas de las anteriores. Por ejemplo, puede haber permiso para propagarse, pero no permiso para ejecutar (suponiendo que se cumpla el supuesto de confianza), y viceversa. Un ejemplo común de solución híbrida es una subasta de flujo de órdenes.

La idea de alto nivel detrás de estos diseños es que los usuarios que necesitan contrapartes pueden necesitar distinguir entre contrapartes mejores y peores (por ejemplo, la otra parte que acepta una operación a un precio favorable). Los flujos de diseño suelen incluir una parte de confianza que recibe intenciones (o transacciones) de los usuarios y facilita las subastas en nombre de los usuarios. Participar en subastas (a veces) no requiere permiso.

Estos tipos de diseños tienen sus propios inconvenientes y es probable que se vean afectados por muchos grupos de intenciones de permiso, pero existen 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 de propagación y descubrimiento de adversarios en forma de mempools alternativos. Diseñar un mecanismo de descubrimiento y coincidencia de intenciones que sea compatible con incentivos y al mismo tiempo descentralizado no es trivial.

¿Dónde puedo equivocarme?

Si bien los intents son un nuevo y emocionante paradigma de transacciones, su adopción generalizada podría significar acelerar una tendencia más amplia de trasladar la actividad de los usuarios a otros mempools. Si no se gestiona adecuadamente, este cambio podría conducir a la centralización y al afianzamiento de intermediarios rentistas.

El flujo de órdenes

La migración desde el mempool público podría centralizar la producción de bloques de Ethereum si se permite la ejecución de la intención y el conjunto de permisos no se elige con cuidado.

La migración desde el mempool público podría centralizar la producción de bloques en Ethereum si se permite la ejecución de la intención, pero el conjunto de permisos no se elige con cuidado.

La gran mayoría de la producción de bloques en Ethereum se produce actualmente a través de MEV-Boost, una implementación fuera del protocolo de 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 depende de la existencia de un mercado competitivo para que los constructores de bloques dirijan MEV al conjunto de validadores. Un problema importante con PBS es que los constructores de bloques obtienen acceso exclusivo a las materias primas necesarias para producir bloques valiosos: transacciones e intención, también conocido como "flujo de pedidos". En el lenguaje de PBS, el acceso autorizado a los intents se conoce como flujo de órdenes exclusivo (EOF). Como se analiza en este artículo, un EOF en manos de la parte equivocada amenaza la estructura de mercado en la que se basa PBS, ya que la exclusividad del flujo de pedidos implica un foso contra las fuerzas competitivas.

Los constructores de bloques (o entidades colaboradoras) que controlan la mayor parte del flujo de pedidos de Ethereum podrán producir la mayoría de los bloques de la red principal, abriendo una vía para la censura. Dado que la red depende de la competencia entre los constructores para pasar valor a los validadores (o ser quemada 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, por supuesto, amenazas importantes al protocolo.

confianza

Dado que muchas soluciones requieren confianza en un intermediario, 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 se encuentran en una posición en la que sólo una de las partes ejecuta la intención, como el constructor de bloques de monopolio de la sección anterior. En un mundo así, los constructores de bloques monopolísticos podrían obtener rentas, y cualquier nueva propuesta sobre cómo manejar la intención sería rechazada si los constructores no la adoptan. Los usuarios individuales pierden poder de negociación frente a un monopolio, efecto que se exacerba cuando los usuarios intentan dar grados adicionales de libertad a los intermediarios.

Desafortunadamente, el estancamiento del mercado debido a la infraestructura centralizada no incluye preocupaciones sobre un mercado para los constructores. Incluso para las empresas de construcción que no son de bloques, una barrera de entrada alta puede colocar a los intermediarios en una posición ventajosa, 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ía de los pedidos que llegan a OFA. El flujo de pedidos se distribuye en gran parte porque estas entidades existen desde hace años o están asociadas con entidades de buena reputación, lo que significa que han logrado ganarse cierto nivel de confianza pública. Si un nuevo diseño de OFA intenta ingresar al mercado, quienquiera que lo ejecute tendrá que dedicar mucho tiempo a convencer a los usuarios y a las billeteras de que tienen buena reputación y no abusarán de su poder. Esta necesidad de ganarse la confianza ciertamente plantea una importante barrera de entrada.

El mercado de subastas de flujo de órdenes recién ha comenzado a ganar terreno, y aún está por ver cómo se desarrollará la competencia, pero el mercado proporciona un ejemplo ilustrativo en el que los mempools autorizados y confiables pueden contener un pequeño número de participantes poderosos, perjudicando así la mejores intereses de los usuarios.

El formato de intención EIP4337 proporciona otro ejemplo de un mecanismo que es posible. Considere un mundo donde existen arquitecturas confiables para admitir 4337 intenciones. Si se propusiera otro formato de intención, podría servir para otros casos de uso, como la funcionalidad de origen cruzado, pero los intermediarios confiables establecidos no adoptan este nuevo formato (después de todo, no obtiene mucha adopción y compite con su modelo de negocio), implementaciones del nuevo formato deberá generar confianza en la nueva entidad. Una vez más, nos encontramos en una situación en la que la innovación y el desafío al status quo encuentran barreras de entrada basadas en la confianza.

Opacidad

Dado que muchas arquitecturas de intención requieren que los usuarios renuncien a cierto control sobre sus activos en la cadena, y los mempools autorizados implican un grado de impermeabilidad desde el exterior, corremos el riesgo de construir un sistema opaco en el que no está claro qué esperan los usuarios o si se cumple. y las amenazas al ecosistema siguen sin detectarse.

Las secciones anteriores abordan los riesgos que los desequilibrios de poder en los mercados de flujo de orden representan para los usuarios y los protocolos. Un problema relacionado es que el ecosistema de middleware y mempools desarrollado entre los usuarios y la cadena de bloques se vuelve opaco incluso para los observadores más atentos. Este problema se aplica especialmente a las aplicaciones basadas en intenciones que intentan 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 las transacciones otorgan un alto grado de libertad a sus ejecutores (por ejemplo, límites de deslizamiento). Por lo tanto, no es un gran salto lógico afirmar que las aplicaciones basadas en intenciones que renuncian a mayores grados de libertad deberían diseñar más cuidadosamente sus sistemas para su ejecución. El peor resultado en este sentido es que el uso de una aplicación basada en intenciones requiere firmar una intención que desaparece (en un bosque oscuro, si se prefiere), que luego de alguna manera se implementa como una transacción sin que esté claro cómo o quién la creó. Por supuesto, la capacidad de monitorear tales ecosistemas también está relacionada con las preocupaciones sobre el EOF y las defensas basadas en la confianza. Si este ecosistema es turbio para los observadores más entusiastas, ¿cómo se supone que la comunidad Ethereum debe monitorear las amenazas a la salud de su ecosistema de producción de bloques?

Mitigar el riesgo

El mempool de Ethereum es limitado. Para algunas aplicaciones, esto se debe a su falta de privacidad (intercalada en el medio) y para otras, 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 manera de conectar a los usuarios a la cadena de bloques evitando al mismo tiempo los peligros antes mencionados.

Al examinar las preguntas anteriores, podemos inferir ciertas propiedades de los sistemas ideales. Un sistema así debería ser

Sin permiso para que cualquiera pueda hacer coincidir y ejecutar intenciones 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 el proceso de informar la ejecución de intenciones se informe públicamente cuando las garantías de privacidad lo permitan y proporcione 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 combinando privacidad y falta de permisos, es posible que el sistema ideal no esté listo pronto. Por lo tanto, diferentes soluciones hacen sus propias compensaciones que pueden servir mejor a diferentes aplicaciones. Si bien mecanismos como crlists surgieron en respuesta a muchos de los mismos problemas que rodean a las aplicaciones basadas en transacciones, y pueden no ser aplicables a la intención, un dispositivo que permita a los usuarios recurrir a las transacciones siempre que sea posible haría bien en mejorar el peor de los casos. Del mismo modo, las aplicaciones que deseen iniciar un grupo de intenciones, si no están autorizadas, hacen bien en buscar puntos en común y, si lo hacen, elegir intermediarios con cuidado.

En términos generales, pedimos a los diseñadores de aplicaciones basadas en intenciones que consideren plenamente el impacto fuera de la cadena de sus aplicaciones, porque pueden afectar a la comunidad en general, no solo a su base de usuarios, y pedimos a la comunidad en general que se centre de cerca en lo fuera de la cadena. ecosistema alrededor de Ethereum.

en conclusión

La adopción de intents representa un cambio de un paradigma imperativo a uno declarativo, que promete mejorar significativamente la experiencia del usuario y las pérdidas de eficiencia debido a las fugas de MEV. La necesidad de estas aplicaciones es clara y muchas aplicaciones basadas en intenciones se han utilizado ampliamente durante muchos años.

La creciente intención de adoptar, impulsada por ERC4337, puede acelerar la transferencia de mempools de Ethereum a nuevos lugares. Si bien este cambio es razonable e inevitable, los diseñadores de aplicaciones basadas en intenciones tienen buenas razones para diseñar cuidadosamente los componentes fuera de la cadena de sus sistemas al desarrollar una infraestructura sólida.

Todavía queda mucha investigación e ingeniería por hacer en este incipiente paradigma transaccional y en áreas que no cubrimos en este documento, como el diseño de un lenguaje de expresión de intención que permita la privacidad. Si encuentra interesante este u otros temas de investigación relacionados con la intención, comuníquese con 0xquintus georgios@paradigm.xyz.

*Muchas gracias a Dan Robinson, Charlie Noyes, Matt Huang, John gu, Xinyuan Sun y Elijah Fox por sus comentarios sobre este artículo, y a Achal Srinivasan por diseñar los gráficos. *