Agenda

El Problema

1. Definir el estado final: ¿qué hace que las aplicaciones de cripto sean "utilizables"

2. ¿Por qué la "abstracción de cadena" es una solución a un problema de UX que surge de la topología fundamental de las blockchains modulares

3. Por qué las aplicaciones criptográficas utilizables deben construirse sobre la infraestructura de abstracción de cadena

El Espacio de Soluciones

1. Cómo la arquitectura basada en la intención dará lugar a la abstracción de la cadena

2. Comprender que los mercados de intención funcionan mejor cuando la red de solucionadores es grande y competitiva

3. Iniciar la red del solucionador de intenciones requiere incorporar más aplicaciones que producirán intenciones

La Propuesta

1. Por qué necesitamos un estándar de intenciones entre cadenas que priorice la 'UX del solucionador' para hacer crecer el mercado de solucionadores e intenciones lo suficiente como para lograr efectos de red

Las aplicaciones criptográficas utilizables no pueden construirse sin abstracción de cadena

¿Están nuestros mejores y más brillantes construyendo infraestructura redundante?

Muchos han lamentado que los mejores ingenieros de criptomonedas y pensadores más centrados estén sobrealocando atención y energía hacia ofrecer más espacio de bloque a los usuarios finales. Esta crítica tiene mérito; hay demasiados L2 disponibles para los usuarios finales en comparación con la demanda de ellos.

Sin embargo, rechazo la noción de que no existan aplicaciones criptográficas útiles en la actualidad.

Las finanzas descentralizadas ofrecen a las personas la capacidad de autocustodiar activos digitales, lo que les permite eludir a proveedores de servicios draconianos y usar sus activos digitales para comprar cosas valoradas en el mundo real. La promesa de los datos autocustodiados también ofrece una alternativa utópica para las personas que se vuelven cada vez más cautelosas a la hora de confiar en los monopolios FAANG para mantener sus datos seguros.

El verdadero problema, en mi opinión, no es la falta de aplicaciones criptográficas útiles, sino la fricción para los usuarios finales que intentan acceder a ellas. Los usuarios finales deberían poder experimentar lo siguiente al interactuar con aplicaciones criptográficas:

1. Velocidad: Las aplicaciones deben sentirse tan rápidas como las aplicaciones web2.
2. Costo: A diferencia de web2, todas las interacciones web3 deben incurrir en algún costo, pero el "costo por clic" debería ser despreciable.
3. Resistencia a la censura ("permiso para no tener permiso"): Cualquiera con una billetera debería poder interactuar con la aplicación si puede permitirse hacer clic.
4. Seguridad: Los clics deben hacer lo que los usuarios esperan que hagan y no revertir, todas las actualizaciones web3 deben ser permanentes.

Estas son las propiedades de las aplicaciones de cripto "utilizables".

Hemos estado tratando de construir una criptomoneda utilizable durante mucho tiempo

Las soluciones modulares de blockchain de hoy ofrecen a los consumidores todas estas propiedades, pero no todas están disponibles en el mismo lugar.

En 2020, las blockchains eran monolíticas, ofreciendo dos de las tres propiedades a los usuarios finales: velocidad, costo o seguridad. Entonces imaginamos un futuro centrado en rollup o modularque desbloquearía las tres propiedades simultáneamente.

Hoy, hemos construido las bases para esta infraestructura centrada en rollup. L2 ofrece espacio de bloque barato y rápido, y la mayoría de ellos ofrecen espacio de bloque sin permisos. Por el contrario, L1 ofrece espacio de bloque seguro y resistente a la Tercera Guerra Mundial. (Puedes leer más sobre el equilibrio entre seguridad y experiencia de usuario ofrecido por L1 y L2 en mi breve artículo de investigación). Estos L2 se conectan de forma segura a L1 a través de rutas de mensajes canónicas, sentando las bases para una red modular pero interoperable. En los últimos cuatro años, hemos construido la fibra óptica entre blockchains que algún día respaldarán aplicaciones cripto útiles. Pero ¿por qué son tan inutilizables las blockchains modulares?

