TL; Dr

• La experiencia de usuario criptográfica predeterminada hoy en día es que los usuarios siempre sepan con qué red están interactuando. Sin embargo, los usuarios de Internet no tienen que saber con qué proveedor de nube están interactuando. Llevar este enfoque a las cadenas de bloques es lo que llamamos Abstracción de la Cadena.
• Este artículo presenta el marco CAKE, es decir, los elementos clave de abstracción de cadena. Se compone de cuatro capas: Aplicaciones, Permisos, Resolución y Asentamiento, que colectivamente facilitan las operaciones de cross-chain sin problemas para los usuarios.
• Lograr la abstracción de la cadena requiere el uso de un conjunto complejo de tecnologías para proporcionar una ejecución confiable, rentable, segura, rápida y privada.
• Definimos el espacio de compensación cross-chain en la abstracción de cadena como un trilema y proponemos seis diseños, cada uno de los cuales ofrece ventajas únicas.
• Para dar con éxito el orden a un futuro de abstracción en cadena, es imperativo que nosotros, como industria, definamos y adoptemos un estándar común para la mensajería entre las capas del CAKE. Un gran estándar es la guinda del pastel. 🎂

Introduction

En 2020, la red Ethereum pasó a una hoja de ruta centrada en rollup para el escalado. Cuatro años después de esa decisión, más de 50 rollups (L2) ya están en producción. Si bien rollups proporcionar un escalado horizontal muy necesario para el espacio de bloques EVM, ha arruinado totalmente la experiencia del usuario.

A los usuarios no les debe importar, ni saber, con qué rollup están interactuando. Que los usuarios de cripto sepan con qué rollup (Optimism o Base) están interactuando es equivalente a que los usuarios de web2 sepan con qué proveedor de nube (AWS o GCP) están interactuando. La abstracción de la cadena es una visión en la que la información de la cadena se abstrae del usuario. El usuario solo conecta su billetera a una dApp y firma la operación prevista, los detalles para asegurarse de que el usuario tenga el saldo correcto en la cadena de destino y luego ejecutar la operación prevista ocurren detrás de escena.

A lo largo de este artículo, observaremos que la abstracción en cadena es un problema verdaderamente multidisciplinario. Implica interacciones con la capa de aplicación, la capa de permisos, la capa de solucionador y la capa de asentamiento. Presentamos el marco de los Elementos Clave de Abstracción de Cadena (CAKE) 🎂 y luego profundizamos en las compensaciones de diseño de los sistemas de abstracción de cadena.

Introducing the CAKE Framework

En un mundo abstraído en cadena, un usuario va a un sitio web de dApps, conecta su billetera, firma la operación prevista y espera una eventual liquidación. Toda la complejidad de adquirir los activos requeridos para la cadena objetivo y la liquidación final se abstrae del usuario, sucediendo en las capas de infraestructura del CAKE. Hay tres capas de infraestructura del CAKE:

1. Capa de permisos: el usuario conecta su billetera a una dApp y solicita la cotización de una intención de usuario. Una intención es lo que el usuario espera (es decir, la salida) al final de una transacción y no la ruta final que toma la transacción. Puede ser transferir USDT a una dirección de Tron o depositar USDC en una estrategia de generación de rendimiento en Arbitrum. La billetera debe ser capaz de conocer los activos de los usuarios (es decir, el estado de lectura) y ejecutar transacciones (es decir, el estado de actualización) en las cadenas de destino.
2. Capa de solucionador: la capa de solucionador calcula las tarifas y la velocidad de ejecución en función del saldo inicial y la intención del usuario. Este proceso, conocido como resolución, es crucial en un entorno cross-chain donde las transacciones se vuelven asíncronas y las subtransacciones pueden fallar durante la ejecución. La introducción de la asincronicidad crea un trilema cross-chain que involucra tarifas, velocidad de ejecución y garantía de ejecución.
3. Capa de asentamiento: Después de que el usuario aprueba la transacción con su clave privada, la capa de liquidación asegura su ejecución. Implica dos pasos: unir los activos del usuario a la cadena objetivo y luego ejecutar la transacción. Si el protocolo utiliza solucionadores sofisticados para ciertas operaciones, pueden aportar su propia liquidez y ejecutar la operación en nombre del usuario sin necesidad de puentes.

