I. Introducción

Blockchain modular es un paradigma innovador de diseño de blockchain que tiene como objetivo mejorar la eficiencia y escalabilidad del sistema a través de la especialización y división del trabajo. Antes del nacimiento de la cadena de bloques modular, se necesitaba una única cadena (monolítica) para manejar todas las tareas, incluida la capa de ejecución, la capa de disponibilidad de datos, la capa de consenso y la capa de liquidación. Las cadenas de bloques modulares resuelven estos problemas al tratar estos esfuerzos como módulos libremente combinables, cada uno centrado en una función específica.

Capa de ejecución: Responsable de procesar y verificar todas las transacciones y gestionar los cambios de estado de blockchain.

Capa de consenso: acordar el orden de las transacciones.

Capa de liquidación: se utiliza para completar transacciones, verificar pruebas y construir puentes entre diferentes capas de ejecución.

Capa de disponibilidad de datos: responsable de garantizar que todos los datos necesarios estén disponibles para los participantes de la red para su verificación.

La tendencia de la cadena de bloques modular no es solo un cambio tecnológico, sino también una estrategia importante para promover todo el ecosistema de la cadena de bloques para enfrentar los desafíos futuros. GeekCartel analizará el concepto de blockchain modular y proyectos relacionados, con el objetivo de proporcionar una interpretación integral y práctica del conocimiento de blockchain modular, ayudar a los lectores a comprender mejor la blockchain modular y esperar las tendencias de desarrollo futuras. Nota: El contenido de este artículo no constituye un consejo de inversión.

2. Celestia, la pionera de la cadena de bloques modular

En 2018, Mustafa Albasan y Vitalik Buterin publicaron un artículo innovador que proporcionaba nuevas ideas para resolver el problema de escalabilidad de blockchain. "Muestreo de disponibilidad de datos y prueba de fraude" presenta un método mediante el cual una cadena de bloques puede expandir automáticamente el espacio de almacenamiento a medida que se agregan nodos de red. En 2019, Mustafa Albasan investigó profundamente y escribió "Lazy Ledger", proponiendo el concepto de un sistema blockchain que solo se ocupa de la disponibilidad de datos.

Con base en estos conceptos nació Celestia como la primera red de Disponibilidad de Datos (DA) con estructura modular. Construida con CometBFT y Cosmos SDK, es una cadena de bloques de prueba de participación (PoS) que mejora efectivamente la escalabilidad mientras mantiene la descentralización.

La capa DA es fundamental para la seguridad de cualquier blockchain, ya que garantiza que cualquiera pueda inspeccionar el libro de transacciones y verificarlo. Si el productor del bloque propone un bloque cuando no todos los datos están disponibles, el bloque puede lograr finalidad pero contener transacciones no válidas. Incluso si un bloqueo es válido, los datos del bloque que no se pueden verificar completamente afectarán negativamente a los usuarios y la funcionalidad de la red.

Celestia implementa dos funciones clave, a saber, muestreo de disponibilidad de datos (DAS) y árbol de nombres Merkle (NMT). DAS permite que los nodos ligeros verifiquen la disponibilidad de datos sin descargar bloques completos. Los NMT permiten dividir los datos en bloques en espacios de nombres separados para diferentes aplicaciones, lo que significa que las aplicaciones solo necesitan descargar y procesar los datos relacionados con ellos, lo que reduce en gran medida los requisitos de procesamiento de datos. Es importante destacar que DAS permite a Celestia escalar a medida que aumenta la cantidad de usuarios (nodos ligeros) sin comprometer la seguridad del usuario final.

Las cadenas de bloques modulares están haciendo posible construir nuevas cadenas de una manera sin precedentes, con diferentes tipos de cadenas de bloques modulares trabajando juntas para diferentes propósitos y con diferentes arquitecturas. Celestia propuso oficialmente varias ideas y ejemplos de diseño de arquitectura modular, mostrándonos la flexibilidad y componibilidad de la blockchain modular:

Figura 1 Arquitectura de Capa 1 y Capa 2

Capa 1 y Capa 2: Lo que Celestia llama modularidad ingenua se construyó originalmente para la escalabilidad de Ethereum como un monolito. La Capa 1 se centra en la ejecución y la Capa 1 proporciona otras funciones clave.

  • Celestia admite cadenas construidas basadas en pilas de tecnología Arbitrum Orbit, Optimism Stack y Polygon CDK (que pronto serán compatibles) para usar Celestia como capa DA. La capa 2 existente puede usar la tecnología Rollup para cambiar sus datos de publicación a Ethereum a publicación a Celestia. Los compromisos de bloques se publican en Celestia, que es más escalable que el enfoque tradicional de publicar datos en una sola cadena.

  • Celestia admite RollApp (una cadena dedicada a aplicaciones) construida en base a componentes de tecnología Dymension como capa de ejecución. Es similar a los conceptos de Capa 1 y Capa 2 de Ethereum. La capa de liquidación de RollApps se basa en Dymension Hub (se explicará más adelante). la capa DA usa Celestia, las cadenas interactúan a través del protocolo IBC (IBC se basa en el SDK de Cosmos, un protocolo que permite que las blockchains se comuniquen entre sí. Las cadenas que usan IBC pueden compartir cualquier tipo de datos, siempre que estén codificados en bytes ).

Figura 2: Arquitectura de capa de ejecución, liquidación y DA

Ejecución, liquidación y disponibilidad de datos: las cadenas de bloques modulares optimizadas, como las capas de ejecución, liquidación y disponibilidad de datos, se pueden desacoplar entre cadenas de bloques modulares especializadas.

