Estudio sobre el problema de la liquidez y la toma a la gente por tonta en la era de Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el surgimiento de herramientas como RaaS, muchas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes demandas de 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 ritmo de las cadenas públicas, lo que ha llevado a que muchos proyectos se rompan en el TGE.
Con la ayuda de OP Stack, una plataforma de intercambio lanzó su propia Capa 2, otra plataforma de intercambio lanzó Ink; gracias a 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 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. A pesar de que estas Capa 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 y alcanzar un consenso en la misma cadena.
El ecosistema multichain actual presenta 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, existen muchas soluciones de liquidez, como la abstracción de cadena, la intención, la ejecución de Clearing, Native CrossChain, ZKSharding, etc., pero su esencia central es la misma.
Utilizamos la arquitectura Cake, que es bastante reconocida en la industria, para presentar de arriba hacia abajo los componentes centrales de la abstracción de cadena cruzada:
Capa de Aplicación (Application Layer)
Esta es la capa con la que los usuarios interactúan directamente, y también es la capa más abstracta en la solución de liquidez, ya que oculta por completo los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente 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 negociación conectando su billetera a la dApp y solicitando un precio. Aquí, la "intención" se refiere al resultado final de la negociación que el usuario espera (es decir, la salida), y no a la ruta de ejecución específica de la negociació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 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 términos de liquidez, se ha integrado principalmente con 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 velocidades de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos. Derivados de tales intenciones como el componente Predicate pueden implementar las intenciones de los usuarios bajo reglas específicas.
Capa de liquidación
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de las soluciones de liquidez y estado descentralizado 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): 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 confirmación final (Finality), el mecanismo de prueba de Capa 2, etc., para garantizar el funcionamiento eficiente de todo el sistema de múltiples cadenas.
Solución
Actualmente, hay varias soluciones en el mercado para resolver la liquidez fragmentada. Después de revisar una gran cantidad de soluciones, encontramos que las principales son estas formas:
Con RaaS como centro: soluciones de Rollup como OP Stack ayudan a construir liquidez y estado compartido en OP Stack al incorporar ordenadores compartidos específicos y puentes entre cadenas. Esto espera poder resolver la liquidez y el estado disperso desde una dirección de un nivel más alto. Aquí hay un diseño más específico que es el de ordenadores compartidos individuales, esta solución está más dirigida a Capa 2 y no tiene aplicabilidad universal.
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 varios protocolos de blockchain mediante una tecnología llamada "firma en cadena". El componente central es la red MPC, que sustituye a los usuarios para firmar transacciones multichain. Esta solución, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia de usuario (UX), implica una implementación backend compleja para los desarrolladores y no resuelve en esencia la liquidez y la dispersión de estados.
Centrado en la red de intención fuera de la cadena: el núcleo es que los usuarios envían intenciones a la red Solver, este rol de Solver compite en 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 el protocolo integrado en sí. Aunque las intenciones pueden, en teoría, lograr operaciones intercadena complejas de cualquier dificultad, en la práctica se necesita contar con suficientes Solvers de liquidez para ayudar, y cuando se enfrentan a algunas demandas 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 implementación de la red Solver se volverá aún mayor, y los requisitos para operar un Solver también serán más altos.
Centrado en la red de liquidez en cadena: esta dirección se especializa en optimizar el problema de liquidez entre cadenas, pero no ha resuelto el problema de dispersión del estado en otras cadenas. Su núcleo es construir una capa de liquidez, sobre la cual se desarrollan 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. Estos proyectos necesitan gestionar procesos complejos entre cadenas, lo que exige mucho a los desarrolladores, por lo tanto, también son muy propensos a sufrir 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 en 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. Encima de estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que es el Solver Layer, Permission Layer y Application Layer. Las diversas soluciones de abstracción o liquidez que enumeramos anteriormente, construidas en diferentes direcciones, se adhieren a estos diferentes niveles, que pueden entenderse como una relación de flujo hacia arriba y hacia abajo. Sin embargo, estas soluciones aún no son soluciones atómicas; el problema de la fragmentación de liquidez ha llevado a la aparición de muchos problemas derivados complejos. Por lo tanto, en cuanto a la interoperabilidad, han surgido una variedad de soluciones. Pero, en esencia, todavía dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción de cadenas para ver cómo cada uno aborda el problema de la fragmentación de liquidez desde su propio punto de partida.
Un proyecto 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 al lado de construcción de otras aplicaciones, pero la liquidez final se coloca en la capa de liquidez de este proyecto. Sin embargo, hasta ahora no ha revelado el funcionamiento subyacente.
Otro proyecto ha construido tres componentes centrales: la capa de compatibilidad de Intent, Validity y la capa de liquidación general. Las aplicaciones externas o la capa de intenciones pueden publicar intenciones para este proyecto, y luego su capa de compatibilidad de Intent puede convertir las intenciones externas en un formato que el Solver del protocolo pueda reconocer, utilizando el formato normalizado que es el lenguaje de Validity. Los nodos de este proyecto son responsables de enviar el resultado final a la capa de liquidación general a través de puentes de cadena cruzada, tecnología de liquidación rápida, entre otros. Este proyecto todavía se encuentra en la etapa de construcción y no ha revelado más detalles sobre el trabajo.
También hay una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccionales. Su misión principal es proporcionar herramientas de gestión de inventario eficientes para empresas de comercio profesional y conectar fácilmente con protocolos DeFi centrales al liquidar transacciones según la intención de uso. Al mismo tiempo, el proyecto ha creado un mercado de préstamos para llevar a cabo transacciones de préstamo. Esta aplicación se enfoca más en el comercio en sí. Actualmente, todavía se encuentra en fase de desarrollo.
Un proyecto 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.
Otro proyecto es el mercado de potencia de cómputo ZK de Ethereum, el procesador ZK y los desarrolladores de Capa 2, cuyo equipo tiene una sólida base en tecnología ZK. Se propuso una solución de zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando el procesamiento paralelo de fragmentos y generando ZKP, mientras que el fragmento principal verifica los datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. El fragmento principal también gestiona la distribución de validadores y cuentas en los fragmentos de ejecución. El protocolo de consenso utilizado por el comité de validación también es Hotstuff, que es común en los proyectos de ejecución paralela más recientes. Este proyecto L2 incorporó desde el principio la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados por el comité de validadores de cada fragmento como transacciones.
Su idea básica es construir una arquitectura de comunicación entre fragmentos integrada, similar a IBC, a través de una arquitectura de Layer 2 fragmentada, lo que resolvería los problemas de liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, ya que el problema de la dispersión de la liquidez es un problema de múltiples cadenas, y lo que se construye es un único 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.
Ethereum también está abordando el problema de la liquidez entre cadenas, actualmente algunos proyectos están apoyando 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 universal para las operaciones entre cadenas cruzadas L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación para lograr una ejecución entre cadenas sin costuras, siendo su núcleo principal un Filler que también puede considerarse como el rol de Solver en la abstracción de cadenas. Esta propuesta está siendo revisada actualmente por el grupo de trabajo de Cake.
OP Stack, ERC-7683 y zkSharding son soluciones internas de Ethereum para la fragmentación de liquidez entre Capa 2, abordando respectivamente los niveles de arquitectura, consenso y aplicación. OP Stack resuelve de una vez el problema de la transmisión de información y la descentralización del Sequencer al diseñar una solución completa de múltiples Capa 2. Cuando utilizas la arquitectura de OP Stack, se implementan automáticamente contratos cruzados, y existe un Supervisor que desafía para evitar la transmisión de información cruzada falsa. Actualmente, algunas plataformas de intercambio populares utilizan la arquitectura de OP Stack.
Entre ellos, el más típico es Unichain. Unichain se basa principalmente en la integración con la red Superchain.
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.
9 me gusta
Recompensa
9
5
Compartir
Comentar
0/400
GasFeeCrier
· hace11h
Pocos proyectos de blockchain
Ver originalesResponder0
ApyWhisperer
· hace23h
Desarrollar escenarios cross-chain lo antes posible
Ver originalesResponder0
ETHReserveBank
· hace23h
caen por debajo del precio de emisión hay que culpar a la emisión excesiva
Era de Capa 2: Exploración del problema de la Liquidez y soluciones
Estudio sobre el problema de la liquidez y la toma a la gente por tonta en la era de Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el surgimiento de herramientas como RaaS, muchas cadenas públicas están desarrollándose rápidamente. Muchas entidades desean construir su propia cadena para representar diferentes demandas de 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 ritmo de las cadenas públicas, lo que ha llevado a que muchos proyectos se rompan en el TGE.
Con la ayuda de OP Stack, una plataforma de intercambio lanzó su propia Capa 2, otra plataforma de intercambio lanzó Ink; gracias a 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 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. A pesar de que estas Capa 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 y alcanzar un consenso en la misma cadena.
El ecosistema multichain actual presenta 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, existen muchas soluciones de liquidez, como la abstracción de cadena, la intención, la ejecución de Clearing, Native CrossChain, ZKSharding, etc., pero su esencia central es la misma.
Utilizamos la arquitectura Cake, que es bastante reconocida en la industria, para presentar de arriba hacia abajo los componentes centrales de la abstracción de cadena cruzada:
Capa de Aplicación (Application Layer)
Esta es la capa con la que los usuarios interactúan directamente, y también es la capa más abstracta en la solución de liquidez, ya que oculta por completo los detalles de la conversión de liquidez. En la capa de aplicación, los usuarios interactúan con la interfaz frontal, sin necesariamente 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 negociación conectando su billetera a la dApp y solicitando un precio. Aquí, la "intención" se refiere al resultado final de la negociación que el usuario espera (es decir, la salida), y no a la ruta de ejecución específica de la negociació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 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 términos de liquidez, se ha integrado principalmente con 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 velocidades de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos. Derivados de tales intenciones como el componente Predicate pueden implementar las intenciones de los usuarios bajo reglas específicas.
Capa de liquidación
Esta es la capa intermedia utilizada para resolver la intención del usuario. Los componentes centrales de las soluciones 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, etc., para garantizar el funcionamiento eficiente de todo el sistema de múltiples cadenas.
Solución
Actualmente, hay varias soluciones en el mercado para resolver la liquidez fragmentada. Después de revisar una gran cantidad de soluciones, encontramos que las principales son estas formas:
Con RaaS como centro: soluciones de Rollup como OP Stack ayudan a construir liquidez y estado compartido en OP Stack al incorporar ordenadores compartidos específicos y puentes entre cadenas. Esto espera poder resolver la liquidez y el estado disperso desde una dirección de un nivel más alto. Aquí hay un diseño más específico que es el de ordenadores compartidos individuales, esta solución está más dirigida a Capa 2 y no tiene aplicabilidad universal.
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 varios protocolos de blockchain mediante una tecnología llamada "firma en cadena". El componente central es la red MPC, que sustituye a los usuarios para firmar transacciones multichain. Esta solución, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia de usuario (UX), implica una implementación backend compleja para los desarrolladores y no resuelve en esencia la liquidez y la dispersión de estados.
Centrado en la red de intención fuera de la cadena: el núcleo es que los usuarios envían intenciones a la red Solver, este rol de Solver compite en 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 el protocolo integrado en sí. Aunque las intenciones pueden, en teoría, lograr operaciones intercadena complejas de cualquier dificultad, en la práctica se necesita contar con suficientes Solvers de liquidez para ayudar, y cuando se enfrentan a algunas demandas 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 implementación de la red Solver se volverá aún mayor, y los requisitos para operar un Solver también serán más altos.
Centrado en la red de liquidez en cadena: esta dirección se especializa en optimizar el problema de liquidez entre cadenas, pero no ha resuelto el problema de dispersión del estado en otras cadenas. Su núcleo es construir una capa de liquidez, sobre la cual se desarrollan 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. Estos proyectos necesitan gestionar procesos complejos entre cadenas, lo que exige mucho a los desarrolladores, por lo tanto, también son muy propensos a sufrir 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 en 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. Encima de estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta, que es el Solver Layer, Permission Layer y Application Layer. Las diversas soluciones de abstracción o liquidez que enumeramos anteriormente, construidas en diferentes direcciones, se adhieren a estos diferentes niveles, que pueden entenderse como una relación de flujo hacia arriba y hacia abajo. Sin embargo, estas soluciones aún no son soluciones atómicas; el problema de la fragmentación de liquidez ha llevado a la aparición de muchos problemas derivados complejos. Por lo tanto, en cuanto a la interoperabilidad, han surgido una variedad de soluciones. Pero, en esencia, todavía dependen de estos componentes. A continuación, discutiremos algunos proyectos típicos de conceptos de abstracción de cadenas para ver cómo cada uno aborda el problema de la fragmentación de liquidez desde su propio punto de partida.
Un proyecto 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 al lado de construcción de otras aplicaciones, pero la liquidez final se coloca en la capa de liquidez de este proyecto. Sin embargo, hasta ahora no ha revelado el funcionamiento subyacente.
Otro proyecto ha construido tres componentes centrales: la capa de compatibilidad de Intent, Validity y la capa de liquidación general. Las aplicaciones externas o la capa de intenciones pueden publicar intenciones para este proyecto, y luego su capa de compatibilidad de Intent puede convertir las intenciones externas en un formato que el Solver del protocolo pueda reconocer, utilizando el formato normalizado que es el lenguaje de Validity. Los nodos de este proyecto son responsables de enviar el resultado final a la capa de liquidación general a través de puentes de cadena cruzada, tecnología de liquidación rápida, entre otros. Este proyecto todavía se encuentra en la etapa de construcción y no ha revelado más detalles sobre el trabajo.
También hay una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccionales. Su misión principal es proporcionar herramientas de gestión de inventario eficientes para empresas de comercio profesional y conectar fácilmente con protocolos DeFi centrales al liquidar transacciones según la intención de uso. Al mismo tiempo, el proyecto ha creado un mercado de préstamos para llevar a cabo transacciones de préstamo. Esta aplicación se enfoca más en el comercio en sí. Actualmente, todavía se encuentra en fase de desarrollo.
Un proyecto 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.
Otro proyecto es el mercado de potencia de cómputo ZK de Ethereum, el procesador ZK y los desarrolladores de Capa 2, cuyo equipo tiene una sólida base en tecnología ZK. Se propuso una solución de zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando el procesamiento paralelo de fragmentos y generando ZKP, mientras que el fragmento principal verifica los datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. El fragmento principal también gestiona la distribución de validadores y cuentas en los fragmentos de ejecución. El protocolo de consenso utilizado por el comité de validación también es Hotstuff, que es común en los proyectos de ejecución paralela más recientes. Este proyecto L2 incorporó desde el principio la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados por el comité de validadores de cada fragmento como transacciones.
Su idea básica es construir una arquitectura de comunicación entre fragmentos integrada, similar a IBC, a través de una arquitectura de Layer 2 fragmentada, lo que resolvería los problemas de liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, ya que el problema de la dispersión de la liquidez es un problema de múltiples cadenas, y lo que se construye es un único 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.
Ethereum también está abordando el problema de la liquidez entre cadenas, actualmente algunos proyectos están apoyando 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 universal para las operaciones entre cadenas cruzadas L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación para lograr una ejecución entre cadenas sin costuras, siendo su núcleo principal un Filler que también puede considerarse como el rol de Solver en la abstracción de cadenas. Esta propuesta está siendo revisada actualmente por el grupo de trabajo de Cake.
OP Stack, ERC-7683 y zkSharding son soluciones internas de Ethereum para la fragmentación de liquidez entre Capa 2, abordando respectivamente los niveles de arquitectura, consenso y aplicación. OP Stack resuelve de una vez el problema de la transmisión de información y la descentralización del Sequencer al diseñar una solución completa de múltiples Capa 2. Cuando utilizas la arquitectura de OP Stack, se implementan automáticamente contratos cruzados, y existe un Supervisor que desafía para evitar la transmisión de información cruzada falsa. Actualmente, algunas plataformas de intercambio populares utilizan la arquitectura de OP Stack.
Entre ellos, el más típico es Unichain. Unichain se basa principalmente en la integración con la red Superchain.