En el ecosistema Web3, el puente entre cadenas es una parte muy importante. Es una instalación clave para romper los silos entre cadenas y lograr la interconexión entre cadenas. En el pasado, la gente era muy activa en la exploración y práctica de la tecnología cross-chain. El número de productos de puentes de cadena cruzada relacionados ha llegado a cientos. Algunos están comprometidos con la construcción de una capa de interoperabilidad unificada, mientras que otros están tratando de abrir la circulación de activos multicadena. Tienen diferentes visiones y compensaciones en términos de soluciones técnicas.
Lo que este artículo quiere discutir es: ¿Cuál es el futuro de los puentes entre cadenas? ¿Qué tipo de protocolos entre cadenas son más prometedores? ¿Qué aplicaciones entre cadenas son más propensas a obtener una adopción masiva? ¿Cómo deberían los desarrolladores construir aplicaciones entre cadenas? A continuación, el autor discutirá la tendencia de desarrollo de los puentes entre cadenas y presentará tres argumentos principales:
Una nueva generación de puentes intercadenas seguros y de alto rendimiento se convertirá en la corriente principal
Las aplicaciones de cadena completa se convertirán en un nuevo paradigma de dApp
·Los puentes oficiales de emisores de activos como USDC reemplazarán a los puentes de intercambio de liquidez
La tecnología intercadena se puede entender como una extensión de la expansión de la capacidad. Cuando una cadena no es suficiente para llevar todas las solicitudes de transacción, permita que varias cadenas las lleven y utilicen puentes intercadena para conectarlas. Para entender los puentes intercadena, primero debemos aclarar qué problemas necesitan resolver los puentes intercadena, para así dividirlos en diferentes niveles.
El núcleo de la capa de protocolo es un mecanismo de seguridad para la transmisión de mensajes entre cadenas, es decir, un método para verificar mensajes entre cadenas. Según los diferentes métodos de verificación y las ideas de Vitalik y otros, la industria ha dividido los puentes entre cadenas en tres tipos: intercambio atómico basado en bloqueos de tiempo de hash, verificación de testigos y verificación de clientes ligeros. Más tarde, el fundador de Connext, Arjun Bhuptani, resumió los puentes entre cadenas en tres paradigmas: verificación local, verificación externa y verificación nativa.
Entre ellos, la verificación local solo se aplica a los activos entre cadenas, no puede admitir ningún mensaje entre cadenas y la experiencia del usuario no es amigable (requiere dos acciones del usuario para completar una transacción). Algunos de los primeros puentes de cadena cruzada que adoptaron este esquema han cambiado de rumbo y han abandonado esta ruta. La verificación nativa es la más segura, pero el costo es demasiado alto. Por un lado, el coste del gas para los usuarios es demasiado alto, e incluso en algunos casos no es económicamente viable en absoluto. Por otro lado, el costo de codificación para los desarrolladores es demasiado alto. Para conectarse a diferentes cadenas de bloques, deben desarrollar por separado los correspondientes programas de verificación de clientes ligeros. La cantidad de ingeniería es extremadamente grande y el ámbito de aplicación es extremadamente limitado. Por último, la mayoría de los puentes entre cadenas siguen utilizando soluciones de verificación externas. Los costos de gas del usuario y los costos de desarrollo e implementación son relativamente bajos y respaldan cualquier mensaje a lo largo de la cadena. Sin embargo, lo que más se ha criticado de la verificación externa es la seguridad. Ya sea Multichian, que experimentó tormentas eléctricas este año, o RoninBridge (Puente Oficial de Axie Infinity) y HorizenBridge (Puente Oficial de Harmony Chain), a los que los hackers les robaron las llaves, todos nos dicen que una simple solución de verificación externa no puede ser el fin de los puentes entre cadenas.
Los riesgos de seguridad de los puentes entre cadenas cruzadas obstaculizan el desarrollo de las aplicaciones descentralizadas entre cadenas. La capa de aplicación es muy cuidadosa al diseñar servicios correspondientes. En primer lugar, es necesario evitar enlaces relacionados con la interoperabilidad entre cadenas tanto como sea posible, y en segundo lugar, las aplicaciones conocidas tienden a construir sus propios puentes entre cadenas (este es el caso de los principales proyectos DeFi como AAVE, Maker y Compound). Como puedes imaginar, en una ciudad con una seguridad muy deficiente, la gente elegiría no viajar, y los ricos llevarían sus propios guardaespaldas cuando viajan.
Lo alentador, sin embargo, es que está creciendo rápidamente una nueva generación de puentes cruzados más seguros. Entre ellos se encuentran puentes de doble capa de seguridad como LayerZero y Chainlink CCIP; puentes ZK (proyectos representativos: Polyhedra, MAP Protocol, Way Network) que combinan la tecnología ZK con clientes ligeros; puentes de verificación optimista que utilizan mecanismos de juego económico para proteger la seguridad cruzada (proyectos representativos: Nomad, cBridge); y aquellos que combinan tecnologías de ZK y TEE Bridge (proyecto representativo: Bool Network).
En resumen, la infraestructura de puente de cadena cruzada de próxima generación logra una mayor seguridad sin sacrificar el rendimiento, proporcionando una garantía sólida para la capa de aplicación en diseños relacionados con la interoperabilidad de cadena cruzada.
Inicialmente, casi todas las dApps se desplegaron en Ethereum porque no existían otras opciones. Sin embargo, con la prosperidad del ecosistema de la capa de aplicaciones, Ethereum se vio abrumado. Esto dio a otras cadenas públicas la oportunidad de desarrollarse. Varios asesinos de ETH, así como sidechains y Capa 2, aparecieron uno tras otro.
Desde la perspectiva de las dApps, Ethereum es una megaciudad como Shanghai, que tiene una gran población pero recursos limitados y poco dinero. Si mi escenario comercial requiere un alto rendimiento pero no requiere una alta interoperabilidad, entonces puedo implementarlo en una cadena lateral que no esté demasiado abarrotada. Por ejemplo, no es necesario abrir una fábrica de impresión o una plantación en Shanghai; puedes elegir una ubicación en las afueras. La historia de dYdX dejando Ethereum probablemente sea familiar para todos.
Al mismo tiempo, una dApp puede implementarse en múltiples cadenas para participar en "operaciones de cadena", atender a usuarios en diferentes cadenas, y expandir escala y ingresos. Por ejemplo, Sushiswap, el primer caso exitoso de un ataque vampiro, fue desplegado frenéticamente en 28 cadenas. Como podemos imaginar, básicamente hay Sushiswap en la cadena pública del nombre.
Sin embargo, este ecosistema de aplicaciones multi-cadena ha brindado a los usuarios una experiencia muy pobre: para interactuar con aplicaciones en diferentes cadenas, también es necesario comprender las diferencias entre las diferentes cadenas, registrar direcciones en múltiples cadenas, recargar las tarifas de gas en cada cadena, y finalmente mover activos de un lado a otro entre diferentes cadenas. ¡Dios mío, es tan agotador!
Más importante aún, muchos protocolos DeFi implican el uso de liquidez. Si despliegas en múltiples cadenas, debes guiar la liquidez en múltiples cadenas. Esto hará que la liquidez se disperse en diferentes cadenas y no se comparta en profundidad, lo que causará un mayor impacto en el precio para los usuarios al operar. En respuesta, algunas personas están preocupadas por el desarrollo de Ethereum L2, creyendo que L2 puede descomponer la liquidez de Ethereum y hacer que pierda su ventaja competitiva. También hay investigadores que han propuesto una solución unificada de liquidez como SLAMM, pero esta solución crea más problemas de los que resuelve. Es bastante pobre, así que no entraré en detalles aquí. Los amigos interesados pueden consultar los materiales relevantes.
La verdadera pregunta central es: ¿cómo se pueden agregar los recursos y ecosistemas en cada cadena para que los usuarios no tengan que ser conscientes de la existencia de una 'cadena'? Por ejemplo, tengo 1 ETH, ¿puedo usarlo donde quiera y ocultar el proceso de intercambio automático y pago de gas en diferentes cadenas? Quiero usar una aplicación, ¿puedo usarla en cualquier cadena sin cruzar activos? Al mismo tiempo, la parte del proyecto ya no tiene que hacer cola para seleccionar una cadena. En lugar de desplegar repetidamente en múltiples cadenas, se puede implementar en la cadena más adecuada, ¿y luego las personas en diferentes cadenas pueden usarla?
La capa de aplicación requiere un nuevo paradigma para ocultar la capa de “cadena”. Algunas personas imitaron el concepto de “abstracción de cuenta” y acuñaron un nuevo término llamado “abstracción de cadena”, que es lo que significa. ¡Veamos cómo funciona un proyecto de LSD?
Por ejemplo, Bifrost afirma ser el pionero de LSD de cadena completa, utilizando una arquitectura diferente a la de otros productos de LSD. Bifrost tiene su propia cadena, Bifrost Parachain, que es la parachain de Polkadot. El módulo de participación de liquidez de Bifrost solo se implementa en Bifrost Parachain, y la liquidez de su activo LSD, vToken, también se encuentra en Bifrost Parachain, pero otras cadenas pueden usar el módulo de participación de liquidez de Bifrost Parachain y la liquidez a través de llamadas remotas. Como resultado:
Los usuarios no pueden sentir en absoluto el proceso de entrega entre cadenas detrás de estas operaciones. Todo es como si se hiciera localmente. Todos pueden experimentarlo a través de la aplicación Omni LSD dApp. Actualmente, la aplicación Omni LSD dApp admite la creación/canjeo/intercambio remotos de vTokens en Ethereum, Moonbeam, Moonriver y AStar.
Sin las características anteriores, si los usuarios desean depositar vDOT en Moonbeam, ¡deben operar manualmente tres pasos, lo cual es muy molesto!
① Transferir DOT de Moonbeam cross-chain a Bifrost
② Obtenga vDOT apostando DOT en la cadena Bifrost
③ Transfer vDOT de cadena cruzada de regreso a MoonBeam
Sin embargo, a través de la función de llamada remota, los activos del usuario parecen poder completar los tres pasos anteriores sin salir de la cadena Moonbeam y convertir directamente DOT en vDOT en la cadena Moonbeam. En otras palabras, a lo largo del proceso, los usuarios experimentan los servicios en la cadena Bifrost como si estuvieran utilizando la aplicación local de Moonbeam.
¡Suena bastante genial! ¿Pero cómo se puede lograr esto? En realidad, no es complicado. Bifrost ha desplegado un módulo remoto (modular remoto) en otras cadenas para recibir las solicitudes de los usuarios y pasarlas a través de las cadenas hasta la Parachain de Bifrost. Después de que se complete el procesamiento del módulo de garantía de liquidez, los resultados se devuelven al módulo remoto a través de la cadena. Los usuarios solo necesitan hacer solicitudes en la cadena remota, y el proceso posterior será desencadenado y completado por los retransmisores.
Bifrost se refiere a su arquitectura como una “arquitectura de cadena completa”. La comparación con las estrategias de implementación de múltiples cadenas de otros protocolos LSD se muestra a continuación:
La razón para hablar tan firmemente sobre la arquitectura de Bifrost es para que todos puedan entender completamente a lo que Bifrost se refiere como una "arquitectura de cadena completa". Lo que la arquitectura de Bifrost realmente representa es un nuevo paradigma general.
En su publicación de blog 'Contrato inteligente entre cadenas', Chainlink describió una vez esta arquitectura como un modelo 'tienda principal+sucursal'. La lógica principal de la aplicación se coloca en una cadena, como una 'tienda principal', y luego las otras cadenas proporcionan un módulo de acceso remoto para permitir la interacción con los usuarios finales (obtener la entrada del usuario y producir los resultados deseados), al igual que 'tiendas' una por una.
Después de que la tienda obtiene la entrada del usuario, la entrada se pasa a través de la cadena a la tienda principal, la tienda principal ingresa los resultados después del procesamiento, y luego transmite los resultados a través de la cadena a la tienda para la salida al usuario. En algunos casos, los diferentes módulos de la tienda principal pueden dividirse en diferentes cadenas, y juntos forman una tienda principal virtual. Bajo esta arquitectura, la lógica principal del programa está en la tienda principal, la aplicación tiene un registro de estado unificado, y los problemas de liquidez fragmentada y experiencia del usuario se han resuelto. Además, la aplicación de esta arquitectura también tiene una mejor composabilidad entre cadenas, y las aplicaciones en otras cadenas también pueden acceder de forma remota a la función de la tienda principal como lo hacen los usuarios en otras cadenas.
Aunque Bifrost se refiere a esta estructura como una arquitectura de “cadena completa,” al autor personalmente no le gusta realmente el término “cadena completa,” u Omni-Chain, porque es un término con un significado poco claro. Inicialmente, LayerZero inventó el término para resaltar su escalabilidad sin igual, pero LayerZero nunca explicó completamente qué es en realidad “cadena completa.” ¿Es “toda la cadena”? Definitivamente no; ninguna aplicación se ejecuta en cada cadena. El autor tiene un proyecto de juego que dice que están haciendo un juego de cadena completa. Solo aprendí que “cadena completa” significa “todo el código está en la cadena,” lo que distingue solo algunos juegos Web3 con datos de activos en la cadena, que no son compatibles con el estilo de “cadena completa” descrito por LayerZero.
Creo que la expresión más apropiada es "abstracción de cadena", Abstracción de Cadena o Agnóstico de Cadena (no relacionado con la cadena); ambas pueden expresar un estado donde "los usuarios no necesitan preocuparse por la cadena".
Finalmente, queremos hablar de otra proposición importante en el sector de la cadena cruzada — liquidez. Primero, averigüemos de qué nivel de problema se trata. La liquidez no pertenece a la capa del protocolo porque no está relacionada con la transmisión segura y ordenada de mensajes entre cadenas. Pertenece a la capa de aplicación, y es un tipo especial de aplicación - SwapBridge.
La categoría más grande de aplicaciones entre cadenas debe ser puentes de activos. Los puentes de activos también se dividen en WrapBridge y SwapBridge. El primero ayuda a los usuarios a lograr la transferencia de activos a través de la lógica de bloqueo-acuñación/quema-desbloqueo, también conocido como un "puente de transferencia de activos", mientras que SwapBridge ayuda a los usuarios a lograr el intercambio directo de activos nativos reservando liquidez en múltiples cadenas, también conocido como "puentes de intercambio de liquidez".
Entre ellos, SwapBridge tiene la gama más amplia de aplicaciones y muchos proyectos. Los diferentes proyectos de SwapBridge compiten esencialmente por la eficiencia de la liquidez. ¿Quién puede proporcionar a los usuarios la máxima profundidad con gastos de liquidez mínimos? En otras palabras, la liquidez es el núcleo del servicio proporcionado por SwapBridge. Todos compiten por quién tiene la mejor ventaja de costos. Esta es la misma lógica que en la competencia comercial en general. Lo que todos necesitan entender aquí es que la ventaja de costos creada por la estrategia de subvención es insostenible; se debe tener una ventaja en términos de diseño del mecanismo de liquidez.
Pero CCTP, lanzado por el emisor de USDC Circle, hizo que muchos esfuerzos de SwapBridge fueran irrelevantes; en otras palabras, CCTP destruyó SwapBridge. Se siente como si la Civilización de los Tres Cuerpos hubiera tomado cientos de millones de años y más de 200 rondas de civilización para resolver el Problema de los Tres Cuerpos, pero al final Circle te dice: ¡El Problema de los Tres Cuerpos está sin resolver! Por ejemplo, en el intercambio entre cadenas de activos, USDC es el activo medio más utilizado. En otras palabras, cuando necesitas intercambiar activos A en la cadena X por activos B en la cadena Y, a menudo necesitas intercambiar A por USDC en la cadena X, luego reemplazar USDC en la cadena X por USDC en la cadena Y, y luego intercambiar USDC por el activo B en la cadena Y.
Por lo tanto, la principal forma de liquidez que SwapBridge reserva en varias cadenas es USDC. CCTP puede luego soportar USDC en la cadena X para ser intercambiado directamente por USDC nativo en la cadena Y a través de la lógica de quemado-creación sin la necesidad de reservas de liquidez. En otras palabras, CCTP no tiene costos de liquidez en absoluto, y las tarifas del puente experimentadas por el usuario pueden ser extremadamente bajas.
Quizás dirías que además de USDC, ¿no hay también USDT como un activo de medios comúnmente utilizado? Sin mencionar en el sector DEX, la tasa de uso de USDT es mucho menor que la de USDC, así que no temas aprender sobre Tether y Circle. ¿Puedes idear esto? Entonces, lo que quiero decirte es que SwapBridge está muerto, y el puente oficial del emisor de activos tendrá una ventaja de costo inigualable en cuanto a liquidez entre cadenas. En cuanto a algunos SwapBridges que en su lugar integran CCTP, eso es lógica de agregador.
La capa del protocolo puente entre cadenas está volviéndose más segura y confiable, y la era de los puentes de firmas múltiples está llegando a su fin. En el pasado, la impresión de que las cadenas cruzadas eran inseguras desaparecerá con la popularización de la infraestructura de cadenas cruzadas de próxima generación;
Las aplicaciones entre cadenas están mejorando enormemente la experiencia del usuario a través de la iteración de paradigmas. La "abstracción de cadena" no es menos significativa que la "abstracción de cuenta", y está creando condiciones para la manipulación masiva de Web3;
CCTP lanzado por Circle puso fin a la era Sengoku de la competencia de liquidez de SwapBridge, y nos mostró el final del intercambio de activos entre cadenas.
En resumen, ¡el sector interconectado está experimentando cambios drásticos! Solo entendiendo el camino a seguir podemos caminar con más confianza.
En pocas palabras, un puente entre cadenas se puede dividir en una capa de protocolo y una capa de aplicación. La capa de protocolo es responsable de proporcionar una plataforma segura y ordenada para la mensajería entre cadenas, mientras que la capa de aplicación construye dApps basadas en esta plataforma para dirigirse a los usuarios y satisfacer diversas necesidades en diferentes escenarios.
En el ecosistema Web3, el puente entre cadenas es una parte muy importante. Es una instalación clave para romper los silos entre cadenas y lograr la interconexión entre cadenas. En el pasado, la gente era muy activa en la exploración y práctica de la tecnología cross-chain. El número de productos de puentes de cadena cruzada relacionados ha llegado a cientos. Algunos están comprometidos con la construcción de una capa de interoperabilidad unificada, mientras que otros están tratando de abrir la circulación de activos multicadena. Tienen diferentes visiones y compensaciones en términos de soluciones técnicas.
Lo que este artículo quiere discutir es: ¿Cuál es el futuro de los puentes entre cadenas? ¿Qué tipo de protocolos entre cadenas son más prometedores? ¿Qué aplicaciones entre cadenas son más propensas a obtener una adopción masiva? ¿Cómo deberían los desarrolladores construir aplicaciones entre cadenas? A continuación, el autor discutirá la tendencia de desarrollo de los puentes entre cadenas y presentará tres argumentos principales:
Una nueva generación de puentes intercadenas seguros y de alto rendimiento se convertirá en la corriente principal
Las aplicaciones de cadena completa se convertirán en un nuevo paradigma de dApp
·Los puentes oficiales de emisores de activos como USDC reemplazarán a los puentes de intercambio de liquidez
La tecnología intercadena se puede entender como una extensión de la expansión de la capacidad. Cuando una cadena no es suficiente para llevar todas las solicitudes de transacción, permita que varias cadenas las lleven y utilicen puentes intercadena para conectarlas. Para entender los puentes intercadena, primero debemos aclarar qué problemas necesitan resolver los puentes intercadena, para así dividirlos en diferentes niveles.
El núcleo de la capa de protocolo es un mecanismo de seguridad para la transmisión de mensajes entre cadenas, es decir, un método para verificar mensajes entre cadenas. Según los diferentes métodos de verificación y las ideas de Vitalik y otros, la industria ha dividido los puentes entre cadenas en tres tipos: intercambio atómico basado en bloqueos de tiempo de hash, verificación de testigos y verificación de clientes ligeros. Más tarde, el fundador de Connext, Arjun Bhuptani, resumió los puentes entre cadenas en tres paradigmas: verificación local, verificación externa y verificación nativa.
Entre ellos, la verificación local solo se aplica a los activos entre cadenas, no puede admitir ningún mensaje entre cadenas y la experiencia del usuario no es amigable (requiere dos acciones del usuario para completar una transacción). Algunos de los primeros puentes de cadena cruzada que adoptaron este esquema han cambiado de rumbo y han abandonado esta ruta. La verificación nativa es la más segura, pero el costo es demasiado alto. Por un lado, el coste del gas para los usuarios es demasiado alto, e incluso en algunos casos no es económicamente viable en absoluto. Por otro lado, el costo de codificación para los desarrolladores es demasiado alto. Para conectarse a diferentes cadenas de bloques, deben desarrollar por separado los correspondientes programas de verificación de clientes ligeros. La cantidad de ingeniería es extremadamente grande y el ámbito de aplicación es extremadamente limitado. Por último, la mayoría de los puentes entre cadenas siguen utilizando soluciones de verificación externas. Los costos de gas del usuario y los costos de desarrollo e implementación son relativamente bajos y respaldan cualquier mensaje a lo largo de la cadena. Sin embargo, lo que más se ha criticado de la verificación externa es la seguridad. Ya sea Multichian, que experimentó tormentas eléctricas este año, o RoninBridge (Puente Oficial de Axie Infinity) y HorizenBridge (Puente Oficial de Harmony Chain), a los que los hackers les robaron las llaves, todos nos dicen que una simple solución de verificación externa no puede ser el fin de los puentes entre cadenas.
Los riesgos de seguridad de los puentes entre cadenas cruzadas obstaculizan el desarrollo de las aplicaciones descentralizadas entre cadenas. La capa de aplicación es muy cuidadosa al diseñar servicios correspondientes. En primer lugar, es necesario evitar enlaces relacionados con la interoperabilidad entre cadenas tanto como sea posible, y en segundo lugar, las aplicaciones conocidas tienden a construir sus propios puentes entre cadenas (este es el caso de los principales proyectos DeFi como AAVE, Maker y Compound). Como puedes imaginar, en una ciudad con una seguridad muy deficiente, la gente elegiría no viajar, y los ricos llevarían sus propios guardaespaldas cuando viajan.
Lo alentador, sin embargo, es que está creciendo rápidamente una nueva generación de puentes cruzados más seguros. Entre ellos se encuentran puentes de doble capa de seguridad como LayerZero y Chainlink CCIP; puentes ZK (proyectos representativos: Polyhedra, MAP Protocol, Way Network) que combinan la tecnología ZK con clientes ligeros; puentes de verificación optimista que utilizan mecanismos de juego económico para proteger la seguridad cruzada (proyectos representativos: Nomad, cBridge); y aquellos que combinan tecnologías de ZK y TEE Bridge (proyecto representativo: Bool Network).
En resumen, la infraestructura de puente de cadena cruzada de próxima generación logra una mayor seguridad sin sacrificar el rendimiento, proporcionando una garantía sólida para la capa de aplicación en diseños relacionados con la interoperabilidad de cadena cruzada.
Inicialmente, casi todas las dApps se desplegaron en Ethereum porque no existían otras opciones. Sin embargo, con la prosperidad del ecosistema de la capa de aplicaciones, Ethereum se vio abrumado. Esto dio a otras cadenas públicas la oportunidad de desarrollarse. Varios asesinos de ETH, así como sidechains y Capa 2, aparecieron uno tras otro.
Desde la perspectiva de las dApps, Ethereum es una megaciudad como Shanghai, que tiene una gran población pero recursos limitados y poco dinero. Si mi escenario comercial requiere un alto rendimiento pero no requiere una alta interoperabilidad, entonces puedo implementarlo en una cadena lateral que no esté demasiado abarrotada. Por ejemplo, no es necesario abrir una fábrica de impresión o una plantación en Shanghai; puedes elegir una ubicación en las afueras. La historia de dYdX dejando Ethereum probablemente sea familiar para todos.
Al mismo tiempo, una dApp puede implementarse en múltiples cadenas para participar en "operaciones de cadena", atender a usuarios en diferentes cadenas, y expandir escala y ingresos. Por ejemplo, Sushiswap, el primer caso exitoso de un ataque vampiro, fue desplegado frenéticamente en 28 cadenas. Como podemos imaginar, básicamente hay Sushiswap en la cadena pública del nombre.
Sin embargo, este ecosistema de aplicaciones multi-cadena ha brindado a los usuarios una experiencia muy pobre: para interactuar con aplicaciones en diferentes cadenas, también es necesario comprender las diferencias entre las diferentes cadenas, registrar direcciones en múltiples cadenas, recargar las tarifas de gas en cada cadena, y finalmente mover activos de un lado a otro entre diferentes cadenas. ¡Dios mío, es tan agotador!
Más importante aún, muchos protocolos DeFi implican el uso de liquidez. Si despliegas en múltiples cadenas, debes guiar la liquidez en múltiples cadenas. Esto hará que la liquidez se disperse en diferentes cadenas y no se comparta en profundidad, lo que causará un mayor impacto en el precio para los usuarios al operar. En respuesta, algunas personas están preocupadas por el desarrollo de Ethereum L2, creyendo que L2 puede descomponer la liquidez de Ethereum y hacer que pierda su ventaja competitiva. También hay investigadores que han propuesto una solución unificada de liquidez como SLAMM, pero esta solución crea más problemas de los que resuelve. Es bastante pobre, así que no entraré en detalles aquí. Los amigos interesados pueden consultar los materiales relevantes.
La verdadera pregunta central es: ¿cómo se pueden agregar los recursos y ecosistemas en cada cadena para que los usuarios no tengan que ser conscientes de la existencia de una 'cadena'? Por ejemplo, tengo 1 ETH, ¿puedo usarlo donde quiera y ocultar el proceso de intercambio automático y pago de gas en diferentes cadenas? Quiero usar una aplicación, ¿puedo usarla en cualquier cadena sin cruzar activos? Al mismo tiempo, la parte del proyecto ya no tiene que hacer cola para seleccionar una cadena. En lugar de desplegar repetidamente en múltiples cadenas, se puede implementar en la cadena más adecuada, ¿y luego las personas en diferentes cadenas pueden usarla?
La capa de aplicación requiere un nuevo paradigma para ocultar la capa de “cadena”. Algunas personas imitaron el concepto de “abstracción de cuenta” y acuñaron un nuevo término llamado “abstracción de cadena”, que es lo que significa. ¡Veamos cómo funciona un proyecto de LSD?
Por ejemplo, Bifrost afirma ser el pionero de LSD de cadena completa, utilizando una arquitectura diferente a la de otros productos de LSD. Bifrost tiene su propia cadena, Bifrost Parachain, que es la parachain de Polkadot. El módulo de participación de liquidez de Bifrost solo se implementa en Bifrost Parachain, y la liquidez de su activo LSD, vToken, también se encuentra en Bifrost Parachain, pero otras cadenas pueden usar el módulo de participación de liquidez de Bifrost Parachain y la liquidez a través de llamadas remotas. Como resultado:
Los usuarios no pueden sentir en absoluto el proceso de entrega entre cadenas detrás de estas operaciones. Todo es como si se hiciera localmente. Todos pueden experimentarlo a través de la aplicación Omni LSD dApp. Actualmente, la aplicación Omni LSD dApp admite la creación/canjeo/intercambio remotos de vTokens en Ethereum, Moonbeam, Moonriver y AStar.
Sin las características anteriores, si los usuarios desean depositar vDOT en Moonbeam, ¡deben operar manualmente tres pasos, lo cual es muy molesto!
① Transferir DOT de Moonbeam cross-chain a Bifrost
② Obtenga vDOT apostando DOT en la cadena Bifrost
③ Transfer vDOT de cadena cruzada de regreso a MoonBeam
Sin embargo, a través de la función de llamada remota, los activos del usuario parecen poder completar los tres pasos anteriores sin salir de la cadena Moonbeam y convertir directamente DOT en vDOT en la cadena Moonbeam. En otras palabras, a lo largo del proceso, los usuarios experimentan los servicios en la cadena Bifrost como si estuvieran utilizando la aplicación local de Moonbeam.
¡Suena bastante genial! ¿Pero cómo se puede lograr esto? En realidad, no es complicado. Bifrost ha desplegado un módulo remoto (modular remoto) en otras cadenas para recibir las solicitudes de los usuarios y pasarlas a través de las cadenas hasta la Parachain de Bifrost. Después de que se complete el procesamiento del módulo de garantía de liquidez, los resultados se devuelven al módulo remoto a través de la cadena. Los usuarios solo necesitan hacer solicitudes en la cadena remota, y el proceso posterior será desencadenado y completado por los retransmisores.
Bifrost se refiere a su arquitectura como una “arquitectura de cadena completa”. La comparación con las estrategias de implementación de múltiples cadenas de otros protocolos LSD se muestra a continuación:
La razón para hablar tan firmemente sobre la arquitectura de Bifrost es para que todos puedan entender completamente a lo que Bifrost se refiere como una "arquitectura de cadena completa". Lo que la arquitectura de Bifrost realmente representa es un nuevo paradigma general.
En su publicación de blog 'Contrato inteligente entre cadenas', Chainlink describió una vez esta arquitectura como un modelo 'tienda principal+sucursal'. La lógica principal de la aplicación se coloca en una cadena, como una 'tienda principal', y luego las otras cadenas proporcionan un módulo de acceso remoto para permitir la interacción con los usuarios finales (obtener la entrada del usuario y producir los resultados deseados), al igual que 'tiendas' una por una.
Después de que la tienda obtiene la entrada del usuario, la entrada se pasa a través de la cadena a la tienda principal, la tienda principal ingresa los resultados después del procesamiento, y luego transmite los resultados a través de la cadena a la tienda para la salida al usuario. En algunos casos, los diferentes módulos de la tienda principal pueden dividirse en diferentes cadenas, y juntos forman una tienda principal virtual. Bajo esta arquitectura, la lógica principal del programa está en la tienda principal, la aplicación tiene un registro de estado unificado, y los problemas de liquidez fragmentada y experiencia del usuario se han resuelto. Además, la aplicación de esta arquitectura también tiene una mejor composabilidad entre cadenas, y las aplicaciones en otras cadenas también pueden acceder de forma remota a la función de la tienda principal como lo hacen los usuarios en otras cadenas.
Aunque Bifrost se refiere a esta estructura como una arquitectura de “cadena completa,” al autor personalmente no le gusta realmente el término “cadena completa,” u Omni-Chain, porque es un término con un significado poco claro. Inicialmente, LayerZero inventó el término para resaltar su escalabilidad sin igual, pero LayerZero nunca explicó completamente qué es en realidad “cadena completa.” ¿Es “toda la cadena”? Definitivamente no; ninguna aplicación se ejecuta en cada cadena. El autor tiene un proyecto de juego que dice que están haciendo un juego de cadena completa. Solo aprendí que “cadena completa” significa “todo el código está en la cadena,” lo que distingue solo algunos juegos Web3 con datos de activos en la cadena, que no son compatibles con el estilo de “cadena completa” descrito por LayerZero.
Creo que la expresión más apropiada es "abstracción de cadena", Abstracción de Cadena o Agnóstico de Cadena (no relacionado con la cadena); ambas pueden expresar un estado donde "los usuarios no necesitan preocuparse por la cadena".
Finalmente, queremos hablar de otra proposición importante en el sector de la cadena cruzada — liquidez. Primero, averigüemos de qué nivel de problema se trata. La liquidez no pertenece a la capa del protocolo porque no está relacionada con la transmisión segura y ordenada de mensajes entre cadenas. Pertenece a la capa de aplicación, y es un tipo especial de aplicación - SwapBridge.
La categoría más grande de aplicaciones entre cadenas debe ser puentes de activos. Los puentes de activos también se dividen en WrapBridge y SwapBridge. El primero ayuda a los usuarios a lograr la transferencia de activos a través de la lógica de bloqueo-acuñación/quema-desbloqueo, también conocido como un "puente de transferencia de activos", mientras que SwapBridge ayuda a los usuarios a lograr el intercambio directo de activos nativos reservando liquidez en múltiples cadenas, también conocido como "puentes de intercambio de liquidez".
Entre ellos, SwapBridge tiene la gama más amplia de aplicaciones y muchos proyectos. Los diferentes proyectos de SwapBridge compiten esencialmente por la eficiencia de la liquidez. ¿Quién puede proporcionar a los usuarios la máxima profundidad con gastos de liquidez mínimos? En otras palabras, la liquidez es el núcleo del servicio proporcionado por SwapBridge. Todos compiten por quién tiene la mejor ventaja de costos. Esta es la misma lógica que en la competencia comercial en general. Lo que todos necesitan entender aquí es que la ventaja de costos creada por la estrategia de subvención es insostenible; se debe tener una ventaja en términos de diseño del mecanismo de liquidez.
Pero CCTP, lanzado por el emisor de USDC Circle, hizo que muchos esfuerzos de SwapBridge fueran irrelevantes; en otras palabras, CCTP destruyó SwapBridge. Se siente como si la Civilización de los Tres Cuerpos hubiera tomado cientos de millones de años y más de 200 rondas de civilización para resolver el Problema de los Tres Cuerpos, pero al final Circle te dice: ¡El Problema de los Tres Cuerpos está sin resolver! Por ejemplo, en el intercambio entre cadenas de activos, USDC es el activo medio más utilizado. En otras palabras, cuando necesitas intercambiar activos A en la cadena X por activos B en la cadena Y, a menudo necesitas intercambiar A por USDC en la cadena X, luego reemplazar USDC en la cadena X por USDC en la cadena Y, y luego intercambiar USDC por el activo B en la cadena Y.
Por lo tanto, la principal forma de liquidez que SwapBridge reserva en varias cadenas es USDC. CCTP puede luego soportar USDC en la cadena X para ser intercambiado directamente por USDC nativo en la cadena Y a través de la lógica de quemado-creación sin la necesidad de reservas de liquidez. En otras palabras, CCTP no tiene costos de liquidez en absoluto, y las tarifas del puente experimentadas por el usuario pueden ser extremadamente bajas.
Quizás dirías que además de USDC, ¿no hay también USDT como un activo de medios comúnmente utilizado? Sin mencionar en el sector DEX, la tasa de uso de USDT es mucho menor que la de USDC, así que no temas aprender sobre Tether y Circle. ¿Puedes idear esto? Entonces, lo que quiero decirte es que SwapBridge está muerto, y el puente oficial del emisor de activos tendrá una ventaja de costo inigualable en cuanto a liquidez entre cadenas. En cuanto a algunos SwapBridges que en su lugar integran CCTP, eso es lógica de agregador.
La capa del protocolo puente entre cadenas está volviéndose más segura y confiable, y la era de los puentes de firmas múltiples está llegando a su fin. En el pasado, la impresión de que las cadenas cruzadas eran inseguras desaparecerá con la popularización de la infraestructura de cadenas cruzadas de próxima generación;
Las aplicaciones entre cadenas están mejorando enormemente la experiencia del usuario a través de la iteración de paradigmas. La "abstracción de cadena" no es menos significativa que la "abstracción de cuenta", y está creando condiciones para la manipulación masiva de Web3;
CCTP lanzado por Circle puso fin a la era Sengoku de la competencia de liquidez de SwapBridge, y nos mostró el final del intercambio de activos entre cadenas.
En resumen, ¡el sector interconectado está experimentando cambios drásticos! Solo entendiendo el camino a seguir podemos caminar con más confianza.
En pocas palabras, un puente entre cadenas se puede dividir en una capa de protocolo y una capa de aplicación. La capa de protocolo es responsable de proporcionar una plataforma segura y ordenada para la mensajería entre cadenas, mientras que la capa de aplicación construye dApps basadas en esta plataforma para dirigirse a los usuarios y satisfacer diversas necesidades en diferentes escenarios.