Figura 3: Arquitectura de capa de ejecución y DA

Ejecución y DA: dado que el propósito de implementar una cadena de bloques modular es ser flexible, la capa de ejecución no se limita a publicar sus bloques en la capa de liquidación. Por ejemplo, es posible crear una pila modular que no involucre la capa de liquidación, solo la capa de ejecución encima de la capa de consenso y la capa de disponibilidad de datos.

Bajo esta pila modular, la capa de ejecución sería soberana y publicaría sus transacciones en otra cadena de bloques, generalmente para realizar pedidos y disponibilidad de datos, pero manejaría su propia liquidación. En el contexto de la pila modular, el resumen soberano es responsable de la ejecución y la liquidación, mientras que la capa DA maneja el consenso y la disponibilidad de datos.

La diferencia entre la acumulación soberana y la acumulación de contratos inteligentes es:

  • Las transacciones acumuladas de contratos inteligentes se verifican mediante contratos inteligentes en la capa de liquidación. Las transacciones de Sovereign Rollup son verificadas por nodos de Sovereign Rollup.

  • En comparación con el contrato inteligente Rollup, los nodos del soberano Rollu tienen autonomía. En un Rollup soberano, el orden y la validez de las transacciones son administrados por la propia red del Rollup en lugar de depender de una capa de liquidación separada.

Actualmente, Rollkit y Sovereign SDK proporcionan un marco para implementar redes de prueba soberanas Rollup en Celestia.

3. Explorar soluciones modulares en el ecosistema blockchain.

1. Modularización de la capa de ejecución

Antes de introducir la modularización de la capa de ejecución, debemos comprender qué es la tecnología Rollup.

La tecnología actual de modularización de la capa de ejecución se basa principalmente en Rollup, que es una solución de escalamiento que opera fuera de la cadena de la Capa 1. Esta solución realiza transacciones fuera de la cadena, lo que significa que ocupa menos espacio en bloque y también es una de las soluciones de expansión importantes para Ethereum. Después de ejecutar la transacción, enviará un lote de datos de la transacción o prueba de ejecución a la Capa 1 y lo liquidará en la Capa 1. La tecnología Rollup proporciona una solución de escalabilidad para redes de Capa 1 manteniendo al mismo tiempo la descentralización y la seguridad.

Figura 4: Arquitectura técnica acumulativa

Tomando Ethereum como ejemplo, la tecnología Rollup puede mejorar aún más el rendimiento y la privacidad mediante el uso de ZK-Rollup o Optimistic Rollup.

  • ZK-Rollup utiliza pruebas de conocimiento cero para verificar la exactitud de las transacciones empaquetadas, garantizando así la seguridad y privacidad de las transacciones.

  • Optimistic Rollup primero asume que estas transacciones son válidas antes de enviar el estado de la transacción a la cadena principal de Ethereum. Durante el período de desafío, cualquiera puede calcular una prueba de fraude para verificar la transacción.

1.1 Ethereum Layer 2: creación de soluciones de escalamiento futuras

Inicialmente, Ethereum adoptó tecnologías de cadena lateral y fragmentación para escalar, pero la cadena lateral sacrificó algo de descentralización y seguridad para lograr un alto rendimiento. Los paquetes acumulativos de capa 2 se desarrollaron mucho más rápido de lo esperado y han proporcionado una gran cantidad de extensiones, y se proporcionarán más después de que Proto-Danksharding esté disponible. implementado. Esto significa que las "cadenas de fragmentos" ya no son necesarias y ahora se han eliminado de la hoja de ruta de Ethereum.

Ethereum subcontrata la capa de ejecución a la Capa 2 basada en la tecnología Rollup para reducir la carga en la cadena principal. EVM proporciona un entorno de ejecución estandarizado y seguro para contratos inteligentes ejecutados en la capa Rollup. Algunas soluciones Rollup están diseñadas teniendo en cuenta la compatibilidad con EVM, de modo que los contratos inteligentes ejecutados en la capa Rollup aún puedan aprovechar las características y funciones de EVM, como OP Mainnet, Arbitrum One y Polygon zkEVM, etc.

Figura 5: Solución de escalado de Capa 2 de Ethereum

Estas capas 2 ejecutan contratos inteligentes y procesan transacciones, pero aún dependen de Ethereum para:

Liquidación: todas las transacciones acumuladas se completan en la red principal de Ethereum. Los usuarios de Optimistic Rollups deben esperar a que transcurra el período de desafío o que la transacción se considere válida después de los cálculos antifraude. Los usuarios de ZK Rollups deben esperar hasta que se demuestre su validez.

Consenso y disponibilidad de datos: los rollups publican datos de transacciones en la red principal de Ethereum en forma de CallData, lo que permite a cualquiera ejecutar transacciones rollup y reconstruir su estado si es necesario. Los rollups optimistas requieren una gran cantidad de espacio de bloque y un período de desafío de 7 días antes de ser confirmados en la cadena principal de Ethereum. ZK Rollups proporciona una finalidad instantánea y almacena datos disponibles para verificación durante 30 días, pero requiere una potencia informática significativa para crear pruebas.

1.2 Red B²: Creación de Bitcoin ZK-Rollup

B² Network es el primer ZK-Rollup en Bitcoin, que aumenta la velocidad de las transacciones sin sacrificar la seguridad. Utilizando la tecnología Rollup, B² Network proporciona una plataforma que puede ejecutar contratos inteligentes completos de Turing para transacciones fuera de la cadena, mejorando así la eficiencia de las transacciones y minimizando los costos.

