Investigación sobre el problema de la liquidez en la Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el surgimiento de herramientas como RaaS, numerosas cadenas públicas están en rápido desarrollo. Muchas entidades desean construir su propia cadena para representar diferentes demandas de interés y buscar una valoración más alta. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema para seguir el ritmo de las cadenas públicas, lo que ha llevado a que muchos proyectos se desplomen en su TGE.
Gracias a OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma ha publicado Ink; aprovechando la tecnología ZK, una plataforma ha lanzado XLayer; Sony ha lanzado Soneium, y LINE ha introducido Kaia, entre otros. Hoy en día, el costo y la complejidad técnica para construir una cadena se han reducido drásticamente, operar una cadena basada en OP Stack cuesta 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 en la parte inferior, les resulta difícil construir aplicaciones en la misma cadena y alcanzar un consenso.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y dispersión del estado. Dado que la existencia de múltiples cadenas es inevitable, la interoperabilidad es un área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como la abstracción de cadena, la intención, la ejecución de compensación, CrossChain nativo, ZKSharding, pero su esencia central es la misma.
Utilizamos la arquitectura Cake, 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 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 y no necesariamente comprenden el mecanismo de conversión de liquidez subyacente.
Capa de Permisos
Ubicado por debajo de la capa de aplicación, los usuarios satisfacen su intención de transacción conectando su billetera a dApp y solicitando una cotización. Aquí, la "intención" se refiere al resultado final de 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 clave (Key Management and Account Abstraction)
Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener las estructuras de cuentas únicas de cada cadena. Por ejemplo, el sistema de cuentas centrado en objetos de SUI es completamente diferente al de EVM. One Balance es un proyecto representativo en este campo, que construye un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo requiere compromisos confiables entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta al generar billeteras de cuentas multichain para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en cuanto a la liquidez, se integraron principalmente 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, y 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 intenciones. 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 la solución 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 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.
Actualmente, en el mercado hay varias soluciones para la liquidez y, después de revisar una gran cantidad de ellas, encontramos que principalmente existen estas formas:
Centrado en RaaS: Soluciones de Rollup como OP Stack, al incorporar un ordenante compartido específico y puentes entre cadenas, ayudan a construir liquidez y estado compartido en Rollup construido sobre OP Stack. Esto espera poder resolver la liquidez y el estado dispersos en una dirección de nivel más alto. Aquí hay un diseño más específico que es el ordenante compartido por separado, esta solución está más orientada a Capa 2 y no tiene universalidad.
Enfoque 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 de cadena". El componente central es la red MPC, que firma transacciones de múltiples cadenas en lugar del usuario. Esta solución, aunque puede resolver enormemente 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.
Centrado en la red de intención fuera de la cadena: es decir, la red de solucionadores en el diagrama de la estructura del pastel de nuestra "introducción". El núcleo es que los usuarios envían intenciones a la red de solucionadores, y el rol del solucionador compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos solucionadores pueden ser Agentes AI, CEX, creadores de mercado, e incluso el protocolo integrado en sí. Aunque la intención teóricamente puede realizar operaciones complejas entre cadenas de cualquier dificultad, en la práctica se requiere que haya suficientes solucionadores de liquidez para ayudar. Además, cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los solucionadores. Si se introducen métodos como pruebas de fraude, la dificultad de implementar la red de solucionadores se incrementará, y el umbral para operar como solucionador también será más alto.
Centrado en la red de liquidez en cadena: esta dirección está especializada en optimizar el problema de liquidez entre cadenas, pero no ha resuelto el problema de la 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.
Centrarse en aplicaciones en cadena: Este tipo de aplicaciones construye aplicaciones de alta liquidez mediante la integración de grandes MM, o aplicaciones de terceros, etc. Estos proyectos requieren 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 una que integre la liquidez dispersa de toda la cadena, tendrá 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, el Settlement Layer 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 un nivel más abstracto, que son el Solver Layer, Permission Layer y Application Layer. Las diferentes soluciones de abstracción o liquidez que enumeramos anteriormente, construidas en diferentes direcciones, se ajustan a estos diferentes niveles, que pueden entenderse como una relación entre upstream y downstream. Sin embargo, estas soluciones todavía no son soluciones atómicas. El problema de la fragmentación de la liquidez ha generado la aparición de muchos problemas derivados complicados, por lo que han surgido una variedad de soluciones para la interoperabilidad. 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 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 están listos para usar. Es equivalente a otros extremos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente no ha revelado el funcionamiento interno.
Khalani ha construido tres componentes centrales: la capa de compatibilidad de Intent, Validity y la capa de liquidación universal. Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intent de Khalani puede convertir las intenciones externas en un formato que el Solver del protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validity. Los nodos de Khalani son responsables de enviar el resultado final a la capa de liquidación universal a través de puentes entre cadenas, tecnología de liquidación rápida, etc.
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y piscinas de liquidez unidireccionales. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas eficientes para la gestión de inventario 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í.
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.
=nil; Foundation propuso la solución 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 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. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo.
Ethereum también está trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, algunas de las principales plataformas de intercambio 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 de cadena cruzada entre L2 y cadenas laterales, estandarizando las interfaces de pedido y liquidación, y logrando una ejecución fluida entre cadenas. Su núcleo principal es un Filler, que también se puede considerar como el papel de Solver en la abstracción de cadena para el pago en nombre de otros.
OP Stack 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. Cuando utilizas la arquitectura de OP Stack, se despliegan automáticamente contratos cruzados, y existe un Supervisor para desafiar y evitar la transmisión de información cruzada falsa.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo con muchas soluciones. Las soluciones de Capa 2 se dividen en las que resuelven el mensaje entre cadenas incrustado en Ethereum, especialmente ERC-7683, y también en Capa 2, como OP, que construye el OP Stack para compartir el Sequencer. Fuera del contexto de Capa 2, todas las Capa 1 también enfrentan problemas de liquidez, estado y experiencia del usuario fragmentados; hay soluciones centradas en aplicaciones específicamente para la liquidez, así como soluciones fuera de la cadena como la de Solver Network, e incluso existen soluciones centradas en cuentas como NEAR, pero también necesitan basarse en roles fuera de la cadena como Solver.
La falta de liquidez, el estado y la experiencia del usuario en las cadenas cruzadas son problemas de toda la industria blockchain. Si se piensa en términos generales, se necesita abordar esto de una manera más abstracta, similar a la abstracción de cadenas. Esto equivale a ser realmente
Ver originales
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
10 me gusta
Recompensa
10
6
Compartir
Comentar
0/400
PancakeFlippa
· hace11h
tomar a la gente por tonta 早晚要重组 看好后市
Ver originalesResponder0
CryptoPhoenix
· hace11h
Sufriendo y luchando, el bull run eventualmente llegará a mí
Ver originalesResponder0
Blockblind
· hace11h
¿Quién salvará la liquidez de los inversores minoristas?
Ver originalesResponder0
FOMOSapien
· hace11h
El desarrollo cross-chain ya está muy extendido.
Ver originalesResponder0
GasFeeNightmare
· hace11h
De nuevo hay que empezar a calcular el gas... pequeños expertos en arbitraje de cada cadena en la noche.
Ver originalesResponder0
PaperHandsCriminal
· hace11h
Maldita sea, otra vez me han tomado a la gente por tonta.
( Explicación: Este comentario se ajusta perfectamente al perfil de "manos de papel", insinuando con un tono autocrítico que ha perdido dinero nuevamente en la fluctuación del mercado. El comentario es breve y coloquial, con un tono de resignación y autocrítica, lo que se adapta muy bien a la forma de expresión auténtica en las plataformas sociales. )
Integración de liquidez en la era de Capa 2: desafíos y oportunidades que enfrenta el ecosistema multichain
Investigación sobre el problema de la liquidez en la Capa 2
Con la transición de Ethereum hacia soluciones de escalado centradas en Capa 2, junto con el surgimiento de herramientas como RaaS, numerosas cadenas públicas están en rápido desarrollo. Muchas entidades desean construir su propia cadena para representar diferentes demandas de interés y buscar una valoración más alta. Sin embargo, la aparición de numerosas cadenas públicas ha dificultado el desarrollo del ecosistema para seguir el ritmo de las cadenas públicas, lo que ha llevado a que muchos proyectos se desplomen en su TGE.
Gracias a OP Stack, una plataforma de intercambio ha lanzado su propia Capa 2, otra plataforma ha publicado Ink; aprovechando la tecnología ZK, una plataforma ha lanzado XLayer; Sony ha lanzado Soneium, y LINE ha introducido Kaia, entre otros. Hoy en día, el costo y la complejidad técnica para construir una cadena se han reducido drásticamente, operar una cadena basada en OP Stack cuesta 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 en la parte inferior, les resulta difícil construir aplicaciones en la misma cadena y alcanzar un consenso.
El ecosistema multichain actual presenta un nuevo desafío: Liquidez y dispersión del estado. Dado que la existencia de múltiples cadenas es inevitable, la interoperabilidad es un área que debe ser explorada y resuelta. Actualmente hay muchas soluciones de liquidez, como la abstracción de cadena, la intención, la ejecución de compensación, CrossChain nativo, ZKSharding, pero su esencia central es la misma.
Utilizamos la arquitectura Cake, 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 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 y no necesariamente comprenden el mecanismo de conversión de liquidez subyacente.
Capa de Permisos
Ubicado por debajo de la capa de aplicación, los usuarios satisfacen su intención de transacción conectando su billetera a dApp y solicitando una cotización. Aquí, la "intención" se refiere al resultado final de 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 clave (Key Management and Account Abstraction)
Debido a la existencia de un entorno multichain, se necesita un sistema de gestión de cuentas y abstracción que se adapte a diferentes cadenas para mantener las estructuras de cuentas únicas de cada cadena. Por ejemplo, el sistema de cuentas centrado en objetos de SUI es completamente diferente al de EVM. One Balance es un proyecto representativo en este campo, que construye un sistema de cuentas confiable, sin necesidad de establecer un consenso entre cadenas, solo requiere compromisos confiables entre los sistemas de cuentas existentes. Near Account logra una gestión abstracta al generar billeteras de cuentas multichain para los usuarios, optimizando enormemente la experiencia del usuario y reduciendo la fragmentación de la UX. Sin embargo, en cuanto a la liquidez, se integraron principalmente 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, y 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 intenciones. 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 la solución de liquidez y estado descentralizado 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.
Actualmente, en el mercado hay varias soluciones para la liquidez y, después de revisar una gran cantidad de ellas, encontramos que principalmente existen estas formas:
Centrado en RaaS: Soluciones de Rollup como OP Stack, al incorporar un ordenante compartido específico y puentes entre cadenas, ayudan a construir liquidez y estado compartido en Rollup construido sobre OP Stack. Esto espera poder resolver la liquidez y el estado dispersos en una dirección de nivel más alto. Aquí hay un diseño más específico que es el ordenante compartido por separado, esta solución está más orientada a Capa 2 y no tiene universalidad.
Enfoque 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 de cadena". El componente central es la red MPC, que firma transacciones de múltiples cadenas en lugar del usuario. Esta solución, aunque puede resolver enormemente 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.
Centrado en la red de intención fuera de la cadena: es decir, la red de solucionadores en el diagrama de la estructura del pastel de nuestra "introducción". El núcleo es que los usuarios envían intenciones a la red de solucionadores, y el rol del solucionador compite en las ofertas, proporcionando el mejor tiempo de finalización y precio de transacción. Estos solucionadores pueden ser Agentes AI, CEX, creadores de mercado, e incluso el protocolo integrado en sí. Aunque la intención teóricamente puede realizar operaciones complejas entre cadenas de cualquier dificultad, en la práctica se requiere que haya suficientes solucionadores de liquidez para ayudar. Además, cuando se encuentran algunas demandas fuera de la cadena, existe la posibilidad de fraude por parte de los solucionadores. Si se introducen métodos como pruebas de fraude, la dificultad de implementar la red de solucionadores se incrementará, y el umbral para operar como solucionador también será más alto.
Centrado en la red de liquidez en cadena: esta dirección está especializada en optimizar el problema de liquidez entre cadenas, pero no ha resuelto el problema de la 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.
Centrarse en aplicaciones en cadena: Este tipo de aplicaciones construye aplicaciones de alta liquidez mediante la integración de grandes MM, o aplicaciones de terceros, etc. Estos proyectos requieren 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 una que integre la liquidez dispersa de toda la cadena, tendrá 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, el Settlement Layer 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 un nivel más abstracto, que son el Solver Layer, Permission Layer y Application Layer. Las diferentes soluciones de abstracción o liquidez que enumeramos anteriormente, construidas en diferentes direcciones, se ajustan a estos diferentes niveles, que pueden entenderse como una relación entre upstream y downstream. Sin embargo, estas soluciones todavía no son soluciones atómicas. El problema de la fragmentación de la liquidez ha generado la aparición de muchos problemas derivados complicados, por lo que han surgido una variedad de soluciones para la interoperabilidad. 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 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 están listos para usar. Es equivalente a otros extremos de construcción de aplicaciones, pero la liquidez final se coloca en la capa de liquidez de Infinit. Sin embargo, actualmente no ha revelado el funcionamiento interno.
Khalani ha construido tres componentes centrales: la capa de compatibilidad de Intent, Validity y la capa de liquidación universal. Las aplicaciones externas o la capa de intención pueden publicar intenciones a Khalani, y luego la capa de compatibilidad de Intent de Khalani puede convertir las intenciones externas en un formato que el Solver del protocolo puede reconocer, utilizando el formato normalizado que es el lenguaje de Validity. Los nodos de Khalani son responsables de enviar el resultado final a la capa de liquidación universal a través de puentes entre cadenas, tecnología de liquidación rápida, etc.
Liquorice es una aplicación descentralizada que permite el descubrimiento de precios basado en subastas y piscinas de liquidez unidireccionales. La misión principal de Liquorice es proporcionar a las empresas de trading profesionales herramientas eficientes para la gestión de inventario 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í.
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.
=nil; Foundation propuso la solución 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 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. =nil; L2 desde el principio integró la comunicación entre fragmentos en el protocolo.
Ethereum también está trabajando para resolver el problema de la liquidez entre cadenas. Actualmente, algunas de las principales plataformas de intercambio 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 de cadena cruzada entre L2 y cadenas laterales, estandarizando las interfaces de pedido y liquidación, y logrando una ejecución fluida entre cadenas. Su núcleo principal es un Filler, que también se puede considerar como el papel de Solver en la abstracción de cadena para el pago en nombre de otros.
OP Stack 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. Cuando utilizas la arquitectura de OP Stack, se despliegan automáticamente contratos cruzados, y existe un Supervisor para desafiar y evitar la transmisión de información cruzada falsa.
Resolver el problema de la liquidez entre cadenas es un campo muy complejo con muchas soluciones. Las soluciones de Capa 2 se dividen en las que resuelven el mensaje entre cadenas incrustado en Ethereum, especialmente ERC-7683, y también en Capa 2, como OP, que construye el OP Stack para compartir el Sequencer. Fuera del contexto de Capa 2, todas las Capa 1 también enfrentan problemas de liquidez, estado y experiencia del usuario fragmentados; hay soluciones centradas en aplicaciones específicamente para la liquidez, así como soluciones fuera de la cadena como la de Solver Network, e incluso existen soluciones centradas en cuentas como NEAR, pero también necesitan basarse en roles fuera de la cadena como Solver.
La falta de liquidez, el estado y la experiencia del usuario en las cadenas cruzadas son problemas de toda la industria blockchain. Si se piensa en términos generales, se necesita abordar esto de una manera más abstracta, similar a la abstracción de cadenas. Esto equivale a ser realmente
( Explicación: Este comentario se ajusta perfectamente al perfil de "manos de papel", insinuando con un tono autocrítico que ha perdido dinero nuevamente en la fluctuación del mercado. El comentario es breve y coloquial, con un tono de resignación y autocrítica, lo que se adapta muy bien a la forma de expresión auténtica en las plataformas sociales. )