Estudio sobre el problema de la fragmentación de la liquidez en la era de Capa 2
Con la transición de Ethereum hacia una estrategia de escalado centrada en Capa 2, y el surgimiento de herramientas como RaaS, muchas cadenas públicas han evolucionado 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 mantenerse al día con el ritmo de las cadenas públicas, lo que ha llevado a que muchos proyectos fracasen en el momento de su lanzamiento.
Aprovechando OP Stack, una plataforma de intercambio lanzó su propia Capa 2; aprovechando la tecnología ZK, otra plataforma de intercambio lanzó su propia capa; una empresa lanzó su propia cadena, una empresa de software de mensajería lanzó su propia cadena, etc. Hoy en día, el costo y la barrera técnica 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 sin duda será una era de coexistencia de múltiples cadenas. Aunque estas cadenas de 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 trae 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 cadenas, la intención, la ejecución de Clearing, CrossChain nativo, 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 más abstracta en la solución de liquidez, ya que oculta completamente los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente entender el mecanismo de conversión de liquidez en la capa subyacente.
Capa de Permisos(Permission Layer)
Ubicado por debajo de la capa de aplicación, los usuarios satisfacen 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 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. Algunos proyectos han construido sistemas de cuentas confiables, sin necesidad de establecer un consenso entre cadenas, solo requieren un compromiso confiable entre los sistemas de cuentas existentes. Además, otros proyectos logran la gestión de abstracción generando 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.
Resolver Capa ( Capa )
Esta capa se encarga de recibir e implementar la intención de transacción del usuario, el rol de 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, los proyectos basados en la intención han construido varias soluciones impulsadas por la intención. Derivados de tales intenciones, como el componente Predicate, pueden realizar la intención 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 las soluciones de liquidez y estado distribuido incluyen:
Oráculo (: utilizado para obtener información del estado en otras cadenas.
Puente intercadena ) Bridges (: responsable de la transmisión de información y Liquidez intercadena.
Confirmación previa ): reducir 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 finalidad (Finality), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Actualmente, hay diversas soluciones en el mercado para resolver la liquidez y, tras revisar numerosas opciones, hemos encontrado que las principales son las siguientes:
Centrado en RaaS: soluciones de Rollup como OP Stack ayudan a construir Rollups en OP Stack compartiendo liquidez y estado a través de la incorporación de un ordenante compartido específico y un puente entre cadenas. Esto espera abordar la dispersión de liquidez y estado en un nivel más alto. Hay un diseño más específico que es el ordenante compartido independiente, esta solución está más enfocada en Capa 2 y no tiene universalidad.
Centrado en la cuenta: construir una billetera de cuenta de cadena completa, que soporte la firma y ejecución de transacciones a través de múltiples protocolos de blockchain mediante una tecnología llamada "firma en cadena". El componente central es la red MPC, que firma las transacciones multichain en lugar del usuario. 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 de backend compleja y no resuelve esencialmente la liquidez y la dispersión de estados.
Centrarse en la red de intención fuera de la cadena: es decir, nuestra red de Solver en el diagrama de arquitectura del "introducción" de la tarta, el núcleo es que los usuarios envían intenciones a la red de Solver, este rol de Solver compite por las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos Solvers pueden ser agentes de IA, CEX, creadores de mercado o incluso protocolos integrados. Aunque las intenciones teóricamente pueden realizar operaciones complejas de cadena cruzada de cualquier dificultad, en la práctica se necesita tener suficientes Solvers de liquidez para ayudar, y cuando se enfrentan a algunas necesidades fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen medios como pruebas de fraude, la dificultad de implementar la red de Solver aumentará, y el umbral para operar un Solver también será más alto.
Centrado en la red de liquidez en la cadena: esta dirección se especializa en optimizar el problema de liquidez entre cadenas, pero no ha resuelto otros problemas de dispersión del estado 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 mediante la integración de grandes MM, o aplicaciones de terceros, etc. Este tipo de proyectos requiere gestionar procesos complejos entre cadenas, lo que implica altas exigencias para los desarrolladores, y por lo tanto, también es muy propenso 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 que integre la liquidez, especialmente al reunir la liquidez fragmentada de toda la cadena, tendría un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos categorías anteriores, podemos ver que según la estructura del pastel, la Capa de Liquidación es la solución más atómica, y sobre estas soluciones atómicas como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que son la Capa de Solucionadores, la Capa de Permisos y la Capa de Aplicaciones. Las diferentes soluciones de abstracción o liquidez que hemos enumerado anteriormente se pueden entender como una relación de upstream y downstream en diferentes direcciones. Sin embargo, estas soluciones aún no son soluciones atómicas; el problema de la fragmentación de la liquidez ha traído consigo la aparición de muchos problemas derivados complejos, por lo que han surgido una variedad de soluciones para la interoperabilidad. Pero en esencia, todavía dependen de estos componentes.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo y con numerosas soluciones, como las soluciones de Capa 2 que se dividen en aquellas que utilizan mensajes cruzados incrustados, especialmente ERC-7683, y el OP Stack construido en Capa 2 para compartir el Secuenciador. Fuera del contexto de Capa 2, todas las Capa 1 también enfrentan problemas de liquidez, estado y disociación de la experiencia del usuario, existiendo soluciones centradas en aplicaciones específicamente para la liquidez, así como soluciones fuera de la cadena de Solver Network, incluso soluciones centradas en cuentas, pero también necesitan basarse en roles fuera de la cadena como el de Solver.
Reconocemos que la liquidez entre cadenas, el estado y la fragmentación de la experiencia del usuario son problemas en toda la industria de la blockchain. Si se piensa en términos generales, es necesario abordar esto de una manera más abstracta, similar a la abstracción de cadenas, lo que equivale a la verdadera entrada a Web3, resolviendo la fragmentación en la experiencia del usuario, mientras que la integración de la liquidez y el estado se realiza en lugares que el usuario no puede percibir. En cuanto a cómo integrar específicamente, se divide en el uso de redes Solver fuera de la cadena y la integración atómica de puentes entre cadenas, entre otras instalaciones, lo cual merece ser discutido. En general, el futuro será multichain, resolver el problema de la dispersión de la liquidez es un reto que la industria necesariamente enfrentará, y esta integración de liquidez en toda la cadena tiene un amplio espacio para el crecimiento, lo que podría construir una nueva entrada a Internet en la era de Web3.
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.
17 me gusta
Recompensa
17
3
Republicar
Compartir
Comentar
0/400
FromMinerToFarmer
· 07-25 18:33
Tomar a la gente por tonta y luego unir es inevitable
Ver originalesResponder0
StakeWhisperer
· 07-23 11:21
¿Para qué hacer más cadenas si hay poco dinero?
Ver originalesResponder0
RumbleValidator
· 07-23 11:09
Las múltiples cadenas están destinadas a convertirse en una tendencia.
Desafíos de la era de Capa 2: exploración de la fragmentación de liquidez y soluciones en un ecosistema multichain
Estudio sobre el problema de la fragmentación de la liquidez en la era de Capa 2
Con la transición de Ethereum hacia una estrategia de escalado centrada en Capa 2, y el surgimiento de herramientas como RaaS, muchas cadenas públicas han evolucionado 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 mantenerse al día con el ritmo de las cadenas públicas, lo que ha llevado a que muchos proyectos fracasen en el momento de su lanzamiento.
Aprovechando OP Stack, una plataforma de intercambio lanzó su propia Capa 2; aprovechando la tecnología ZK, otra plataforma de intercambio lanzó su propia capa; una empresa lanzó su propia cadena, una empresa de software de mensajería lanzó su propia cadena, etc. Hoy en día, el costo y la barrera técnica 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 sin duda será una era de coexistencia de múltiples cadenas. Aunque estas cadenas de 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 trae 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 cadenas, la intención, la ejecución de Clearing, CrossChain nativo, 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 más abstracta en la solución de liquidez, ya que oculta completamente los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente entender el mecanismo de conversión de liquidez en la capa subyacente.
Capa de Permisos(Permission Layer)
Ubicado por debajo de la capa de aplicación, los usuarios satisfacen 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 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. Algunos proyectos han construido sistemas de cuentas confiables, sin necesidad de establecer un consenso entre cadenas, solo requieren un compromiso confiable entre los sistemas de cuentas existentes. Además, otros proyectos logran la gestión de abstracción generando 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.
Resolver Capa ( Capa )
Esta capa se encarga de recibir e implementar la intención de transacción del usuario, el rol de 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, los proyectos basados en la intención han construido varias soluciones impulsadas por la intención. Derivados de tales intenciones, como el componente Predicate, pueden realizar la intención 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 las soluciones de liquidez y estado distribuido incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la finalidad (Finality), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Actualmente, hay diversas soluciones en el mercado para resolver la liquidez y, tras revisar numerosas opciones, hemos encontrado que las principales son las siguientes:
Centrado en RaaS: soluciones de Rollup como OP Stack ayudan a construir Rollups en OP Stack compartiendo liquidez y estado a través de la incorporación de un ordenante compartido específico y un puente entre cadenas. Esto espera abordar la dispersión de liquidez y estado en un nivel más alto. Hay un diseño más específico que es el ordenante compartido independiente, esta solución está más enfocada en Capa 2 y no tiene universalidad.
Centrado en la cuenta: construir una billetera de cuenta de cadena completa, que soporte la firma y ejecución de transacciones a través de múltiples protocolos de blockchain mediante una tecnología llamada "firma en cadena". El componente central es la red MPC, que firma las transacciones multichain en lugar del usuario. 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 de backend compleja y no resuelve esencialmente la liquidez y la dispersión de estados.
Centrarse en la red de intención fuera de la cadena: es decir, nuestra red de Solver en el diagrama de arquitectura del "introducción" de la tarta, el núcleo es que los usuarios envían intenciones a la red de Solver, este rol de Solver compite por las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos Solvers pueden ser agentes de IA, CEX, creadores de mercado o incluso protocolos integrados. Aunque las intenciones teóricamente pueden realizar operaciones complejas de cadena cruzada de cualquier dificultad, en la práctica se necesita tener suficientes Solvers de liquidez para ayudar, y cuando se enfrentan a algunas necesidades fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers. Si se introducen medios como pruebas de fraude, la dificultad de implementar la red de Solver aumentará, y el umbral para operar un Solver también será más alto.
Centrado en la red de liquidez en la cadena: esta dirección se especializa en optimizar el problema de liquidez entre cadenas, pero no ha resuelto otros problemas de dispersión del estado 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 mediante la integración de grandes MM, o aplicaciones de terceros, etc. Este tipo de proyectos requiere gestionar procesos complejos entre cadenas, lo que implica altas exigencias para los desarrolladores, y por lo tanto, también es muy propenso 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 que integre la liquidez, especialmente al reunir la liquidez fragmentada de toda la cadena, tendría un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos categorías anteriores, podemos ver que según la estructura del pastel, la Capa de Liquidación es la solución más atómica, y sobre estas soluciones atómicas como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que son la Capa de Solucionadores, la Capa de Permisos y la Capa de Aplicaciones. Las diferentes soluciones de abstracción o liquidez que hemos enumerado anteriormente se pueden entender como una relación de upstream y downstream en diferentes direcciones. Sin embargo, estas soluciones aún no son soluciones atómicas; el problema de la fragmentación de la liquidez ha traído consigo la aparición de muchos problemas derivados complejos, por lo que han surgido una variedad de soluciones para la interoperabilidad. Pero en esencia, todavía dependen de estos componentes.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo y con numerosas soluciones, como las soluciones de Capa 2 que se dividen en aquellas que utilizan mensajes cruzados incrustados, especialmente ERC-7683, y el OP Stack construido en Capa 2 para compartir el Secuenciador. Fuera del contexto de Capa 2, todas las Capa 1 también enfrentan problemas de liquidez, estado y disociación de la experiencia del usuario, existiendo soluciones centradas en aplicaciones específicamente para la liquidez, así como soluciones fuera de la cadena de Solver Network, incluso soluciones centradas en cuentas, pero también necesitan basarse en roles fuera de la cadena como el de Solver.
Reconocemos que la liquidez entre cadenas, el estado y la fragmentación de la experiencia del usuario son problemas en toda la industria de la blockchain. Si se piensa en términos generales, es necesario abordar esto de una manera más abstracta, similar a la abstracción de cadenas, lo que equivale a la verdadera entrada a Web3, resolviendo la fragmentación en la experiencia del usuario, mientras que la integración de la liquidez y el estado se realiza en lugares que el usuario no puede percibir. En cuanto a cómo integrar específicamente, se divide en el uso de redes Solver fuera de la cadena y la integración atómica de puentes entre cadenas, entre otras instalaciones, lo cual merece ser discutido. En general, el futuro será multichain, resolver el problema de la dispersión de la liquidez es un reto que la industria necesariamente enfrentará, y esta integración de liquidez en toda la cadena tiene un amplio espacio para el crecimiento, lo que podría construir una nueva entrada a Internet en la era de Web3.