Figura 6: Arquitectura de red B²

Como se muestra en la figura, la capa ZK-Rollup de B² Network utiliza la solución zkEVM y es responsable de la ejecución de las transacciones de los usuarios dentro de la red de Capa 2 y la salida de los certificados relacionados.

A diferencia de otros Rollups, B² Network ZK-Rollup consta de múltiples componentes, incluido el módulo de abstracción de cuentas, el servicio RPC, Mempool, secuenciadores, zkEVM, agregadores, sincronizadores y Prover. El módulo de abstracción de cuentas implementa la abstracción de cuentas nativa, lo que permite a los usuarios programar de manera flexible una mayor seguridad y una mejor experiencia de usuario en sus cuentas. zkEVM es compatible con EVM y también puede ayudar a los desarrolladores a migrar DApps de otras cadenas compatibles con EVM a B² Network.

Los sincronizadores garantizan que la información se sincronice desde el nodo B² con la capa acumulativa, incluida la información de secuencia, los datos de transacciones de Bitcoin y otros detalles. Los nodos B² actúan como validadores fuera de la cadena y son ejecutores de múltiples funciones únicas en la red B². El módulo Bitcoin Committer en el nodo B² construye una estructura de datos para registrar los datos acumulativos de B² y genera un Tapscript llamado "inscripción B²". Luego, el Bitcoin Committer envía un UTXO de un satoshi a una dirección Taproot que contiene la inscripción $B^{ 2 }$, y los datos acumulativos se escribirán en Bitcoin.

Además, el Bitcoin Committer establece un desafío con límite de tiempo, lo que permite al retador desafiar la promesa de una verificación a prueba de zk. Si no hay retadores durante el bloqueo de tiempo o el desafío falla, el Rollup finalmente se confirma en Bitcoin; si el desafío tiene éxito, el Rollup se revertirá;

Ya sea Ethereum o Bitcoin, la Capa 1 es esencialmente una cadena única y reciben datos extendidos de la Capa 2. En la mayoría de los casos, la capacidad de la Capa 2 también depende de la capacidad de la Capa 1. Por lo tanto, la implementación de pilas de Capa 1 y Capa 2 no es ideal para la escalabilidad. Cuando la Capa 1 alcance su límite de rendimiento, la Capa 2 también se verá afectada, lo que puede generar mayores tarifas de transacción y tiempos de confirmación extendidos, lo que afectará la eficiencia y la experiencia del usuario de todo el sistema.

2. Modularización de la capa DA

Además de que la solución DA de Celestia es favorecida por Layer 2, han surgido una tras otra otras soluciones innovadoras centradas en DA, que desempeñan un papel clave en todo el ecosistema blockchain.

2.1 EigenDA: potenciando la tecnología Rollup

EigenDA es un servicio DA descentralizado, seguro y de alto rendimiento cuyo diseño está inspirado en Danksharding. Rollup permite publicar datos en EigenDA para reducir los costos de transacción, aumentar el rendimiento de las transacciones y asegurar la componibilidad en todo el ecosistema EigenLayer.

Al crear un almacenamiento de datos temporal descentralizado en Ethereum Rollup, los operadores de EigenDA pueden manejar el almacenamiento de datos directamente. Los operadores se refieren a aquellos que participan en las operaciones de la red y son responsables de procesar, verificar y almacenar datos. EigenDA puede expandirse horizontalmente a medida que aumenta la cantidad de promesas y operadores.

EigenDA combina la tecnología Rollup y simultáneamente transfiere la parte de DA al procesamiento fuera de la cadena para lograr escalabilidad. Por lo tanto, ya no es necesario copiar y almacenar los datos de transacciones reales en cada nodo, lo que reduce la necesidad de ancho de banda y almacenamiento. On-chain solo maneja metadatos y mecanismos de responsabilidad relacionados con la disponibilidad de datos (la responsabilidad permite almacenar datos fuera de la cadena y verificar su integridad y autenticidad si es necesario).

Figura 7: Flujo de datos básicos de EigenDA

Como se muestra en la figura, Rollup escribe lotes de transacciones en la capa DA. A diferencia de los sistemas que utilizan pruebas de fraude para detectar datos maliciosos, EigenDA divide los datos en fragmentos y genera el compromiso KZG y múltiples pruebas de revelación que requieren que los nodos solo descarguen una pequeña cantidad. de datos [O(1/n)] en lugar de descargar el blob completo. El protocolo de arbitraje de fraude de Rollup también puede verificar que los datos del blob coincidan con el compromiso de KZG proporcionado en la prueba EigenDA. Al realizar esta verificación, la cadena de Capa 2 garantiza que el secuenciador/proponente no pueda manipular los datos de la transacción de la raíz del estado acumulativo.

2.2 Nubit: la primera solución DA modular en Bitcoin

Nubit es una capa DA escalable nativa de Bitcoin. Nubit es pionero en un futuro nativo de Bitcoin diseñado para aumentar el rendimiento de datos y los servicios de disponibilidad para satisfacer las crecientes necesidades del ecosistema. Su visión es incorporar a la vasta comunidad de desarrolladores al ecosistema de Bitcoin y brindarles herramientas escalables, seguras y descentralizadas.