Lograr la abstracción de la cadena significa combinar las tres capas de infraestructura anteriores en un producto unificado. Una idea clave al combinar estas capas es la diferencia entre transferir información y transferir valor. La transferencia de información entre cadenas debe ser sin pérdidas y, por lo tanto, debe depender de las vías más seguras. Supongamos que un usuario está intentando votar Sí en una votación de gobernanza de una cadena a otra, no quiere que su voto se convierta en un quizás. Por otro lado, la transferencia de valor puede tener pérdidas según las preferencias de los usuarios. Se puede aprovechar un tercero sofisticado para ofrecer al usuario una transferencia de valor más rápida, barata o garantizada. Tenga en cuenta que el 95% del espacio de bloque de ethereum (ponderado por las tarifas pagadas a los validadores) se consume para transferir valor.

Decisiones clave de diseño

Las tres capas anteriores introducen las decisiones de diseño clave que deben ser tomadas por un CAF. Están relacionados con quién controla el poder sobre la ejecución de la intención, qué información debe revelarse a los solucionadores y cuáles son las vías de liquidación disponibles para los solucionadores. Veamos cada uno de ellos en detalle.

Capa de permisos

La capa de permisos contiene la clave privada del usuario y firma mensajes en su nombre, que luego se ejecutan on-chain como transacciones. Un CAF necesita soporte esquemas de firma y cargas útiles de transacciones para todas las cadenas objetivo que desea soporte. Por ejemplo, una billetera que admita el esquema de firma ECDSA y el estándar de transacción EVM se limitará a Ethereum, sus L2 y sus cadenas laterales (por ejemplo, la billetera Metamask). Por otro lado, una billetera que admita tanto EVM como SVM (Solana VM) podrá soporte ambos ecosistemas (por ejemplo, la billetera Phantom). Es importante tener en cuenta que el mismo mnemotécnico se puede usar para generar billeteras en cadenas EVM y SVM.

Una sola transacción multicadena consta de varias subtransacciones que deben ejecutarse en el orden correcto. Estas subtransacciones deben ejecutarse en múltiples cadenas, cada una con sus propias tarifas variables en el tiempo y nonce. La forma en que se lleva a cabo la coordinación y liquidación de estas subtransacciones es una decisión de diseño crucial para la capa de permisos.

1. Las billeteras EOA son software de billetera que se ejecutan en las máquinas de los usuarios y contienen sus claves privadas. Pueden ser extensiones basadas en navegador (como Metamask y Phantom), aplicaciones móviles (como Coinbase Wallet) o hardware dedicado (como Ledger). Las billeteras EOA requieren que el usuario firme individualmente cada subtransacción, lo que actualmente requiere varios clics. También requieren que el usuario mantenga saldos de tarifas en la cadena objetivo, lo que introduce una fricción significativa en el proceso. Sin embargo, la fricción de múltiples clics se puede abstraer del usuario al permitirle firmar múltiples subtransacciones con un solo clic.
2. En las billeteras de abstracción de cuentas (AA), el usuario aún tiene acceso a su clave privada, pero separan al firmante de la carga útil de la transacción con el ejecutor de la transacción. Permitir que las partes sofisticadas agrupen y ejecuten de forma atómica las transacciones de los usuarios (Avocado, Pimlico). Las billeteras AA aún requieren que el usuario firme individualmente cada subtransacción (actualmente a través de múltiples clics), pero no requieren la tenencia de saldos de tarifas en cada cadena.
3. Los agentes basados en políticas mantienen la clave privada del usuario en un entorno de ejecución independiente y generan mensajes firmados en su nombre en función de las políticas de usuario. Los bots de Telegram, el agregador de cuentas cercanas o los TEE SUAVE son billeteras basadas en políticas, mientras que Entropy o Capsule son extensiones de billetera basadas en políticas. El usuario solo tiene que firmar una única aprobación y la posterior firma de las subtransacciones y la gestión de las tarifas pueden ser realizadas sobre la marcha por estos agentes.

Solver Layer

