Estudio sobre el problema de la fragmentación de la liquidez en la era de Layer2
Con la transición de Ethereum hacia soluciones de escalado centradas en Layer 2, junto con el auge de herramientas como RaaS, muchas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema para mantener el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos caigan por debajo de su precio de lanzamiento en el TGE.
Gracias a OP Stack, una plataforma de intercambio ha lanzado su propia Capa Base 2, otra plataforma de intercambio ha publicado Ink; aprovechando la tecnología ZK, una plataforma ha lanzado XLayer; Sony ha presentado Soneium y LINE ha lanzado Kaia, entre otros. Hoy en día, los costos y las barreras tecnológicas para construir una cadena se han reducido drásticamente, y el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro será indudablemente una era de coexistencia de múltiples cadenas. A pesar de que estas cadenas Layer 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades Web2 detrás de ellas tienen una gran cantidad de aplicaciones descendentes, les resulta difícil construir aplicaciones en la misma cadena y alcanzar un consenso.
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 es un área que debe ser explorada y solucionada. Actualmente hay muchas soluciones de liquidez, como las que todos hemos escuchado: abstracción de cadena, intención, Clearing Execution, Native CrossChain, ZKSharding, 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 (Application Layer)
Esta es la capa de interacción directa del usuario, y también es la capa 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 puede que no comprendan el mecanismo de conversión de liquidez subyacente.
Capa de Permisos (Permission Layer)
Ubicado por debajo de la capa de aplicación, el usuario satisface su intención de negociación conectando su billetera a la dApp y solicitando una cotización. Aquí, "intención" se refiere al resultado final esperado de la transacción (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 cuentas (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 un compromiso confiable entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta generando 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 integran principalmente las cadenas públicas existentes.
Capa de Resolución (Solver Layer)
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 más rápidos y velocidad de ejecución. Sobre esta base, proyectos basados en intenciones como Anoma han construido diversas soluciones impulsadas por intenciones. Derivados de estas 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 (Oracle): utilizado para obtener información sobre el estado en otras cadenas.
Puentes (Bridges): responsables de la transmisión de información y liquidez entre cadenas.
Confirmación anticipada (Pre-Confirmation): acortar el tiempo de confirmación entre cadenas.
Disponibilidad de datos (DA): proporciona la accesibilidad de los datos.
Además, también se deben considerar factores como la liquidez entre cadenas, la finalización (Finality), los mecanismos de prueba de Layer 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Solución
Actualmente, hay varias soluciones en el mercado para abordar la liquidez y tomar a la gente por tonta. Después de revisar una gran cantidad de soluciones, encontramos que las principales son estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a construir Rollups en OP Stack mediante la incorporación de ordenadores compartidos específicos y puentes entre cadenas para compartir liquidez y estado. Esto espera abordar la dispersión de liquidez y estado desde una dirección de un nivel más alto. Aquí hay un diseño más segmentado que es un ordenador compartido por separado, esta solución se dirige más a Layer2 y no tiene universalidad, como Astria, Espresso, etc.
Enfocado en cuentas: similar a NEAR, construir una billetera de cuentas en toda 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 MPC, que firma las transacciones multichain en lugar del usuario. Esta solución, aunque resuelve en gran medida el problema de la fragmentación de UX, implica una implementación backend compleja para los desarrolladores y no soluciona esencialmente la Liquidez y la dispersión del estado.
Centrado en una red de intenciones fuera de la cadena: es decir, nuestra red de Solver en el diagrama de la arquitectura del "introducción" de la tarta, el núcleo es que los usuarios envían intenciones a la red de Solver, y este rol de Solver compite por las cotizaciones, ofreciendo 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. Proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque las intenciones pueden, en teoría, permitir operaciones cruzadas de cualquier complejidad, en la práctica se requiere tener suficientes Solvers de Liquidez para ayudar, y al encontrarse con ciertas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen métodos como la prueba de fraude, la dificultad de implementación de la red de Solvers 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 está específicamente optimizada para el problema de liquidez entre cadenas, pero no ha resuelto otros problemas de estado disperso en cadena. Su núcleo es construir una capa de liquidez, en la cual se desarrollan aplicaciones para compartir la liquidez de toda la cadena. Algunos proyectos incluyen: Raye Network, INFINIT, Everclear, Elixir, entre otros.
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, algún DEX, Hedgemony, etc. Este tipo de proyectos requieren gestionar procesos complejos entre cadenas, lo que plantea altas exigencias para los desarrolladores, por lo tanto, también son muy propensos a incidentes de 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 para consolidar la Liquidez dispersa de toda la cadena, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos clasificaciones anteriores, podemos ver que, según la estructura del pastel, la Capa de Liquidación es la solución más atómica. Sobre estas soluciones atómicas, como las soluciones cruzadas, los oráculos y las soluciones de Pre-Confirmación, se construye una capa más abstracta, que incluye la Capa de Solucionador, la Capa de Permisos y la Capa de Aplicación. Las diversas soluciones de abstracción o de liquidez que hemos enumerado anteriormente, construidas en diferentes direcciones, 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 dado lugar a la aparición de muchos problemas derivados complejos. Por lo tanto, para abordar la interoperabilidad, han surgido una variedad de soluciones. Pero, en esencia, aún dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción en cadenas, para ver cómo cada uno aborda el problema de la fragmentación de la liquidez desde su propio punto de partida.
INFINIT
INFINIT ha construido un servicio RaaS en el ámbito DeFi, que puede proporcionar componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, entre otros, y 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. Hasta ahora, 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 construyó tres componentes centrales: la capa de compatibilidad de 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 la capa de compatibilidad de Intents de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validez. El nodo de Khalani es responsable de enviar el resultado final a la capa de liquidación general a través de puentes intercadena, 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. En agosto, obtuvo 2.2 millones de dólares en una ronda de financiación inicial de Ethereal Ventures, Nascent, Maelstrom Capital, entre otros.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y piscinas de liquidez unidireccionales. La misión principal de Liquorice es proporcionar herramientas de gestión de inventario eficientes para empresas de trading profesionales y conectarse fácilmente a los protocolos DeFi centrales al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice ha creado un mercado de préstamos para realizar transacciones de préstamo. Esta aplicación se centra más en el trading en sí. Actualmente todavía se encuentra en fase de desarrollo, y en julio anunció que había obtenido una financiación de 1.2 millones de dólares en la ronda Pre-seed liderada por GreenField.
Xion
Xion es una evolución de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Después, el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyó Xion para mejorar este problema. Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, lo que lo hace más nativo y seguro que otros puentes entre cadenas. Ha realizado cuatro rondas de financiamiento, con inversores como Animoca, Multicoin, Alliance DAO, Mechanism, entre otros.
=nil; Fundación
nil es el mercado de potencia computacional ZK de Ethereum, un coprocesador ZK y un desarrollador de Layer2, con un equipo que posee 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 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 es también 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 verificados como transacciones por el comité de validadores de cada fragmento.
Su idea básica es construir una arquitectura de comunicación entre fragmentos integrada, similar a IBC, a través de una arquitectura Layer2 fragmentada, lo que permitiría resolver los problemas de Liquidez y estado disperso. Sin embargo, su idea central no es razonable, porque el problema de la dispersión de la liquidez es un problema de múltiples cadenas, y lo que se construye es una única Layer2, 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 entre cadenas. Actualmente, algunos de los principales Layer 2 y DEX son los primeros en apoyar públicamente el estándar ERC7683, que también utiliza un enfoque de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar común para las operaciones entre L2 y las cadenas laterales, estandarizando las interfaces de pedidos y liquidaciones, logrando una ejecución sin problemas entre cadenas; su núcleo principal es que un Filler también puede.
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.
16 me gusta
Recompensa
16
6
Republicar
Compartir
Comentar
0/400
GasFeeCryer
· hace3h
No hay dinero que haga que cruce la cadena.
Ver originalesResponder0
GasBandit
· hace11h
Otra vez en L2
Ver originalesResponder0
DecentralizedElder
· hace11h
¿Otra vez un tomar a la gente por tonta?
Ver originalesResponder0
PriceOracleFairy
· hace11h
smh viendo cómo estos l2s se fragmentan como las promesas de mi ex... la teoría de juegos de liquidez es brutal af rn
Ver originalesResponder0
MEVSandwich
· hace11h
tomar a la gente por tonta y tomar a la gente por tonta, hasta la Billetera ya no es suficiente.
Ver originalesResponder0
NestedFox
· hace11h
tomar a la gente por tonta？¿no es lo mismo si hay un puente?
Exploración de los problemas de fragmentación de liquidez y soluciones en la era de Layer2
Estudio sobre el problema de la fragmentación de la liquidez en la era de Layer2
Con la transición de Ethereum hacia soluciones de escalado centradas en Layer 2, junto con el auge de herramientas como RaaS, muchas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema para mantener el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos caigan por debajo de su precio de lanzamiento en el TGE.
Gracias a OP Stack, una plataforma de intercambio ha lanzado su propia Capa Base 2, otra plataforma de intercambio ha publicado Ink; aprovechando la tecnología ZK, una plataforma ha lanzado XLayer; Sony ha presentado Soneium y LINE ha lanzado Kaia, entre otros. Hoy en día, los costos y las barreras tecnológicas para construir una cadena se han reducido drásticamente, y el costo de operar una cadena basada en OP Stack es de aproximadamente 10,000 dólares al mes.
El futuro será indudablemente una era de coexistencia de múltiples cadenas. A pesar de que estas cadenas Layer 2 pueden optar por la compatibilidad con EVM para lograr la interoperabilidad, debido a que las entidades Web2 detrás de ellas tienen una gran cantidad de aplicaciones descendentes, les resulta difícil construir aplicaciones en la misma cadena y alcanzar un consenso.
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 es un área que debe ser explorada y solucionada. Actualmente hay muchas soluciones de liquidez, como las que todos hemos escuchado: abstracción de cadena, intención, Clearing Execution, Native CrossChain, ZKSharding, 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 (Application Layer)
Esta es la capa de interacción directa del usuario, y también es la capa 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 puede que no comprendan el mecanismo de conversión de liquidez subyacente.
Capa de Permisos (Permission Layer)
Ubicado por debajo de la capa de aplicación, el usuario satisface su intención de negociación conectando su billetera a la dApp y solicitando una cotización. Aquí, "intención" se refiere al resultado final esperado de la transacción (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 cuentas (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 un compromiso confiable entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta generando 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 integran principalmente las cadenas públicas existentes.
Capa de Resolución (Solver Layer)
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 más rápidos y velocidad de ejecución. Sobre esta base, proyectos basados en intenciones como Anoma han construido diversas soluciones impulsadas por intenciones. Derivados de estas 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 finalización (Finality), los mecanismos de prueba de Layer 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Solución
Actualmente, hay varias soluciones en el mercado para abordar la liquidez y tomar a la gente por tonta. Después de revisar una gran cantidad de soluciones, encontramos que las principales son estas formas:
Centrado en RaaS: soluciones de Rollup como OP Stack, que ayudan a construir Rollups en OP Stack mediante la incorporación de ordenadores compartidos específicos y puentes entre cadenas para compartir liquidez y estado. Esto espera abordar la dispersión de liquidez y estado desde una dirección de un nivel más alto. Aquí hay un diseño más segmentado que es un ordenador compartido por separado, esta solución se dirige más a Layer2 y no tiene universalidad, como Astria, Espresso, etc.
Enfocado en cuentas: similar a NEAR, construir una billetera de cuentas en toda 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 MPC, que firma las transacciones multichain en lugar del usuario. Esta solución, aunque resuelve en gran medida el problema de la fragmentación de UX, implica una implementación backend compleja para los desarrolladores y no soluciona esencialmente la Liquidez y la dispersión del estado.
Centrado en una red de intenciones fuera de la cadena: es decir, nuestra red de Solver en el diagrama de la arquitectura del "introducción" de la tarta, el núcleo es que los usuarios envían intenciones a la red de Solver, y este rol de Solver compite por las cotizaciones, ofreciendo 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. Proyectos en este ámbito incluyen Anoma, Khalani, Enso, aori y Valantis. Aunque las intenciones pueden, en teoría, permitir operaciones cruzadas de cualquier complejidad, en la práctica se requiere tener suficientes Solvers de Liquidez para ayudar, y al encontrarse con ciertas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen métodos como la prueba de fraude, la dificultad de implementación de la red de Solvers 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 está específicamente optimizada para el problema de liquidez entre cadenas, pero no ha resuelto otros problemas de estado disperso en cadena. Su núcleo es construir una capa de liquidez, en la cual se desarrollan aplicaciones para compartir la liquidez de toda la cadena. Algunos proyectos incluyen: Raye Network, INFINIT, Everclear, Elixir, entre otros.
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, algún DEX, Hedgemony, etc. Este tipo de proyectos requieren gestionar procesos complejos entre cadenas, lo que plantea altas exigencias para los desarrolladores, por lo tanto, también son muy propensos a incidentes de 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 para consolidar la Liquidez dispersa de toda la cadena, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos clasificaciones anteriores, podemos ver que, según la estructura del pastel, la Capa de Liquidación es la solución más atómica. Sobre estas soluciones atómicas, como las soluciones cruzadas, los oráculos y las soluciones de Pre-Confirmación, se construye una capa más abstracta, que incluye la Capa de Solucionador, la Capa de Permisos y la Capa de Aplicación. Las diversas soluciones de abstracción o de liquidez que hemos enumerado anteriormente, construidas en diferentes direcciones, 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 dado lugar a la aparición de muchos problemas derivados complejos. Por lo tanto, para abordar la interoperabilidad, han surgido una variedad de soluciones. Pero, en esencia, aún dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción en cadenas, para ver cómo cada uno aborda el problema de la fragmentación de la liquidez desde su propio punto de partida.
INFINIT
INFINIT ha construido un servicio RaaS en el ámbito DeFi, que puede proporcionar componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, entre otros, y 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. Hasta ahora, 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 construyó tres componentes centrales: la capa de compatibilidad de 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 la capa de compatibilidad de Intents de Khalani puede convertir las intenciones externas en un formato que el Solver de protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validez. El nodo de Khalani es responsable de enviar el resultado final a la capa de liquidación general a través de puentes intercadena, 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. En agosto, obtuvo 2.2 millones de dólares en una ronda de financiación inicial de Ethereal Ventures, Nascent, Maelstrom Capital, entre otros.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y piscinas de liquidez unidireccionales. La misión principal de Liquorice es proporcionar herramientas de gestión de inventario eficientes para empresas de trading profesionales y conectarse fácilmente a los protocolos DeFi centrales al liquidar transacciones con intención de uso. Al mismo tiempo, Liquorice ha creado un mercado de préstamos para realizar transacciones de préstamo. Esta aplicación se centra más en el trading en sí. Actualmente todavía se encuentra en fase de desarrollo, y en julio anunció que había obtenido una financiación de 1.2 millones de dólares en la ronda Pre-seed liderada por GreenField.
Xion
Xion es una evolución de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Después, el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyó Xion para mejorar este problema. Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, lo que lo hace más nativo y seguro que otros puentes entre cadenas. Ha realizado cuatro rondas de financiamiento, con inversores como Animoca, Multicoin, Alliance DAO, Mechanism, entre otros.
=nil; Fundación
nil es el mercado de potencia computacional ZK de Ethereum, un coprocesador ZK y un desarrollador de Layer2, con un equipo que posee 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 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 es también 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 verificados como transacciones por el comité de validadores de cada fragmento.
Su idea básica es construir una arquitectura de comunicación entre fragmentos integrada, similar a IBC, a través de una arquitectura Layer2 fragmentada, lo que permitiría resolver los problemas de Liquidez y estado disperso. Sin embargo, su idea central no es razonable, porque el problema de la dispersión de la liquidez es un problema de múltiples cadenas, y lo que se construye es una única Layer2, 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 entre cadenas. Actualmente, algunos de los principales Layer 2 y DEX son los primeros en apoyar públicamente el estándar ERC7683, que también utiliza un enfoque de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar común para las operaciones entre L2 y las cadenas laterales, estandarizando las interfaces de pedidos y liquidaciones, logrando una ejecución sin problemas entre cadenas; su núcleo principal es que un Filler también puede.