Estudio sobre el problema de la liquidez segregada en la era de Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el auge de herramientas como RaaS, muchas cadenas públicas han evolucionado rápidamente. Muchas entidades buscan construir su propia cadena para representar diferentes intereses y buscar una valoración más alta. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado que el desarrollo del ecosistema mantenga el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos se devalúen en el momento de su TGE.
A través de OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma de intercambio ha publicado Ink; gracias a la tecnología ZK, otra plataforma de intercambio ha lanzado XLayer; Sony ha lanzado Soneium, LINE ha lanzado Kaia, entre otros. Hoy en día, el capital y el umbral tecnológico para construir una cadena se han reducido drásticamente, el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro será una era de coexistencia de múltiples cadenas. Aunque estas cadenas de Capa 2 puedan 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 posteriores, les resulta difícil construir aplicaciones y alcanzar un consenso en la misma cadena.
El ecosistema actual de múltiples cadenas ha traído 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 área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como las que todos hemos oído hablar, abstracción de cadena, intención, Clearing Execution, Native CrossChain, ZKSharding, pero su esencia central es la misma.
Usamos la arquitectura Cake, reconocida en la industria, para presentar de arriba hacia abajo 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 más abstracta en la solución de liquidez, ya que 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 conocer el mecanismo de conversión de liquidez subyacente.
Capa de Permiso(Capa de Permiso)
Ubicado por 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 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 Capa 2 ( Gestión de claves y abstracción de cuentas )
Debido a la existencia de un entorno multi-cadena, 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. 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 ámbito, que construye un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo con promesas confiables entre los sistemas de cuentas existentes. Near Account logra la gestión abstracta generando billeteras de cuentas multi-cadena para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en términos de liquidez, se integraron principalmente las cadenas públicas existentes.
Resolver Capa ( Capa )
Esta capa es responsable de recibir e implementar 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 y velocidad de ejecución más rápidos. 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 de los usuarios bajo reglas específicas.
Capa de liquidación (Settlement Layer)
Esta es la capa intermedia utilizada para resolver el nivel para implementar la intención del usuario. Los componentes centrales de las soluciones de Liquidez y estado descentralizado incluyen:
Oráculo (: utilizado para obtener información de 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 ), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
( solución
Actualmente, hay varias soluciones en el mercado para resolver la liquidez tomar a la gente por tonta. Después de revisar una gran cantidad de soluciones, encontramos que principalmente hay estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a construir Rollup sobre OP Stack mediante la incorporación de ordenadores compartidos específicos y puentes entre cadenas para compartir liquidez y estado. Esto espera resolver la liquidez y la dispersión del estado desde un nivel más alto. Hay un diseño más específico que es el ordenador compartido diseñado por separado, esta solución se dirige más a la Capa 2, no tiene universalidad, como Astria, Espresso y Flashbots.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta a lo largo de toda la cadena, soportada 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 clave es la red MPC, que firma las transacciones multichain en lugar del usuario. Esta solución, aunque puede resolver en gran medida el problema de la fragmentación de UX, implica una implementación backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión de estados.
Centrado en la red de intención fuera de la cadena: es decir, nuestra red de Solver en el diagrama de la arquitectura del pastel de "introducción", donde 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 mejor tiempo de finalización y el 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 las intenciones teóricamente pueden 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 demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers; si se introducen métodos como pruebas de fraude, la dificultad de implementar la red de Solvers aumentará, y el umbral para operar un Solver también será más alto.
Centrado en una red de liquidez en cadena: esta dirección está especialmente optimizada para el problema 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 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 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 que 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 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, el Settlement Layer es la solución de nivel más atómico. Sobre 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 anteriormente en diferentes direcciones se pueden entender como relaciones de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de la liquidez ha dado lugar a una serie de problemas derivados complicados. Por lo tanto, en respuesta a la interoperabilidad, han surgido soluciones diversas y variadas. Pero, en esencia, aún dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción de cadenas para ver cómo cada uno aborda el problema de la fragmentación de la liquidez desde su propio punto de partida.
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. También puede ofrecer componentes como Leverage Trading y Yield Strategy que se pueden activar de inmediato. Es equivalente 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 ha revelado el funcionamiento subyacente. Actualmente, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla de algunas instituciones de inversión reconocidas.
)# Khalani Network
Khalani construyó tres componentes centrales: la capa compatible con Intent, la Validez 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 intenciones de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo puede 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 de cadena cruzada, 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 del trabajo. En agosto, obtuvo 2,2 millones de dólares en financiación de la ronda semilla de algunas instituciones de inversión reconocidas.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccional. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas eficientes de gestión de inventario, y al mismo tiempo, conectarse fácilmente a algunos protocolos DeFi clave al liquidar transacciones con intención de uso. Además, Liquorice ha creado un mercado de préstamos para llevar a cabo transacciones de préstamo. Esta aplicación se centra más en el trading en sí. Actualmente sigue en fase de desarrollo, y en julio anunció la obtención de 1.2 millones de dólares en una ronda de financiación Pre-seed de algunas instituciones de inversión reconocidas.
Xion
Xion es una evolución de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Posteriormente, 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 se basa en 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 financiación, con algunos inversores de instituciones de inversión reconocidas.
=nil; Fundación
nil es el mercado de capacidad de cálculo ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2, el equipo tiene una profunda 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 valida 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 también es Hotstuff, lo cual es común en los proyectos de ejecución paralela más recientes. =nil; L2 incorporó la comunicación entre fragmentos en el protocolo desde el principio. Los mensajes entre fragmentos son validados 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 Layer 2 fragmentada, lo que resolvería los problemas de liquidez y dispersión de estado. Sin embargo, su idea central no es razonable, ya que el problema que resuelve la dispersión de liquidez es un problema de múltiples cadenas, y lo que se está construyendo es un único Layer 2, lo que significa que para resolverlo, todas las cadenas tendrían que convertirse en un fragmento de ZK-sharding, lo cual es difícil de lograr.
ERC-7683
Ethereum también está abordando el problema de la liquidez cruzada, actualmente algunos proyectos conocidos apoyan 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 universal para las operaciones de cadena cruzada entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidaciones, logrando una ejecución cruzada sin problemas; su núcleo principal es un Filler, que también se puede describir como el papel de Solver en la abstracción de la cadena para el pago. Esta propuesta ha sido construida por algunos proyectos conocidos 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 las capas de arquitectura, consenso y aplicación. OP Stack resuelve de una vez el problema de la transmisión de información y la descentralización del Sequencer, diseñando una solución completa de múltiples Capa 2. Al usar la arquitectura OP Stack, se desplegarán automáticamente contratos cruzados, y habrá un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, hay algunos proyectos conocidos que utilizan la arquitectura OP Stack.
Entre ellos, el más típico es Unichain. Unichain resuelve el problema de la fragmentación de la liquidez entre cadenas principalmente mediante la integración con la red Superchain. Esta configuración facilita el movimiento de liquidez sin problemas al ofrecer las siguientes funciones:
Puente entre cadenas basado en intenciones: este
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.
15 me gusta
Recompensa
15
5
Republicar
Compartir
Comentar
0/400
GateUser-75ee51e7
· hace19h
Demasiadas cadenas pequeñas solo se preocupan por la valoración. Basura.
Ver originalesResponder0
GasFeeCry
· 08-10 19:23
La pista no puede soportarlo más.
Ver originalesResponder0
ContractExplorer
· 08-10 19:22
¡Voy a hacer la cadena más explosiva! ¿Quién se une a mí?
Ver originalesResponder0
MemeEchoer
· 08-10 19:21
Otra ola de soñadores de cadenas públicas con el mismo final jajaja
Ver originalesResponder0
TokenEconomist
· 08-10 18:59
en realidad, este es un clásico dilema del prisionero en la distribución de liquidez l2... déjame desglosar las matemáticas rápidamente
Explorando el problema de la fragmentación de liquidez en la era de Capa 2 y las soluciones principales.
Estudio sobre el problema de la liquidez segregada en la era de Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el auge de herramientas como RaaS, muchas cadenas públicas han evolucionado rápidamente. Muchas entidades buscan construir su propia cadena para representar diferentes intereses y buscar una valoración más alta. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado que el desarrollo del ecosistema mantenga el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos se devalúen en el momento de su TGE.
A través de OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma de intercambio ha publicado Ink; gracias a la tecnología ZK, otra plataforma de intercambio ha lanzado XLayer; Sony ha lanzado Soneium, LINE ha lanzado Kaia, entre otros. Hoy en día, el capital y el umbral tecnológico para construir una cadena se han reducido drásticamente, el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro será una era de coexistencia de múltiples cadenas. Aunque estas cadenas de Capa 2 puedan 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 posteriores, les resulta difícil construir aplicaciones y alcanzar un consenso en la misma cadena.
El ecosistema actual de múltiples cadenas ha traído 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 área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como las que todos hemos oído hablar, abstracción de cadena, intención, Clearing Execution, Native CrossChain, ZKSharding, pero su esencia central es la misma.
Usamos la arquitectura Cake, reconocida en la industria, para presentar de arriba hacia abajo 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 más abstracta en la solución de liquidez, ya que 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 conocer el mecanismo de conversión de liquidez subyacente.
Capa de Permiso(Capa de Permiso)
Ubicado por 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 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 Capa 2 ( Gestión de claves y abstracción de cuentas )
Debido a la existencia de un entorno multi-cadena, 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. 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 ámbito, que construye un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo con promesas confiables entre los sistemas de cuentas existentes. Near Account logra la gestión abstracta generando billeteras de cuentas multi-cadena para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en términos de liquidez, se integraron principalmente las cadenas públicas existentes.
Resolver Capa ( Capa )
Esta capa es responsable de recibir e implementar 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 y velocidad de ejecución más rápidos. 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 de los usuarios bajo reglas específicas.
Capa de liquidación (Settlement Layer)
Esta es la capa intermedia utilizada para resolver el nivel para implementar la intención del usuario. Los componentes centrales de las soluciones de Liquidez y estado descentralizado incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la finalidad (Finality ), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
( solución
Actualmente, hay varias soluciones en el mercado para resolver la liquidez tomar a la gente por tonta. Después de revisar una gran cantidad de soluciones, encontramos que principalmente hay estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a construir Rollup sobre OP Stack mediante la incorporación de ordenadores compartidos específicos y puentes entre cadenas para compartir liquidez y estado. Esto espera resolver la liquidez y la dispersión del estado desde un nivel más alto. Hay un diseño más específico que es el ordenador compartido diseñado por separado, esta solución se dirige más a la Capa 2, no tiene universalidad, como Astria, Espresso y Flashbots.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta a lo largo de toda la cadena, soportada 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 clave es la red MPC, que firma las transacciones multichain en lugar del usuario. Esta solución, aunque puede resolver en gran medida el problema de la fragmentación de UX, implica una implementación backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión de estados.
Centrado en la red de intención fuera de la cadena: es decir, nuestra red de Solver en el diagrama de la arquitectura del pastel de "introducción", donde 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 mejor tiempo de finalización y el 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 las intenciones teóricamente pueden 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 demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers; si se introducen métodos como pruebas de fraude, la dificultad de implementar la red de Solvers aumentará, y el umbral para operar un Solver también será más alto.
Centrado en una red de liquidez en cadena: esta dirección está especialmente optimizada para el problema 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 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 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 que 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 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, el Settlement Layer es la solución de nivel más atómico. Sobre 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 anteriormente en diferentes direcciones se pueden entender como relaciones de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de la liquidez ha dado lugar a una serie de problemas derivados complicados. Por lo tanto, en respuesta a la interoperabilidad, han surgido soluciones diversas y variadas. Pero, en esencia, aún dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción de cadenas para ver cómo cada uno aborda el problema de la fragmentación de la liquidez desde su propio punto de partida.
![Capa 2时代下，Liquidez割裂问题的研究])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp###
(# 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. También puede ofrecer componentes como Leverage Trading y Yield Strategy que se pueden activar de inmediato. Es equivalente 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 ha revelado el funcionamiento subyacente. Actualmente, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla de algunas instituciones de inversión reconocidas.
)# Khalani Network
Khalani construyó tres componentes centrales: la capa compatible con Intent, la Validez 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 intenciones de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo puede 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 de cadena cruzada, 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 del trabajo. En agosto, obtuvo 2,2 millones de dólares en financiación de la ronda semilla de algunas instituciones de inversión reconocidas.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccional. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas eficientes de gestión de inventario, y al mismo tiempo, conectarse fácilmente a algunos protocolos DeFi clave al liquidar transacciones con intención de uso. Además, Liquorice ha creado un mercado de préstamos para llevar a cabo transacciones de préstamo. Esta aplicación se centra más en el trading en sí. Actualmente sigue en fase de desarrollo, y en julio anunció la obtención de 1.2 millones de dólares en una ronda de financiación Pre-seed de algunas instituciones de inversión reconocidas.
Xion
Xion es una evolución de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Posteriormente, 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 se basa en 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 financiación, con algunos inversores de instituciones de inversión reconocidas.
=nil; Fundación
nil es el mercado de capacidad de cálculo ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2, el equipo tiene una profunda 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 valida 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 también es Hotstuff, lo cual es común en los proyectos de ejecución paralela más recientes. =nil; L2 incorporó la comunicación entre fragmentos en el protocolo desde el principio. Los mensajes entre fragmentos son validados 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 Layer 2 fragmentada, lo que resolvería los problemas de liquidez y dispersión de estado. Sin embargo, su idea central no es razonable, ya que el problema que resuelve la dispersión de liquidez es un problema de múltiples cadenas, y lo que se está construyendo es un único Layer 2, lo que significa que para resolverlo, todas las cadenas tendrían que convertirse en un fragmento de ZK-sharding, lo cual es difícil de lograr.
ERC-7683
Ethereum también está abordando el problema de la liquidez cruzada, actualmente algunos proyectos conocidos apoyan 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 universal para las operaciones de cadena cruzada entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidaciones, logrando una ejecución cruzada sin problemas; su núcleo principal es un Filler, que también se puede describir como el papel de Solver en la abstracción de la cadena para el pago. Esta propuesta ha sido construida por algunos proyectos conocidos 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 las capas de arquitectura, consenso y aplicación. OP Stack resuelve de una vez el problema de la transmisión de información y la descentralización del Sequencer, diseñando una solución completa de múltiples Capa 2. Al usar la arquitectura OP Stack, se desplegarán automáticamente contratos cruzados, y habrá un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, hay algunos proyectos conocidos que utilizan la arquitectura OP Stack.
Entre ellos, el más típico es Unichain. Unichain resuelve el problema de la fragmentación de la liquidez entre cadenas principalmente mediante la integración con la red Superchain. Esta configuración facilita el movimiento de liquidez sin problemas al ofrecer las siguientes funciones:
Puente entre cadenas basado en intenciones: este