Los miembros del equipo de Nubit son profesores y estudiantes de doctorado de UCSB (Universidad de California, Santa Bárbara) con destacada reputación académica e influencia global. No solo son competentes en investigación académica, sino que también tienen una amplia experiencia en la implementación de ingeniería blockchain. El equipo escribió un artículo sobre un indexador modular junto con domo (el creador de Brc 20), agregó el diseño de la capa DA a la estructura del indexador del metaprotocolo Bitcoin y participó en el establecimiento y formulación de estándares de la industria.

Las principales innovaciones de Nubit: mecanismo de consenso, puente sin confianza y disponibilidad de datos. Utiliza algoritmos de consenso innovadores y Lightning Network para heredar las características completamente resistentes a la censura de Bitcoin, y utiliza DAS para mejorar la eficiencia:

  • Mecanismo de consenso: Nubit explora un consenso eficiente basado en PBFT (Tolerancia práctica a fallas bizantinas) impulsado por SNARK para la agregación de firmas. La combinación del esquema PBFT y la tecnología zkSNARK reduce significativamente la complejidad de la comunicación para verificar firmas entre verificadores y verifica la exactitud de las transacciones sin acceder a todo el conjunto de datos.

  • DAS: El DAS de Nubit se implementa realizando múltiples rondas de muestreo aleatorio en pequeñas partes de los datos del bloque. Cada ronda exitosa de muestreo aumenta la probabilidad de que los datos sean plenamente utilizables. Una vez que se alcanza un nivel de confianza predeterminado, los datos del bloque se consideran accesibles.

  • Puente sin confianza: Nubit utiliza un puente sin confianza, que aprovecha el canal de pago de Lightning Network. Este enfoque es consistente con los métodos de pago nativos de Bitcoin sin agregar requisitos de confianza adicionales. En comparación con las soluciones puente existentes, conlleva menores riesgos para los usuarios.

Figura 8: Componentes básicos de Nubit

Revisamos además el ciclo de vida completo del sistema que se muestra en la Figura 8 utilizando un caso de uso específico. Supongamos que Alice quiere utilizar el servicio DA de Nubit para completar una transacción (Nubit admite múltiples tipos de datos, incluidos, entre otros, inscripciones, datos acumulativos, etc.).

  • Paso 1.1: Alice primero debe pagar la tarifa del gas a través del puente sin confianza de Nubit para continuar con el servicio. En particular, Alice necesita obtener un desafío público del puente sin confianza, indicado por el valor hash del bloque de altura).

  • Paso 1.2 y Paso 2: Alice debe obtener el resultado de la evaluación R del VDF relacionado con la ronda actual, enviar R y enviar sus datos y metadatos de transacción (como dirección y nonce) al validador para fusionarlos en el mempool.

  • Paso 3: el proceso mediante el cual los validadores proponen bloques y sus encabezados después de llegar a un consenso. El encabezado del bloque incluye el compromiso de los datos y su codificación Reed-Solomon (código RS) asociada, mientras que el bloque en sí contiene los datos originales, el código RS correspondiente y los detalles básicos de la transacción.

  • Paso 4: El ciclo de vida finaliza con la recuperación de datos de Alice. Los clientes ligeros descargan encabezados de bloques, mientras que los nodos completos obtienen bloques y sus encabezados.

Los clientes ligeros realizan el proceso DAS para verificar la disponibilidad de datos. Además, después de proponer un número umbral de bloques, los puntos de control de este historial se registran en la cadena de bloques de Bitcoin mediante marcas de tiempo de Bitcoin. Esto garantiza que el conjunto de validadores bloquee posibles ataques remotos y admita una desvinculación rápida.

3. Otras soluciones

Además de las cadenas que se centran en la modularización de capas específicas, los servicios de almacenamiento descentralizados pueden proporcionar soporte a largo plazo para la capa DA. También existen algunos protocolos y cadenas que brindan a los desarrolladores soluciones personalizadas y completas que permiten a los usuarios crear fácilmente sus propias cadenas sin siquiera crear código.

3.1 EthStorage: almacenamiento dinámico descentralizado

EthStorage es la primera Capa 2 modular que implementa almacenamiento descentralizado dinámico, proporcionando almacenamiento de valor clave (KV) programable impulsado por DA, extendiendo el almacenamiento programable a cientos a un costo de 1/100 a 1/1000 TB o incluso PB. Proporciona una solución DA a largo plazo para Rollups y abre nuevas posibilidades para aplicaciones totalmente en cadena, como juegos, redes sociales, inteligencia artificial y más.

Figura 9: Escenarios de aplicación de EthStorage

El fundador de EthStorage, Qi Zhou, se dedica a la industria Web3 desde 2018. Tiene un doctorado del Instituto de Tecnología de Georgia y ha trabajado como ingeniero en empresas de primer nivel como Google y Facebook. Su equipo también ha recibido el apoyo de la Fundación Ethereum.

Como una de las características principales de la actualización de Ethereum Cancún, EIP-4844 (también conocido como fragmentación Proto-dank), introduce bloques de datos temporales (blobs) para el almacenamiento acumulativo de capa 2, lo que mejora la escalabilidad y la seguridad. La red no necesita verificar cada transacción en el bloque, solo necesita confirmar si el blob adjunto al bloque contiene los datos correctos, lo que reduce en gran medida el costo de Rollup. Sin embargo, los datos del blob solo están disponibles temporalmente, lo que significa que se descartarán en unas pocas semanas. Esto tiene un impacto significativo: la Capa 2 no puede derivar incondicionalmente el último estado de la Capa 1. Si ya no se puede recuperar un dato de la Capa 1, es posible que no sea posible sincronizar la cadena mediante Rollup.