La inevitabilidad de las redes de blockchain modulares es que los activos de capital se acumularán en las capas más seguras, mientras que los clics de los usuarios se acumularán en las capas más rápidas y económicas.

La topología modular de blockchain fomenta que el espacio de bloque seguro se ofrezca en una capa diferente que el espacio de bloque económico y rápido. Los usuarios naturalmente preferirán almacenar su valor en las redes más seguras, pero exigirán interactuar con mayor frecuencia con las económicas y rápidas.Por diseñoLas rutas canónicas entre L2 y L1 son lentas y/o costosas. Estos fenómenos explican por qué los usuarios deben recorrer estas vías canónicas para pagar las interacciones de L2 utilizando activos de L1. Esto resulta en una experiencia de usuario de criptomonedas "inutilizable".

Vitalik sobre diferentes tipos de L2s

El objetivo de la abstracción de la cadena es reducir la fricción de enviar valor a lo largo de estos caminos en protocolo lejos del usuario.Abstractores de cadenaSuponga que los usuarios prefieren especificar su estado final deseado a las dapps como "intenciones" y es responsabilidad de la dapp cumplir sus intenciones. Los usuarios no deberían tener que comprometer la custodia segura de sus activos para acceder a tarifas bajas y baja latencia.

Por lo tanto, abstracción de cadenadepende críticamente de que los usuarios puedan transferir valor a través de redes de forma segura, económica y rápida. Un flujo común de usuarios hoy en día es que un usuario con un saldo USDC en una cadena “segura” como Ethereum desea acuñar un NFT o intercambiar por nuevos tokens en una cadena más reciente como Blast o Base. La forma de hacer esto en la menor cantidad de pasos posible es ejecutar secuencialmente una serie de transacciones de Puente→Intercambio→Acuñación (o Intercambio→Puente→Acuñación).

En este ejemplo, la intención del usuario es utilizar su USDC en la cadena segura para acuñar un NFT en otra cadena. El usuario estará satisfecho siempre y cuando reciba el NFT y su saldo de USDC se cargue donde elija custodiarlo.

La arquitectura basada en intenciones es la única forma de construir una abstracción de cadena

La abstracción de la cadena se basa en la transferencia de valor entre cadenas, pero enviar valor a través de rutas de mensajería canónicas es caro o lento. Los "puentes rápidos" ofrecen alternativas baratas y rápidas para que los usuarios envíen valor a través de redes, pero introducen nuevas suposiciones de confianza. El paso de mensajes es la forma más intuitiva de construir un puente rápido porque está modelado según la arquitectura TCP/IP; se basa en un protocolo de puente que actúa como el enrutador TCP para conectar dos cadenas.

Diagrama TCP/IP de ResearchGate

La transferencia de valor a través del paso de mensajes implica que el protocolo Gate envíe mensajes entre sus contratos en las cadenas de origen y destino. Este mensaje se desencadena en el lado de origen por una transacción del usuario y se transmite al lado de destino una vez que se verifica la 'validez' del mensaje.

Un mensaje solo puede ser verificado después de que la transacción de la cadena de origen que inicia el mensaje se haya finalizado, lo que significa que la transacción está incluida permanentemente en la cadena de bloques canónica de la cadena de origen. Esta verificación se puede completar como una prueba de validez que demuestra la inclusión del consenso de la transacción en la cadena de origen, como una propuesta optimista, o después de que un umbral de firmas de testigos que atestiguan su inclusión se haya acumulado en el lado de origen. Una vez que el mensaje se transmite al contrato puente en la cadena de destino, los tokens se liberan al usuario.

Hay varios problemas fundamentales con esta arquitectura:

1. El mecanismo de verificación debe esperar la total finalidad antes de enviar el mensaje al contrato del protocolo de la cadena de destino. Esto puede tardar hasta siete días para las capas 2 con períodos de finalidad optimista.
2. Se envía un mensaje entre cadenas por transacción de puente O los mensajes se agrupan por lotes, pero el lote solo se puede enviar después de que finalice el último mensaje del lote.
3. El puente tiene una capacidad limitada para obtener liquidez externa para ofrecer mejoras de precio al usuario porque debe ser declarativo sobre la ruta de cumplimiento de la intención del usuario.

Los puentes rápidos de paso de mensajes van a ser inseguros, lentos o costosos dependiendo del mecanismo de verificación. Los mercados de intención son una arquitectura alternativa para el puente rápido que surge de una idea clave:

El valor es fungible y no debería importarle al destinatario cómo se transfiere el valor siempre y cuando reciba los fondos

¿Puede un Gate externalizar la transferencia de valor a un agente sofisticado para ganar velocidad y reducir costos? La liquidez es dinámica dentro y fuera de la cadena y la mejora de precios se puede lograr si el mecanismo de Gate tiene la flexibilidad de elegir un camino de ejecución óptimo en el momento de la transferencia de Gate.

Los mecanismos de intención permiten a los usuarios especificar condiciones o convenios precisos bajo los cuales su transacción de transferencia de valor puede ser ejecutada.

Una intención mínima viable es una orden de pagar X token desde la cadena A para recibir Y token en la cadena B.

El protocolo de puente no necesita enviar un mensaje entre dominios por transacción de puente para cumplir con la intención de cruce de un usuario. En cambio, el protocolo subcontrata la transferencia de valor a un agente seleccionado de una red de resolutores sin permisos, y el resolutor individual buscará el reembolso más tarde del protocolo de puente. En comparación, los mecanismos de paso de mensajes especifican exactamente cómo deben ejecutarse sus transacciones y no necesitan depender de la disponibilidad de un agente.

Protocolos de liquidación de intenciones

Los protocolos de puente basados en la intención pueden ser etiquetados de manera más precisa como protocolos de liquidación de intención que son responsables de asegurar que los solucionadores no violen las condiciones especificadas por el usuario. Los protocolos de liquidación de intención ofrecen a los solucionadores la seguridad de que serán reembolsados y recompensados por cumplir las intenciones del usuario. Para hacerlo, los protocolos de liquidación de intención necesitan recurrir a un oráculo para verificar la autenticidad del cumplimiento de la intención. La seguridad del oráculo puede estar fundamentada en un período de desafío optimista, un umbral de testigos o estar basada en una prueba de validez ZK, por ejemplo.

Los protocolos de liquidación de intención ofrecen transferencias de valor rápidas y baratas porque los solucionadores individuales pueden asumir el riesgo de finalidad e identificar los caminos de ejecución óptimos

Los puentes de paso de mensajes solo pueden comunicarse tan rápido como la cadena de origen alcance la finalidad. Los tiempos de finalización son de siete días en los rollups optimistas y de una hora en los rollups ZK en la actualidad. A pesar de que estos tiempos de finalidad deberían tender a la baja tras la adopción más amplia de la tecnología de cliente ligero ZK y los avances en la tecnología de preconfirmación de secuenciación compartida, es poco probable que los tiempos de finalización de todas las cadenas de bloques se sientan "instantáneos" para los usuarios, lo que sugiere una necesidad persistente de soluciones de puente rápidas. Es imposible retransmitir un mensaje más rápido que el período de finalidad sin asumir el riesgo de finalidad, que está fuera del ámbito de un puente de paso de mensajes, a menos que el puente desee agregar un agente de confianza adicional a la ruta de retransmisión que respalde las pérdidas debidas a las reorganizaciones de la cadena.

