Estudio sobre el problema de la fragmentación de la liquidez en la era de Capa 2
Después de que Ethereum se orientara hacia soluciones de escalado centradas en Capa 2, junto con 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 seguir el ritmo de estas, lo que ha llevado a que muchos proyectos enfrenten dificultades desde el principio.
Gracias a OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, mientras que otra plataforma de intercambio ha publicado un nuevo proyecto de blockchain; utilizando tecnología ZK, una plataforma de intercambio ha lanzado una nueva capa. Algunas grandes empresas tecnológicas también han publicado sucesivamente sus propios proyectos de blockchain. Hoy en día, el capital y el umbral técnico 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 empresas de tecnología tradicionales 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 es un área que debe explorarse y resolverse. Actualmente, hay muchas soluciones de liquidez, como la abstracción de cadenas, intenciones, Clearing Execution, Native CrossChain, ZKSharding, etc., 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 cadenas cruzadas:
Capa de aplicación: 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 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: ubicada debajo de la capa de aplicación, los usuarios satisfacen su intención de negociación al conectar su billetera a dApp y solicitar cotizaciones. Aquí, la "intención" se refiere al resultado final de la transacción que el usuario espera, y no a la ruta de ejecución específica de la transacción.
Gestión de cuentas y capa abstracta: Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y una capa abstracta que se adapten a diferentes cadenas para mantener la estructura de cuentas única de cada cadena. Algunos proyectos han construido un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo con compromisos confiables entre los sistemas de cuentas existentes. Además, hay proyectos que logran una gestión abstracta generando billeteras de cuentas multichain para los usuarios, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de UX. Sin embargo, en términos de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Capa 2: Esta capa se encarga de recibir e implementar las intenciones de negociación de los usuarios. El rol de Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de negociación más rápidos y mayor velocidad de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar 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 disperso incluyen: oráculos, puentes entre cadenas, soluciones de confirmación anticipada y disponibilidad de datos. Además, también se deben considerar factores como la liquidez entre cadenas, la confirmación final y el mecanismo de prueba de Capa 2, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Actualmente, hay varias soluciones en el mercado para resolver la liquidez tomar a la gente por tonta. Después de revisar una gran cantidad de opciones, encontramos que las principales son las siguientes:
Centrado en RaaS: similar a algunas soluciones de Rollup, asiste en la construcción de Rollup compartiendo liquidez y estado al agregar un ordenamiento compartido específico y puentes entre cadenas. Se espera que esto pueda abordar la dispersión de liquidez y estado desde una perspectiva de mayor nivel. Dentro de esto, hay un diseño más segmentado que es un ordenamiento compartido independiente, este enfoque está más dirigido a 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 técnica llamada "firma en cadena". El componente central es la red MPC, que firma las transacciones multicanal en lugar de los usuarios. Esta solución, aunque puede resolver en gran medida el problema de fragmentación de la experiencia del usuario, implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Centrado en la red de intenciones fuera de la cadena: es decir, nuestra red Solver en el gráfico de arquitectura del "introducción" del pastel, el núcleo es que los usuarios envían intenciones a la red Solver, este rol de Solver compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos Solvers pueden ser Agentes de IA, intercambios, creadores de mercado e incluso el protocolo integrado en sí. Aunque en teoría la intención puede lograr operaciones intercadena complejas de cualquier dificultad, en la práctica se necesita suficiente Liquidez de Solvers para ayudar, y cuando se enfrentan a algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte del Solver; si se introducen mecanismos de prueba de fraude, la dificultad de implementación de la red Solver se incrementará, y el umbral para operar un Solver también será más alto.
Centrarse en la red de liquidez en cadena: esta dirección está específicamente optimizada para el problema de liquidez entre cadenas, pero no resuelve otros problemas de dispersión de estado en cadena. Su núcleo es construir una capa de liquidez, sobre la cual se construirán aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en la cadena: este tipo de aplicaciones construye aplicaciones de alta liquidez mediante la integración de grandes creadores de mercado o aplicaciones de terceros. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que implica altas exigencias para los desarrolladores, y por lo tanto, son propensos a tener vulnerabilidades de seguridad.
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 fragmentada de toda la cadena, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos clasificaciones anteriores, podemos ver que, según la estructura del pastel, el Settlement Layer 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 el Solver Layer, Permission Layer y Application Layer. Las diferentes soluciones abstractas o de liquidez que hemos enumerado anteriormente en diferentes direcciones se pueden entender como una relación entre la parte superior e inferior de la cadena. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de la liquidez ha dado lugar a la aparición de muchos problemas derivados complejos, por lo que surgieron una variedad de soluciones para la interoperabilidad. Pero, en esencia, todavía dependen de estos componentes.
A continuación, discutiremos varios proyectos típicos de conceptos de abstracción de cadenas, para ver cómo cada uno aborda el problema de la liquidez y cómo lo resuelve 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. 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 2 de este proyecto. Sin embargo, actualmente aún no se ha revelado el funcionamiento subyacente.
Otro proyecto ha construido tres componentes centrales, que son la capa de compatibilidad de Intent, Validez y la capa de liquidación universal. Las aplicaciones externas o la capa de intención pueden publicar intenciones a este proyecto, y luego su capa de compatibilidad de Intent puede convertir las intenciones externas en un formato que el Solver del protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validez. Los nodos de este proyecto son responsables de enviar el resultado final a la capa de liquidación universal a través de puentes entre cadenas y tecnologías de liquidación rápida. Este proyecto aún se encuentra en la etapa de construcción y no ha revelado más detalles sobre el trabajo.
También hay un proyecto que es una aplicación descentralizada, que permite el descubrimiento de precios basado en subastas y un pool de liquidez unilateral. Su misión principal es proporcionar herramientas de gestión de inventarios eficientes para empresas de trading profesionales y conectarse fácilmente a los protocolos DeFi centrales al liquidar transacciones con intención de uso. Al mismo tiempo, el proyecto creó un mercado de préstamos para realizar transacciones de préstamo. Esta aplicación se centra más en el trading en sí.
Un proyecto es una actualización de otra marca, que anteriormente se centraba en aplicaciones para consumidores. Después, el equipo descubrió que existía un gran problema de fragmentación en las interacciones en cadena, por lo que construyeron un nuevo proyecto para mejorar este problema. Este se basa en el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativo y seguro que otros puentes entre cadenas.
Una fundación es un desarrollador del mercado de potencia ZK, procesadores ZK y Capa 2 de Ethereum, y el equipo cuenta con una sólida base técnica en ZK. Se propuso la solución zkSharding, que utiliza la tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando procesamiento paralelo de fragmentos y generando ZKP, mientras que el fragmento principal verifica los datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. El fragmento principal también gestiona la distribución de validadores y cuentas en el fragmento de ejecución. El protocolo de consenso utilizado por el comité de validación es también Hotstuff, lo cual es común en los proyectos de ejecución paralela más recientes. La solución integró desde el principio la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados como transacciones por el comité de validadores de cada fragmento.
Su idea básica es construir una arquitectura de comunicación interfragmento incrustada similar a IBC a través de una arquitectura de Capa 2 fragmentada, lo que resolvería 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 la liquidez es el problema de múltiples cadenas; lo que construye es una única Capa 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á trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, hay varios proyectos principales que apoyan públicamente un estándar ERC, que utiliza un enfoque de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar general para las operaciones entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación, y logrando una ejecución intercadena sin problemas. Su núcleo principal es un Filler, que también se puede considerar como el papel de Solver en la abstracción de cadenas para el pago. Esta propuesta ha sido construida conjuntamente por dos proyectos principales y actualmente está siendo revisada por el grupo de trabajo.
Ciertas pilas tecnológicas, el estándar ERC mencionado anteriormente y zkSharding, son soluciones internas de Ethereum para la fragmentación de liquidez entre Capa 2, abordando el problema desde los niveles de arquitectura, consenso y aplicación. Esta pila tecnológica diseña una solución completa de múltiples Capa 2 para resolver de una vez los problemas de transmisión de información y la descentralización del Sequencer. Al utilizar esta arquitectura de pila tecnológica, se desplegarán automáticamente contratos cruzados, y habrá un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, varios proyectos conocidos están utilizando esta arquitectura de pila tecnológica.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo y con muchas soluciones, por ejemplo, las soluciones de Capa 2 se dividen en aquellas que resuelven mediante mensajes intercadena incrustados en Ethereum, especialmente el estándar ERC mencionado anteriormente, y las que utilizan un Sequencer compartido construido sobre cierta pila de tecnología. Fuera del contexto de Capa 2, todas las Capa 1 también.
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.
21 me gusta
Recompensa
21
5
Compartir
Comentar
0/400
HalfPositionRunner
· 07-07 10:37
Otra vez es un lío... tomar a la gente por tonta de verdad.
Ver originalesResponder0
ThreeHornBlasts
· 07-06 21:46
Hay demasiados L2, es un verdadero caos. ¿Cuándo se podrán unificar?
Ver originalesResponder0
LeverageAddict
· 07-06 21:45
¿Cómo se juega con múltiples cadenas de manera caótica?
Ver originalesResponder0
ForkLibertarian
· 07-06 21:36
¿Todos quieren ser papá de la cadena, verdad?
Ver originalesResponder0
SybilAttackVictim
· 07-06 21:22
¿Quién se lleva la culpa de la división en el mundo Cripto? ¿Realmente todos quieren ser el gran L2?
Análisis del problema de la fragmentación de la liquidez en la era de las múltiples cadenas y sus soluciones.
Estudio sobre el problema de la fragmentación de la liquidez en la era de Capa 2
Después de que Ethereum se orientara hacia soluciones de escalado centradas en Capa 2, junto con 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 seguir el ritmo de estas, lo que ha llevado a que muchos proyectos enfrenten dificultades desde el principio.
Gracias a OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, mientras que otra plataforma de intercambio ha publicado un nuevo proyecto de blockchain; utilizando tecnología ZK, una plataforma de intercambio ha lanzado una nueva capa. Algunas grandes empresas tecnológicas también han publicado sucesivamente sus propios proyectos de blockchain. Hoy en día, el capital y el umbral técnico 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 empresas de tecnología tradicionales 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 es un área que debe explorarse y resolverse. Actualmente, hay muchas soluciones de liquidez, como la abstracción de cadenas, intenciones, Clearing Execution, Native CrossChain, ZKSharding, etc., 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 cadenas cruzadas:
Capa de aplicación: 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 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: ubicada debajo de la capa de aplicación, los usuarios satisfacen su intención de negociación al conectar su billetera a dApp y solicitar cotizaciones. Aquí, la "intención" se refiere al resultado final de la transacción que el usuario espera, y no a la ruta de ejecución específica de la transacción.
Gestión de cuentas y capa abstracta: Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y una capa abstracta que se adapten a diferentes cadenas para mantener la estructura de cuentas única de cada cadena. Algunos proyectos han construido un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo con compromisos confiables entre los sistemas de cuentas existentes. Además, hay proyectos que logran una gestión abstracta generando billeteras de cuentas multichain para los usuarios, lo que optimiza enormemente la experiencia del usuario y reduce la fragmentación de UX. Sin embargo, en términos de liquidez, se ha integrado principalmente con las cadenas públicas existentes.
Capa 2: Esta capa se encarga de recibir e implementar las intenciones de negociación de los usuarios. El rol de Solver compite aquí para ofrecer una mejor experiencia al usuario, incluyendo tiempos de negociación más rápidos y mayor velocidad de ejecución. Sobre esta base, se han construido diversas soluciones impulsadas por intenciones basadas en intenciones. Derivados de tales intenciones, como el componente Predicate, pueden realizar 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 disperso incluyen: oráculos, puentes entre cadenas, soluciones de confirmación anticipada y disponibilidad de datos. Además, también se deben considerar factores como la liquidez entre cadenas, la confirmación final y el mecanismo de prueba de Capa 2, para garantizar el funcionamiento eficiente de todo el sistema multichain.
Actualmente, hay varias soluciones en el mercado para resolver la liquidez tomar a la gente por tonta. Después de revisar una gran cantidad de opciones, encontramos que las principales son las siguientes:
Centrado en RaaS: similar a algunas soluciones de Rollup, asiste en la construcción de Rollup compartiendo liquidez y estado al agregar un ordenamiento compartido específico y puentes entre cadenas. Se espera que esto pueda abordar la dispersión de liquidez y estado desde una perspectiva de mayor nivel. Dentro de esto, hay un diseño más segmentado que es un ordenamiento compartido independiente, este enfoque está más dirigido a 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 técnica llamada "firma en cadena". El componente central es la red MPC, que firma las transacciones multicanal en lugar de los usuarios. Esta solución, aunque puede resolver en gran medida el problema de fragmentación de la experiencia del usuario, implica una implementación de backend compleja para los desarrolladores y no resuelve esencialmente la liquidez y la dispersión del estado.
Centrado en la red de intenciones fuera de la cadena: es decir, nuestra red Solver en el gráfico de arquitectura del "introducción" del pastel, el núcleo es que los usuarios envían intenciones a la red Solver, este rol de Solver compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos Solvers pueden ser Agentes de IA, intercambios, creadores de mercado e incluso el protocolo integrado en sí. Aunque en teoría la intención puede lograr operaciones intercadena complejas de cualquier dificultad, en la práctica se necesita suficiente Liquidez de Solvers para ayudar, y cuando se enfrentan a algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte del Solver; si se introducen mecanismos de prueba de fraude, la dificultad de implementación de la red Solver se incrementará, y el umbral para operar un Solver también será más alto.
Centrarse en la red de liquidez en cadena: esta dirección está específicamente optimizada para el problema de liquidez entre cadenas, pero no resuelve otros problemas de dispersión de estado en cadena. Su núcleo es construir una capa de liquidez, sobre la cual se construirán aplicaciones para compartir la liquidez de toda la cadena.
Centrado en aplicaciones en la cadena: este tipo de aplicaciones construye aplicaciones de alta liquidez mediante la integración de grandes creadores de mercado o aplicaciones de terceros. Estos proyectos requieren gestionar procesos complejos entre cadenas, lo que implica altas exigencias para los desarrolladores, y por lo tanto, son propensos a tener vulnerabilidades de seguridad.
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 fragmentada de toda la cadena, tendrá un gran potencial, y también hemos visto muchas soluciones diferentes.
En las dos clasificaciones anteriores, podemos ver que, según la estructura del pastel, el Settlement Layer 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 el Solver Layer, Permission Layer y Application Layer. Las diferentes soluciones abstractas o de liquidez que hemos enumerado anteriormente en diferentes direcciones se pueden entender como una relación entre la parte superior e inferior de la cadena. Sin embargo, estas soluciones aún no son soluciones atómicas, y el problema de la fragmentación de la liquidez ha dado lugar a la aparición de muchos problemas derivados complejos, por lo que surgieron una variedad de soluciones para la interoperabilidad. Pero, en esencia, todavía dependen de estos componentes.
A continuación, discutiremos varios proyectos típicos de conceptos de abstracción de cadenas, para ver cómo cada uno aborda el problema de la liquidez y cómo lo resuelve 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. 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 2 de este proyecto. Sin embargo, actualmente aún no se ha revelado el funcionamiento subyacente.
Otro proyecto ha construido tres componentes centrales, que son la capa de compatibilidad de Intent, Validez y la capa de liquidación universal. Las aplicaciones externas o la capa de intención pueden publicar intenciones a este proyecto, y luego su capa de compatibilidad de Intent puede convertir las intenciones externas en un formato que el Solver del protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validez. Los nodos de este proyecto son responsables de enviar el resultado final a la capa de liquidación universal a través de puentes entre cadenas y tecnologías de liquidación rápida. Este proyecto aún se encuentra en la etapa de construcción y no ha revelado más detalles sobre el trabajo.
También hay un proyecto que es una aplicación descentralizada, que permite el descubrimiento de precios basado en subastas y un pool de liquidez unilateral. Su misión principal es proporcionar herramientas de gestión de inventarios eficientes para empresas de trading profesionales y conectarse fácilmente a los protocolos DeFi centrales al liquidar transacciones con intención de uso. Al mismo tiempo, el proyecto creó un mercado de préstamos para realizar transacciones de préstamo. Esta aplicación se centra más en el trading en sí.
Un proyecto es una actualización de otra marca, que anteriormente se centraba en aplicaciones para consumidores. Después, el equipo descubrió que existía un gran problema de fragmentación en las interacciones en cadena, por lo que construyeron un nuevo proyecto para mejorar este problema. Este se basa en el protocolo de consenso Comet BFT. La comunicación entre cadenas que utiliza se basa en Cosmos IBC, por lo que es más nativo y seguro que otros puentes entre cadenas.
Una fundación es un desarrollador del mercado de potencia ZK, procesadores ZK y Capa 2 de Ethereum, y el equipo cuenta con una sólida base técnica en ZK. Se propuso la solución zkSharding, que utiliza la tecnología ZK para escalar horizontalmente la red principal de Ethereum, ejecutando procesamiento paralelo de fragmentos y generando ZKP, mientras que el fragmento principal verifica los datos, se comunica con Ethereum y sincroniza el estado de la red entre todos los validadores. El fragmento principal también gestiona la distribución de validadores y cuentas en el fragmento de ejecución. El protocolo de consenso utilizado por el comité de validación es también Hotstuff, lo cual es común en los proyectos de ejecución paralela más recientes. La solución integró desde el principio la comunicación entre fragmentos en el protocolo. Los mensajes entre fragmentos son verificados como transacciones por el comité de validadores de cada fragmento.
Su idea básica es construir una arquitectura de comunicación interfragmento incrustada similar a IBC a través de una arquitectura de Capa 2 fragmentada, lo que resolvería 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 la liquidez es el problema de múltiples cadenas; lo que construye es una única Capa 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á trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, hay varios proyectos principales que apoyan públicamente un estándar ERC, que utiliza un enfoque de cadena cruzada basado en Intent. Su objetivo principal es establecer un estándar general para las operaciones entre L2 y cadenas laterales, estandarizando las interfaces de pedidos y liquidación, y logrando una ejecución intercadena sin problemas. Su núcleo principal es un Filler, que también se puede considerar como el papel de Solver en la abstracción de cadenas para el pago. Esta propuesta ha sido construida conjuntamente por dos proyectos principales y actualmente está siendo revisada por el grupo de trabajo.
Ciertas pilas tecnológicas, el estándar ERC mencionado anteriormente y zkSharding, son soluciones internas de Ethereum para la fragmentación de liquidez entre Capa 2, abordando el problema desde los niveles de arquitectura, consenso y aplicación. Esta pila tecnológica diseña una solución completa de múltiples Capa 2 para resolver de una vez los problemas de transmisión de información y la descentralización del Sequencer. Al utilizar esta arquitectura de pila tecnológica, se desplegarán automáticamente contratos cruzados, y habrá un Supervisor para desafiar y evitar la transmisión de información cruzada falsa. Actualmente, varios proyectos conocidos están utilizando esta arquitectura de pila tecnológica.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo y con muchas soluciones, por ejemplo, las soluciones de Capa 2 se dividen en aquellas que resuelven mediante mensajes intercadena incrustados en Ethereum, especialmente el estándar ERC mencionado anteriormente, y las que utilizan un Sequencer compartido construido sobre cierta pila de tecnología. Fuera del contexto de Capa 2, todas las Capa 1 también.