Una vez que un usuario publica su intención, la capa de resolución implica devolver una tarifa y un tiempo de confirmación al usuario. Este problema está estrechamente relacionado con el diseño de una subasta de flujo de pedidos y se ha escrito en detalle aquí. Un CAF puede aprovechar las rutas en el protocolo para ejecutar la intención de un usuario o aprovechar sofisticados terceros, también conocidos como solucionadores, para proporcionar una experiencia de usuario mejorada al usuario al comprometer algunas garantías de seguridad. Las siguientes dos decisiones de diseño surgen cuando incorporamos los solucionadores a un marco CAF y están relacionadas con la información.

Un intent consta de dos tipos de valores extraíbles (EV): EV_ordering y EV_signal. EV_ordering es un valor específico de la cadena de bloques, normalmente extraído por entidades que ejecutan órdenes de usuario como constructores de bloques o validadores. Por otro lado, EV_signal representa el valor accesible para cualquier entidad que observe el orden antes de que se registre oficialmente en la cadena de bloques.

Las diferentes intenciones de usuario tienen diferentes distribuciones entre EV_ordering y EV_signal. Por ejemplo, la intención de intercambiar monedas en un DEX suele tener un EV_ordering alto pero un EV_signal bajo. Por el contrario, una transacción de hackeo entrante tendrá un mayor componente de EV_signal ya que ejecutarla por adelantado devolverá significativamente más valor que ejecutarla. Es importante tener en cuenta que los EV_signal a veces pueden ser negativos, como en el caso de las operaciones de los creadores de mercado, donde las entidades que ejecutan estas órdenes pueden experimentar pérdidas debido a una mejor comprensión de las condiciones futuras del mercado por parte de los creadores de mercado.

Cuando alguien tiene la capacidad de observar la intención de un usuario con anticipación, puede participar en el front-running, lo que conduce a la fuga de valor. Además, la posibilidad de que EV_signal sean negativas crea un entorno competitivo entre los solucionadores, lo que hace que presenten ofertas más bajas y da lugar a una mayor fuga de valor (también conocida como selección adversa). En última instancia, las fugas afectan al usuario, ya sea aumentando las tarifas u ofreciendo precios menos favorables. Tenga en cuenta que las tarifas bajas o la mejora de precios son dos caras de la misma moneda y se usarán indistintamente durante el resto del artículo.

Intercambio de información

Hay 3 métodos para compartir información con los solucionadores:

1. Mempool público: la intención del usuario se difunde públicamente, ya sea en un mempool público o en una capa DA. El primer solucionador que puede cumplir con la solicitud ejecuta el orden y se convierte en el ganador. Este sistema es altamente extractivo, ya que los usuarios revelan tanto el EV_ordering como el EV_signal de su orden. Ejemplos de este tipo de subasta incluyen el mempool público de Ethereum y varios puentes de blockchain. En el caso de los puentes, los usuarios deben colocar sus activos en custodia antes de transferirlos a la cadena de destino como precaución contra los ataques de duelo. Sin embargo, este proceso expone involuntariamente sus intenciones públicamente.
2. Intercambio parcial: Un CAF puede optar por limitar la cantidad de valor que revela a los oferentes limitando la información divulgada. Sin embargo, este enfoque da como resultado una pérdida directa de la optimalidad del precio y puede dar lugar a otros problemas, como el spam de ofertas.
3. Mempool privado: Los desarrollos recientes en MPC y TEE abren la posibilidad de lograr mempools completamente privados. No se filtra ninguna información fuera del entorno de ejecución, por lo que los solucionadores codifican sus preferencias, que coinciden con cada intención. Aunque la mempool privada captura EV_ordering, no puede capturar completamente el valor en EV_signal. Imagínese lo que sucederá si se envía una transacción de piratería al mempool. La primera persona que vea este orden puede adelantarse a la venta potencial y captar EV_signal. En una mempool privada, la información se libera solo después de que se confirma un bloqueo y, por lo tanto, quien pueda ver la transacción puede capturar el EV_signal. Uno puede imaginar a los solucionadores haciendo girar atestación nodos para atrapar EV_signal de bloques nuevos acuñados por un TEE, convirtiendo EV_signal captura en una carrera latencia.

Lista

de solucionadores La CAF también debe decidir cuántos y qué postores pueden participar en la subasta. A grandes rasgos, las opciones son las siguientes:

• Acceso abierto: Las barreras de entrada para la capacidad de participar son lo más bajas posible. Esto es similar a un mempool público y filtra tanto EV_signal como EV_ordering.
• Acceso cerrado: Existe cierto control sobre la capacidad de ejecutar un orden, ya sea a través de una lista blanca, un sistema de reputación, una tarifa o una subasta de asientos. El mecanismo de control de acceso debe garantizar que los solucionadores del sistema no capturen EV_signal. Algunos ejemplos son las subastas de 1inch Auction, Cowswap Auctions y Uniswap X. La competencia para ganar pedidos captura EV_ordering para el usuario, mientras que el mecanismo de compuerta puede capturar el EV_signal para el generador de orden (Billetera, dApps).
• Acceso exclusivo: El acceso exclusivo es un caso especial de la subasta de solucionadores sentados en la que solo se selecciona un solucionador en cada período de tiempo. Dado que no se filtra información a otros solucionadores, no hay selección adversa ni descuento por adelantado. El originador del flujo de órdenes captura el valor esperado de EV_signal y EV_ordering, ya que no hay competencia, el usuario solo puede obtener ejecución y no hay mejora de precio. Algunos ejemplos de estas subastas son las subastas de Robinhood y DFlow.

Asentamiento Capa

Una vez que una billetera firma un conjunto de transacciones, deben ejecutarse en la cadena de bloques. Las transacciones entre cadenas convierten el proceso de liquidación de atómico a asíncrono. Mientras se ejecutan y confirman las transacciones iniciales, el estado de la cadena de destino puede cambiar, lo que puede provocar un error en la transacción que puede provocar un líder. En esta subsección se estudiarán las ventajas y desventajas entre el coste de la seguridad, el tiempo de confirmación y la garantía de ejecución.

Es importante tener en cuenta que la ejecución de la transacción prevista en la cadena de destino depende de la mecánica de inclusión de transacciones de la cadena de destino. Incluyendo la capacidad de censurar una transacción y el mecanismo de tarifas de la cadena objetivo, entre otros factores. Creemos que la elección de la cadena objetivo es una decisión de la dApp y la consideraremos más allá del alcance de este artículo.

Cross-Chain Oracle

Dos cadenas de bloques con estados y mecanismos de consenso distintos requieren un intermediario, como un oráculo, para facilitar la transferencia de información entre ellas. Los oráculos sirven como relés de información entre cadenas. Esto incluye la verificación de situaciones como el bloqueo de fondos por parte de un usuario en un cuenta de custodia para un bloqueo y acuñar puente, o la confirmación del saldo de tokens de un usuario en la cadena de origen para participar en la votación de gobernanza en la cadena de destino.

Los oráculos transfieren información entre cadenas a la velocidad de la cadena más lenta. Esto es necesario para gestionar el riesgo de reorganización, ya que el Oráculo debe esperar el consenso sobre la cadena de origen. Consideremos un escenario en el que un usuario quiere puente USDC de la cadena de origen a la cadena de destino. Para ello, el usuario bloquea sus fondos en un depósito en garantía. Sin embargo, si el Oráculo no espera suficientes confirmaciones y procede a acuñar tokens para el usuario en la cadena de destino, puede ocurrir un problema. En el caso de una reorganización, si el usuario sobrescribe su transacción de depósito en garantía, el Oráculo tendría un doble gasto.

Hay dos tipos de oráculos:

1. Oracle fuera de protocolo requiere validadores de terceros separados de los que ejecutan el consenso para transferir información entre cadenas. La necesidad de validadores adicionales aumenta el costo de ejecutar el Oracle. LayerZero, Wormhole, ChainLink y la red Axelar son ejemplos de oráculos fuera de protocolo.
2. Un oráculo en protocolo está profundamente integrado en el algoritmo de consenso de un ecosistema y utiliza el conjunto de validadores que ejecuta el consenso para transferir información. Cosmos tiene IBC para las cadenas que ejecutan el SDK de Cosmos, el ecosistema Polygon está trabajando en AggLayer, mientras que Optimism está trabajando en Superchain. Cada oráculo utiliza un espacio de bloques dedicado para transferir información entre cadenas del mismo ecosistema.
3. Los secuenciadores compartidos son entidades fuera del protocolo que tienen derechos de ordenación de transacciones en el protocolo, es decir, pueden proporcionar agrupación de transacciones entre cadenas. Aunque todavía están en desarrollo, los secuenciadores compartidos no tienen que esperar ciertas confirmaciones de bloques para reducir el riesgo de reorganización. Para proporcionar realmente atomicidad cross-chain, los secuenciadores compartidos deben poder ejecutar transacciones posteriores condicionadas al éxito de transacciones anteriores, convirtiéndolas en una cadena de cadenas.