La aceleración ofrecida por la arquitectura basada en intenciones surge porque los solucionadores individuales dentro de una red de solucionadores heterogénea pueden asumir más riesgo de finalidad que un protocolo de paso de mensajes y satisfacer la intención de un usuario antes de que el riesgo de reorganización de la cadena desaparezca por completo. Posteriormente, los solucionadores cobrarán a los usuarios por este riesgo de finalidad que asumen a cambio de tiempos de llenado más rápidos.

La externalización del cumplimiento de intenciones entre cadenas a un agente también conduce a una mejora de precios en promedio para los usuarios. En puentes basados en intenciones, los solucionadores que adelantan los pedidos de los usuarios en la cadena de destino deseada son reembolsados más tarde por el sistema después de que se valide su cumplimiento. Estos acuerdos de intenciones se pueden agrupar para amortizar costos. Los llenadores, a diferencia de los usuarios, no exigen un reembolso instantáneo y cobrarán a los usuarios de acuerdo por adelantarles capital. El acuerdo en lotes no es único en la arquitectura basada en intenciones, pero la arquitectura es más sinérgica con el acuerdo en lotes porque separa el paso de reembolso del paso de cumplimiento de intenciones.

La mayor fuente de mejora de precios proviene de la intuición de que el valor es fungible, y encontrar el mejor camino justo a tiempo generalmente superará la transferencia de valor. (Sin embargo, algunos caminos serán imposibles de vencer en costo justo a tiempo, como cuando se conecta USDC sobre CCTP).

Los puentes de transferencia de mensajes deben codificar cómo transferirán valor al usuario. Algunos optan por enviar tokens fuera de un pool de liquidez a una tasa de cambio predeterminada, mientras que otros acuñan tokens representativos para los destinatarios que luego necesitan intercambiar por el activo de token canónico deseado.

Al cumplir con la intención de un usuario, un agente puede obtener liquidez de una combinación de lugares de liquidez en cadena y fuera de cadena. Las redes de solución competitiva ofrecen a los usuarios fuentes ilimitadas de liquidez en teoría (pero incluso estas fuentes de liquidez pueden agotarse rápidamente cuando la tendencia del volumen va en una dirección durante eventos de alta volatilidad en cadena como los populares lanzamientos de NFT, airdrops y rug pulls).

Al enviar una orden de intercambio entre cadenas como una intención, los solucionadores pueden internalizar el MEV generado por la orden como una mejora de precio.

La arquitectura basada en la intención está diseñada fundamentalmente para ser segura

Los puentes basados en intenciones pueden construirse de forma segura porque separan las demandas urgentes del usuario de las demandas complejas de la red de liquidación. Los solucionadores pueden esperar el reembolso, a diferencia de los usuarios, y cobrarán a los usuarios por la cantidad de tiempo que el protocolo de liquidación les haga esperar el reembolso. Por lo tanto, las liquidaciones de intenciones pueden validarse utilizando mecanismos muy robustos sin una restricción de tiempo estricta. Esto es preferible desde el punto de vista de la seguridad porque verificar el cumplimiento de una intención es intuitivamente complejo.

Como ejemplo de verificación de intención en producción, A travésvalida y reembolsa llenadores en lotes siguiendo un período de desafío optimista de 90 minutos. Por supuesto, las redes de liquidación deben esforzarse por reembolsar a los llenadores lo más rápido posible para reducir las tarifas de los usuarios finales. Una mejora en el mecanismo de desafío optimista sería un mecanismo de prueba de validez ZK, que requeriría codificar la lógica de validación de la intención en un circuito ZK. En mi opinión, es inevitable que los mecanismos de prueba de validez reemplacen a los mecanismos de desafío optimista y permitan a las redes de liquidación de intenciones reembolsar a los usuarios más rápido.

Entonces, ¿cómo surge la abstracción de cadena a partir de la arquitectura basada en intención?

Recuerde que la abstracción de la cadena requiere transferencia de valor entre cadenas rápida y económica. Tampoco debería requerir que el usuario envíe una transacción en cadena en la red donde se almacenan sus activos.