Con EthStorage como solución de almacenamiento DA a largo plazo, las capas 2 pueden obtener datos completos de su capa DA en cualquier momento.

Características técnicas:

  • EthStorage puede realizar un almacenamiento dinámico descentralizado: las soluciones de almacenamiento descentralizadas existentes pueden admitir la carga de grandes cantidades de datos, pero no se pueden modificar ni eliminar, y los datos nuevos solo se pueden volver a cargar. EthStorage implementa funciones CRUD a través del paradigma original de almacenamiento de valores clave, es decir, crear, actualizar, leer y eliminar datos almacenados, mejorando así significativamente la flexibilidad de la gestión de datos.

  • Solución descentralizada de Capa 2 basada en la capa DA: EthStorage es una capa de almacenamiento modular. Siempre que haya EVM y DA para reducir los costos de almacenamiento, puede ejecutarla en cualquier blockchain (pero actualmente muchas Capa 1 no tienen capa DA), incluso. en la Capa 2.

  • Altamente integrado con ETH: el cliente de EthStorage es un superconjunto del cliente de Ethereum Geth, lo que significa que cuando se ejecuta un nodo de EthStorage, aún puede participar en cualquier proceso de Ethereum. Un nodo puede ser un nodo de validación de Ethereum al mismo tiempo. También es el nodo de datos de EthStorage.

Flujo de trabajo de EthStorage:

  • Los usuarios cargan sus datos en el contrato de aplicación, que luego interactúa con el contrato EthStorage para almacenar los datos.

  • En la red EthStorage Layer 2, se notifica a los proveedores de almacenamiento sobre los datos que esperan ser almacenados.

  • Los proveedores de almacenamiento descargan datos de Ethereum Data Availability Network.

  • El proveedor de almacenamiento envía prueba de almacenamiento a la Capa 1, lo que demuestra que hay una gran cantidad de réplicas en la red de Capa 2.

  • El contrato EthStorage recompensa a los proveedores de almacenamiento que presentan con éxito pruebas de almacenamiento.

3.2 AltLayer - Servicio de personalización modular

AltLayer proporciona un servicio Rollups-as-a-Service (RaaS) versátil y sin código. Los productos RaaS están diseñados para el mundo de múltiples cadenas y múltiples VM, y son compatibles con EVM y WASM. También admite diferentes SDK Rollup como OP Stack, Arbitrum Orbit, Polygon zkEVM, ZKStack y Starkware de ZKSync, diferentes servicios de pedidos compartidos (como Espresso y Radius) y diferentes capas DA (como Celestia, EigenLayer) y diferentes pilas Rollup. Muchas capas otros servicios modulares.

Se pueden implementar pilas de Rollup multifuncionales a través de AltLayer, por ejemplo, se puede construir un Rollup diseñado para aplicaciones usando Arbitrum Orbit, usando Arbitrum One como DA y capa de liquidación, mientras que otro Rollup diseñado para propósitos generales puede usar ZK Stack Construido usando Celestia como Capa DA y Ethereum como capa de liquidación.

Nota: Cuando vea esto, es posible que se pregunte: ¿por qué OP y Arbitrum pueden implementar la capa de liquidación? De hecho, estas pilas acumulativas de Capa 2 actualmente están implementando un trabajo "intercadena" similar al propuesto por Cosmos para lograr la interconexión: OP propuso Superchain, y OP Stack sirve como una pila de desarrollo estandarizada para admitir la tecnología Optimism, integrando diferentes redes de Capa 2. integrados entre sí, promoviendo la interoperabilidad entre estas redes, Arbitrum ha propuesto la estrategia Orbitchain, que permite la creación y despliegue de la Capa 3 en la red principal de Arbitrum basada en Arbitrum Nitro (pila de tecnología), también conocidas como cadenas de aplicaciones. Las cadenas de órbita se pueden liquidar directamente en la capa 2 o directamente en Ethereum.

3.3 Dymension: modularización de pila completa

Dymension es una red blockchain modular basada en Cosmos SDK, diseñada para garantizar la seguridad y la interoperabilidad de RollApp mediante el uso del estándar IBC.

Dymension divide las funciones de blockchain en múltiples capas. Dymension Hub actúa como capa de liquidación y capa de consenso para proporcionar seguridad, interoperabilidad y liquidez a RollApp, y RollApp actúa como capa de ejecución. La capa de disponibilidad de datos es un proveedor de DA compatible con el protocolo Dymension. Los desarrolladores pueden elegir el proveedor de disponibilidad de datos adecuado según sus necesidades.

La capa de liquidación (Dymension Hub) mantiene el registro de RollApps y la información importante correspondiente, como el estado, la lista de secuenciadores, el secuenciador actualmente activo, la suma de comprobación del módulo de ejecución, etc. La lógica del servicio acumulativo está anclada dentro de la capa de liquidación, formando un centro para la interoperabilidad nativa. Dymension Hub como capa de asentamiento tiene las siguientes características:

  • Proporcionar servicios acumulativos de forma nativa en la capa de liquidación: proporciona los mismos supuestos de confianza y seguridad que la capa base, pero con un espacio de diseño más simple, seguro y eficiente.

  • Comunicación y transacciones: RollApp de Dymension implementa comunicaciones y transacciones entre RollApp en la capa de liquidación a través de módulos integrados, proporcionando un puente de confianza minimizada. Además, RollApps puede comunicarse con otras cadenas habilitadas para IBC a través del Hub.

  • RVM (RollApp Virtual Machine): la capa de liquidación de Dymension activa RVM en caso de una disputa por fraude. RVM puede resolver disputas en varios entornos de ejecución (como EVM), ampliando las capacidades y la flexibilidad del alcance de ejecución de RollApp.

  • Resistente a la censura: los usuarios que han sido sometidos a la censura de Sequencer pueden emitir una transacción especial a la capa de liquidación. Esta transacción se reenvía al secuenciador y se solicita que se ejecute dentro del rango de tiempo especificado. Si una transacción no se procesa dentro del tiempo especificado, el secuenciador será penalizado.

  • AMM (Creador de mercado automatizado): Dymension introduce un AMM integrado en el centro de liquidación, creando así un centro financiero central. Proporcionar liquidez compartida a todo el ecosistema.