Tokens

puente En un mundo multicadena, los saldos de tokens y tarifas de usuario se distribuyen por todas las redes. Antes de cada operación cross-chain, el usuario necesita puente fondos de la cadena de origen a la cadena de destino. Actualmente hay 34 puentes activos con un TVL combinado de $7,7 mil millones y puentes volumen de $8,6 mil millones en los últimos 30 días.

El puente de tokens es un caso de transferencia de valor. Esto crea una oportunidad para utilizar terceros especializados que sobresalen en la gestión de capital y están dispuestos a asumir el riesgo de reorganización, reduciendo el costo y el tiempo requerido para las transacciones de los usuarios.

Existen 2 tipos de puentes:

1. Lock and Mint puente: Un acuñar puente de bloqueo y acuñación verifica los depósitos de tokens en la cadena de origen y acuña tokens en la cadena de destino. Si bien se necesita un pequeño capital para iniciar un puente de este tipo, se necesita una inversión significativa para la transferencia segura de información de bloqueo entre cadenas. Las brechas de seguridad en estos puentes han resultado en la pérdida de miles de millones de dólares para los poseedores de tokens.
2. Liquidez puentes: Liquidez puentes utilizan pools de liquidez en las cadenas de origen y destino, junto con un algoritmo para determinar las tasas de conversión entre los tokens de origen y destino. Si bien estos puentes tienen costos iniciales más altos, requieren menores garantías de seguridad. En caso de que se produzca una violación de la seguridad, solo están en riesgo los fondos de los pools de liquidez.

En ambos tipos de puentes hay un costo de liquidez que debe ser pagado por el usuario. En los puentes Lock and Mint, el costo de liquidez es al intercambiar del token envuelto al token deseado (USDC.e a USDC) en la cadena de destino, mientras que en los puentes de Liquidez, el costo de liquidez es al intercambiar del token en la cadena de origen al token en la cadena de destino.

Trilema de cadena cruzada

Las 5 decisiones de diseño anteriores dan subir al trilema cross-chain. Un CAF tiene que elegir 2 propiedades entre Garantía de Ejecución, Tarifas Bajas y Velocidad de Ejecución.

1. Las rutas en el protocolo son rutas designadas para transferir información a través de cadenas. Estas cuentas de sistemas para la reorganización corren el riesgo de sacrificar la velocidad de ejecución, pero reducen los costos al eliminar la necesidad de un conjunto de validadores adicional o costos de liquidez.
2. La agregación de solucionadores recopila cotizaciones de varios solucionadores para identificar la ruta más barata y rápida para cumplir con la intención de un usuario. Sin embargo, debido a la selección adversa y a la ejecución anticipada, los solucionadores a veces pueden no satisfacer la intención, lo que da lugar a una reducción de la ejecución.
3. La competencia de ejecución selecciona un solucionador ganador organizando una carrera entre solucionadores para ejecutar una intención o eligiendo un solo solucionador exclusivamente. Ambos enfoques conducen a tarifas altas para el usuario, ya que los solucionadores compiten por la ejecución en lugar de la mejora del precio.

Las seis piezas de CAKE

Para escribir este artículo, hemos estudiado más de 20 diseños diferentes de equipos que trabajan explícita e implícitamente en la abstracción de cadenas. En esta sección, analizamos seis implementaciones independientes de CA que, en nuestra opinión, tienen eficiencias inherentes y ajuste del producto al mercado. Estos diseños tienen el potencial de componerse entre sí si se construyen correctamente.

Una conclusión clave de este ejercicio es que necesitamos un estándar común para expresar las intenciones de cross-chain. Cada uno de los equipos está trabajando en sus propios métodos y protocolos para codificar las intenciones de los usuarios. La unificación hacia un estándar mejorará la comprensión del usuario del mensaje que está firmando, facilitará que los solucionadores y los oráculos entiendan estas intenciones y simplificará la integración con las billeteras.

Puentes ungidos de token

Puente alineado con el ecosistema