La intención del usuario no necesita ser enviada onchain por el usuario si incluye un Permit2oEIP3074signature. Esto es cierto tanto para puentes de paso de mensajes como para puentes basados en la intención. Ambas arquitecturas pueden aprovechar el patrón Permit2 para permitir al usuario firmar fuera de la cadena la cantidad de tokens que están dispuestos a pagar desde su billetera de cadena de origen.

Los mercados de intención mejoran el soporte de la cadena de abstracción porque ofrecen transferencia de valor entre cadenas barata y rápida. Imagina un mundo donde un usuario podría solicitar a un solucionador que le dé un presupuesto para ingresar a una posición de participación en WETH en Arbitrum, utilizando su USDC en Optimism como pago. El usuario podría enviar esta intención fuera de la cadena a una subasta de RFQ donde los solucionadores podrían ofertar por ella. El solucionador ganador de la subasta podría luego recibir la intención firmada del usuario, que contiene una autorización para gastar su USDC en Optimism, la cantidad deseada de WETH a recibir en Arbitrum y los datos de llamada necesarios para depositar este WETH en una posición de participación en Arbitrum. El solucionador podría posteriormente enviar esta transacción en Optimism (en nombre del usuario) para iniciar la intención entre cadenas y retirar USDC de la billetera de Optimism del usuario. Finalmente, el solucionador podría completar la intención del usuario en Arbitrum enviándoles WETH y reenviando los datos de llamada para ingresar al usuario en la posición de participación en la cadena.

Construir una infraestructura de abstracción de cadena significa hacer que este flujo de usuarios se sienta instantáneo y económico sin necesidad de que envíen una transacción en la cadena. Concluyamos este artículo discutiendo los obstáculos para una adopción más amplia de las intenciones.

Arquitectura de Intención por Across

Para que la mejor experiencia del usuario se materialice a partir de la abstracción de cadena basada en la intención, necesitamos una red competitiva de solucionadores

La conexión con intenciones depende de los efectos de red del solucionador para funcionar mejor que las variantes de paso de mensajes. Este es el compromiso central de la intención frente a las arquitecturas de paso de mensajes. Realísticamente, no todas las aplicaciones que producen intenciones necesitarán acceso a un conjunto de solucionadores perfectamente competitivo, y algunos podrían preferir enrutamiento de sus intenciones a redes de resolución oligopólicas. Sin embargo, el estado actual de las redes de resolución es inmaduroy no está cerca de cumplir con las suposiciones de la vitalidad de la red del solucionador en las que dependen los mercados de intención.

No queremos un mundo donde cada dapp esté enviando intenciones a redes de solucionadores aisladas. El mejor caso para la experiencia de usuario es que muchas dapps se comuniquen con los mismos grupos de solucionadores, y todas las dapps tengan la libertad de cambiar a qué grupos de solucionadores envían sus intenciones.

¿Cómo iniciamos la red del solver?

Debemos priorizar la experiencia del solucionador UX.

Ejecutar un solucionador de intenciones es complicado y requiere experiencia en la creación de software altamente eficiente, así como en la gestión del riesgo de inventario entre cadenas. Naturalmente, habrá partes limitadas interesadas en pagar el costo inicial para ejecutar este código. En el mejor de los casos, un solucionador escrito para una dapp, como un solucionador UniswapX, podría reutilizarse para resolver otras dapps productoras de intenciones como Across y CowSwap.

Realmente necesitamos aumentar la eficiencia de capital agregado de la red del solucionador para todas las dapps basadas en intenciones. Esto requerirá abordar las barreras para ejecutar un solucionador.

Para esto, necesitaremos que las dapps que producen intenciones sean visibles para cualquier solucionador y asegurar que todos los solucionadores tengan acceso a muchas redes de liquidación de intenciones diferenciadas y competitivas. Esto daría confianza a los solucionadores de que podrían elegir encaminar sus cumplimientos de intenciones a una red de liquidación en la que confíen. La competencia entre las redes de liquidación también reduciría los costos para los solucionadores.