4. Comparación de cadenas de bloques modulares multiecológicas

En el artículo anterior, analizamos en profundidad el sistema blockchain modular y muchos proyectos representativos. Ahora cambiaremos el enfoque al análisis comparativo entre diferentes ecologías, con el objetivo de comprender la blockchain modular de manera objetiva y completa.

5. Resumen y perspectivas

Como podemos ver, el ecosistema blockchain se está desarrollando hacia la modularidad. En el mundo blockchain anterior, cada cadena operaba de forma aislada y competía entre sí, lo que dificultaba que los usuarios, desarrolladores y activos fluyeran entre diferentes cadenas, lo que limitaba el desarrollo y la innovación generales del ecosistema. En el mundo WEB3, el descubrimiento y la solución de problemas son un proceso de esfuerzos conjuntos. Al principio, Bitcoin y Ethereum atrajeron mucha atención como cadenas individuales, pero a medida que se expusieron los problemas de las cadenas individuales, las cadenas modulares gradualmente atrajeron la atención. Por tanto, la aparición de las cadenas modulares no es un accidente, sino un acontecimiento inevitable.

Las cadenas de bloques modulares aumentan la flexibilidad y la eficiencia de la cadena al permitir que los componentes individuales se optimicen y personalicen de forma independiente. Pero esta arquitectura también enfrenta desafíos, como retrasos en las comunicaciones y una mayor complejidad de las interacciones del sistema. De hecho, los beneficios a largo plazo de la arquitectura modular, como una mayor capacidad de mantenimiento, reutilización y flexibilidad, a menudo superan sus penalizaciones de rendimiento a corto plazo. En el futuro, a medida que la tecnología se desarrolle, estos problemas encontrarán mejores soluciones.

GeekCartel cree que el ecosistema blockchain tiene la responsabilidad de proporcionar una capa base confiable y herramientas comunes en toda la pila modular para promover vínculos directos y fluidos entre las cadenas. Si el ecosistema puede ser más armonioso e interconectado, los usuarios podrán usarlo más fácilmente. La tecnología blockchain también atraerá a más usuarios nuevos a Web3.

6. Lectura ampliada: Protocolo de recuperación: inyectar seguridad nativa en ecosistemas heterogéneos

También existen algunos protocolos de restablecimiento que agregan de manera efectiva recursos de seguridad dispersos a través del mecanismo de nuevo compromiso y mejoran la seguridad general de la red blockchain. Este proceso no sólo resuelve el problema de la fragmentación de los recursos de seguridad, sino que también mejora las capacidades de defensa de la red contra posibles ataques. También proporciona incentivos adicionales para los participantes y anima a más usuarios a participar en el mantenimiento de la seguridad de la red. De esta manera, el protocolo Restating abre nuevas formas de mejorar la seguridad y eficiencia de la red, promoviendo efectivamente el desarrollo saludable del ecosistema blockchain.

1. EigenLayer: protocolo de recuperación descentralizado de Ethereum

EigenLayer es un protocolo construido en Ethereum que introduce el mecanismo de recuperación, una nueva primitiva para la seguridad criptoeconómica. Esta primitiva permite reutilizar ETH en la capa de consenso, agrega la seguridad de ETH entre todos los módulos y mejora la seguridad de las DApps que dependen de módulos. Apostar ETH de forma nativa o utilizar tokens de participación de liquidez (LST). Los usuarios que apuestan ETH pueden optar por unirse al contrato inteligente EigenLayer para volver a apostar su ETH o LST y extender la seguridad criptoeconómica a otras aplicaciones en la red para obtener recompensas adicionales.

Cuando Ethereum pasó a una hoja de ruta centrada en Rollup, las aplicaciones que podían crearse en Ethereum se expandieron significativamente.

Sin embargo, cualquier módulo que no pueda implementarse o probarse en el EVM no puede absorber la confianza colectiva de Ethereum. Dichos módulos implican el procesamiento de entradas desde fuera de Ethereum, por lo que su procesamiento no se puede verificar dentro del protocolo interno de Ethereum. Dichos módulos incluyen cadenas laterales basadas en nuevos protocolos de consenso, capas de disponibilidad de datos, nuevas máquinas virtuales, redes Oracle, puentes, etc. Normalmente, dichos módulos requieren AVS con su propia semántica de verificación distribuida para la verificación. Por lo general, estos AVS están protegidos por su propio token nativo o tienen permisos por naturaleza.

Actualmente existen algunos problemas con el ecosistema AVS:

  • Supuesto de confianza de seguridad. Los innovadores que desarrollan AVS deben navegar por una nueva red de confianza en materia de seguridad.

  • Fuga de valor. A medida que cada AVS desarrolla su propio grupo de confianza, los usuarios deben pagar tarifas a estos grupos además de las tarifas de transacción a Ethereum. Esta desviación en el flujo de tarifas da como resultado una fuga de valor de Ethereum.

  • Carga de ingredientes. Para la mayoría de los AVS que operan hoy en día, el costo de capital de apostar es significativamente mayor que cualquier costo operativo.

  • Las DApps tienen un modelo de confianza más bajo. El ecosistema AVS actual ha creado un problema. En términos generales, cualquier dependencia de middleware de una DApp puede convertirse en objetivo de un ataque.