Competencia de precios de Solver

Mensajería controlada por billetera

Competición de velocidad Solver

Subastas exclusivas por lotes

propósito

Transferencias baratas entre cadenas

Llamada de mensajes entre cadenas

Intercambios baratos entre cadenas

Llamada de mensajes entre cadenas

Transferencias rápidas entre cadenas

Llamada de mensajes entre cadenas

Ejemplos

CCTP, CCIP, xERC20

AggLayer, Superchain, IBC

Bungee, Jumper, Uniswap X

Alfred, Aguacate, Cerca de la cuenta

A través, Orbitador

Na

billetera

cualquier

cualquier

Depende de la implementación

AA o basado en políticas

cualquier

cualquier

Información compartida

público

público

Depende de la implementación

Depende de la implementación

Todo o nada

ninguno

Listas del solucionador

Depende de la implementación

Depende de la implementación

Acceso cerrado

Depende de la implementación

Depende de la implementación

exclusivo

oráculo

En el protocolo

En el protocolo

Fuera de protocolo

Fuera de protocolo

Fuera de protocolo

Fuera de protocolo

Puente de token

Quemar y acuñar

Bloquear y acuñar

Depende del solucionador

Depende del solucionador

Liquidez puente

Depende de la implementación

Token Ungted Bridges

Hay un caso especial de bloqueo y acuñar puente que no paga el costo de liquidez, también llamado burn and acuñar puente (ej. USDC CCTP). El equipo de tokens unge una dirección de token canónica en cada cadena, mientras que el puente tiene la autoridad para acuñar el token, es decir, el token que el usuario necesita.

Si entrecierras los ojos lo suficiente, una quemadura y acuñar puente es similar a una transferencia de cross-chain a la velocidad de suficientes confirmaciones de bloque. xERC20 es uno de esos estándares para ungir tokens canónicos y sus puentes autorizados en las cadenas de destino. Un puente ungido por token es un ejemplo de una ruta en el protocolo, es decir, compromete la velocidad para la garantía de ejecución y las tarifas bajas, por ejemplo, CCTP tarda 20 minutos en ejecutar una transferencia.

Puente alineado con

el ecosistema Un puente alineado con el ecosistema permite la transferencia de mensajes arbitrarios entre cadenas dentro del mismo ecosistema. Entra en la categoría de rutas en el protocolo, priorizando la garantía de ejecución y las tarifas bajas sobre la velocidad. Algunos ejemplos son Cosmos IBC, Polygon AggLayer y Optimism Superchain.

Hace tres años, el ecosistema de Cosmos enfrentó desafíos similares a los que enfrenta Ethereum hoy. La liquidez estaba fragmentada en todas las cadenas, cada cadena tenía su propio token de tarifa y la administración de cuentas multicadena era engorrosa. El ecosistema de Cosmos abordó estos problemas mediante la implementación de puentes de paso de mensajes en el protocolo a través de IBC, lo que resultó en cuentas multicadena y transferencias cross-chain sin problemas.

El ecosistema cosmos se compone de cadenas independientes que tienen seguridad soberana y finalidad rápida, lo que hace que la ruta en el protocolo para la mensajería cross-chain sea muy rápida. Por otro lado, el ecosistema de los rollups depende de la expiración del período de desafío (Optimistic Rollups) o de la confirmación de zk-proofs (Validity Rollups) para su finalidad. Las rutas en el protocolo para el paso de mensajes a través de ecosistemas serán lentas debido a estas restricciones de finalidad.

Competencia de precios de Solver

Una competencia de precios de Solver implica compartir información orden con todos los solucionadores. Los solucionadores tienen como objetivo incorporar el valor esperado (EV) generado por la intención del orden y proporcionarlo a los usuarios. La selección del solucionador ganador en el sistema se basa en maximizar la mejora del precio para el usuario. Sin embargo, este diseño conlleva el riesgo de no ejecución y requiere mecanismos adicionales para garantizar la inclusión fiable de órdenes. Algunos ejemplos de estos mecanismos son Uniswap X, Bungee y Jumper.

Billetera Los mensajes coordinados

