Estudio sobre el problema de la liquidez en la era de Capa 2

Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2 y el auge de herramientas como RaaS, numerosas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes intereses y buscar una mayor valoración. Sin embargo, la proliferación de 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 desplomen en su TGE.

Con la ayuda de OP Stack, una plataforma de intercambio lanzó su propia Capa 2, otra plataforma de intercambio lanzó Ink; utilizando la tecnología ZK, una plataforma de intercambio lanzó XLayer; Sony lanzó Soneium, LINE lanzó Kaia, entre otros. Hoy en día, los costos y las barreras tecnológicas para construir una cadena se han reducido considerablemente, y 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. A pesar de que 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 la parte inferior, 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 resuelta. Actualmente, hay muchas soluciones de liquidez, como la abstracción de cadena, la intención, la ejecución de compensación, CrossChain nativo, ZKSharding, etc., pero su esencia central es la misma.

Utilizamos la arquitectura Cake, reconocida en la industria, para presentar de arriba a abajo la composición de los componentes centrales de la abstracción de cadena cruzada:

Capa de Aplicación

Esta es la capa con la que el usuario interactúa directamente, y 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 no necesariamente entienden 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 transacción conectando su billetera a la dApp y solicitando un presupuesto. Aquí, la "intención" se refiere al resultado final esperado de la transacción por parte del usuario (es decir, la salida), y no al camino de ejecución específico 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, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de la UX. Sin embargo, en términos de liquidez, se ha integrado principalmente las cadenas públicas existentes.

Capa de Solución (Solver Layer)

Esta capa se encarga de recibir y realizar 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 velocidad de ejecución. Sobre esta base, los proyectos basados en intenciones han construido diversas soluciones impulsadas por intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar las intenciones de los usuarios 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 acceso 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.

Solución

Actualmente, hay varias soluciones en el mercado para resolver la liquidez fragmentada. Tras revisar una gran cantidad de opciones, hemos encontrado que las principales son las siguientes:

1. Centrados en RaaS: soluciones de Rollup como OP Stack, que ayudan a compartir Liquidez y estado en los Rollup construidos sobre OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas. 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 ordenante compartido separado, esta solución está más dirigida a Capa 2 y no tiene aplicabilidad general.

2. Centrado en la cuenta: construir una billetera de cuenta 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 de los usuarios. Aunque esta solución puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), para los desarrolladores implica una implementación backend compleja, y no resuelve esencialmente la liquidez y la dispersión de estados.

3. Centrado en la red de intención fuera de la cadena: la clave es que los usuarios envían intenciones a la red de Solver, el rol de Solver compite en las cotizaciones, ofreciendo el mejor tiempo de finalización y precio de transacción. Estos Solver pueden ser Agentes AI, CEX, Creadores de mercado e incluso el protocolo integrado en sí. Aunque las intenciones teóricamente pueden lograr operaciones complejas de múltiples cadenas de cualquier dificultad, en la práctica se requiere tener suficientes Solver de liquidez para ayudar, y cuando se enfrentan a algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solver. Si se introducen métodos como la prueba de fraude, la dificultad de implementación de la red de Solver aumentará, y los requisitos para operar como Solver también serán más altos.

4. Centrado en una red de liquidez en cadena: Esta dirección está específicamente optimizada para problemas de liquidez entre cadenas, pero no resuelve otros problemas de estado disperso 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.

5. Centrado en aplicaciones en la cadena: este tipo de aplicaciones construyen aplicaciones de alta liquidez mediante la integración de grandes MM o aplicaciones de terceros. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que exige un alto nivel a 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 integrando la liquidez de toda la cadena que está dispersa, 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 más atómica, y sobre estas soluciones atómicas como las de cadenas cruzadas, 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 se ajustan a estos diferentes niveles y pueden entenderse como una relación de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de liquidez ha traído consigo la aparición de muchos problemas derivados complicados. Por lo tanto, en relación con la interoperabilidad, han surgido una variedad de soluciones. Sin embargo, 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 liquidez desde su propio punto de partida.

INFINIT

INFINIT ha construido un servicio RaaS en el ámbito DeFi, que puede proporcionar los componentes necesarios para la construcción directa de protocolos DeFi, como Oracle, Pool Type, IRM, Asset, etc., y también puede ofrecer componentes como Leverage Trading y Yield Strategy que se pueden activar de inmediato. 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 una ronda de financiamiento semilla de 6 millones de dólares de ciertas instituciones de inversión.

Khalani Network

Khalani ha construido tres componentes centrales: la capa de compatibilidad de intención, la validez y la capa de liquidación universal.

Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intención de Khalani puede convertir las intenciones externas en un formato que el Solver del protocolo pueda reconocer, utilizando un formato normalizado que es el lenguaje de Validez. El nodo de Khalani es responsable de enviar el resultado final a la capa de liquidación general a través de puentes cruzados, tecnologías de liquidación rápida, etc. Este proyecto todavía se encuentra en la fase de construcción y no se han revelado más detalles sobre el trabajo. En agosto, recibió 2.2 millones de dólares en financiación en ronda semilla de ciertas instituciones de inversión.

Liquorice

Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y piscinas de liquidez unilaterales. 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 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éstamos. Esta aplicación se centra más en el trading en sí. Actualmente, todavía está en fase de desarrollo y anunció en julio que obtuvo 1.2 millones de dólares en una ronda de financiación Pre-seed liderada por una institución de inversión.

Xion

Xion es una actualizació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 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, por lo que es más nativa y segura que otros puentes entre cadenas. Ha realizado cuatro rondas de financiamiento y ha obtenido el apoyo de varias instituciones de inversión.

=nil; Fundación

nil es el mercado de potencia ZK de Ethereum, un coprocesador ZK y un desarrollador de Capa 2, el equipo tiene una sólida 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 de transacciones en paralelo mediante fragmentación y generando ZKP, mientras que la fragmentación principal verifica datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. La fragmentación principal también gestiona la distribución de validadores y cuentas en la fragmentación de ejecución. El protocolo de consenso utilizado por el consejo 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 consejo de validadores de cada fragmento como transacciones.

Su idea básica es construir una arquitectura de comunicación cruzada entre fragmentos incorporada, similar a IBC, a través de la arquitectura de Layer 2 fragmentada, lo que puede resolver los problemas de Liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, porque el problema que resuelve la dispersión de liquidez es el problema de múltiples cadenas, mientras que lo que se construye 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á trabajando para resolver el problema de la liquidez cruzada, actualmente algunos proyectos conocidos apoyan primero el estándar ERC7683, que utiliza un método de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar común para las operaciones cruzadas de L2 y cadenas laterales, estandarizando las interfaces de órdenes y liquidación, logrando una ejecución cruzada sin problemas, siendo su núcleo un Filler, que también puede ser considerado el rol de Solver en la abstracción de cadenas para el pago. Esta propuesta ha sido construida conjuntamente 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 Layer 2, abordando los problemas desde las capas de arquitectura, consenso y aplicación. OP Stack resuelve de una vez los problemas de transmisión de información y la descentralización del Sequencer al diseñar una solución completa de múltiples Layer 2. Al utilizar la arquitectura OP Stack, se despliegan automáticamente contratos cruzados, y existe un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, muchas plataformas de intercambio y proyectos conocidos utilizan la arquitectura OP Stack.

Entre ellos, el más típico es Unichain. Unichain se basa principalmente en la colaboración con