Investigación sobre el problema de la liquidez fragmentada en la era de Capa 2
Desde que Ethereum se ha centrado en soluciones de escalabilidad basadas en Capa 2, junto con el auge de herramientas como RaaS, numerosas cadenas públicas han evolucionado rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes demandas de interés y buscar una mayor valoración. Sin embargo, la aparición de tantas cadenas públicas ha dificultado que el desarrollo del ecosistema siga el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos se desmoronen 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; aprovechando la tecnología ZK, otra plataforma 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, 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 Capa 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades de Web2 detrás de ellas tienen una gran cantidad de aplicaciones descendentes, les resulta difícil construir aplicaciones y alcanzar un consenso en la misma cadena.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y dispersión de 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 la abstracción de cadena, intención, Clearing Execution, Native CrossChain, ZKSharding, etc., pero su esencia central es la misma.
Utilizamos la arquitectura Cake, reconocida en la industria, para presentar de arriba hacia abajo la composición de los componentes centrales de la abstracción de cadena cruzada:
Capa de aplicación ( Capa de aplicación )
Esta es la capa con la que los usuarios interactúan directamente, y también es la más abstracta de las soluciones de liquidez, ya que oculta por completo los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente conocer 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 satisfacen su intención de transacción al conectar su billetera a la dApp y solicitar un presupuesto. 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 claves ( Key Management and Account Abstraction )
Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener las estructuras de cuentas únicas 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 un consenso entre cadenas, solo requiere compromisos confiables entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta al generar billeteras de cuentas multichain para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de UX. Sin embargo, en términos de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Resolver Capa ( Capa )
Esta capa se encarga 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 más rápidos y una mayor velocidad de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos de intenciones. Los derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones del usuario bajo reglas específicas.
Capa de liquidación (Settlement Layer )
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de la solución de liquidez y estado disperso incluyen:
Oráculo (: utilizado para obtener información sobre el estado en otras cadenas.
Puente intercadena ) Bridges (: responsable de la transmisión de información y liquidez entre cadenas.
Confirmación anticipada de ) Pre-Confirmation (: acortar 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, etc., 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(
Actualmente, hay varias soluciones en el mercado para la fragmentación de liquidez. Tras revisar una gran cantidad de opciones, hemos encontrado que las principales son las siguientes:
Centrado en RaaS: similar a soluciones de Rollup como OP Stack, asistiendo en la construcción de Rollup en OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas para compartir liquidez y estado. Esto espera resolver la dispersión de liquidez y estado en un nivel más alto. Aquí hay un diseño más específico que es un ordenante compartido separado, esta solución está más dirigida a Capa 2, no tiene universalidad.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta de cadena completa, que a través de una tecnología llamada "firma de cadena" soporte la firma y ejecución de transacciones a través de múltiples protocolos de blockchain. El componente central es la red MPC, que firma las transacciones en múltiples cadenas 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 intenciones fuera de la cadena: es decir, la red de solucionadores en el diagrama de arquitectura de "introducción" del pastel, el núcleo es que los usuarios envían intenciones a la red de solucionadores, este rol de solucionador compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos solucionadores pueden ser agentes de IA, CEX, creadores de mercado o incluso el protocolo integrado en sí. Aunque las intenciones pueden teóricamente realizar operaciones inter-cadenas complejas de cualquier dificultad, en la práctica se necesita suficiente Liquidez de solucionadores para ayudar, y cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los solucionadores. Si se introducen medios como pruebas de fraude, la dificultad de implementar la red de solucionadores aumentará, y el umbral para operar un solucionador 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 resuelve otros problemas de estado disperso en la cadena. Su núcleo es construir una capa de liquidez, sobre la cual se construyen aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en cadena: Este tipo de aplicaciones construyen aplicaciones de alta liquidez integrando grandes MM o aplicaciones de terceros. Estos proyectos requieren gestionar procesos complejos entre cadenas, exigen mucho a los desarrolladores y, por lo tanto, son 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 fragmentada de toda la cadena, tendrá un potencial muy grande.
![Investigación sobre el problema de la división de liquidez en la era de Capa 2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
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. 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 hemos listado anteriormente se pueden entender como relaciones de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas. El problema de la fragmentación de la Liquidez ha llevado a la aparición de muchos problemas derivados complejos, por lo que han surgido una variedad de soluciones para la interoperabilidad. 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 propia perspectiva.
)# INFINIT
INFINIT ha construido un servicio RaaS para el ecosistema DeFi, que puede proporcionar los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Tipo de Pool, IRM, Activo, etc., y también puede ofrecer componentes como Trading con Apalancamiento y Estrategia de Rendimiento que se pueden activar de inmediato. Es comparable a otros extremos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente aún no se ha revelado el funcionamiento subyacente.
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 luego la capa de compatibilidad de Intents de Khalani puede convertir las intenciones externas en un formato que el protocolo Solver puede reconocer, utilizando el formato normalizado que es el lenguaje Validity. 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 sobre el trabajo.
Regaliz
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y un grupo de liquidez unidireccional. La misión principal de Liquorice es proporcionar herramientas de gestión de inventario eficientes para empresas de trading profesionales y facilitar la conexión con protocolos DeFi centrales al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice ha creado 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.
Xion
Xion es una actualización de la marca Burnt. Anteriormente, Burnt se centraba en aplicaciones para consumidores, pero luego el equipo descubrió que había un gran problema de fragmentación en las interacciones en cadena, por lo que construyeron 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.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp(
)# =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. Propusieron 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 incorporó la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados por el comité de validación de cada fragmento como transacciones.
Su idea básica es construir una arquitectura de comunicación entre fragmentos incrustada similar a IBC a través de la arquitectura de Layer 2 fragmentada, lo que puede resolver los problemas de Liquidez y estado disperso. 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 Layer 2, lo que significa que para resolverlo, todas las cadenas deben convertirse en un fragmento de ZK-sharding, lo cual es difícil de lograr.
ERC-7683
Ethereum también está trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, varias plataformas están apoyando 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 entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidaciones, logrando una ejecución sin problemas 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 cadena que realiza el pago. Esta propuesta ha sido construida por dos proyectos y actualmente está siendo revisada por el grupo de trabajo de Cake.
![Investigación sobre el problema de la liquidez desgajada en la era de Capa 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp(
)# 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 los problemas de transmisión de información y descentralización del Sequencer mediante el diseño de una solución completa de múltiples Capa 2. Al utilizar la arquitectura de OP Stack, se despliegan automáticamente contratos cruzados, y existe un Supervisor que desafía para evitar la transmisión de información cruzada falsa. Actualmente, hay varios proyectos conocidos que utilizan la arquitectura de OP Stack.
entre ellos, el más representativo es Unichain. Unichain se basa principalmente en
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.
10 me gusta
Recompensa
10
5
Compartir
Comentar
0/400
MemeTokenGenius
· hace11h
tomar a la gente por tonta无药可医
Ver originalesResponder0
SocialAnxietyStaker
· hace11h
La salida de Layer2 se está acelerando
Ver originalesResponder0
GateUser-9ad11037
· hace11h
Los grandes problemas requieren una respuesta flexible
Análisis de los desafíos y soluciones de la liquidez en la era de la Capa 2 tomados por tonta
Investigación sobre el problema de la liquidez fragmentada en la era de Capa 2
Desde que Ethereum se ha centrado en soluciones de escalabilidad basadas en Capa 2, junto con el auge de herramientas como RaaS, numerosas cadenas públicas han evolucionado rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes demandas de interés y buscar una mayor valoración. Sin embargo, la aparición de tantas cadenas públicas ha dificultado que el desarrollo del ecosistema siga el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos se desmoronen 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; aprovechando la tecnología ZK, otra plataforma 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, 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 Capa 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades de Web2 detrás de ellas tienen una gran cantidad de aplicaciones descendentes, les resulta difícil construir aplicaciones y alcanzar un consenso en la misma cadena.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y dispersión de 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 la abstracción de cadena, intención, Clearing Execution, Native CrossChain, ZKSharding, etc., pero su esencia central es la misma.
Utilizamos la arquitectura Cake, reconocida en la industria, para presentar de arriba hacia abajo la composición de los componentes centrales de la abstracción de cadena cruzada:
Capa de aplicación ( Capa de aplicación )
Esta es la capa con la que los usuarios interactúan directamente, y también es la más abstracta de las soluciones de liquidez, ya que oculta por completo los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente conocer 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 satisfacen su intención de transacción al conectar su billetera a la dApp y solicitar un presupuesto. 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 claves ( Key Management and Account Abstraction )
Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener las estructuras de cuentas únicas 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 un consenso entre cadenas, solo requiere compromisos confiables entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta al generar billeteras de cuentas multichain para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de UX. Sin embargo, en términos de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Resolver Capa ( Capa )
Esta capa se encarga 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 más rápidos y una mayor velocidad de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos de intenciones. Los derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones del usuario bajo reglas específicas.
Capa de liquidación (Settlement Layer )
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de 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(, el mecanismo de prueba de Capa 2, etc., 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(
Actualmente, hay varias soluciones en el mercado para la fragmentación de liquidez. Tras revisar una gran cantidad de opciones, hemos encontrado que las principales son las siguientes:
Centrado en RaaS: similar a soluciones de Rollup como OP Stack, asistiendo en la construcción de Rollup en OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas para compartir liquidez y estado. Esto espera resolver la dispersión de liquidez y estado en un nivel más alto. Aquí hay un diseño más específico que es un ordenante compartido separado, esta solución está más dirigida a Capa 2, no tiene universalidad.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta de cadena completa, que a través de una tecnología llamada "firma de cadena" soporte la firma y ejecución de transacciones a través de múltiples protocolos de blockchain. El componente central es la red MPC, que firma las transacciones en múltiples cadenas 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 intenciones fuera de la cadena: es decir, la red de solucionadores en el diagrama de arquitectura de "introducción" del pastel, el núcleo es que los usuarios envían intenciones a la red de solucionadores, este rol de solucionador compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos solucionadores pueden ser agentes de IA, CEX, creadores de mercado o incluso el protocolo integrado en sí. Aunque las intenciones pueden teóricamente realizar operaciones inter-cadenas complejas de cualquier dificultad, en la práctica se necesita suficiente Liquidez de solucionadores para ayudar, y cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los solucionadores. Si se introducen medios como pruebas de fraude, la dificultad de implementar la red de solucionadores aumentará, y el umbral para operar un solucionador 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 resuelve otros problemas de estado disperso en la cadena. Su núcleo es construir una capa de liquidez, sobre la cual se construyen aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en cadena: Este tipo de aplicaciones construyen aplicaciones de alta liquidez integrando grandes MM o aplicaciones de terceros. Estos proyectos requieren gestionar procesos complejos entre cadenas, exigen mucho a los desarrolladores y, por lo tanto, son 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 fragmentada de toda la cadena, tendrá un potencial muy grande.
![Investigación sobre el problema de la división de liquidez en la era de Capa 2])https://img-cdn.gateio.im/webp-social/moments-e170f453d0b5b33f7ffc55facc9626c8.webp(
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. 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 hemos listado anteriormente se pueden entender como relaciones de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas. El problema de la fragmentación de la Liquidez ha llevado a la aparición de muchos problemas derivados complejos, por lo que han surgido una variedad de soluciones para la interoperabilidad. 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 propia perspectiva.
)# INFINIT
INFINIT ha construido un servicio RaaS para el ecosistema DeFi, que puede proporcionar los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Tipo de Pool, IRM, Activo, etc., y también puede ofrecer componentes como Trading con Apalancamiento y Estrategia de Rendimiento que se pueden activar de inmediato. Es comparable a otros extremos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente aún no se ha revelado el funcionamiento subyacente.
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 luego la capa de compatibilidad de Intents de Khalani puede convertir las intenciones externas en un formato que el protocolo Solver puede reconocer, utilizando el formato normalizado que es el lenguaje Validity. 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 sobre el trabajo.
Regaliz
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y un grupo de liquidez unidireccional. La misión principal de Liquorice es proporcionar herramientas de gestión de inventario eficientes para empresas de trading profesionales y facilitar la conexión con protocolos DeFi centrales al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice ha creado 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.
Xion
Xion es una actualización de la marca Burnt. Anteriormente, Burnt se centraba en aplicaciones para consumidores, pero luego el equipo descubrió que había un gran problema de fragmentación en las interacciones en cadena, por lo que construyeron 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.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究]###https://img-cdn.gateio.im/webp-social/moments-0f51232f5a7495ce85432c8feb374ed1.webp(
)# =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. Propusieron 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 incorporó la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados por el comité de validación de cada fragmento como transacciones.
Su idea básica es construir una arquitectura de comunicación entre fragmentos incrustada similar a IBC a través de la arquitectura de Layer 2 fragmentada, lo que puede resolver los problemas de Liquidez y estado disperso. 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 Layer 2, lo que significa que para resolverlo, todas las cadenas deben convertirse en un fragmento de ZK-sharding, lo cual es difícil de lograr.
ERC-7683
Ethereum también está trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, varias plataformas están apoyando 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 entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidaciones, logrando una ejecución sin problemas 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 cadena que realiza el pago. Esta propuesta ha sido construida por dos proyectos y actualmente está siendo revisada por el grupo de trabajo de Cake.
![Investigación sobre el problema de la liquidez desgajada en la era de Capa 2]###https://img-cdn.gateio.im/webp-social/moments-e4d53accc40f8c915eaabbd2909f51d4.webp(
)# 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 los problemas de transmisión de información y descentralización del Sequencer mediante el diseño de una solución completa de múltiples Capa 2. Al utilizar la arquitectura de OP Stack, se despliegan automáticamente contratos cruzados, y existe un Supervisor que desafía para evitar la transmisión de información cruzada falsa. Actualmente, hay varios proyectos conocidos que utilizan la arquitectura de OP Stack.
entre ellos, el más representativo es Unichain. Unichain se basa principalmente en