Autor original: Archivo de lecturas en espejo favoritas
Compilación original: Shenchao TechFlow
Resumen de puntos clave
La experiencia de usuario de cifrado predeterminada actual es que los usuarios sepan siempre con qué red están interactuando. Sin embargo, los usuarios de Internet no necesitan saber con qué proveedor de nube están interactuando. Llevar este enfoque a la cadena de bloques es lo que llamamos abstracción de cadena.
Este artículo presenta el marco de elementos clave de abstracción de cadena (CAKE). El marco consta de cuatro partes: capa de aplicación, capa de permiso, capa de resolución y capa de liquidación, con el objetivo de proporcionar a los usuarios una experiencia operativa entre cadenas perfecta.
La implementación de la abstracción de la cadena requiere un conjunto complejo de tecnologías para garantizar la confiabilidad, rentabilidad, seguridad, velocidad y privacidad del proceso de ejecución.
Definimos las compensaciones entre cadenas en la abstracción de la cadena como un trilema y proponemos seis alternativas de diseño, cada una con sus ventajas únicas.
Para dar con éxito el salto a un futuro de abstracción encadenada, como industria debemos definir y adoptar un estándar común para el paso de información entre las capas de CAKE. Un buen estándar es la guinda del pastel.
Introducción
En 2020, la red Ethereum pasó a una hoja de ruta de escalamiento centrada en rollups. Cuatro años después, se utilizan más de 50 capas enrollables (L2). Si bien la capa acumulada proporciona la escala horizontal requerida, rompe por completo la experiencia del usuario.
A los usuarios no les debería importar ni comprender con qué paquete acumulativo están interactuando. Los usuarios de criptomonedas saben qué paquete acumulativo están utilizando (Optimismo o Base), lo que equivale a que los usuarios de Web2 sepan qué proveedor de nube están utilizando (AWS o GCP). La visión de Chain Abstraction es abstraer la información de la cadena del campo de visión del usuario. El usuario simplemente conecta la billetera a la dApp y firma las acciones previstas; los detalles para garantizar que el usuario tenga el saldo correcto en la cadena objetivo y realice las acciones previstas se cuidan detrás de escena.
En este artículo, exploraremos cómo la abstracción de la cadena es un problema verdaderamente multidisciplinario que involucra la interacción de la capa de aplicación, la capa de permisos, la capa de resolución y la capa de liquidación. Presentamos el marco de elementos clave de la abstracción de la cadena (CAKE) y profundizamos en las compensaciones del diseño de los sistemas de abstracción de la cadena.
Presentamos el marco CAKE
En el mundo de la abstracción de cadenas, los usuarios visitan el sitio web de la dApp, se conectan a su billetera, firman operaciones y esperan la liquidación final. Todas las operaciones complejas se realizan en la capa de infraestructura de CAKE. Las tres capas de infraestructura de CAKE incluyen:
Capa de permisos: los usuarios conectan sus billeteras a las dApps y solicitan cotizaciones según la intención del usuario. La intención se refiere al resultado que el usuario espera obtener al final de la transacción, no a la ruta de la transacción. Por ejemplo, transfiera USDT a una dirección de Tron o deposite USDC en una estrategia generadora de rendimiento en Arbitrum. La billetera debe poder leer los activos del usuario (es decir, leer el estado) y realizar transacciones en la cadena de destino (es decir, actualizar el estado).
Capa de resolución: la capa de resolución estima las tarifas y la velocidad de ejecución en función del saldo inicial y la intención del usuario. En una configuración entre cadenas, este proceso, llamado resolución, es fundamental porque las transacciones son asincrónicas y las subtransacciones pueden fallar durante la ejecución. La asincronicidad introduce un trilema entre cadenas que involucra tarifas, velocidad de ejecución y garantías de ejecución.
Capa de liquidación: después de que un usuario aprueba una transacción utilizando una clave privada, la capa de liquidación garantiza su ejecución. Consta de dos pasos: conectar los activos del usuario con la cadena de destino y luego ejecutar la transacción. Si los protocolos utilizan solucionadores complejos para determinadas operaciones, pueden proporcionar su propia liquidez y realizar operaciones en nombre de los usuarios sin necesidad de puentes.
Implementar la abstracción de la cadena significa fusionar las tres capas de infraestructura anteriores en un producto unificado. Una idea clave para fusionar estas capas es la diferencia entre entrega de información y entrega de valor. La transferencia de información entre cadenas no debe producir pérdidas, así que confíe en el camino más seguro. Por ejemplo, los usuarios que votan "sí" en una cadena a un voto de gobernanza en otra cadena no quieren que su voto se convierta en "tal vez". Por otro lado, dependiendo de las preferencias del usuario, se puede perder la entrega de valor. Se puede aprovechar un tercero maduro para proporcionar a los usuarios una entrega de valor más rápida, más barata o garantizada. Es importante tener en cuenta que el 95% del espacio de bloque de Ethereum se utiliza para la transferencia de valor, según las tarifas pagadas a los validadores.
decisiones clave de diseño
Los tres niveles anteriores introducen las decisiones de diseño clave que CAF debe tomar. Estas decisiones involucran quién controla la autoridad para ejecutar la intención, qué información se revela al solucionador y qué vías de liquidación están disponibles para el solucionador. A continuación se muestra un análisis detallado de cada nivel.
Nivel de permiso
La capa de permiso contiene la clave privada del usuario y firma mensajes en nombre del usuario, que luego se ejecutan como transacciones en cadena. CAF debe respaldar los esquemas de firma y las cargas útiles de transacciones de todas las cadenas objetivo. Por ejemplo, las billeteras que admiten el esquema de firma ECDSA y el estándar de transacciones EVM se limitarán a Ethereum, su L2 y las cadenas laterales (como la billetera Metamask). Por otro lado, las billeteras que soportan EVM y SVM (Solana VM) podrán soportar estos dos ecosistemas (como la billetera Phantom). Cabe señalar que se puede utilizar la misma frase mnemotécnica para generar billeteras tanto en la cadena EVM como en la SVM.
Una transacción multicadena consta de múltiples subtransacciones que deben ejecutarse en el orden correcto. Estas subtransacciones deben ejecutarse en múltiples cadenas, cada una con sus propias tarifas y nonces que varían en el tiempo. La forma en que se coordinan y resuelven estas subtransacciones es una decisión de diseño clave para la capa de permisos.
La billetera EOA es un software de billetera que se ejecuta en la máquina del usuario y contiene su clave privada. Pueden ser extensiones basadas en navegador como Metamask y Phantom, aplicaciones móviles como Coinbase Wallet o hardware especializado como Ledger. Las billeteras EOA requieren que los usuarios firmen cada subtransacción individualmente, lo que actualmente requiere múltiples clics. También requieren que los usuarios mantengan saldos de tarifas en la cadena objetivo, lo que introduce una fricción significativa en el proceso. Sin embargo, al permitir a los usuarios firmar múltiples subtransacciones con un solo clic, se puede abstraer al usuario de la fricción de múltiples clics.
En una billetera de Abstracción de Cuenta (AA), los usuarios aún tienen acceso a sus claves privadas, pero separan al firmante de la carga útil de la transacción del ejecutor de la transacción. Permite a partes complejas agrupar y ejecutar transacciones de usuarios de forma atómica (Avocado, Pimlico). Las billeteras AA aún requieren que los usuarios firmen cada subtransacción individualmente (actualmente mediante múltiples clics), pero no requieren que se mantenga un saldo de tarifas en cada cadena.
Los agentes basados en políticas guardan la clave privada del usuario en un entorno de ejecución separado y generan mensajes firmados en nombre del usuario según la política del usuario. Telegram Bot, Near Account Aggregator o SUAVE TEE son billeteras basadas en estrategias, mientras que Entropy o Capsule son extensiones de billetera basadas en estrategias. Los usuarios solo necesitan firmar un formulario de aprobación, y estos agentes pueden completar la firma posterior de subtransacciones y la gestión de gastos durante la operación.
capa de solucionador
Después de que el usuario publica la intención, la capa de resolución implica devolver la tarifa y el tiempo de confirmación al usuario. Este tema está estrechamente relacionado con el diseño de subastas de flujo de órdenes y se analiza en detalle aquí. CAF puede aprovechar las rutas dentro del protocolo para ejecutar la intención del usuario, o aprovechar a terceros complejos (es decir, solucionadores) para comprometer ciertas garantías de seguridad para brindar a los usuarios una experiencia de usuario mejorada. La introducción de un solucionador en el marco CAF conduce a las siguientes dos decisiones de diseño, que están estrechamente relacionadas con la información.
Las intenciones constan de dos tipos de valores extraíbles (EV): valores EV_ordering y EV_signal.
EV_ordering es un valor específico de blockchain que normalmente extrae la entidad que ejecuta las órdenes de los usuarios (como los constructores de bloques o los validadores).
EV_signal representa el valor al que puede acceder cualquier entidad que cumpla con la orden antes de que se registre oficialmente en la cadena de bloques.
Las diferentes intenciones de los usuarios tienen diferentes distribuciones entre EV_ordering y EV_signal. Por ejemplo, la intención de intercambiar monedas en un DEX generalmente tiene un valor EV_ordering alto pero un valor EV_signal bajo. Por el contrario, el componente EV_signal de una transacción pirateada será mayor porque la ejecución anticipada ganará más valor que la ejecución de la transacción. Vale la pena señalar que EV_signal a veces puede ser negativo, como en el caso de las operaciones de los creadores de mercado, donde la entidad que ejecuta estas órdenes puede sufrir pérdidas ya que el creador de mercado tiene un mejor conocimiento de las condiciones futuras del mercado.
Cuando alguien es capaz de observar la intención de un usuario de antemano, puede adelantarse, provocando una fuga de valor. Además, la posibilidad de una señal EV_negativa crea un entorno competitivo entre los solucionadores, lo que les hace presentar ofertas más bajas, lo que provoca una mayor fuga de valor (también conocida como selección adversa). En última instancia, las filtraciones afectan a los usuarios al aumentar las tarifas u ofrecer mejores ofertas. Tenga en cuenta que las tarifas bajas o los precios aumentados son dos caras de la misma moneda y se utilizarán indistintamente a lo largo del resto de este artículo.
El intercambio de información
Hay tres formas de compartir información con el solucionador:
Mempool público: las intenciones del usuario se transmiten públicamente al mempool público o a la capa de disponibilidad de datos, y el primer solucionador que pueda satisfacer la solicitud ejecuta la orden y se convierte en el ganador. Este sistema extrae en gran medida la información del usuario porque los usuarios exponen su pedido_EV y su señal_EV. Por ejemplo, el mempool público de Ethereum y varios puentes blockchain. En el caso de un puente, los usuarios deben colocar los activos en custodia antes de transferirlos a la cadena de destino para evitar ataques maliciosos, pero este proceso hace públicas sus intenciones sin darse cuenta.
Compartir parcialmente: CAF puede reducir la cantidad de valor divulgado a los oferentes limitando la información divulgada. Sin embargo, este enfoque conducirá directamente a la pérdida de la optimización del precio y puede generar problemas como el spam de ofertas.
Mempools privados: los desarrollos recientes en MPC y TEE hacen posibles los mempools totalmente privados. No se filtra información fuera del entorno de ejecución y los solucionadores codifican sus preferencias y coinciden con cada intención. Aunque el mempool privado captura EV_ordering, no puede capturar EV_signal por completo. Por ejemplo, si se envía una transacción pirateada a Mempool, la primera persona que vea el pedido puede adelantarse a la transacción y capturar la señal EV. En un mempool privado, la información solo se publica después de que se confirma el bloqueo, por lo que cualquiera que vea la transacción puede capturar la señal EV. Es concebible que el solucionador establezca nodos de autenticación para capturar EV_signal de bloques de TEE recién creados, convirtiendo la captura de EV_signal en una competencia retrasada.
lista de solucionadores
La CAF también debe decidir cuántos y cuáles postores podrán participar en la subasta. Las principales opciones son las siguientes:
Acceso Abierto: La barrera de entrada más baja posible para la posibilidad de participar. Esto es similar a exponer mempool, que filtra EV_signal y EV_ordering.
Restringir el acceso: activar capacidades de ejecución de órdenes a través de listas blancas, sistemas de reputación, tarifas o subastas de asientos. El mecanismo de activación es necesario para garantizar que los solucionadores del sistema no capturen la señal EV_signal. Por ejemplo, subasta de 1 pulgada, subasta Cowswap y subasta Uniswap X. La competencia ganadora de pedidos captura EV_ordering para los usuarios, mientras que los mecanismos de activación capturan EV_signal para los generadores de pedidos (billeteras, dApps).
Acceso exclusivo: El acceso exclusivo es un formato de subasta especial en el que solo se selecciona un solucionador por período de tiempo. Dado que no se filtra información a otros solucionadores, no hay selección adversa ni descuentos anticipados. El iniciador del flujo de órdenes captura los valores esperados de EV_signal y EV_ordering porque sin competencia, los usuarios solo obtienen ejecuciones pero no mejoras de precios. Ejemplos de este tipo de subastas son las subastas Robinhood y DFlow.
capa de asentamiento
Una vez que una billetera firma un conjunto de transacciones, deben ejecutarse en la cadena de bloques. Las transacciones entre cadenas transforman el proceso de liquidación de una operación atómica a una operación asincrónica. Durante la ejecución y confirmación de la transacción inicial, el estado de la cadena de destino puede cambiar, lo que podría provocar que la transacción falle. Esta subsección explora las compensaciones entre el costo de seguridad, el tiempo de confirmación y las garantías de ejecución.
Es importante señalar que la ejecución de la transacción prevista en la cadena objetivo depende del mecanismo de inclusión de transacciones de la cadena objetivo, incluida la capacidad de revisar transacciones 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 está más allá del alcance de este artículo.
Oráculo de cadena cruzada
Dos blockchains con diferentes estados y mecanismos de consenso requieren de un intermediario, como un oráculo, para facilitar la transferencia de información entre ellas. El oráculo actúa como un relevo para la transferencia de información entre cadenas, incluida la verificación de que un usuario haya bloqueado fondos en una cuenta de depósito en garantía en un puente de bloqueo y acuñación, o la confirmación del saldo de tokens de un usuario en la cadena original para participar en las votaciones de gobernanza en la cadena. cadena objetivo.
El oráculo transmite información a la velocidad de la cadena más lenta. Esto es para gestionar el riesgo de reorganización, porque el oráculo necesita esperar el consenso de la cadena original. Supongamos que un usuario quiere conectar USDC desde la cadena original a la cadena de destino y, para ello, bloquea sus fondos en depósito de garantía. Sin embargo, pueden surgir problemas si el oráculo no espera suficientes confirmaciones y continúa acuñando tokens para el usuario en la cadena de destino. Si se produce una reorganización y los usuarios sobrescriben sus transacciones de depósito en garantía, Oracle provocará un doble gasto.
Hay dos tipos de oráculos:
Oráculos fuera de protocolo: deben estar separados de los validadores externos que ejecutan el consenso para pasar información entre cadenas. Los validadores adicionales aumentan el costo de ejecutar un oráculo. LayerZero, Wormhole, ChainLink y Axelar Networks son ejemplos de oráculos fuera de protocolo.
Oráculos dentro del protocolo: profundamente integrados en el algoritmo de consenso del ecosistema y comunican información utilizando el conjunto de validadores que ejecutan el consenso. El IBC de Cosmos se utiliza para cadenas que ejecutan Cosmos SDK, el ecosistema Polygon está desarrollando AggLayer y Optimism está desarrollando Superchain. Cada oráculo utiliza un espacio de bloque dedicado para pasar información entre cadenas en el mismo ecosistema.
Los secuenciadores compartidos son entidades fuera del protocolo que tienen derechos de ordenación de transacciones dentro del protocolo, es decir, pueden agrupar transacciones entre cadenas. Aunque todavía está en desarrollo, el secuenciador compartido no tiene que esperar confirmaciones de bloques específicos para reducir el riesgo de reorganizaciones. Para lograr verdaderamente la atomicidad entre cadenas, el secuenciador compartido debe poder ejecutar transacciones posteriores si las transacciones anteriores tienen éxito, convirtiéndolas así en cadenas.
ficha puente
En un mundo de múltiples cadenas, los saldos de tokens y tarifas de un usuario están dispersos en todas las redes. Antes de cada operación entre cadenas, los usuarios deben transferir fondos de la cadena original a la cadena de destino. Actualmente hay 34 puentes entre cadenas activos con un TVL total de $ 7,7 mil millones y un volumen de puentes en los últimos 30 días de $ 8,6 mil millones.
Los tokens puente son un caso de transferencia de valor. Esto crea oportunidades para aprovechar a terceros profesionales que sean buenos en la gestión de capital y estén dispuestos a asumir riesgos de reestructuración, reduciendo el costo y el tiempo necesarios para que los usuarios negocien.
Hay dos tipos de puentes de cadenas cruzadas:
Lock and Mint Bridge: Lock and Mint Bridge verifica los depósitos de tokens en la cadena original y acuña tokens en la cadena de destino. El capital necesario para lanzar un puente de este tipo es pequeño, pero la transferencia segura de información bloqueada requiere una inversión significativa. Las violaciones de seguridad en estos puentes provocaron pérdidas de miles de millones de dólares para los poseedores de tokens.
Puente de liquidez: Liquidity Bridge utiliza los grupos de liquidez en la cadena original y la cadena de destino, y utiliza algoritmos para determinar la tasa de conversión entre la cadena original y el token de destino. Si bien estos puentes tienen un costo inicial más alto, requieren menores garantías de seguridad. Si se produce una violación de seguridad, sólo los fondos del fondo de liquidez están en riesgo.
En ambos puentes entre cadenas, los usuarios deben pagar costos de liquidez. En un puente de bloqueo y acuñación, se incurre en el costo de liquidez al intercambiar del token envuelto al token deseado (USDC.e a USDC) en la cadena objetivo, mientras que en un puente de liquidez, se incurre en el costo de liquidez al intercambiar del original. token a USDC Ocurre cuando los tokens de la cadena se intercambian por tokens de la cadena de destino.
Trilema entre cadenas
Las cinco decisiones de diseño anteriores plantean el trilema entre cadenas. CAF debe elegir dos atributos entre garantía de ejecución, tarifas bajas y velocidad de ejecución.
Ruta intraprotocolo: es la ruta de transmisión de información entre cadenas designada. Estos sistemas tienen en cuenta el riesgo de reorganización, sacrificando la velocidad de ejecución pero reduciendo los costos al eliminar conjuntos de validadores adicionales o costos de liquidez.
Agregación de solucionadores: recopile citas de múltiples solucionadores para identificar la ruta más barata y rápida para ejecutar la intención del usuario. Sin embargo, debido a la selección adversa y al avance, a veces el solucionador puede no cumplir con la intención, lo que resulta en una ejecución reducida.
Competencia de ejecución: seleccione el solucionador ganador organizándolos para competir con los intentos de ejecución o seleccionando un único solucionador. Ambos enfoques generan altas tarifas para los usuarios, ya que los solucionadores compiten por la ejecución en lugar de por mejoras de precios.
Los seis componentes de CAKE
Para este artículo, estudiamos más de 20 diseños de equipos que trabajan directa e indirectamente en la abstracción de la cadena. En esta sección, analizamos seis implementaciones de CA independientes que creemos que tienen una eficiencia inherente y un ajuste entre el producto y el mercado. Si se construyen correctamente, estos diseños tienen el potencial de combinarse entre sí.
Una conclusión clave es que necesitamos un estándar unificado para la expresión de intenciones entre cadenas. Cada equipo está trabajando en sus propios métodos y protocolos para codificar la intención del usuario. Un estándar unificado mejorará la comprensión de los usuarios de sus mensajes firmados, facilitará que los solucionadores y oráculos comprendan estas intenciones y simplificarán la integración con las billeteras.
Puente designado con token
Existe un caso especial de puentes lock-and-mint que no pagan costos de liquidez, también conocidos como puentes burn-and-mint (por ejemplo, USDC CCTP). El equipo de tokens asigna una dirección de token canónica en cada cadena y el puente tiene la autoridad para acuñar los tokens que el usuario necesita.
Si observa de cerca, verá que el puente Burn and Mint es similar a una transferencia entre cadenas con suficiente velocidad de confirmación de bloque. xERC 20 es un estándar para especificar tokens canónicos y sus puentes delegados en una cadena de destino. Los puentes especificados por tokens son un ejemplo de una ruta intraprotocolo que sacrifica la velocidad por una ejecución garantizada y tarifas bajas; por ejemplo, CCTP tarda 20 minutos en completar una transferencia.
Puente de Coordinación de Ecosistemas
El Puente de Coordinación del Ecosistema puede transmitir mensajes arbitrarios entre cadenas dentro del mismo ecosistema. Estos puentes son vías intraprotocolo que priorizan las garantías de ejecución y las tarifas bajas por encima de la velocidad. Los ejemplos incluyen Cosmos IBC, Polygon AggLayer y Optimism Superchain.
Hace tres años, el ecosistema Cosmos enfrentó desafíos similares a los que enfrenta Ethereum hoy. La liquidez está dispersa en varias cadenas, cada cadena tiene su propio token de tarifa y la gestión de cuentas multicadena es muy engorrosa. El ecosistema Cosmos resuelve estos problemas implementando un puente de mensajería intraprotocolo IBC, que permite una gestión fluida de cuentas multicadena y transferencias entre cadenas.
El ecosistema Cosmos consta de cadenas independientes con seguridad soberana y finalidad rápida, lo que hace que la mensajería entre cadenas dentro del protocolo sea muy rápida. El ecosistema de resumen se basa en el final del período de desafío (resumen optimista) o la presentación de pruebas zk (resumen de validez) para lograr la finalidad. Debido a estas limitaciones de finalidad, la entrega de mensajes en todo el ecosistema será más lenta.
Competencia de precios de solucionador
La competencia de precios de los solucionadores implica compartir información de pedidos con todos los solucionadores. El solucionador está diseñado para combinar el valor esperado (EV) generado por la intención del pedido y proporcionárselo al usuario. La selección del Solver ganador en el sistema se basa en maximizar la mejora del precio al usuario. Sin embargo, este diseño conlleva el riesgo de no ejecución y requiere mecanismos adicionales para garantizar la confiabilidad de la orden. Ejemplos de tales mecanismos incluyen Uniswap X, Bungee y Jumper.
Mensajes de conciliación de billetera
Los mensajes de coordinación de billeteras aprovechan las características proporcionadas por AA o billeteras basadas en políticas para brindar una experiencia entre cadenas compatible con cualquier tipo de intención. Actúa como el agregador de CA definitivo, redirigiendo la intención del usuario entre varios diseños de CA para abordar una intención específica. Los ejemplos incluyen Avocado Wallet, Near Account Aggregator y Metamask Portfolio.
Es importante señalar que durante la última década, el ecosistema criptográfico ha aprendido que la relación entre los usuarios y sus billeteras es muy complicada. Cada vez que pienso en migrar mi frase mnemotécnica de Metamask a otra billetera, me siento extremadamente aterrorizado. Esta es también la razón por la que EIP-4337 todavía tiene una tasa de adopción baja después de dos años y medio, incluso con el apoyo del propio Vitalik Buterin. Aunque las versiones más nuevas del protocolo de billetera pueden ofrecer a los usuarios mejores precios (abstracción de cuentas) o mayor facilidad de uso (billeteras basadas en políticas), migrar a los usuarios desde sus billeteras actuales es una tarea desalentadora.
Competición de velocidad de solucionador
La competencia de velocidad del solucionador permite a los usuarios expresar intenciones para transformaciones específicas entre cadenas para obtener altas garantías de ejecución. No ayuda a los usuarios a minimizar las tarifas, pero proporciona un canal confiable para contener transacciones complejas. El primer solucionador que ejecute una intención basada en las tarifas del creador de bloques o incluya la velocidad ganará esa intención.
El diseño tiene como objetivo lograr altas tasas de inclusión maximizando el EV capturado por el Solver. Sin embargo, esto tiene el costo de la centralización, ya que depende de una gestión de capital compleja en la red principal de Ethereum o de una ejecución de baja latencia en L2.
Subasta masiva exclusiva
Una subasta por lotes exclusiva realiza una subasta por el derecho exclusivo de ejecutar todo el flujo de órdenes dentro de un período de tiempo. Como otros solucionadores no pueden ver las órdenes, ofertan en función de la volatilidad prevista del mercado y la calidad media de ejecución. Las subastas por lotes exclusivas se basan en un precio alternativo para garantizar buenos precios para los usuarios y, por lo tanto, no pueden utilizarse para mejorar los precios. Enviar todo el flujo de pedidos a un único postor elimina la fuga de información y mejora la garantía de ejecución.
en conclusión
Chain Abstraction Framework (CAF) promete proporcionar a los usuarios interacciones fluidas entre cadenas. En este artículo, examinamos diseños en producción y desarrollo de varios equipos que explícita o implícitamente intentan resolver el problema de la abstracción de la cadena. Creemos que este será el año de CAF y esperamos que se produzca una competencia significativa entre diferentes diseños y sus implementaciones durante los próximos 6 a 12 meses.
Las transferencias de valor entre cadenas se habilitarán mediante puentes delegados de tokens para obtener tarifas bajas y una ejecución rápida a través de la velocidad del solucionador o competencias de precios. Las transferencias de mensajes se enrutan a través de puentes de mensajería que coinciden con el ecosistema, diseñados para minimizar los costos del usuario y maximizar la velocidad a través de una plataforma controlada por billetera. En última instancia, estas seis opciones de diseño diferentes formarán un grupo porque cada una de ellas satisface diferentes necesidades y aprovecha las eficiencias en diferentes áreas de la matriz de compensaciones.
Una conclusión importante que obtuvimos de este proceso es que necesitamos un estándar común para expresar intenciones entre cadenas. Actualmente, varios equipos están trabajando de forma independiente en protocolos para codificar la intención del usuario, lo que genera una duplicación de esfuerzos. Un estándar unificado ayudará a mejorar la comprensión de los usuarios de los mensajes firmados, facilitará que los solucionadores y oráculos procesen la intención y simplificará la integración con las billeteras.
Enlace original
