Estudio sobre el problema de la liquidez fragmentada en la era de Capa 2
Introducción
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 aparición de numerosas cadenas públicas ha dificultado que el desarrollo del ecosistema siga el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos enfrenten una caída de precios en su oferta inicial de tokens.
Gracias a la tecnología OP Stack, una plataforma de intercambio lanzó su propia red Capa 2 llamada Base, mientras que otra plataforma lanzó Ink; utilizando la tecnología ZK, una plataforma de intercambio presentó XLayer; Sony lanzó Soneium y LINE presentó Kaia, entre otros. 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 será sin duda 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 actual ecosistema multichain 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 cadenas, intenciones, Clearing Execution, Native CrossChain, ZKSharding, etc., pero su esencia central es similar.
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 con la que los usuarios interactúan directamente, y es la capa más abstracta de 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 subyacente.
Capa de Permisos (Permission Layer)
Ubicado 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 esperado de la transacción (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 ha construido un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo se requiere un compromiso de confianza entre los sistemas de cuentas existentes. Near Account implementa la gestión abstracta al generar 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 han integrado principalmente las cadenas públicas existentes.
Capa de Solución (Solver Layer)
Esta capa se encarga 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, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos de intención. Los derivados de tales 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 las soluciones 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), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Solución
Actualmente, hay varias soluciones en el mercado para resolver la liquidez que toma a la gente por tonta. Tras revisar numerosas opciones, hemos encontrado que las principales son estas formas:
Centrado en RaaS: soluciones Rollup como OP Stack, que ayudan a construir Rollup en OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas para compartir liquidez y estado. Esto espera poder abordar la liquidez y la dispersión del estado desde una dirección de un nivel más alto. Dentro de esto, hay un diseño más específico para un ordenante compartido separado, que se dirige más a Capa 2 y no tiene universalidad.
Centrado en la cuenta: a través de la construcción de una billetera de cuenta en toda la cadena, se admite la firma y ejecución de transacciones a través de múltiples protocolos de blockchain. El componente central es la red MPC, que firma las transacciones multichain en lugar del usuario. Esta solución, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Enfocado en la red de intenciones fuera de la cadena: la clave es que los usuarios envían intenciones a la red Solver, donde este rol compite en las ofertas, proporcionando el tiempo de finalización y el precio de transacción más óptimos. Estos Solvers pueden ser Agentes de IA, CEX, Creadores de Mercado e incluso protocolos integrados. Aunque las intenciones pueden, en teoría, realizar operaciones complejas intercadena de cualquier dificultad, en la práctica se requiere suficiente Liquidez de Solvers para asistir, y al enfrentar algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers.
Centrarse en una red de liquidez en cadena: Esta dirección se especializa en optimizar los problemas de liquidez entre cadenas, pero no resuelve otros problemas de dispersión del estado en cadena. Su núcleo es construir una capa de liquidez, sobre la cual se desarrollan aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en cadena: Este tipo de aplicaciones construyen aplicaciones de alta liquidez integrando grandes MM, o aplicaciones de terceros, entre otros. Estos proyectos necesitan gestionar procesos complejos entre cadenas, lo que exige mucho 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 dispersa 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. Sobre estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta: la Capa de Solución, la Capa de Permiso y la Capa de Aplicación. Las diferentes soluciones de abstracción o de liquidez que hemos enumerado anteriormente en diferentes direcciones se alinean con estos diferentes niveles, que se pueden entender como una relación de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas. El problema de la fragmentación de la liquidez ha llevado a la aparición de muchos problemas derivados complejos, por lo que, 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 la 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 Trading con Apalancamiento y Estrategia de Rendimiento 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 se ha revelado el funcionamiento subyacente. Actualmente, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla.
Khalani Network
Khalani construyó tres componentes centrales, que son la capa de compatibilidad de Intent, Validity y la capa de liquidación general.
Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intención de Khalani puede convertir las intenciones externas en un formato que el protocolo Solver puede reconocer, utilizando el formato normalizado que es el lenguaje Validity. El nodo Khalani es responsable 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, etc. Este proyecto aún se encuentra en la fase de construcción y no se han divulgado más detalles sobre el trabajo. En agosto, obtuvo 2,2 millones de dólares en financiamiento de la ronda semilla.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccionales. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas de gestión de inventario eficientes 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 llevar a cabo transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente, sigue en fase de desarrollo y en julio anunció una financiación de 1.2 millones de dólares en la ronda Pre-seed.
Xion
Xion es una mejora de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Más tarde, el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyeron Xion para solucionar este problema. Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativa y segura que otros puentes entre cadenas. Ha realizado cuatro rondas de financiación.
=nil; Fundación
nil es el mercado de potencia ZK de Ethereum, un coprocesador ZK y desarrollador de Capa 2, con un equipo que tiene una profunda base técnica en ZK. Se propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutar el procesamiento paralelo de fragmentos y generar ZKP, mientras que el fragmento principal verifica 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, que es común en los proyectos más recientes de ejecución paralela. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo.
Su idea básica es construir una arquitectura de comunicación cruzada entre fragmentos incrustada similar a IBC a través de una arquitectura de Layer 2 en fragmentos, lo que podría resolver los problemas de Liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, ya que el problema que resuelve la dispersión de la Liquidez es el problema de múltiples cadenas, y lo que construye es una sola 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 entre cadenas, actualmente hay múltiples plataformas que apoyan 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 L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación, logrando una ejecución entre cadenas sin interrupciones, y su núcleo principal es un Filler que también se puede considerar como el rol de Solver en la abstracción de cadenas que actúa como intermediario. Esta propuesta 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 Capa 2, que abordan el problema desde las capas de arquitectura, consenso y aplicación. OP Stack resuelve de una vez los problemas de transmisión de información y descentralización del Sequencer mediante el diseño de una solución completa de múltiples Capa 2. Al utilizar la arquitectura OP Stack, se desplegarán automáticamente contratos cruzados, y habrá un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, varias plataformas de intercambio conocidas utilizan la arquitectura OP Stack.
Entre ellos, el más típico es
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.
7 me gusta
Recompensa
7
4
Compartir
Comentar
0/400
NotAFinancialAdvice
· hace13h
¿Otra vez hablando de layer2?
Ver originalesResponder0
MetaverseVagabond
· hace13h
He estado perdiendo en casi todas las L2 que he jugado.
Análisis de la exploración y soluciones al problema de la liquidez rota en el ecosistema de Capa 2
Estudio sobre el problema de la liquidez fragmentada en la era de Capa 2
Introducción
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 aparición de numerosas cadenas públicas ha dificultado que el desarrollo del ecosistema siga el ritmo de estas cadenas, lo que ha llevado a que muchos proyectos enfrenten una caída de precios en su oferta inicial de tokens.
Gracias a la tecnología OP Stack, una plataforma de intercambio lanzó su propia red Capa 2 llamada Base, mientras que otra plataforma lanzó Ink; utilizando la tecnología ZK, una plataforma de intercambio presentó XLayer; Sony lanzó Soneium y LINE presentó Kaia, entre otros. 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 será sin duda 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 actual ecosistema multichain 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 cadenas, intenciones, Clearing Execution, Native CrossChain, ZKSharding, etc., pero su esencia central es similar.
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 con la que los usuarios interactúan directamente, y es la capa más abstracta de 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 subyacente.
Capa de Permisos (Permission Layer)
Ubicado 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 esperado de la transacción (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 ha construido un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo se requiere un compromiso de confianza entre los sistemas de cuentas existentes. Near Account implementa la gestión abstracta al generar 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 han integrado principalmente las cadenas públicas existentes.
Capa de Solución (Solver Layer)
Esta capa se encarga 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, se han construido diversas soluciones impulsadas por intenciones basadas en proyectos de intención. Los derivados de tales 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 las soluciones de liquidez y estado disperso incluyen:
Además, también se deben considerar factores como la liquidez entre cadenas, la finalización (Finality), el mecanismo de prueba de Capa 2, entre otros, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Solución
Actualmente, hay varias soluciones en el mercado para resolver la liquidez que toma a la gente por tonta. Tras revisar numerosas opciones, hemos encontrado que las principales son estas formas:
Centrado en RaaS: soluciones Rollup como OP Stack, que ayudan a construir Rollup en OP Stack mediante la incorporación de un ordenante compartido específico y puentes entre cadenas para compartir liquidez y estado. Esto espera poder abordar la liquidez y la dispersión del estado desde una dirección de un nivel más alto. Dentro de esto, hay un diseño más específico para un ordenante compartido separado, que se dirige más a Capa 2 y no tiene universalidad.
Centrado en la cuenta: a través de la construcción de una billetera de cuenta en toda la cadena, se admite la firma y ejecución de transacciones a través de múltiples protocolos de blockchain. El componente central es la red MPC, que firma las transacciones multichain en lugar del usuario. Esta solución, aunque puede resolver en gran medida el problema de la fragmentación de la experiencia del usuario (UX), implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Enfocado en la red de intenciones fuera de la cadena: la clave es que los usuarios envían intenciones a la red Solver, donde este rol compite en las ofertas, proporcionando el tiempo de finalización y el precio de transacción más óptimos. Estos Solvers pueden ser Agentes de IA, CEX, Creadores de Mercado e incluso protocolos integrados. Aunque las intenciones pueden, en teoría, realizar operaciones complejas intercadena de cualquier dificultad, en la práctica se requiere suficiente Liquidez de Solvers para asistir, y al enfrentar algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los Solvers.
Centrarse en una red de liquidez en cadena: Esta dirección se especializa en optimizar los problemas de liquidez entre cadenas, pero no resuelve otros problemas de dispersión del estado en cadena. Su núcleo es construir una capa de liquidez, sobre la cual se desarrollan aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en cadena: Este tipo de aplicaciones construyen aplicaciones de alta liquidez integrando grandes MM, o aplicaciones de terceros, entre otros. Estos proyectos necesitan gestionar procesos complejos entre cadenas, lo que exige mucho 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 dispersa 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. Sobre estas soluciones atómicas, como las de cadena cruzada, oráculos y Pre-Confirmation, se construye una capa más abstracta: la Capa de Solución, la Capa de Permiso y la Capa de Aplicación. Las diferentes soluciones de abstracción o de liquidez que hemos enumerado anteriormente en diferentes direcciones se alinean con estos diferentes niveles, que se pueden entender como una relación de upstream y downstream. Sin embargo, estas soluciones aún no son soluciones atómicas. El problema de la fragmentación de la liquidez ha llevado a la aparición de muchos problemas derivados complejos, por lo que, 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 la 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 Trading con Apalancamiento y Estrategia de Rendimiento 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 se ha revelado el funcionamiento subyacente. Actualmente, INFINIT ha obtenido 6 millones de dólares en financiamiento de la ronda semilla.
Khalani Network
Khalani construyó tres componentes centrales, que son la capa de compatibilidad de Intent, Validity y la capa de liquidación general.
Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intención de Khalani puede convertir las intenciones externas en un formato que el protocolo Solver puede reconocer, utilizando el formato normalizado que es el lenguaje Validity. El nodo Khalani es responsable 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, etc. Este proyecto aún se encuentra en la fase de construcción y no se han divulgado más detalles sobre el trabajo. En agosto, obtuvo 2,2 millones de dólares en financiamiento de la ronda semilla.
Liquorice
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y pools de liquidez unidireccionales. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas de gestión de inventario eficientes 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 llevar a cabo transacciones de préstamos. Esta aplicación se centra más en el trading en sí. Actualmente, sigue en fase de desarrollo y en julio anunció una financiación de 1.2 millones de dólares en la ronda Pre-seed.
Xion
Xion es una mejora de la marca Burnt, que anteriormente se centraba en aplicaciones para consumidores. Más tarde, el equipo descubrió que había un gran problema de fragmentación en las interacciones en la cadena, por lo que construyeron Xion para solucionar este problema. Xion está construido sobre el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativa y segura que otros puentes entre cadenas. Ha realizado cuatro rondas de financiación.
=nil; Fundación
nil es el mercado de potencia ZK de Ethereum, un coprocesador ZK y desarrollador de Capa 2, con un equipo que tiene una profunda base técnica en ZK. Se propuso la solución zkSharding, que utiliza tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutar el procesamiento paralelo de fragmentos y generar ZKP, mientras que el fragmento principal verifica 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, que es común en los proyectos más recientes de ejecución paralela. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo.
Su idea básica es construir una arquitectura de comunicación cruzada entre fragmentos incrustada similar a IBC a través de una arquitectura de Layer 2 en fragmentos, lo que podría resolver los problemas de Liquidez y dispersión del estado. Sin embargo, su idea central no es razonable, ya que el problema que resuelve la dispersión de la Liquidez es el problema de múltiples cadenas, y lo que construye es una sola 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 entre cadenas, actualmente hay múltiples plataformas que apoyan 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 L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación, logrando una ejecución entre cadenas sin interrupciones, y su núcleo principal es un Filler que también se puede considerar como el rol de Solver en la abstracción de cadenas que actúa como intermediario. Esta propuesta 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 Capa 2, que abordan el problema desde las capas de arquitectura, consenso y aplicación. OP Stack resuelve de una vez los problemas de transmisión de información y descentralización del Sequencer mediante el diseño de una solución completa de múltiples Capa 2. Al utilizar la arquitectura OP Stack, se desplegarán automáticamente contratos cruzados, y habrá un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, varias plataformas de intercambio conocidas utilizan la arquitectura OP Stack.
Entre ellos, el más típico es