La proposición de valor de las redes de liquidación de intenciones es ofrecer seguridad a los solucionadores, así como otras características que afectarían la capacidad del solucionador para completar una intención.

La elección del solver de la red de liquidación de intenciones afectará su capacidad para ofrecer tarifas y garantías de tiempo de ejecución a los usuarios. Algunas redes de liquidación podrían ofrecer períodos de exclusividad para el solver, lo que apoyaría el desarrollo de subastas fuera de la cadena donde los solvers y los usuarios podrían negociar y comprometerse con las tarifas de retransmisión. (Estas subastas de intenciones podrían ofrecer además preconfirmaciones económicamente garantizadas, potenciando aún más la experiencia de usuario. Para obtener más información sobre un flujo de usuario que presente el descubrimiento de intenciones a través de subastas y preconfirmaciones, recomiendo esto charla de Karthik de Sorella.)

Algunas redes de liquidación pueden ofrecer vencimiento de intención (es decir, enviar el valor de vuelta a los usuarios después de que se haya pasado una fecha límite de cumplimiento), respaldo de intención (es decir, la red de liquidación utiliza su propio balance para cumplir la intención del usuario si ningún solucionador lo hace), o cadena de reembolso flexible (es decir, permitir al solucionador ser reembolsado en su cadena de elección).

Al final, las redes de liquidación competirán ferozmente para recompensar a los solucionadores de manera rápida y económica sin comprometer la seguridad. A su vez, los solucionadores enviarán su flujo de pedidos a las redes de liquidación que les permitan ofrecer las tarifas más baratas a los usuarios para que puedan ganar el flujo de pedidos de la dapp. La competencia en las redes de liquidación y de solucionadores depende de que todas las partes en la cadena de suministro de intenciones coordinen para hablar el mismo idioma, y la competencia llevará a la mejor UX para la transferencia de valor entre cadenas.

Está claro que necesitamos un estándar para las intenciones entre cadenas

Si los solucionadores pueden asumir que las intenciones compartirán elementos comunes, entonces pueden reutilizar su código para resolver las intenciones originadas por diferentes dapps y, posteriormente, reducir sus costos de configuración. Si diferentes dapps crean intenciones que se ajustan al mismo estándar, entonces todas pueden dirigir sus intenciones a los mismos grupos de solucionadores. Esto ayudaría a incorporar la próxima generación de dapps al darles la capacidad de conectar directamente sus intenciones entre cadenas en un grupo de solucionadores existente y maduro. Las nuevas dapps no tendrían que incorporar solucionadores individualmente y, en cambio, tendrían acceso a transferencias de valor baratas, rápidas, seguras y sin permisos.

El software de seguimiento de terceros también podría rastrear más fácilmente los estados de intención para cualquier nueva dapp si se ajustan a un estándar.

Este estándar de intención debería permitir que el principal de la intención o el solucionador especifiquen en qué red de liquidación desean liquidar su intención.

Imagino protocolos de liquidación competitivos como SUAVE, Across, Anoma y Khalani ofreciendo características diferenciadas a los solucionadores de intenciones. Dependiendo de qué red de liquidación esté reembolsando al solucionador, éste puede ofrecer diferentes garantías de precio y tiempo al propietario de la intención. La dapp y el solucionador podrían acordar dirigir la intención de un usuario a una red de liquidación en la que confíen para evitar la censura, mantener la privacidad de los datos y también ser suficientemente seguros como para ser confiables para reembolsar al solucionador.

Al consagrar la elección de la red de liquidación en la orden de intención misma, el solucionador podría incorporar esta certeza en la cotización que mostrarían al usuario. El solucionador y el usuario eliminarían la incertidumbre inicial sobre la fijación de precios del puente antes de enviar la intención en la cadena, lo que reduciría los costos.