Figura 10: Comparación entre el servicio AVS actual y EigenLayer

En términos de arquitectura de EigenLayer, AVS es un servicio creado en base al protocolo EigenLayer, aprovechando la seguridad compartida de Ethereum. EigenLayer presenta dos enfoques novedosos, seguridad centralizada mediante apuestas y gobernanza de libre mercado, que ayudan a extender la seguridad de Ethereum a cualquier sistema y eliminar las ineficiencias de las rígidas estructuras de gobernanza existentes:

  • Proporciona seguridad colectiva a través de la recolateralización. EigenLayer proporciona un nuevo mecanismo de seguridad colectiva al permitir asegurar ETH regarantizado en lugar de sus propios tokens. Específicamente, los validadores de Ethereum pueden configurar sus credenciales de retiro de la cadena de balizas en contratos inteligentes de EigenLayer y optar por nuevos módulos creados en EigenLayer. Los validadores descargan y ejecutan cualquier software de nodo adicional requerido por estos módulos. Luego, estos módulos pueden imponer condiciones de reducción adicionales al ETH apostado de los validadores que opten por participar en el módulo.

  • Los mercados abiertos ofrecen incentivos. EigenLayer proporciona un mecanismo de mercado abierto para gestionar la seguridad proporcionada por los validadores y cómo se consumen los AVS. EigenLayer crea un entorno en el mercado donde los módulos individuales necesitarán incentivar suficientemente a los validadores para que asignen ETH de re-stake a sus propios módulos, y los validadores ayudarán a decidir qué módulos son dignos de recibir esta seguridad colectiva adicional.

Al combinar estos enfoques, EigenLayer actúa como un mercado abierto donde AVS puede aprovechar la seguridad conjunta proporcionada por los validadores de Ethereum, promoviendo a los validadores a través de incentivos de recompensa y sanciones para lograr compensaciones más óptimas en seguridad y rendimiento.

2. Babylon: proporciona seguridad de Bitcoin para Cosmos y otras cadenas de puntos de venta

Babylon es una cadena de bloques de Capa 1 fundada por el profesor David Tse de la Universidad de Stanford. El equipo está formado por investigadores de Stanford y desarrolladores y consultores empresariales experimentados. Babylon propuso el protocolo de participación de Bitcoin, que fue diseñado como un complemento modular para muchos algoritmos de consenso de PoS diferentes, proporcionando una primitiva que puede volver a apostar el protocolo.

Basado en tres aspectos de Bitcoin (servicio de marca de tiempo, espacio de bloque y valor de activo), Babylon es capaz de ofrecer la seguridad de Bitcoin a todas las numerosas cadenas PoS (como Cosmos, Binance Smart Chain, Polkadot, Polygon y otras cadenas de bloques que ya tienen fuertes, ecosistemas interoperables) para crear un ecosistema más robusto y unificado.

La marca de tiempo de Bitcoin resuelve el ataque de larga distancia de PoS:

Los ataques de larga distancia se refieren a la posibilidad de iniciar una cadena bifurcada aprovechando la posibilidad de que los nodos de verificación en la cadena PoS regresen a un bloque histórico donde todavía estaban comprometidos después de quitar la participación. Este problema es inherente al sistema PoS y no se puede resolver por completo simplemente mejorando el mecanismo de consenso de la propia cadena PoS. Las cadenas PoS como Ethereum y Cosmos se enfrentan a este desafío.​

Después de la introducción de las marcas de tiempo de Bitcoin, los datos en cadena de la cadena PoS se almacenarán en la cadena de Bitcoin en forma de marcas de tiempo de Bitcoin. Incluso si alguien quiere crear una bifurcación de la cadena PoS, su marca de tiempo de Bitcoin correspondiente debe ser. más tarde que la cadena original, por lo que los ataques a larga distancia serán ineficaces en este momento.

Acuerdo de compromiso de Bitcoin:

El protocolo permite a los poseedores de Bitcoin apostar sus Bitcoins inactivos para aumentar la seguridad de la cadena PoS y obtener ingresos en el proceso.

La infraestructura central del protocolo de participación de Bitcoin es el plano de control entre Bitcoin y la cadena PoS, como se muestra en la siguiente figura.

Figura 11: Arquitectura del sistema con plano de control y plano de datos

Control Plane se implementa como una cadena para garantizar que sea descentralizado, seguro, resistente a la censura y escalable. Este plano de control es responsable de una variedad de funciones clave, que incluyen:

• Proporcionar un servicio de marca de tiempo de Bitcoin a las cadenas PoS para permitirles sincronizarse con la red Bitcoin.

• Actuar como un mercado, haciendo coincidir las cadenas de apuestas y PoS de Bitcoin, y rastreando la información de apuestas y verificación, como el registro y la actualización de claves EOTS;

• Registrar la firma de finalidad de la cadena PoS;

Al apostar su BTC, los usuarios pueden proporcionar servicios de verificación para cadenas PoS, capas DA, oráculos, AVS, etc. Babylon ahora también puede proporcionar servicios para Altlayer, Nubit, etc.

Referencias

