Estudio sobre el problema de la fragmentación de Liquidez en la era Layer2
Con la transición de Ethereum hacia soluciones de escalado centradas en Layer 2, así como el auge de herramientas como RaaS, numerosas 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 que el desarrollo del ecosistema siga el ritmo de las cadenas públicas, lo que lleva a que muchos proyectos se desvaloricen en el TGE.
Aprovechando OP Stack, una plataforma de intercambio lanzó su propia Capa Base 2, otra plataforma de intercambio publicó Ink; utilizando tecnología ZK, una plataforma de intercambio lanzó XLayer; Sony lanzó Soneium, LINE presentó Kaia, entre otros. Hoy en día, el costo y la barrera técnica para construir una cadena se han reducido significativamente, 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. Aunque estas cadenas Layer 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 y alcanzar consenso en la misma cadena.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y estado disperso. 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 la abstracción de cadenas, la intención, la ejecución de Clearing, CrossChain nativo, 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 centrales de la abstracción de cadena cruzada:
Capa de Aplicación ( Capa de Aplicación )
Esta es la capa de interacción directa del usuario, y también es la capa más abstracta de la solución 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 y no necesariamente entienden el mecanismo de conversión de liquidez subyacente.
Capa de Permisos(Capa de Permisos)
Ubicado por debajo de la capa de aplicación, los usuarios conectan su billetera a la dApp y solicitan cotizaciones para satisfacer su intención de comercio. 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 abstracción de (Gestión de claves y abstracción de cuentas)
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 ú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 confiable, sin necesidad de establecer consenso entre cadenas, solo se requiere un compromiso confiable entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta generando billeteras de cuentas multichain para los usuarios, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de la UX. Sin embargo, en términos de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Capa de Solución (Solver Layer )
Esta capa es responsable de recibir e implementar las intenciones de transacción del usuario. El rol de Solver compite aquí para proporcionar una mejor experiencia al usuario, incluyendo tiempos de transacción más rápidos y velocidades de ejecución. Sobre esta base, proyectos basados en intenciones como Anoma han construido diversas soluciones impulsadas por intenciones. Derivados de tales intenciones, como el componente Predicate, pueden implementar las intenciones del usuario bajo reglas específicas.
Capa de Liquidación(Capa de Liquidación)
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de la solución de Liquidez y estado disperso incluyen:
Oráculo (: utilizado para obtener información sobre el estado en otras cadenas.
Puente entre cadenas ) Bridges (: responsable 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 Layer 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
( solución
Actualmente, en el mercado hay varias soluciones para resolver la liquidez tomar a la gente por tonta. Después de revisar una gran cantidad de soluciones, encontramos que las principales son estas formas:
Centrado en RaaS: soluciones Rollup como OP Stack, mediante la incorporación de un ordenadores compartidos específicos y puentes entre cadenas para ayudar a compartir la liquidez y el estado de los Rollup construidos sobre OP Stack. Esto espera poder resolver la liquidez y el estado dispersos en un nivel superior. Dentro de esto, hay un diseño más segmentado que es un ordenador compartido separado, esta solución está más orientada a Layer2, no tiene aplicabilidad universal, como Astria, Espresso y Flashbots.
Centrado en la cuenta: similar a NEAR, construir una billetera de cuenta de cadena completa, soportada por una tecnología llamada "firma de cadena" para 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 de los usuarios. Este conjunto de soluciones, aunque puede resolver en gran medida el problema de la fragmentación de 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 intención fuera de la cadena: es decir, la red de Solver en el diagrama de la estructura del pastel de "introducción". El núcleo es que los usuarios envían intenciones a la red de Solver. Este rol de Solver compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos Solvers pueden ser agentes de IA, CEX, creadores de mercado o incluso protocolos integrados como Liquorice, entre otros. Los proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque la intención puede, en teoría, lograr operaciones complejas de cadena cruzada de cualquier dificultad, en la práctica se necesita suficiente Liquidez de Solvers para ayudar, y cuando se enfrentan a algunas necesidades fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen medios como pruebas de fraude, la dificultad de implementación de la red de Solvers aumentará, y el umbral para operar como Solver también será mayor.
Centrado en la 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 dispersión del estado en cadena. Su núcleo es construir una capa de liquidez, sobre la cual se desarrollan 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 a través de la integración de grandes MM, o aplicaciones de terceros, como Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Este tipo de proyectos requieren gestionar procesos complejos entre cadenas, lo que exige mucho a los desarrolladores, por lo que también son muy susceptibles a ataques de hackers.
![Investigación sobre el problema de la fragmentación de la liquidez en la era de Layer2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp###
Resolver el problema de la Liquidez es un tema muy importante, ya que en el mundo financiero la Liquidez a menudo lo representa todo. Si se puede construir una plataforma que integre la Liquidez, especialmente integrando la Liquidez de toda la cadena dispersa, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos categorías anteriores, podemos ver que, según la estructura del pastel, el Settlement Layer es la solución más atómica. Por encima de estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que son el Solver Layer, Permission Layer y Application Layer. Las diferentes soluciones de abstracción o Liquidez que enumeramos arriba, construidas en diferentes direcciones, se pueden entender como una relación de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas, el problema de la ruptura de Liquidez ha traído consigo la aparición de numerosos problemas derivados complejos, por lo tanto, en cuanto a interoperabilidad, han surgido una variedad de soluciones. Pero, en esencia, todavía 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 aborda el problema de la ruptura de Liquidez desde su propio punto de partida.
(# INFINIT
INFINIT ha construido un servicio RaaS en el ámbito DeFi, que puede proporcionar 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 Leverage Trading y Yield Strategy que se pueden activar de inmediato. Equivale a otros extremos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente no se ha revelado el funcionamiento subyacente. Hasta ahora, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla de Robot Ventures, Electric Capital y Maelstrom Capital.
![Investigación sobre el problema de la liquidez y la fragmentación en la era Layer2])https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
(# Khalani Network
Khalani ha construido tres componentes centrales: 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 la capa de compatibilidad de Intent de Khalani puede convertir las intenciones externas en un formato que el Solver del protocolo pueda reconocer, utilizando un formato normalizado que es el lenguaje de Validez. El nodo de 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, entre otros. Este proyecto aún se encuentra en la fase de construcción y no se han revelado más detalles sobre el 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.
![Investigación sobre el problema de la fragmentación de la liquidez en la era Layer2])https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
(# Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unilateral. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas eficientes de gestión de inventario, y conectar fácilmente con los protocolos centrales de DeFi al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice creó un mercado de préstamos para llevar a cabo transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente sigue en fase de desarrollo, y en julio anunció que había obtenido una financiación de 1.2 millones de dólares en una ronda Pre-seed liderada por GreenField.
![Investigación sobre el problema de la fragmentación de liquidez en la era Layer2])https://img-cdn.gateio.im/webp-social/moments-480179c7379a7927397a4c027efdc0a9.webp###
(# Xion
Xion es una evolución de la marca Burnt. Anteriormente, Burnt se centraba en aplicaciones para consumidores, pero el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyeron Xion para mejorar esta situación. 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 nativo y seguro que otros puentes entre cadenas. Ha llevado a cabo cuatro rondas de financiación, con inversores como Animoca, Multicoin, Alliance DAO y Mechanism.
)# =nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y desarrollador de Layer2, con un equipo que tiene una sólida base técnica en ZK. Propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la cadena principal de Ethereum, ejecutar el procesamiento de transacciones en paralelo mediante fragmentación y generar 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 el fragmento de ejecución. El protocolo de consenso utilizado por el comité de validación es también Hotstuff, que es común en los proyectos de ejecución paralela más recientes. =nil; L2 integró la comunicación entre fragmentos en el protocolo desde el principio. 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 Layer2 fragmentada, lo que podría resolver los problemas de Liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, porque el problema que resuelve la dispersión de Liquidez es el problema de múltiples cadenas; lo que construye es una única Layer2, lo que significa que para resolverlo, todas las cadenas deben convertirse en un fragmento de ZK-sharding, lo cual es difícil de lograr.
![Investigación sobre el problema de la liquidez fragmentada en la era de Layer2]###https://img-cdn.gateio.im/webp-social/moments-69852e6a1bbab8f4fc50f48006eb6fef.webp###
(# ERC-7683
Ethereum también está trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, ciertos DEX y OP son los primeros en 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 general para las operaciones entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación para lograr una ejecución sin fisuras entre cadenas. Su núcleo principal es un Filler, que también se puede considerar como el rol de Solver en la abstracción de la cadena para el pago. Esta propuesta fue construida conjuntamente por un DEX y Across.
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.
14 me gusta
Recompensa
14
2
Compartir
Comentar
0/400
PumpBeforeRug
· hace7h
¿Se puede hacer un vínculo? Siento que está condenado igual que una cadena pública.
La fragmentación de la liquidez en la era de Layer2: discusión sobre desafíos y soluciones
Estudio sobre el problema de la fragmentación de Liquidez en la era Layer2
Con la transición de Ethereum hacia soluciones de escalado centradas en Layer 2, así como el auge de herramientas como RaaS, numerosas 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 que el desarrollo del ecosistema siga el ritmo de las cadenas públicas, lo que lleva a que muchos proyectos se desvaloricen en el TGE.
Aprovechando OP Stack, una plataforma de intercambio lanzó su propia Capa Base 2, otra plataforma de intercambio publicó Ink; utilizando tecnología ZK, una plataforma de intercambio lanzó XLayer; Sony lanzó Soneium, LINE presentó Kaia, entre otros. Hoy en día, el costo y la barrera técnica para construir una cadena se han reducido significativamente, 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. Aunque estas cadenas Layer 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 y alcanzar consenso en la misma cadena.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y estado disperso. 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 la abstracción de cadenas, la intención, la ejecución de Clearing, CrossChain nativo, 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 centrales de la abstracción de cadena cruzada:
Capa de Aplicación ( Capa de Aplicación )
Esta es la capa de interacción directa del usuario, y también es la capa más abstracta de la solución 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 y no necesariamente entienden el mecanismo de conversión de liquidez subyacente.
Capa de Permisos(Capa de Permisos)
Ubicado por debajo de la capa de aplicación, los usuarios conectan su billetera a la dApp y solicitan cotizaciones para satisfacer su intención de comercio. 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 abstracción de (Gestión de claves y abstracción de cuentas)
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 ú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 confiable, sin necesidad de establecer consenso entre cadenas, solo se requiere un compromiso confiable entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta generando billeteras de cuentas multichain para los usuarios, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de la UX. Sin embargo, en términos de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Capa de Solución (Solver Layer )
Esta capa es responsable de recibir e implementar las intenciones de transacción del usuario. El rol de Solver compite aquí para proporcionar una mejor experiencia al usuario, incluyendo tiempos de transacción más rápidos y velocidades de ejecución. Sobre esta base, proyectos basados en intenciones como Anoma han construido diversas soluciones impulsadas por intenciones. Derivados de tales intenciones, como el componente Predicate, pueden implementar las intenciones del usuario bajo reglas específicas.
Capa de Liquidación(Capa de Liquidación)
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de la solución de Liquidez y estado disperso incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la finalidad (Finality ), los mecanismos de prueba de Layer 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
( solución
Actualmente, en el mercado hay varias soluciones para resolver la liquidez tomar a la gente por tonta. Después de revisar una gran cantidad de soluciones, encontramos que las principales son estas formas:
Centrado en RaaS: soluciones Rollup como OP Stack, mediante la incorporación de un ordenadores compartidos específicos y puentes entre cadenas para ayudar a compartir la liquidez y el estado de los Rollup construidos sobre OP Stack. Esto espera poder resolver la liquidez y el estado dispersos en un nivel superior. Dentro de esto, hay un diseño más segmentado que es un ordenador compartido separado, esta solución está más orientada a Layer2, no tiene aplicabilidad universal, como Astria, Espresso y Flashbots.
Centrado en la cuenta: similar a NEAR, construir una billetera de cuenta de cadena completa, soportada por una tecnología llamada "firma de cadena" para 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 de los usuarios. Este conjunto de soluciones, aunque puede resolver en gran medida el problema de la fragmentación de 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 intención fuera de la cadena: es decir, la red de Solver en el diagrama de la estructura del pastel de "introducción". El núcleo es que los usuarios envían intenciones a la red de Solver. Este rol de Solver compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos Solvers pueden ser agentes de IA, CEX, creadores de mercado o incluso protocolos integrados como Liquorice, entre otros. Los proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque la intención puede, en teoría, lograr operaciones complejas de cadena cruzada de cualquier dificultad, en la práctica se necesita suficiente Liquidez de Solvers para ayudar, y cuando se enfrentan a algunas necesidades fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen medios como pruebas de fraude, la dificultad de implementación de la red de Solvers aumentará, y el umbral para operar como Solver también será mayor.
Centrado en la 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 dispersión del estado en cadena. Su núcleo es construir una capa de liquidez, sobre la cual se desarrollan 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 a través de la integración de grandes MM, o aplicaciones de terceros, como Liquorice, Socket, Radiant Capital, 1inch, Hedgemony, etc. Este tipo de proyectos requieren gestionar procesos complejos entre cadenas, lo que exige mucho a los desarrolladores, por lo que también son muy susceptibles a ataques de hackers.
![Investigación sobre el problema de la fragmentación de la liquidez en la era de Layer2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp###
Resolver el problema de la Liquidez es un tema muy importante, ya que en el mundo financiero la Liquidez a menudo lo representa todo. Si se puede construir una plataforma que integre la Liquidez, especialmente integrando la Liquidez de toda la cadena dispersa, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos categorías anteriores, podemos ver que, según la estructura del pastel, el Settlement Layer es la solución más atómica. Por encima de estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que son el Solver Layer, Permission Layer y Application Layer. Las diferentes soluciones de abstracción o Liquidez que enumeramos arriba, construidas en diferentes direcciones, se pueden entender como una relación de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas, el problema de la ruptura de Liquidez ha traído consigo la aparición de numerosos problemas derivados complejos, por lo tanto, en cuanto a interoperabilidad, han surgido una variedad de soluciones. Pero, en esencia, todavía 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 aborda el problema de la ruptura de Liquidez desde su propio punto de partida.
(# INFINIT
INFINIT ha construido un servicio RaaS en el ámbito DeFi, que puede proporcionar 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 Leverage Trading y Yield Strategy que se pueden activar de inmediato. Equivale a otros extremos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente no se ha revelado el funcionamiento subyacente. Hasta ahora, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla de Robot Ventures, Electric Capital y Maelstrom Capital.
![Investigación sobre el problema de la liquidez y la fragmentación en la era Layer2])https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp###
(# Khalani Network
Khalani ha construido tres componentes centrales: 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 la capa de compatibilidad de Intent de Khalani puede convertir las intenciones externas en un formato que el Solver del protocolo pueda reconocer, utilizando un formato normalizado que es el lenguaje de Validez. El nodo de 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, entre otros. Este proyecto aún se encuentra en la fase de construcción y no se han revelado más detalles sobre el 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.
![Investigación sobre el problema de la fragmentación de la liquidez en la era Layer2])https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp###
(# Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unilateral. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas eficientes de gestión de inventario, y conectar fácilmente con los protocolos centrales de DeFi al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice creó un mercado de préstamos para llevar a cabo transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente sigue en fase de desarrollo, y en julio anunció que había obtenido una financiación de 1.2 millones de dólares en una ronda Pre-seed liderada por GreenField.
![Investigación sobre el problema de la fragmentación de liquidez en la era Layer2])https://img-cdn.gateio.im/webp-social/moments-480179c7379a7927397a4c027efdc0a9.webp###
(# Xion
Xion es una evolución de la marca Burnt. Anteriormente, Burnt se centraba en aplicaciones para consumidores, pero el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyeron Xion para mejorar esta situación. 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 nativo y seguro que otros puentes entre cadenas. Ha llevado a cabo cuatro rondas de financiación, con inversores como Animoca, Multicoin, Alliance DAO y Mechanism.
)# =nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y desarrollador de Layer2, con un equipo que tiene una sólida base técnica en ZK. Propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la cadena principal de Ethereum, ejecutar el procesamiento de transacciones en paralelo mediante fragmentación y generar 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 el fragmento de ejecución. El protocolo de consenso utilizado por el comité de validación es también Hotstuff, que es común en los proyectos de ejecución paralela más recientes. =nil; L2 integró la comunicación entre fragmentos en el protocolo desde el principio. 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 Layer2 fragmentada, lo que podría resolver los problemas de Liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, porque el problema que resuelve la dispersión de Liquidez es el problema de múltiples cadenas; lo que construye es una única Layer2, lo que significa que para resolverlo, todas las cadenas deben convertirse en un fragmento de ZK-sharding, lo cual es difícil de lograr.
![Investigación sobre el problema de la liquidez fragmentada en la era de Layer2]###https://img-cdn.gateio.im/webp-social/moments-69852e6a1bbab8f4fc50f48006eb6fef.webp###
(# ERC-7683
Ethereum también está trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, ciertos DEX y OP son los primeros en 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 general para las operaciones entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación para lograr una ejecución sin fisuras entre cadenas. Su núcleo principal es un Filler, que también se puede considerar como el rol de Solver en la abstracción de la cadena para el pago. Esta propuesta fue construida conjuntamente por un DEX y Across.