En colaboración con Uniswap y basándonos en los comentarios del grupo de trabajo de CAKE, Across y yo proponemos el siguiente estándar de intención entre cadenas priorizando la experiencia del usuario del solucionador:

///@titleTipo de orden CrossChain

///@noticeEstructura de pedido estándar para ser firmada por los intercambiadores, difundida a los llenadores y presentada a contratos de liquidación

struct CrossChainOrder {

/// @dev La dirección del contrato por la cual se supone que se liquidará la orden./// Los rellenos envían esta orden a esta dirección de contrato en la cadena de origen dirección settlementContract;/// @dev La dirección del usuario que inicia el intercambio,/// cuyos tokens de entrada serán tomados y pignorados dirección swapper;/// @dev Número aleatorio a utilizar como protección contra repeticiones para la ordenuint256 nonce;/// @dev El chainId de la cadena de origenuint32 originChainId;/// @dev La marca de tiempo para cuando la orden debe ser iniciadauint32 initiateDeadline;/// @dev La marca de tiempo para cuando la orden debe ser completada en la cadena de destinouint32 fillDeadline;/// @dev Datos arbitrarios específicos de la implementación/// Pueden ser utilizados para definir tokens, cantidades, cadenas de destino, tarifas, parámetros de liquidación,/// u otra información específica del tipo de ordenbytes orderData;

}

Este estándar está diseñado para facilitar el trabajo de un solver. Una elección con opinión que hace es apoyar Permit2/EIP3074 nativamente con el nonce e initiateDeadline y proporciona ciertas garantías a los fillers, como la cantidad que se les reembolsará de la red de liquidación y el formato de la intención del usuario que pueden rastrear. Además, se define una función de inicio en el estándar que permite crucialmente al filler, quien llevará la orden onchain, especificar datos adicionales "fillerData" onchain que el usuario no habría conocido en el momento en que firmaron el CrossChainOrder. Esto permite al filler asegurarse de que son recompensados por el contrato de liquidación por enviar la meta-transacción del usuario y también establecer información específica de reembolso como la cadena de reembolso.

Este estándar también está diseñado para facilitar a las dapps el seguimiento del estado de cumplimiento de la intención a lo largo de su ciclo de vida. Cualquier contrato de liquidación que implemente este estándar debería crear un subtipo personalizado ResolvedCrossChainOrder que pueda ser analizado desde el campo de datos de pedido arbitrario. Esto puede incluir información como los tokens involucrados en el intercambio, la(s) cadena(s) de destino y otras restricciones de cumplimiento. Una función de resolución está incluida en el estándar para permitir a las dapps comprender cómo mostrar los estados de intención a los usuarios y para que los solucionadores conozcan la estructura exacta del pedido de intención con el que están trabajando.

///@titleTipo de orden ResolvedCrossChainOrder

/// @noticeUna representación genérica de implementación de una orden

/// @devDefine todos los requisitos para completar un pedido desagregando los datos de pedido específicos de la implementación.

///@devDestinado a mejorar la generalización de la integración al permitir que los rellenos calculen la información exacta de entrada y salida de cualquier orden

struct ResolvedCrossChainOrder {

/// @dev La dirección del contrato por la cual se supone que se liquidará la orden. dirección settlementContract;/// @dev La dirección del usuario que está iniciando el intercambio dirección swapper;/// @dev Número aleatorio a utilizar como protección contra repeticiones para la orden. uint256 nonce;/// @dev El chainId de la cadena de origen uint32 originChainId;/// @dev La marca de tiempo para la cual la orden debe ser iniciada uint32 initiateDeadline;/// @dev La marca de tiempo para la cual la orden debe ser completada en la(s) cadena(s) de destino uint32 fillDeadline;/// @dev Las entradas que se deben tomar del intercambiador como parte de la iniciación de la orden Entrada[] swapperInputs;/// @dev Las salidas que se deben dar al intercambiador como parte del cumplimiento de la orden Salida[] swapperOutputs;/// @dev Las salidas que se deben dar al llenador como parte de la liquidación de la orden Salida[] fillerOutputs;

}

