Inicio
» Noticias
»
Blockchains modulares frente a monolíticas: Celestia, EigenLayer y lo que nos depara el futuro.
Blockchains modulares frente a monolíticas: Celestia, EigenLayer y lo que nos depara el futuro.
La arquitectura blockchain se está alejando del simple debate de que "una sola cadena lo hace todo". La pregunta más relevante es qué funciones deben permanecer juntas, cuáles pueden separarse y qué nuevos riesgos surgen cuando un sistema se vuelve modular. Esto es importante porque la ejecución, la liquidación, el consenso, la disponibilidad de datos, la verificación, la secuenciación y la seguridad compartida ahora pueden combinarse de muchas maneras diferentes.
A septiembre de 2026, no existe un ganador absoluto. Las cadenas monolíticas pueden ofrecer un modelo operativo y de seguridad más robusto, mientras que los sistemas modulares permiten especializar capas individuales y escalar diferentes recursos de forma independiente. Celestia es uno de los ejemplos más claros de una red especializada en disponibilidad de datos. EigenLayer desempeña un papel diferente: no es simplemente «otra cadena de bloques modular», sino un marco de seguridad compartida y de re-apuesta que puede ayudar a otros servicios a impulsar la seguridad económica. Ethereum, por su parte, opera cada vez más como un sistema L1+L2 en lugar de ajustarse perfectamente a la etiqueta de monolítico.
¿Qué significa realmente “monolítico frente a modular”?
Una cadena de bloques monolítica gestiona las principales funciones del protocolo dentro de un sistema base integrado. Estas funciones suelen incluir la ejecución de transacciones, la liquidación, el consenso y la disponibilidad de datos. La arquitectura es más fácil de comprender porque la misma cadena define las reglas, ordena la actividad, verifica las transiciones de estado y pone a disposición los datos de las transacciones.
Una arquitectura de cadena de bloques modular separa algunas de estas tareas en capas especializadas. Una red puede ejecutar transacciones, otra puede proporcionar disponibilidad de datos y otra puede proporcionar liquidación o seguridad. La documentación de Celestia describe el modelo modular como uno en el que la ejecución y la liquidación pueden residir sobre una capa base centrada en el consenso y la disponibilidad de datos. Su documentación actual también explica el muestreo de disponibilidad de datos (DAS), que permite a los nodos ligeros comprobar si los datos del bloque se han publicado sin descargar cada byte del bloque. Consulte la documentación de disponibilidad de datos de Celestia .
Comparación conceptual de pilas de blockchain integradas y modulares. El diagrama muestra cómo se pueden agrupar o separar las responsabilidades; las garantías de seguridad reales dependen de cada protocolo y configuración.
¿Es la arquitectura modular automáticamente mejor que la monolítica?
No. La modularidad es una herramienta de diseño, no una garantía de mejor rendimiento ni de mayor seguridad. Separar las funciones permite que cada capa se optimice para una tarea más específica, pero también crea interfaces entre capas. Estas interfaces introducen suposiciones adicionales: los puentes pueden fallar, los secuenciadores pueden censurar, los datos pueden no estar disponibles cuando se necesitan, las pruebas pueden retrasarse o una aplicación puede depender de varios sistemas con diferentes modelos de confianza.
Los diseños monolíticos reducen parte de esa complejidad entre capas, ya que el mismo conjunto de validadores y las mismas reglas de protocolo suelen regir la mayor parte de la pila. La desventaja es que cada nodo completo puede necesitar gestionar más trabajo, lo que puede dificultar el aumento del rendimiento bruto sin incrementar los requisitos de hardware o ancho de banda.
Recomendación para los lectores: al comparar dos cadenas de bloques, no se limiten a analizar las transacciones por segundo o las comisiones. Anoten dónde se ejecutan las transacciones, dónde se publican los datos, dónde se realiza la liquidación final, quién puede reordenar las transacciones y qué componente puede provocar la interrupción del sistema o la pérdida de fondos.
¿Dónde encaja Celestia en la arquitectura modular?
Celestia se entiende mejor como una red especializada de consenso y disponibilidad de datos. Las aplicaciones y los agregadores pueden publicar datos en Celestia mientras se ejecutan en otro lugar. Esto cambia el problema de escalabilidad: en lugar de exigir a una cadena base que ejecute cada transacción de la aplicación, Celestia se centra en hacer que los datos de los bloques estén disponibles y sean verificables.
Su técnica clave es el muestreo de disponibilidad de datos. Celestia bloquea los datos mediante códigos de borrado, y los nodos ligeros muestrean pequeñas porciones de esos datos con pruebas. Un muestreo exitoso garantiza que los datos completos del bloque estén disponibles. Celestia también utiliza árboles Merkle con espacios de nombres para que las aplicaciones puedan recuperar y demostrar la integridad de los datos relevantes para su propio espacio de nombres, en lugar de descargar datos de aplicaciones no relacionadas.
Eso no significa que la “disponibilidad de datos” sea lo mismo que el almacenamiento permanente. La propia documentación de Celestia distingue explícitamente entre demostrar que se publicaron nuevos datos de bloques y conservar datos históricos indefinidamente. Su documentación actual sobre recuperabilidad indica que el muestreo de nodos ligeros utiliza una ventana móvil de siete días bajo el modelo de poda actual, por lo que los desarrolladores aún necesitan un plan para la recuperación histórica a largo plazo. Consulte la documentación de Celestia sobre recuperabilidad y poda .
Recomendación para desarrolladores: si está considerando Celestia para una agregación de aplicaciones o una cadena de aplicaciones, defina su estrategia de datos históricos por separado de su estrategia de disponibilidad de datos en tiempo real.
¿Es EigenLayer una cadena de bloques modular como Celestia?
No en el mismo sentido. Esta es una simplificación común que conviene corregir. La idea central de EigenLayer es el reapostaje: el staking relacionado con Ethereum puede utilizarse para realizar tareas de validación adicionales para servicios externos. Estos servicios se han denominado históricamente Servicios Validados Activamente (AVS, por sus siglas en inglés). El objetivo es permitir que la nueva infraestructura utilice seguridad criptoeconómica compartida en lugar de crear siempre una economía de validadores completamente independiente desde cero.
Por lo tanto, EigenLayer pertenece al ámbito de la modularidad como una primitiva de seguridad y coordinación, en lugar de simplemente como una cadena de disponibilidad de datos. Eigen Labs describió el lanzamiento de su red principal en 2024 como el lanzamiento de un protocolo de re-apuesta destinado a ampliar la seguridad criptoeconómica para servicios adicionales. Consulte el resumen anual oficial de EigenLayer 2024. La documentación actual de EigenCloud también presenta los AVS de EigenLayer como una forma de crear servicios verificables mediante sus herramientas para desarrolladores; consulte la documentación de EigenCloud .
EigenDA es un ejemplo útil de cómo este modelo de seguridad compartida puede respaldar una infraestructura modular. Se trata de un servicio de disponibilidad de datos integrado en el ecosistema EigenLayer, mientras que EigenLayer constituye el marco de seguridad y re-apuesta más amplio. Una explicación de la arquitectura oficial de Eigen Labs, aunque antigua, sigue siendo útil y describe a EigenDA como un almacén de disponibilidad de datos basado en EigenLayer. Muestra cómo un rollup puede utilizar EigenDA para los datos, al tiempo que sigue utilizando Ethereum para otras partes de la pila. Consulte la descripción general de la integración oficial de EigenDA .
Recomendación para los lectores: distingan entre “EigenLayer” y “EigenDA” en su modelo mental. Uno es el marco más amplio de seguridad compartida/reasignación de recursos; el otro es un sistema específico de disponibilidad de datos dentro de ese ecosistema.
¿Qué es Ethereum ahora: monolítico o modular?
Ethereum es un buen ejemplo de por qué la etiqueta binaria está perdiendo utilidad. Ethereum L1 aún integra la ejecución, el consenso, la liquidación y la disponibilidad de datos nativos en la capa base. Sin embargo, la estrategia de escalabilidad del ecosistema ha trasladado cada vez más la ejecución de los usuarios a las agregaciones L2, mientras que Ethereum proporciona la liquidación, la seguridad y la capacidad de datos.
La Fundación Ethereum ha descrito explícitamente Ethereum como un sistema L1+L2. En marzo de 2026, afirmó que la plataforma debe entenderse como una relación de refuerzo mutuo entre L1 y una red diferenciada de L2, reconociendo también que la fragmentación es una desventaja importante de un entorno multicadena. Véase la estrategia de la Fundación Ethereum sobre la plataforma L1 y L2 .
Esto también se observa en la hoja de ruta de datos de Ethereum. EIP-4844 introdujo el espacio de blobs para rollups, lo que abarata la publicación de datos L2 sin tratar cada byte como datos de llamadas de ejecución ordinarias. La documentación oficial de Ethereum explica que los rollups dependen de la disponibilidad de datos para la verificación independiente y que los datos de blobs son un almacenamiento histórico temporal, no permanente. Consulte la documentación sobre disponibilidad de datos en Ethereum.org .
¿Cuáles son las principales ventajas e inconvenientes de ambos enfoques?
Pregunta
Enfoque monolítico
Enfoque modular
¿Dónde se gestionan las funciones principales?
Principalmente dentro de un protocolo base integrado.
Dividido en capas o servicios especializados.
Estrategia de escalamiento
Aumentar la capacidad del sistema base manteniendo la integración de todas las funciones.
Escalar la ejecución, la disponibilidad de datos, la verificación o la seguridad de forma independiente.
Análisis de seguridad
A menudo, hay menos dependencias externas que auditar.
Es necesario analizar la capa relevante más débil y las interfaces entre capas.
Flexibilidad del desarrollador
Más condicionado por las decisiones de diseño de la capa base.
Puede combinar entornos de ejecución, sistemas DA, capas de liquidación y servicios de seguridad.
Experiencia de usuario
Puede ser más sencillo cuando los activos y las aplicaciones permanecen en una misma cadena.
Puede generar fragmentación de puentes, monederos, liquidez y entre cadenas.
Ruta de actualización
Los cambios pueden requerir coordinación a lo largo del protocolo integrado.
Los módulos individuales pueden evolucionar de forma independiente, pero la compatibilidad se convierte en una preocupación adicional.
¿La modularidad debilita la seguridad?
A veces, pero no necesariamente. Lo importante es si un sistema modular conserva las propiedades de seguridad que los usuarios esperan. Un sistema de agregación que publica datos en una red, los almacena en otra, utiliza un secuenciador centralizado y depende de un puente independiente presenta múltiples vulnerabilidades. Un error o una brecha de seguridad en un componente crítico puede tener consecuencias incluso si la cadena de liquidación en sí misma permanece segura.
Por otro lado, la especialización puede mejorar la seguridad cuando una capa se diseña específicamente para una tarea y expone reglas de verificación claras. Los sistemas de seguridad compartida también pueden reducir la necesidad de que cada nuevo servicio inicie un conjunto de validadores completamente independiente. El resultado depende de la implementación, la distribución de la participación, la diversidad de operadores, las condiciones de penalización, los sistemas de prueba, el diseño del puente, las claves de actualización y la descentralización operativa.
Recomendaciones para inversores y usuarios: busquen un modelo de amenazas publicado y una descripción clara de quién puede actualizar contratos, detener retiros, censurar transacciones o reemplazar operadores. Indicar que está protegido por Ethereum, que utiliza Celestia o que está basado en EigenLayer no proporciona suficiente información.
¿Qué sigue siendo incierto?
Varias cuestiones importantes siguen sin resolverse. En primer lugar, aún no está claro qué servicios modulares generarán mercados de tarifas estables. Una capa técnicamente eficiente todavía necesita suficiente demanda para cubrir los costos de los operadores, el ancho de banda, el almacenamiento, las pruebas y el desarrollo continuo.
En segundo lugar, la experiencia de usuario entre cadenas y capas sigue siendo compleja. La propia estrategia de plataforma de Ethereum para 2026 identifica la fragmentación como un problema fundamental. Una mejor interoperabilidad puede ocultar gran parte de la complejidad a los usuarios, pero ocultar la complejidad no es lo mismo que eliminar las suposiciones de confianza.
En tercer lugar, los sistemas modulares pueden desplazar la centralización en lugar de eliminarla. La ejecución puede descentralizarse mientras que la secuenciación se concentra; la disponibilidad de datos puede descentralizarse mientras que la generación de pruebas se concentra; o la seguridad puede compartirse económicamente mientras que la participación de los operadores permanece agrupada.
Finalmente, el término “modular” abarca diversas arquitecturas. Un rollup soberano que utiliza Celestia no es lo mismo que un Ethereum L2 que publica blobs en Ethereum, ni tampoco es lo mismo que un AVS que utiliza la seguridad EigenLayer. Por lo tanto, las afirmaciones sobre blockchains modulares deben evaluarse pila por pila.
Entonces, ¿qué arquitectura deberían elegir los desarrolladores?
La elección se basa en el cuello de botella y los requisitos de seguridad de la aplicación, no en la etiqueta. Una aplicación financiera de alto valor puede preferir una ruta de liquidación y disponibilidad de datos estrechamente integrada, aunque resulte más costosa. Una aplicación de juegos o redes sociales puede priorizar la ejecución económica y el alto rendimiento de datos. Una cadena de aplicaciones puede requerir reglas de ejecución personalizadas, externalizando la disponibilidad y la seguridad de los datos.
Una evaluación práctica debería responder a cinco preguntas antes de elegir una pila de herramientas:
¿Qué elementos deben permanecer activos para que los usuarios puedan realizar transacciones y retiros?
¿Dónde se publican los datos de las transacciones y durante cuánto tiempo se pueden consultar?
¿Quién ordena las transacciones y puede esa parte censurarlas o modificarlas?
¿Qué mecanismo criptográfico o económico verifica el comportamiento correcto?
¿Qué claves de gobernanza o mecanismos de actualización pueden cambiar esos supuestos?
¿El futuro de las criptomonedas será modular?
La dirección más plausible es la híbrida, en lugar de la de "el ganador se lo lleva todo". Es improbable que las cadenas monolíticas desaparezcan, ya que la ejecución y la seguridad integradas pueden ser valiosas. Al mismo tiempo, las redes especializadas de disponibilidad de datos, los rollups, los servicios de seguridad compartida, los sistemas de prueba y las capas de ejecución interoperables ofrecen a los desarrolladores más formas de ensamblar infraestructura blockchain.
Celestia demuestra la conveniencia de especializar la disponibilidad de datos. EigenLayer demuestra la conveniencia de tratar la seguridad económica como un servicio que puede ser reutilizado por otros sistemas. Ethereum muestra cómo una cadena base puede permanecer integrada mientras evoluciona hacia una plataforma modular L1+L2 más amplia.
El cambio fundamental no radica en que todas las blockchains deban ser modulares, sino en que los desarrolladores ya no tienen que aceptar una arquitectura fija. La próxima fase de las criptomonedas probablemente se definirá por la eficacia con la que los proyectos combinen la especialización con la seguridad verificable, límites de fallo claros, una economía sostenible y una experiencia de usuario que no requiera que las personas comprendan cada capa subyacente.