Desafíos y soluciones de liquidez en la era de Capa 2
Después de que Ethereum se volviera hacia soluciones de escalado centradas en Capa 2, junto con el auge de herramientas como RaaS, muchas cadenas públicas han crecido rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la proliferación de cadenas públicas ha dificultado que el desarrollo del ecosistema mantenga el ritmo con las cadenas públicas, lo que ha llevado a que muchos proyectos se desplomen en el momento de la emisión del token inicial.
Con la ayuda de OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma de intercambio ha publicado Ink; aprovechando la tecnología ZK, una plataforma de intercambio ha lanzado XLayer; una empresa de tecnología ha publicado Soneium, y una empresa de telecomunicaciones ha lanzado Kaia, entre otros. Hoy en día, los costos y las barreras tecnológicas para construir una cadena se han reducido drásticamente, y el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro sin duda será una era de coexistencia de múltiples cadenas. A pesar de que estas Capa 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades de Web2 detrás de ellas tienen una gran cantidad de aplicaciones descendentes, les resulta difícil construir aplicaciones en la misma cadena y alcanzar un consenso.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y dispersión del estado. Dado que la existencia de múltiples cadenas es inevitable, la interoperabilidad es un área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como la abstracción de cadenas, intenciones, Clearing Execution, Native CrossChain, ZKSharding, etc., pero su esencia central es la misma.
Utilizamos la arquitectura Cake, reconocida en la industria, para presentar de arriba hacia abajo la composición de los componentes clave de la abstracción de cadena cruzada:
Capa de Aplicación (Application Layer)
Esta es la capa de interacción directa del usuario, y también es la más abstracta en las soluciones de liquidez, ya que oculta por completo los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente entender el mecanismo de conversión de liquidez subyacente.
Capa de Permiso (Permission Layer)
Ubicado por debajo de la capa de aplicación, el usuario satisface su intención de negociación conectando su billetera a la dApp y solicitando una cotización. Aquí, la "intención" se refiere al resultado final de la transacción esperado por el usuario (es decir, la salida), y no a la ruta de ejecución específica de la transacción.
Gestión de cuentas y abstracción de claves (Key Management and Account Abstraction)
Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener la estructura de cuentas única de cada cadena. Un proyecto ha construido un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo requiere compromisos confiables entre los sistemas de cuentas existentes. Otro proyecto logra la gestión abstracta generando billeteras de cuentas multichain para los usuarios, optimizando en gran medida la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en términos de liquidez, se ha integrado principalmente las cadenas públicas existentes.
Capa de Solución (Solver Layer)
Esta capa es responsable de recibir y realizar las intenciones de transacción de los usuarios, el rol de Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de transacción más rápidos y velocidades de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos de intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones del usuario bajo reglas específicas.
Capa de liquidación (Settlement Layer)
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de las soluciones de liquidez y estado disperso incluyen:
Oráculo (Oracle): utilizado para obtener información de estado en otras cadenas.
Puentes (Bridges): responsables de la transmisión de información y liquidez entre cadenas.
Confirmación anticipada (Pre-Confirmation): reducir el tiempo de confirmación entre cadenas.
Disponibilidad de datos (DA): proporciona accesibilidad a los datos.
Además, también se deben considerar factores como la liquidez entre cadenas, la finalización (Finality), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Actualmente, hay varias soluciones en el mercado para resolver la fragmentación de la liquidez, que incluyen principalmente:
Centrado en RaaS: Asistir en la construcción de Rollup en OP Stack compartiendo liquidez y estado a través de la incorporación de ordenadores compartidos específicos y puentes entre cadenas.
Enfoque en la cuenta: Construir una billetera de cuenta completa en la cadena, apoyando la firma y ejecución de transacciones a través de la tecnología de "firma en cadena" en múltiples protocolos de blockchain.
Centrado en la red de intenciones fuera de la cadena: los usuarios envían intenciones a la red Solver, donde los Solvers compiten con ofertas, proporcionando el tiempo de finalización óptimo y el precio de la transacción.
Centrado en una red de liquidez en cadena: construir una capa de liquidez en la que se desarrollen aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en cadena: construir aplicaciones de alta liquidez mediante la integración de grandes creadores de mercado o aplicaciones de terceros.
Resolver el problema de la liquidez es un tema muy importante. En el mundo financiero, la liquidez a menudo lo representa todo. Si se pudiera construir una plataforma de integración de liquidez, especialmente integrando la liquidez dispersa de toda la cadena, tendría un gran potencial.
Algunos proyectos típicos de conceptos abstractos de cadenas incluyen:
INFINIT
INFINIT ha construido un servicio RaaS en el ámbito DeFi, proporcionando los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, etc., y también puede ofrecer componentes como Trading con Apalancamiento y Estrategia de Rendimiento que se pueden activar de inmediato.
Khalani Network
Khalani ha construido tres componentes centrales, que son la capa de compatibilidad de Intent, Validity y la capa de liquidación general. Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intent de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo pueda reconocer.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccional. Su misión principal es proporcionar a las empresas de trading profesionales herramientas eficientes de gestión de inventario y conectarse fácilmente a los protocolos DeFi centrales al liquidar transacciones con intenciones de uso.
Xion
Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativa y segura que otros puentes entre cadenas.
=nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2. Propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando el procesamiento de transacciones en paralelo mediante fragmentación y generando ZKP.
ERC-7683
Esta es una propuesta para establecer un estándar común para operaciones de cadena cruzada entre Capa 2 y cadenas laterales, con el objetivo de estandarizar las interfaces de pedidos y liquidaciones, logrando una ejecución de cadena cruzada sin fisuras.
OP Stack
OP Stack diseña una solución completa de múltiples Capa 2 para resolver de una vez los problemas de transmisión de información y la descentralización del Sequencer. Al utilizar la arquitectura de OP Stack, se desplegarán automáticamente contratos跨链, y habrá un Supervisor para desafiar y evitar la transmisión de información跨链 falsa.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo y con múltiples soluciones. El futuro sin duda será multichain, y enfrentar el desafío de la dispersión de la liquidez es una obligación que la industria debe afrontar. Además, la integración de esta liquidez en toda la cadena tiene un amplio espacio de crecimiento, y podría construir una infraestructura importante para la era Web3.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Desafíos de liquidez en la era de Capa 2 y soluciones de integración multichain
Desafíos y soluciones de liquidez en la era de Capa 2
Después de que Ethereum se volviera hacia soluciones de escalado centradas en Capa 2, junto con el auge de herramientas como RaaS, muchas cadenas públicas han crecido rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la proliferación de cadenas públicas ha dificultado que el desarrollo del ecosistema mantenga el ritmo con las cadenas públicas, lo que ha llevado a que muchos proyectos se desplomen en el momento de la emisión del token inicial.
Con la ayuda de OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma de intercambio ha publicado Ink; aprovechando la tecnología ZK, una plataforma de intercambio ha lanzado XLayer; una empresa de tecnología ha publicado Soneium, y una empresa de telecomunicaciones ha lanzado Kaia, entre otros. Hoy en día, los costos y las barreras tecnológicas para construir una cadena se han reducido drásticamente, y el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro sin duda será una era de coexistencia de múltiples cadenas. A pesar de que estas Capa 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades de Web2 detrás de ellas tienen una gran cantidad de aplicaciones descendentes, les resulta difícil construir aplicaciones en la misma cadena y alcanzar un consenso.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y dispersión del estado. Dado que la existencia de múltiples cadenas es inevitable, la interoperabilidad es un área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como la abstracción de cadenas, intenciones, Clearing Execution, Native CrossChain, ZKSharding, etc., pero su esencia central es la misma.
Utilizamos la arquitectura Cake, reconocida en la industria, para presentar de arriba hacia abajo la composición de los componentes clave de la abstracción de cadena cruzada:
Capa de Aplicación (Application Layer)
Esta es la capa de interacción directa del usuario, y también es la más abstracta en las soluciones de liquidez, ya que oculta por completo los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente entender el mecanismo de conversión de liquidez subyacente.
Capa de Permiso (Permission Layer)
Ubicado por debajo de la capa de aplicación, el usuario satisface su intención de negociación conectando su billetera a la dApp y solicitando una cotización. Aquí, la "intención" se refiere al resultado final de la transacción esperado por el usuario (es decir, la salida), y no a la ruta de ejecución específica de la transacción.
Gestión de cuentas y abstracción de claves (Key Management and Account Abstraction)
Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener la estructura de cuentas única de cada cadena. Un proyecto ha construido un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo requiere compromisos confiables entre los sistemas de cuentas existentes. Otro proyecto logra la gestión abstracta generando billeteras de cuentas multichain para los usuarios, optimizando en gran medida la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en términos de liquidez, se ha integrado principalmente las cadenas públicas existentes.
Capa de Solución (Solver Layer)
Esta capa es responsable de recibir y realizar las intenciones de transacción de los usuarios, el rol de Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de transacción más rápidos y velocidades de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos de intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones del usuario bajo reglas específicas.
Capa de liquidación (Settlement Layer)
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de las soluciones de liquidez y estado disperso incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la finalización (Finality), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Actualmente, hay varias soluciones en el mercado para resolver la fragmentación de la liquidez, que incluyen principalmente:
Centrado en RaaS: Asistir en la construcción de Rollup en OP Stack compartiendo liquidez y estado a través de la incorporación de ordenadores compartidos específicos y puentes entre cadenas.
Enfoque en la cuenta: Construir una billetera de cuenta completa en la cadena, apoyando la firma y ejecución de transacciones a través de la tecnología de "firma en cadena" en múltiples protocolos de blockchain.
Centrado en la red de intenciones fuera de la cadena: los usuarios envían intenciones a la red Solver, donde los Solvers compiten con ofertas, proporcionando el tiempo de finalización óptimo y el precio de la transacción.
Centrado en una red de liquidez en cadena: construir una capa de liquidez en la que se desarrollen aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en cadena: construir aplicaciones de alta liquidez mediante la integración de grandes creadores de mercado o aplicaciones de terceros.
Resolver el problema de la liquidez es un tema muy importante. En el mundo financiero, la liquidez a menudo lo representa todo. Si se pudiera construir una plataforma de integración de liquidez, especialmente integrando la liquidez dispersa de toda la cadena, tendría un gran potencial.
Algunos proyectos típicos de conceptos abstractos de cadenas incluyen:
INFINIT
INFINIT ha construido un servicio RaaS en el ámbito DeFi, proporcionando los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, etc., y también puede ofrecer componentes como Trading con Apalancamiento y Estrategia de Rendimiento que se pueden activar de inmediato.
Khalani Network
Khalani ha construido tres componentes centrales, que son la capa de compatibilidad de Intent, Validity y la capa de liquidación general. Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intent de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo pueda reconocer.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccional. Su misión principal es proporcionar a las empresas de trading profesionales herramientas eficientes de gestión de inventario y conectarse fácilmente a los protocolos DeFi centrales al liquidar transacciones con intenciones de uso.
Xion
Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativa y segura que otros puentes entre cadenas.
=nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2. Propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando el procesamiento de transacciones en paralelo mediante fragmentación y generando ZKP.
ERC-7683
Esta es una propuesta para establecer un estándar común para operaciones de cadena cruzada entre Capa 2 y cadenas laterales, con el objetivo de estandarizar las interfaces de pedidos y liquidaciones, logrando una ejecución de cadena cruzada sin fisuras.
OP Stack
OP Stack diseña una solución completa de múltiples Capa 2 para resolver de una vez los problemas de transmisión de información y la descentralización del Sequencer. Al utilizar la arquitectura de OP Stack, se desplegarán automáticamente contratos跨链, y habrá un Supervisor para desafiar y evitar la transmisión de información跨链 falsa.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo y con múltiples soluciones. El futuro sin duda será multichain, y enfrentar el desafío de la dispersión de la liquidez es una obligación que la industria debe afrontar. Además, la integración de esta liquidez en toda la cadena tiene un amplio espacio de crecimiento, y podría construir una infraestructura importante para la era Web3.