Estudio sobre el problema de la liquidez tomar a la gente por tonta en la era de Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el surgimiento de herramientas como RaaS, muchas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema, lo que ha llevado a que muchos proyectos se rompan en el momento del TGE.
Con la ayuda de OP Stack, una plataforma de intercambio lanzó su propia Capa 2, otra plataforma de intercambio lanzó Ink; utilizando tecnología ZK, una plataforma de intercambio lanzó XLayer; Sony lanzó Soneium, LINE lanzó Kaia, entre otros. Hoy en día, el costo y la barrera tecnológica 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 será sin duda una era de coexistencia de múltiples cadenas. Aunque estas cadenas de 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 en el lado del cliente, les resulta difícil construir aplicaciones y alcanzar un consenso en la misma cadena.
El ecosistema actual de múltiples cadenas presenta un nuevo desafío: la liquidez y la dispersión del estado. Dado que la existencia de múltiples cadenas es inevitable, la interoperabilidad es un campo que debe ser explorado y resuelto. Actualmente hay muchas soluciones de liquidez, como todos hemos oído hablar de la abstracción de cadena, intención, ejecución de compensación, CrossChain nativo, ZKSharding, pero su esencia central es la misma.
Presentamos la composición de los componentes centrales de la abstracción de cadena cruzada utilizando la arquitectura Cake, que es bastante reconocida en la industria, de arriba hacia abajo:
Capa de Aplicación(Application Layer)
Esta es la capa con la que los usuarios interactúan directamente, y también es la capa más abstracta en la solución de liquidez, porque oculta completamente 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 Permisos(Capa de Permisos)
Ubicado debajo de la capa de aplicación, los usuarios satisfacen su intención de transacción al conectar su billetera a la dApp y solicitar una cotización. Aquí, la "intención" se refiere al resultado final de la transacción que el usuario espera (, es decir, la salida ), y no a la ruta de ejecución específica de la transacción.
Gestión de cuentas y gestión de claves de abstracción de cuentas(Key Management and Account Abstraction)
Debido a la existencia de un entorno de múltiples cadenas, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener la estructura única de cuentas de cada cadena. Por ejemplo, el sistema de cuentas centrado en objetos de SUI es completamente diferente al de EVM. One Balance es un proyecto representativo en este campo, que construye un sistema de cuentas de confianza, sin necesidad de establecer un consenso entre cadenas, solo se requiere un compromiso de confianza entre los sistemas de cuentas existentes. Near Account logra la gestión abstracta generando una billetera de cuentas de múltiples cadenas para los usuarios, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de UX. Sin embargo, en términos de liquidez, principalmente se integran las cadenas públicas existentes.
Resolver Capa ( Capa)
Esta capa se encarga de recibir y realizar la intención de negociación del usuario. El rol de Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de negociación más rápidos y velocidad de ejecución. Sobre esta base, proyectos basados en la intención como Anoma han construido diversas soluciones impulsadas por la intención. Derivados de tales intenciones, como el componente Predicate, pueden realizar la intención 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 la solución de liquidez y estado descentralizado incluyen:
Oráculo (: utilizado para obtener información sobre el estado en otras cadenas.
Puentes跨链桥): responsables de la transmisión de información y liquidez entre cadenas.
Confirmación previa (: reducir el tiempo de confirmación entre cadenas.
Disponibilidad de datos ) DA (: Proporcionar accesibilidad a los datos.
Además, también se deben considerar factores como la liquidez entre cadenas, la finalidad ) Finality (, los mecanismos de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
) solución
Actualmente, en el mercado hay varias soluciones para la liquidez fragmentada. Después de revisar numerosas opciones, encontramos que las principales son estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a construir Rollups en OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas para compartir liquidez y estado. Esto espera poder resolver la liquidez y la dispersión del estado desde una dirección de un nivel más alto. Aquí hay un diseño más segmentado que es un ordenante compartido independiente, esta solución está más dirigida a Capa 2, no tiene aplicabilidad universal, como Astria, Espresso y Flashbots.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta en toda la cadena, respaldada por una tecnología llamada "firma en cadena" que permite firmar y ejecutar transacciones a través de múltiples protocolos de blockchain. El componente central es la red MPC, que firma las transacciones multichain en lugar del usuario. Este conjunto de soluciones, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Centrado en la red de intenciones fuera de la cadena: es decir, nuestra red de Solver en el diagrama de la arquitectura del pastel en la "introducción", el núcleo es que los usuarios envían intenciones a la red de Solver, este rol de Solver compite por las ofertas, proporcionando el tiempo de finalización y el precio de transacción óptimos. Estos Solvers pueden ser Agentes de IA, CEX, Creadores de Mercado e incluso protocolos integrados como Liquorice, entre otros. Los proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque las intenciones pueden, en teoría, lograr operaciones cruzadas de cualquier complejidad, en la práctica se requiere un número suficiente de Solvers con liquidez para ayudar, y cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen métodos de prueba de fraude, la dificultad de implementación de la red de Solvers se incrementará, y el umbral para operar un Solver también será más alto.
Centrado en una red de liquidez en cadena: esta dirección se especializa en optimizar los problemas de liquidez entre cadenas, pero no ha resuelto otros problemas de estado disperso en la cadena. Su núcleo es construir una capa de liquidez, sobre la cual se construirán aplicaciones, para compartir la liquidez de toda la cadena. Algunos proyectos incluyen: Raye Network, INFINIT, Everclear, Elixir, etc.
Centrado en aplicaciones en cadena: este tipo de aplicaciones construyen aplicaciones de alta liquidez integrando grandes MM o aplicaciones de terceros, como Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que exige mucho a los desarrolladores, por lo tanto, también son muy propensos a ataques de hackers.
Resolver el problema de la Liquidez es un tema muy importante, en el mundo financiero la liquidez a menudo lo representa todo. Si se puede construir una plataforma de integración de liquidez, especialmente integrando la liquidez dispersa de toda la cadena, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos clasificaciones anteriores, podemos ver que, según la estructura del pastel, la Capa de Liquidación es la solución más atómica, y sobre estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que son la Capa de Solución, Capa de Permisos y Capa de Aplicación. Las diferentes soluciones abstractas o de liquidez que enumeramos arriba, construidas en diferentes direcciones, se pueden entender como una relación entre la parte superior e inferior. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de liquidez ha traído consigo la aparición de muchos problemas derivados complejos, por lo que, en cuanto a la interoperabilidad, han surgido todo tipo de soluciones. Pero en esencia, aún dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción de cadena para ver cómo cada uno de ellos aborda el problema de la fragmentación de liquidez desde su propio punto de partida.
INFINIT
INFINIT ha construido un servicio RaaS para el ámbito DeFi, que puede proporcionar los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, etc. También puede ofrecer componentes como Leverage Trading y Yield Strategy que se pueden activar de inmediato. Es equivalente a otros puntos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente no ha revelado el funcionamiento interno. Actualmente, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla de Robot Ventures, Electric Capital y Maelstrom Capital.
(# Khalani Network
Khalani construyó tres componentes centrales, que son la capa compatible con Intent, la Validez y la capa de liquidación universal.
Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de intentos de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validez. El nodo Khalani es responsable de enviar el resultado final a la capa de liquidación general a través de puentes entre cadenas, tecnologías de liquidación rápida, etc. Este proyecto aún se encuentra en la fase de construcción y no se han revelado más detalles del trabajo. En agosto, obtuvo 2.2 millones de dólares en financiación de la ronda semilla de Ethereal Ventures, Nascent, Maelstrom Capital, entre otros.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究])https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccionales. La misión principal de Liquorice es proporcionar herramientas de gestión de inventario eficientes para empresas de trading profesionales, y conectar fácilmente a los protocolos DeFi centrales al liquidar transacciones con intenciones de uso. Al mismo tiempo, Liquorice ha creado un mercado de préstamos para realizar transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente aún se encuentra en fase de desarrollo, y en julio anunció haber obtenido 1.2 millones de dólares en una ronda de financiación Pre-seed liderada por GreenField.
(# Xion
Xion es una mejora de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Después, el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyó Xion para mejorar este problema. 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. Ha realizado cuatro rondas de financiamiento, con inversores como Animoca, Multicoin, Alliance DAO, Mechanism, entre otros.
)# =nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y desarrollador de Capa 2, el equipo tiene una sólida base técnica en ZK. Propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando el procesamiento paralelo de fragmentos y generando ZKP, mientras que el fragmento principal verifica los datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. El fragmento principal también gestiona la distribución de validadores y cuentas en los fragmentos de ejecución. El protocolo de consenso utilizado por el comité de validación también es Hotstuff, lo cual es común en los proyectos de ejecución paralela más recientes. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados como transacciones por el comité de validadores de cada fragmento.
Su idea básica es construir una arquitectura de comunicación entre fragmentos incrustada, similar a IBC, a través de una arquitectura de Capa 2 fragmentada, lo que resolvería los problemas de liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, ya que el problema que resuelve la dispersión de la liquidez es un problema multichain; lo que construye es una única Capa 2, lo que significa que para resolverlo, todas las cadenas tendrían que convertirse en un fragmento de ZK-sharding, lo que es difícil de lograr.
![Investigación sobre el problema de la fragmentación de la liquidez en la era de Capa 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
ERC-7683
Ethereum también está trabajando para resolver el problema de la liquidez cruzada, actualmente Arbitrum, OP y un DEX han comenzado a apoyar públicamente el estándar ERC7683, que también utiliza un método de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar común para las operaciones de cadena cruzada entre L2 y cadenas laterales, estandarizando las interfaces de órdenes y liquidación, logrando una ejecución de cadena cruzada sin problemas, y su núcleo principal es un Filler, que también se puede considerar el rol de Solver en la abstracción de cadenas para el pago. Esta propuesta fue construida conjuntamente por un DEX y Across, y actualmente está siendo revisada por el grupo de trabajo de Cake.
(# OP Stack
OP Stack, ERC-7683 y zkSharding son soluciones internas de Ethereum para la fragmentación de liquidez entre Capa 2, que abordan el problema desde los niveles de arquitectura, consenso y aplicación. OP Stack resuelve de una vez la transmisión de información y Sequ al diseñar una solución completa de múltiples Capa 2.
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.
Exploración de soluciones de liquidez cross-chain en la era de Capa 2
Estudio sobre el problema de la liquidez tomar a la gente por tonta en la era de Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el surgimiento de herramientas como RaaS, muchas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema, lo que ha llevado a que muchos proyectos se rompan en el momento del TGE.
Con la ayuda de OP Stack, una plataforma de intercambio lanzó su propia Capa 2, otra plataforma de intercambio lanzó Ink; utilizando tecnología ZK, una plataforma de intercambio lanzó XLayer; Sony lanzó Soneium, LINE lanzó Kaia, entre otros. Hoy en día, el costo y la barrera tecnológica 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 será sin duda una era de coexistencia de múltiples cadenas. Aunque estas cadenas de 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 en el lado del cliente, les resulta difícil construir aplicaciones y alcanzar un consenso en la misma cadena.
El ecosistema actual de múltiples cadenas presenta un nuevo desafío: la liquidez y la dispersión del estado. Dado que la existencia de múltiples cadenas es inevitable, la interoperabilidad es un campo que debe ser explorado y resuelto. Actualmente hay muchas soluciones de liquidez, como todos hemos oído hablar de la abstracción de cadena, intención, ejecución de compensación, CrossChain nativo, ZKSharding, pero su esencia central es la misma.
Presentamos la composición de los componentes centrales de la abstracción de cadena cruzada utilizando la arquitectura Cake, que es bastante reconocida en la industria, de arriba hacia abajo:
Capa de Aplicación(Application Layer)
Esta es la capa con la que los usuarios interactúan directamente, y también es la capa más abstracta en la solución de liquidez, porque oculta completamente 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 Permisos(Capa de Permisos)
Ubicado debajo de la capa de aplicación, los usuarios satisfacen su intención de transacción al conectar su billetera a la dApp y solicitar una cotización. Aquí, la "intención" se refiere al resultado final de la transacción que el usuario espera (, es decir, la salida ), y no a la ruta de ejecución específica de la transacción.
Gestión de cuentas y gestión de claves de abstracción de cuentas(Key Management and Account Abstraction)
Debido a la existencia de un entorno de múltiples cadenas, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener la estructura única de cuentas de cada cadena. Por ejemplo, el sistema de cuentas centrado en objetos de SUI es completamente diferente al de EVM. One Balance es un proyecto representativo en este campo, que construye un sistema de cuentas de confianza, sin necesidad de establecer un consenso entre cadenas, solo se requiere un compromiso de confianza entre los sistemas de cuentas existentes. Near Account logra la gestión abstracta generando una billetera de cuentas de múltiples cadenas para los usuarios, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de UX. Sin embargo, en términos de liquidez, principalmente se integran las cadenas públicas existentes.
Resolver Capa ( Capa)
Esta capa se encarga de recibir y realizar la intención de negociación del usuario. El rol de Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de negociación más rápidos y velocidad de ejecución. Sobre esta base, proyectos basados en la intención como Anoma han construido diversas soluciones impulsadas por la intención. Derivados de tales intenciones, como el componente Predicate, pueden realizar la intención 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 la solución de liquidez y estado descentralizado incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la finalidad ) Finality (, los mecanismos de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
) solución
Actualmente, en el mercado hay varias soluciones para la liquidez fragmentada. Después de revisar numerosas opciones, encontramos que las principales son estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a construir Rollups en OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas para compartir liquidez y estado. Esto espera poder resolver la liquidez y la dispersión del estado desde una dirección de un nivel más alto. Aquí hay un diseño más segmentado que es un ordenante compartido independiente, esta solución está más dirigida a Capa 2, no tiene aplicabilidad universal, como Astria, Espresso y Flashbots.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta en toda la cadena, respaldada por una tecnología llamada "firma en cadena" que permite firmar y ejecutar transacciones a través de múltiples protocolos de blockchain. El componente central es la red MPC, que firma las transacciones multichain en lugar del usuario. Este conjunto de soluciones, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Centrado en la red de intenciones fuera de la cadena: es decir, nuestra red de Solver en el diagrama de la arquitectura del pastel en la "introducción", el núcleo es que los usuarios envían intenciones a la red de Solver, este rol de Solver compite por las ofertas, proporcionando el tiempo de finalización y el precio de transacción óptimos. Estos Solvers pueden ser Agentes de IA, CEX, Creadores de Mercado e incluso protocolos integrados como Liquorice, entre otros. Los proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque las intenciones pueden, en teoría, lograr operaciones cruzadas de cualquier complejidad, en la práctica se requiere un número suficiente de Solvers con liquidez para ayudar, y cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen métodos de prueba de fraude, la dificultad de implementación de la red de Solvers se incrementará, y el umbral para operar un Solver también será más alto.
Centrado en una red de liquidez en cadena: esta dirección se especializa en optimizar los problemas de liquidez entre cadenas, pero no ha resuelto otros problemas de estado disperso en la cadena. Su núcleo es construir una capa de liquidez, sobre la cual se construirán aplicaciones, para compartir la liquidez de toda la cadena. Algunos proyectos incluyen: Raye Network, INFINIT, Everclear, Elixir, etc.
Centrado en aplicaciones en cadena: este tipo de aplicaciones construyen aplicaciones de alta liquidez integrando grandes MM o aplicaciones de terceros, como Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que exige mucho a los desarrolladores, por lo tanto, también son muy propensos a ataques de hackers.
Resolver el problema de la Liquidez es un tema muy importante, en el mundo financiero la liquidez a menudo lo representa todo. Si se puede construir una plataforma de integración de liquidez, especialmente integrando la liquidez dispersa de toda la cadena, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos clasificaciones anteriores, podemos ver que, según la estructura del pastel, la Capa de Liquidación es la solución más atómica, y sobre estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que son la Capa de Solución, Capa de Permisos y Capa de Aplicación. Las diferentes soluciones abstractas o de liquidez que enumeramos arriba, construidas en diferentes direcciones, se pueden entender como una relación entre la parte superior e inferior. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de liquidez ha traído consigo la aparición de muchos problemas derivados complejos, por lo que, en cuanto a la interoperabilidad, han surgido todo tipo de soluciones. Pero en esencia, aún dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción de cadena para ver cómo cada uno de ellos aborda el problema de la fragmentación de liquidez desde su propio punto de partida.
INFINIT
INFINIT ha construido un servicio RaaS para el ámbito DeFi, que puede proporcionar los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, etc. También puede ofrecer componentes como Leverage Trading y Yield Strategy que se pueden activar de inmediato. Es equivalente a otros puntos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente no ha revelado el funcionamiento interno. Actualmente, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla de Robot Ventures, Electric Capital y Maelstrom Capital.
(# Khalani Network
Khalani construyó tres componentes centrales, que son la capa compatible con Intent, la Validez y la capa de liquidación universal.
Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de intentos de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validez. El nodo Khalani es responsable de enviar el resultado final a la capa de liquidación general a través de puentes entre cadenas, tecnologías de liquidación rápida, etc. Este proyecto aún se encuentra en la fase de construcción y no se han revelado más detalles del trabajo. En agosto, obtuvo 2.2 millones de dólares en financiación de la ronda semilla de Ethereal Ventures, Nascent, Maelstrom Capital, entre otros.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究])https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccionales. La misión principal de Liquorice es proporcionar herramientas de gestión de inventario eficientes para empresas de trading profesionales, y conectar fácilmente a los protocolos DeFi centrales al liquidar transacciones con intenciones de uso. Al mismo tiempo, Liquorice ha creado un mercado de préstamos para realizar transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente aún se encuentra en fase de desarrollo, y en julio anunció haber obtenido 1.2 millones de dólares en una ronda de financiación Pre-seed liderada por GreenField.
(# Xion
Xion es una mejora de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Después, el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyó Xion para mejorar este problema. 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. Ha realizado cuatro rondas de financiamiento, con inversores como Animoca, Multicoin, Alliance DAO, Mechanism, entre otros.
)# =nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y desarrollador de Capa 2, el equipo tiene una sólida base técnica en ZK. Propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando el procesamiento paralelo de fragmentos y generando ZKP, mientras que el fragmento principal verifica los datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. El fragmento principal también gestiona la distribución de validadores y cuentas en los fragmentos de ejecución. El protocolo de consenso utilizado por el comité de validación también es Hotstuff, lo cual es común en los proyectos de ejecución paralela más recientes. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados como transacciones por el comité de validadores de cada fragmento.
Su idea básica es construir una arquitectura de comunicación entre fragmentos incrustada, similar a IBC, a través de una arquitectura de Capa 2 fragmentada, lo que resolvería los problemas de liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, ya que el problema que resuelve la dispersión de la liquidez es un problema multichain; lo que construye es una única Capa 2, lo que significa que para resolverlo, todas las cadenas tendrían que convertirse en un fragmento de ZK-sharding, lo que es difícil de lograr.
![Investigación sobre el problema de la fragmentación de la liquidez en la era de Capa 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
ERC-7683
Ethereum también está trabajando para resolver el problema de la liquidez cruzada, actualmente Arbitrum, OP y un DEX han comenzado a apoyar públicamente el estándar ERC7683, que también utiliza un método de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar común para las operaciones de cadena cruzada entre L2 y cadenas laterales, estandarizando las interfaces de órdenes y liquidación, logrando una ejecución de cadena cruzada sin problemas, y su núcleo principal es un Filler, que también se puede considerar el rol de Solver en la abstracción de cadenas para el pago. Esta propuesta fue construida conjuntamente por un DEX y Across, y actualmente está siendo revisada por el grupo de trabajo de Cake.
(# OP Stack
OP Stack, ERC-7683 y zkSharding son soluciones internas de Ethereum para la fragmentación de liquidez entre Capa 2, que abordan el problema desde los niveles de arquitectura, consenso y aplicación. OP Stack resuelve de una vez la transmisión de información y Sequ al diseñar una solución completa de múltiples Capa 2.