///@noticeTokens enviados por el intercambiador como entradas a la orden

struct Input {

/// @dev La dirección del token ERC20 en la cadena de origen dirección del token;/// @dev La cantidad de token a enviaruint256 cantidad;

}

///@noticeTokens que deben recibir para un cumplimiento de orden válido

struct Output {

/// @dev La dirección del token ERC20 en la cadena de destino/// @dev La dirección(0) se utiliza como centinela para el token nativotoken;/// @dev La cantidad del token a enviaruint256 cantidad;/// @dev La dirección para recibir los tokens de salidaaddress destinatario;/// @dev La cadena de destino para esta salidauint32 chainId;

}

Una implementación de contrato de liquidación conforme DEBE implementar la interfaz ISettlementContract:

/// @titleISettlementContract

///@noticeInterfaz estándar para contratos de liquidación

interfaz ISettlementContract {

/// @notice Inicia el proceso de liquidación de un pedido entre cadenas/// @dev Debe ser llamado por el rellenador/// @param order La definición de orden entre cadenas/// @param signature La firma del intercambiador sobre el pedido/// @param fillerData Cualquier dato definido por el rellenador requerido por el liquidadorfunction initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;/// @notice Resuelve un pedido específico entre cadenas en un PedidoEntreCadenasResuelto genérico/// @dev Destinado a mejorar la integración estandarizada de varios tipos de órdenes y contratos de liquidación/// @param order La definición de orden entre cadenas/// @param fillerData Cualquier dato definido por el rellenador requerido por el liquidador/// @returns PedidoEntreCadenasResuelto datos del pedido hidratado que incluye las entradas y salidas del pedidofunction resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

Los objetivos de diseño de este estándar eran mejorar la experiencia del solver, facilitarles el soporte de múltiples redes de liquidación y calcular de manera determinista sus recompensas. Creo que esto les permitirá ofrecer cotizaciones más precisas y ajustadas a los usuarios. Puede leer más detalles sobre este estándar, con el nombre en código ERC7683, en esta publicación de X/Twittery la discusión que la rodeaen el foro de Ethereum Magicians.

Pensamientos Finales

"Los "intents" son confusos porque no están definidos, y esta falta de definición está creando defectos reales en la experiencia de usuario."

Todos quieren que los demás utilicen su definición estándar de una intención, por lo que reconozco plenamente que es prácticamente imposible establecer normas. No creo que definir primero un sistema de liquidación de intenciones e intentar atraer el flujo de órdenes en segundo lugar sea el enfoque correcto para establecer un estándar de la industria en todo el sector.

En mi opinión, el enfoque más viable es que las dapps que ya poseen una gran cantidad de flujo de usuarios y generan muchas intenciones de usuario aceptarán cumplir con algún estándar mínimo que adoptarán sus solvers existentes. Esto formará un nuevo y más grande pool de solvers. Al obtener acceso a orderflow fusionado de lugares ya prominentes, este nuevo pool de solvers obtendrá más ganancias y podrá ofrecer mejores precios a los usuarios finales. Eventualmente, las nuevas dapps también exigirán dirigir sus intenciones a este pool de solvers y respaldarán su estándar de intenciones.

Para empezar, Across y Uniswap se unen propuesta de un estándarpara que todas las partes de la cadena de suministro utilicen al manejar los pedidos de los usuarios para enviar tokens X desde la cadena A y recibir tokens Y en la cadena B. El flujo de pedidos que pasa por UniswapX (que tiene una ventaja comparativa en el diseño de subastas y en la intención de origen) y Across (que tiene una ventaja comparativa en el cumplimiento de intenciones) puede fusionarse y dar inicio al proceso de nutrir una red de solucionadores más grande y competitiva.

Descargo de responsabilidad:

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