Billetera la mensajería coordinada utilizan las capacidades proporcionadas por AA o billeteras basadas en políticas para ofrecer una experiencia cross-chain que es compatible con cualquier tipo de intención. Sirve como el agregador de CA definitivo, redirigiendo las intenciones de los usuarios entre varios diseños de CA para abordar intenciones específicas. Algunos ejemplos son la billetera Avocado, el agregador de cuentas cercanas y la cartera Metamask.

Tenga en cuenta que, durante la última década, el ecosistema criptográfico ha aprendido que la relación entre un usuario y su billetera es muy pegajosa. Personalmente, siento un temor mortal cada vez que pienso en migrar mi mnemotecnia de Metamask a otra billetera. Esta es también la razón por la que, incluso después de 2,5 años y con el respaldo del propio Vitalik Buterin, EIP-4337 ha ganado . Aunque las versiones más recientes de los protocolos de billetera pueden proporcionar al usuario un mejor precio (abstracción de cuentas) o una mayor facilidad de uso (billeteras basadas en políticas), migrar al usuario desde sus billeteras actuales es una tarea cuesta arriba.

Solver Speed Competition

La competición de velocidad Solver permite a los usuarios expresar sus intenciones de transiciones de cross-chain específicas para obtener altas garantías de ejecución. No ayuda a los usuarios a minimizar las tarifas, sino que ofrece un canal confiable para incluir transacciones complejas. El primer solucionador que ejecute la intención en función de las tarifas del generador de bloques o la velocidad de inclusión gana la intención.

El diseño tiene como objetivo lograr una alta tasa de inclusión maximizando el EV capturado por los solucionadores. Sin embargo, tiene el costo de la centralización, ya que se basa en una sofisticada gestión de capital en la red principal de Ethereum o una ejecución de baja latencia en L2.

Subastas exclusivas por lotes

Una subasta exclusiva por lotes realiza una subasta por los derechos exclusivos para ejecutar todos los flujos de orden en una ventana de tiempo a un único solucionador. Dado que otros solucionadores no pueden ver las órdenes, colocan la oferta en función de la volatilidad prevista del mercado y su calidad de ejecución media. Las subastas exclusivas por lotes dependen de un precio de respaldo en orden para asegurar buenos precios para el usuario y, por lo tanto, no se pueden utilizar para mejorar los precios. Enviar todo el flujo de órdenes a un solo licitador elimina la fuga de información y mejora las garantías de ejecución.

Conclusion

Los marcos de abstracción de la cadena (CAF) prometen ofrecer a los usuarios una interacción cross-chain fluida. En este artículo estudiamos diseños en producción y en desarrollo por parte de varios equipos que explícita o implícitamente están tratando de resolver la abstracción en cadena. Creemos que este será el año de los CAF y esperamos que haya una competencia significativa entre los diferentes diseños y sus implementaciones en los próximos 6 a 12 meses.

Transferencia de valor

Transferencia de información

Rutas en el protocolo

Puente ungido por token

Puente alineado con el ecosistema

Agregación de solucionadores

Competencia de precios de Solver

Mensajería coordinada de billetera

Concurso de ejecución

Competición de velocidad Solver

Subastas exclusivas por lotes

Las transferencias de valor entre cadenas se enrutarán a través de una combinación de puentes ungidos por tokens para tarifas bajas y Solver Speed o Price Competitions para velocidad y ejecución. Mientras que las transferencias de información se enrutarán a través de una combinación de puentes de mensajes alineados con el ecosistema que tendrán como objetivo minimizar el costo para los usuarios y para las plataformas controladas por billeteras que maximizarán la velocidad. Las implementaciones finales se agruparán en torno a estos seis diseños distintos, ya que cada uno de ellos satisface necesidades independientes y se beneficia de las eficiencias existentes en diferentes esquinas de la matriz de compensación.

Una conclusión clave de este ejercicio es que necesitamos un estándar común para expresar las intenciones de cross-chain. Varios equipos están trabajando en sus protocolos individuales para codificar las intenciones de los usuarios que provocan la duplicación del trabajo. La unificación hacia un estándar mejorará la comprensión del usuario del mensaje que está firmando, facilitará que los solucionadores y los oráculos trabajen con intenciones y simplificará la integración con las billeteras.

Disclaimer:

1. Este artículo es una reimpresión de [Medium]. Todos los derechos de autor pertenecen al autor original [Archivo de lecturas de espejos favoritos]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos lo gestionarán con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los 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.