Investigación sobre el problema de la liquidez segmentada en la era de la Capa 2
Después de que Ethereum se centrara en soluciones de escalado basadas en Capa 2, junto con el surgimiento de herramientas como RaaS, muchas cadenas públicas han avanzado rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema, lo que ha llevado a que muchos proyectos se desplomen en el TGE.
Con la ayuda de OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma ha publicado Ink; utilizando la tecnología ZK, una plataforma de intercambio ha lanzado XLayer; Sony ha lanzado Soneium, LINE ha presentado Kaia, entre otros. Hoy en día, el costo y las barreras tecnológicas para construir una cadena se han reducido considerablemente, el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro será sin duda una era de coexistencia de múltiples cadenas. Aunque estas Capa 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades de Web2 detrás de ellas tienen una gran cantidad de aplicaciones en el ámbito inferior, es difícil construir aplicaciones y alcanzar el consenso en la misma cadena.
El ecosistema multichain actual 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 se convierte en un área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como la abstracción de cadenas, la intención, la ejecución de clearing, el crosschain nativo, y el ZKSharding, pero su esencia central es la misma.
Utilizamos la arquitectura Cake, que es bastante 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(Application Layer)
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 y pueden no entender el mecanismo de conversión de liquidez subyacente.
Capa de Permiso(Permission Layer)
Situado por debajo de la capa de aplicación, el usuario satisface su intención de transacción conectando su billetera a la dApp y solicitando una cotización. Aquí, la "intención" se refiere al resultado final de la transacción 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 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 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 la gestión de abstracción generando billeteras de cuentas multichain para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en el aspecto de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Resolver Capa(
Esta capa es responsable de recibir e implementar las intenciones de transacción de los usuarios. El rol del Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de transacción más rápidos y velocidades de ejecución. Sobre esta base, proyectos basados en la intención como Anoma han construido diversas soluciones impulsadas por intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones del usuario bajo ciertas reglas.
Capa de Liquidación )Settlement Layer(
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de la solución de liquidez y estado descentralizado incluyen:
Oráculo ) Oracle (: utilizado para obtener información de estado en otras cadenas.
Puentes Capa 2 ): responsables de la transmisión de información y Liquidez entre cadenas.
Confirmación anticipada (: acortar el tiempo de confirmación entre cadenas.
Disponibilidad de datos)DA(: proporciona accesibilidad a los datos.
Además, también se deben considerar factores como la liquidez entre cadenas, la confirmación final ) Finality (, el mecanismo de prueba de Capa 2, entre otros, para garantizar la operación eficiente de todo el sistema multichain.
Actualmente, en el mercado hay varias soluciones para la liquidez fragmentada. Tras revisar una gran cantidad de soluciones, encontramos que principalmente hay estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a compartir liquidez y estado en los Rollups construidos sobre OP Stack mediante la incorporación de un ordenado compartido específico y puentes entre cadenas. Se espera que esto resuelva la descentralización de la liquidez y el estado en un nivel más alto. Dentro de esto, hay un diseño más específico de ordenadores compartidos, esta solución se dirige más hacia Capa 2, no es universal, como Astria, Espresso y Flashbots.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta completa en la cadena, que soporte la firma y ejecución de transacciones a través de múltiples protocolos de blockchain mediante una técnica llamada "firma en cadena". El componente central es la red de MPC, que firma transacciones multichain en lugar de los usuarios. Este sistema, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Centrado en la red de intenciones fuera de la cadena: es decir, la Solver Network en el diagrama de arquitectura del "introducción" de nuestro pastel, el núcleo es que los usuarios envían intenciones a la red Solver, este rol de Solver compite por 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 e incluso protocolos integrados como Liquorice, entre otros. Los proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque la intención teóricamente puede lograr operaciones complejas cruzadas de cualquier dificultad, en la práctica se requiere tener suficientes Solvers de liquidez para ayudar, y cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers; si se introducen medios como la prueba de fraude, la dificultad de implementación de la Solver Network aumentará, y el umbral para operar un Solver también será más alto.
Centrado en la red de liquidez en cadena: esta dirección se dedica a optimizar los problemas de liquidez entre cadenas, pero no ha resuelto otros problemas de dispersión de 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 mediante la integración de grandes MM, o aplicaciones de terceros, como Liquorice, Socket, Radiant Capital, alguna plataforma de trading, Hedgemony, etc. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que implica altas exigencias para los desarrolladores, por lo tanto, también 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 dispersa de toda la cadena, tendrá un gran potencial, y hemos visto muchas soluciones diferentes.
En las dos categorías anteriores, podemos ver que, según la estructura del pastel, la Settlement Layer es la solución más atómica. Sobre estas soluciones atómicas, como las de cross-chain, oráculos y Pre-Confirmation, se construye un nivel más abstracto, que son la Solver Layer, Permission Layer y Application Layer. Los diferentes niveles que enumeramos arriba, que construyen soluciones abstractas o de liquidez en diferentes direcciones, pueden entenderse como una relación 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 traído la aparición de muchos problemas derivados complejos, por lo que se han producido soluciones diversas en torno a 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 cadena para ver cómo cada uno aborda el problema de la fragmentación de la liquidez desde su propia perspectiva.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究])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., y también puede ofrecer componentes como Trading con Apalancamiento y Estrategia de Rendimiento, que están listos para usar. Es equivalente a otros extremos de construcción de aplicaciones, pero la liquidez final se encuentra 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 financiación de la ronda semilla de Robot Ventures, Electric Capital y Maelstrom Capital.
( Khalani Network
Khalani ha construido tres componentes centrales, que son 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 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. Los nodos de Khalani son responsables de enviar el resultado final a la capa de liquidación general a través de puentes intercadena, tecnología de liquidación rápida, etc. Este proyecto aún se encuentra en la fase de construcción y no ha revelado más detalles sobre el trabajo. En agosto, recibió 2,2 millones de dólares en financiamiento inicial de Ethereal Ventures, Nascent, Maelstrom Capital, entre otros.
) Liquorice
Liquorice es una aplicación descentralizada que permite la descubrimiento de precios basado en subastas y piscinas de liquidez unilaterales. 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 protocolos centrales de DeFi como algunos DEX al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice ha creado un mercado de préstamos para realizar transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente sigue en fase de desarrollo, habiendo anunciado en julio una financiación de 1.2 millones de dólares en una ronda Pre-seed liderada por GreenField.
Xion
Xion es una actualización de la marca Burnt. Anteriormente, Burnt se centraba en aplicaciones de consumo, pero luego 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 este problema. Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativa y segura que otros puentes entre cadenas. Ha realizado cuatro rondas de financiación, con inversores como Animoca, Multicoin, Alliance DAO, Mechanism, entre otros.
=nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2, el equipo tiene una sólida base técnica en ZK. Se 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 los fragmentos de ejecución. El protocolo de consenso utilizado por el comité de validación también es Hotstuff, que es común en los proyectos de ejecución paralela más recientes. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son validados por el comité de validadores 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 una arquitectura de Layer 2 fragmentada, lo que puede resolver los problemas de liquidez y dispersión de estados. Sin embargo, su idea central no es razonable, porque el problema que resuelve la dispersión de liquidez es un problema de múltiples cadenas, y lo que se 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á abordando el problema de la liquidez entre cadenas. Actualmente, cierta Capa 2, cierta Capa 2 y cierto DEX 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 común para las operaciones de cadena cruzada entre L2 y cadenas laterales, normalizando las interfaces de pedidos y liquidaciones, logrando una ejecución de cadena cruzada sin problemas. Su núcleo principal es un Filler, que también se puede considerar como el rol de Solver en la abstracción de cadenas que realiza el pago. Esta propuesta fue construida en conjunto por cierto DEX y Across, y actualmente está siendo revisada por el grupo de trabajo de Cake.
OP Stack
OP Stack, ERC-7683, y zkSharding son soluciones internas de Ethereum para la fragmentación de liquidez entre las Capa 2.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
5
Compartir
Comentar
0/400
GateUser-1a2ed0b9
· hace10h
La burbuja de valoración ha revelado su verdadera forma.
Ver originalesResponder0
FOMOmonster
· hace10h
Todos quieren comer carne.
Ver originalesResponder0
SeasonedInvestor
· hace10h
El fenómeno de caer por debajo del precio de emisión se ha vuelto habitual.
Crisis de liquidez en la era de la Capa 2: análisis de desafíos y soluciones
Investigación sobre el problema de la liquidez segmentada en la era de la Capa 2
Después de que Ethereum se centrara en soluciones de escalado basadas en Capa 2, junto con el surgimiento de herramientas como RaaS, muchas cadenas públicas han avanzado rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema, lo que ha llevado a que muchos proyectos se desplomen en el TGE.
Con la ayuda de OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma ha publicado Ink; utilizando la tecnología ZK, una plataforma de intercambio ha lanzado XLayer; Sony ha lanzado Soneium, LINE ha presentado Kaia, entre otros. Hoy en día, el costo y las barreras tecnológicas para construir una cadena se han reducido considerablemente, el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro será sin duda una era de coexistencia de múltiples cadenas. Aunque estas Capa 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades de Web2 detrás de ellas tienen una gran cantidad de aplicaciones en el ámbito inferior, es difícil construir aplicaciones y alcanzar el consenso en la misma cadena.
El ecosistema multichain actual 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 se convierte en un área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como la abstracción de cadenas, la intención, la ejecución de clearing, el crosschain nativo, y el ZKSharding, pero su esencia central es la misma.
Utilizamos la arquitectura Cake, que es bastante 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(Application Layer)
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 y pueden no entender el mecanismo de conversión de liquidez subyacente.
Capa de Permiso(Permission Layer)
Situado por debajo de la capa de aplicación, el usuario satisface su intención de transacción conectando su billetera a la dApp y solicitando una cotización. Aquí, la "intención" se refiere al resultado final de la transacción 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 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 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 la gestión de abstracción generando billeteras de cuentas multichain para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en el aspecto de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Resolver Capa(
Esta capa es responsable de recibir e implementar las intenciones de transacción de los usuarios. El rol del Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de transacción más rápidos y velocidades de ejecución. Sobre esta base, proyectos basados en la intención como Anoma han construido diversas soluciones impulsadas por intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones del usuario bajo ciertas reglas.
Capa de Liquidación )Settlement Layer(
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de la solución de liquidez y estado descentralizado incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la confirmación final ) Finality (, el mecanismo de prueba de Capa 2, entre otros, para garantizar la operación eficiente de todo el sistema multichain.
![Capa 2时代下，Liquidez割裂问题的研究])https://img-cdn.gateio.im/webp-social/moments-a94f0982457fcb1d9c6ef2493b0a499f.webp(
Solución
Actualmente, en el mercado hay varias soluciones para la liquidez fragmentada. Tras revisar una gran cantidad de soluciones, encontramos que principalmente hay estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a compartir liquidez y estado en los Rollups construidos sobre OP Stack mediante la incorporación de un ordenado compartido específico y puentes entre cadenas. Se espera que esto resuelva la descentralización de la liquidez y el estado en un nivel más alto. Dentro de esto, hay un diseño más específico de ordenadores compartidos, esta solución se dirige más hacia Capa 2, no es universal, como Astria, Espresso y Flashbots.
Enfoque centrado en la cuenta: similar a NEAR, construir una billetera de cuenta completa en la cadena, que soporte la firma y ejecución de transacciones a través de múltiples protocolos de blockchain mediante una técnica llamada "firma en cadena". El componente central es la red de MPC, que firma transacciones multichain en lugar de los usuarios. Este sistema, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Centrado en la red de intenciones fuera de la cadena: es decir, la Solver Network en el diagrama de arquitectura del "introducción" de nuestro pastel, el núcleo es que los usuarios envían intenciones a la red Solver, este rol de Solver compite por 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 e incluso protocolos integrados como Liquorice, entre otros. Los proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque la intención teóricamente puede lograr operaciones complejas cruzadas de cualquier dificultad, en la práctica se requiere tener suficientes Solvers de liquidez para ayudar, y cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers; si se introducen medios como la prueba de fraude, la dificultad de implementación de la Solver Network aumentará, y el umbral para operar un Solver también será más alto.
Centrado en la red de liquidez en cadena: esta dirección se dedica a optimizar los problemas de liquidez entre cadenas, pero no ha resuelto otros problemas de dispersión de 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 mediante la integración de grandes MM, o aplicaciones de terceros, como Liquorice, Socket, Radiant Capital, alguna plataforma de trading, Hedgemony, etc. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que implica altas exigencias para los desarrolladores, por lo tanto, también 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 dispersa de toda la cadena, tendrá un gran potencial, y hemos visto muchas soluciones diferentes.
En las dos categorías anteriores, podemos ver que, según la estructura del pastel, la Settlement Layer es la solución más atómica. Sobre estas soluciones atómicas, como las de cross-chain, oráculos y Pre-Confirmation, se construye un nivel más abstracto, que son la Solver Layer, Permission Layer y Application Layer. Los diferentes niveles que enumeramos arriba, que construyen soluciones abstractas o de liquidez en diferentes direcciones, pueden entenderse como una relación 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 traído la aparición de muchos problemas derivados complejos, por lo que se han producido soluciones diversas en torno a 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 cadena para ver cómo cada uno aborda el problema de la fragmentación de la liquidez desde su propia perspectiva.
![Capa 2时代下，Liquidez tomar a la gente por tonta问题的研究])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., y también puede ofrecer componentes como Trading con Apalancamiento y Estrategia de Rendimiento, que están listos para usar. Es equivalente a otros extremos de construcción de aplicaciones, pero la liquidez final se encuentra 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 financiación de la ronda semilla de Robot Ventures, Electric Capital y Maelstrom Capital.
( Khalani Network
Khalani ha construido tres componentes centrales, que son 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 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. Los nodos de Khalani son responsables de enviar el resultado final a la capa de liquidación general a través de puentes intercadena, tecnología de liquidación rápida, etc. Este proyecto aún se encuentra en la fase de construcción y no ha revelado más detalles sobre el trabajo. En agosto, recibió 2,2 millones de dólares en financiamiento inicial de Ethereal Ventures, Nascent, Maelstrom Capital, entre otros.
) Liquorice
Liquorice es una aplicación descentralizada que permite la descubrimiento de precios basado en subastas y piscinas de liquidez unilaterales. 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 protocolos centrales de DeFi como algunos DEX al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice ha creado un mercado de préstamos para realizar transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente sigue en fase de desarrollo, habiendo anunciado en julio una financiación de 1.2 millones de dólares en una ronda Pre-seed liderada por GreenField.
Xion
Xion es una actualización de la marca Burnt. Anteriormente, Burnt se centraba en aplicaciones de consumo, pero luego 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 este problema. Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativa y segura que otros puentes entre cadenas. Ha realizado cuatro rondas de financiación, con inversores como Animoca, Multicoin, Alliance DAO, Mechanism, entre otros.
=nil; Fundación
nil es el mercado de potencia de cálculo ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2, el equipo tiene una sólida base técnica en ZK. Se 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 los fragmentos de ejecución. El protocolo de consenso utilizado por el comité de validación también es Hotstuff, que es común en los proyectos de ejecución paralela más recientes. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son validados por el comité de validadores 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 una arquitectura de Layer 2 fragmentada, lo que puede resolver los problemas de liquidez y dispersión de estados. Sin embargo, su idea central no es razonable, porque el problema que resuelve la dispersión de liquidez es un problema de múltiples cadenas, y lo que se 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á abordando el problema de la liquidez entre cadenas. Actualmente, cierta Capa 2, cierta Capa 2 y cierto DEX 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 común para las operaciones de cadena cruzada entre L2 y cadenas laterales, normalizando las interfaces de pedidos y liquidaciones, logrando una ejecución de cadena cruzada sin problemas. Su núcleo principal es un Filler, que también se puede considerar como el rol de Solver en la abstracción de cadenas que realiza el pago. Esta propuesta fue construida en conjunto por cierto DEX y Across, y actualmente está siendo revisada por el grupo de trabajo de Cake.
OP Stack
OP Stack, ERC-7683, y zkSharding son soluciones internas de Ethereum para la fragmentación de liquidez entre las Capa 2.