imagen:

  • https://celestia.org/learn/modular-architectures/the-modular-stack/#layer-1-and-2

  • https://celestia.org/learn/modular-architectures/the-modular-stack/#execution-settlement-and-data-availability

  • https://celestia.org/learn/modular-architectures/the-modular-stack/#execution-and-data-availability

  • https://learnblockchain.cn/article/6169

  • https://celestia.org/learn/sovereign-rollups/an-introduction/#what-is-a-smart-contract-rollup

  • https://docs.bsquared.network/architecture

  • https://docs.eigenlayer.xyz/eigenda/overview#how-rollups-integrate

  • https://docs.nubit.org/#what-is-nubit

  • https://docs.ethstorage.io/#motivation

  • https://docs.eigenlayer.xyz/assets/files/EigenLayer_WhitePaper- 88 c 47923 ca 0319870 c 611 decd 6 e 562 ad .pdf

  • https://docs.babylonchain.io/assets/files/btc_s Taking_litepaper-32bfea0c243773f0bfac63e148387aef.pdf 

texto:

  • https://arxiv.org/abs/1809.09044

  • https://arxiv.org/abs/1905.09274

  • https://celestia.org/

  • https://github.com/cometbft/cometbft

  • https://github.com/cosmos/cosmos-sdk

  • https://docs.celestia.org/learn/how-celestia-works/data-availability-layer#data-availability-sampling-das

  • https://docs.celestia.org/learn/how-celestia-works/data-availability-layer#namespaced-merkle-trees-nmts

  • https://celestia.org/learn/modular-architectures/the-modular-stack/

  • https://docs.celestia.org/developers/arbitrum-integration

  • https://docs.celestia.org/developers/optimismo

  • https://docs.polygon.technology/cdk/

  • https://portal.dymension.xyz/

  • https://ibc.cosmos.network/main

  • https://celestia.org/learn/sovereign-Rollups/an-introduction/

  • https://docs.celestia.org/developers/rollkit

  • https://github.com/Sovereign-Labs/sovereign-sdk/tree/stable/examples/demo-Rollup

  • https://ethereum.org/developers/docs/scaling/sidechains

  • https://ethereum.org/roadmap#what-about-sharding

  • https://ethereum.org/roadmap/danksharding

  • https://www.optimismo.io/

  • https://arbitrum.io/

  • https://polygon.technology/polygon-zkevm

  • https://ethereum.org/en/developers/docs/scaling/optimistic-Rollups

  • https://ethereum.org/en/developers/docs/scaling/zk-Rollups

  • https://docs.bsquared.network/architecture

  • https://docs.bsquared.network/architecture/Rollup_layer

  • https://ethereum.org/en/roadmap/account-abstraction/

  • https://docs.bsquared.network/architecture/Rollup_layer#synchronizer

  • https://docs.bsquared.network/architecture/da_layer/b2_nodes

  • https://docs.bsquared.network/architecture/da_layer/b2_nodes#bitcoin-committer-module

  • https://www.kraken.com/learn/what-is-taproot

  • https://docs.eigenlayer.xyz/eigenda/overview

  • https://ethereum.org/en/roadmap/danksharding/

  • https://www.eigenlayer.xyz/ecosystem?category=Operador

  • https://ethereum.org/en/roadmap/danksharding/#how-are-blobs-verified

  • https://docs.nubit.org/

  • https://www.halborn.com/blog/post/what-is-practical-byzantine-fault-tolerance-in-blockchain

  • https://www.lightspark.com/learn/lightning

  • https://twitter.com/nubit_org/status/1742735322159747242

  • https://docs.nubit.org/overview/architecture/trustless-bridge

  • https://docs.ethstorage.io/

  • https://file.w3q.w3q-g.w3link.io/0x67d0481cc9c2e9dad2987e58a365aae977dcb8da/dynamic_data_sharding_0_1_6.pdf

  • https://medium.com/@ld-capital/%E4%BB%8Eethstorage-%E5%9B%9E%E7%9C%8B%E8%A2%AB%E5%B8%82%E5%9C%BA -%E5%86%B7%E8%90%BD-%E7%9A%84%E5%8E%BB%E4%B8%AD%E5%BF%83%E5%8C%96%E5%AD%98 %E5%82%A8%E8%B5%9B%E9%81%93-d0a003220362

  • https://www.eip4844.com/

  • https://lorenzo-protocol.gitbook.io/lorenzoprotocol/lorenzo-bitcoin-l2-as-a-service

  • https://zycrypto.com/lorenzo-protocol-integrates-with-babylon-to-transform-the-bitcoin-application-layer/

  • https://labs.binance.com/zh-CN

  • https://www.bnbchain.org/en

  • https://altlayer.io/

  • https://altlayer.io/raas

  • https://t.co/yxP9NTFKIv

  • https://t.co/2KibwFoIgA

  • https://docs.arbitrum.io/launch-orbit-chain/orbit-gentle-introduction

  • https://docs.arbitrum.io/for-devs/concepts/public-chains#arbitrum-one

  • https://tutorials.cosmos.network/academy/1-what-is-cosmos/

  • https://docs.dymension.xyz/

  • https://portal.dymension.xyz/dymension/metrics

Expresiones de gratitud

Todavía queda mucha investigación y trabajo por hacer en este paradigma de infraestructura emergente, y hay muchas áreas que no se tratan en este artículo. Si está interesado en algún tema de investigación relacionado, comuníquese con Chloe.

Muchas gracias a Severus y Jiayi por sus interesantes comentarios y opiniones sobre este artículo.

Enlace original