---
title: "Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?"
description: "Las blockchains modulares prometen capas flexibles, rollups más económicos y mejor escalabilidad, pero cada puente y dependencia añade nuevos riesgos."
language: es
published: 2026-07-15
author: Netts
topic: "Insights"
canonical: https://netts.io/blog/modular-blockchains-lego-dream-or-integration-nightmare?lang=es
languages: [en, ru, es, zh, th, fr, uk, tr, hi, fa, ar, ha, pt, vi, ko, ja, id, de, tl]
translation_outdated: false
---
# Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?

Las blockchains modulares prometen capas flexibles, rollups más económicos y mejor escalabilidad, pero cada puente y dependencia añade nuevos riesgos.

Modular es una palabra sospechosamente agradable. Evoca imágenes de piezas de Lego, librerías de software bien organizadas y muebles entregados en cajas con una bolsa de tornillos al lado. Lo modular implica flexibilidad, modernidad y cierto grado de elegancia, a diferencia de algún mecanismo gigante e indestructible donde cada engranaje está soldado al siguiente. Por eso, este término encuentra su hábitat natural en el marketing cripto. Una blockchain modular es algo que debería encajar con total naturalidad en la mente de cualquiera: la ejecución aquí, la liquidación allá, la disponibilidad de datos abajo, un puente, algo de cifrado de conocimiento cero y, de repente, todo el sistema es más eficiente que la alternativa monolítica.

Cualquiera que haya intentado armar algo modular sabe que la belleza a menudo reside en el engaño. Reemplazar un conjunto de bloques de Lego por otro puede ser decepcionante si los nuevos bloques no son tan resistentes como los antiguos. Ahora imagine que en lugar de piezas de plástico y tornillos tiene supuestos de liquidación, frameworks de rollups, contratos de puentes, comités de disponibilidad de datos, tokens de gobernanza, cronogramas de inversores, auditorías externas y cinco mil líneas de código inicializadas por LLM que nadie lee porque el plazo de lanzamiento está encima.

Las cosas pueden salir bien si se hacen correctamente. Esta verdad tan banal es el núcleo del diseño de las blockchains modulares. No es algo mágico, no promete resolver los problemas por sí solo; únicamente sostiene que la complejidad puede trasladarse de un lugar a otro. Depende de los desarrolladores asegurarse de que esta nueva complejidad distribuida sea manejable. Un sistema modular bien organizado puede aislar un dominio determinado y realizar su tarea mucho mejor de lo que lo haría un sistema monolítico. También puede crear una superficie de ataque de proporciones aterradoras si no se diseña teniendo esto en cuenta.

La razón por la que las blockchains modulares resultan tan interesantes radica en que las formas tradicionales de diseñar sistemas blockchain se toparon con ciertos problemas. Una blockchain monolítica es una capa de liquidación, un entorno de ejecución, un mecanismo de consenso y una capa de disponibilidad de datos, todo mezclado en un único sistema estrechamente integrado. Es el diseño del castillo medieval: simple, elegante, con todas las defensas concentradas en un solo lugar, pero sumamente costoso de construir y mantener.

La liquidación, la ejecución, el consenso y la disponibilidad de datos son fundamentales, pero la competencia por el espacio de bloque entre ellos a menudo deja poco margen para las aplicaciones que buscan liquidar en la cadena. Los usuarios terminan pagando por lo que los desarrolladores no logran priorizar, y estos últimos deben diseñar sorteando limitaciones en lugar de construir la capa de aplicación que imaginaron. Por esto, el diseño de blockchains modulares resulta una perspectiva tan atractiva: promete desacoplar estas funciones y permitir que capas especializadas desempeñen su labor mejor de lo que podría hacerlo una blockchain de propósito general.

![Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?](https://netts.io/blog/images/body/d493cade35e01363c473dc952a4aa7728d3e4dfb-969.webp)

Las actualizaciones centradas en rollups de Ethereum constituyen el ejemplo más destacado de este enfoque, donde la liquidación y la seguridad son provistas por la mainnet de Ethereum, mientras que el entorno de ejecución se despliega por separado en forma de diversos rollups. La reciente actualización Dencun, que introdujo el blobspace, es otro claro ejemplo: permitió que los rollups publiquen sus datos de forma más económica, lo que a su vez hace que las aplicaciones que utilizan estos rollups resulten más accesibles para los usuarios.

Celestia es un protocolo experimental de blockchain modular que también tiene como objetivo proporcionar una capa de liquidación independiente del entorno de ejecución. Es similar a Ethereum en muchos aspectos, pero intenta ser más generalizada y liviana: los rollups de ejecución pueden utilizar su capa de disponibilidad de datos sin adoptar los mecanismos de liquidación y consenso de Ethereum. Celestia recurre al muestreo de disponibilidad de datos para permitir que los nodos ligeros verifiquen que la información se haya publicado correctamente sin necesidad de descargar toda la cadena. Todo el ecosistema que lo rodea es igualmente modular: los frameworks de rollups, las capas de publicación de datos y otras herramientas de infraestructura se construyen por separado, pero interoperan con la cadena base. La demanda existe, pero Celestia aún está dando sus primeros pasos, al igual que muchas otras blockchains modulares.

EigenDA es una capa de disponibilidad de datos construida sobre EigenLayer, que permite a los rollups basados en Ethereum aprovechar la seguridad del Ether en restaking de EigenDA en lugar de proteger sus propias cadenas de disponibilidad de datos. Avail, el antiguo proyecto de Polygon convertido en una capa de disponibilidad de datos independiente, es otro competidor que promete disponibilidad de datos agnóstica respecto a la cadena con verificación de clientes ligeros e interoperabilidad. Todas estas son ideas interesantes que buscan desacoplar la disponibilidad de datos de la liquidación y la ejecución, permitiendo que los rollups sean más ligeros y especializados.

![Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?](https://netts.io/blog/images/body/fc5d02b7525e54517b774df4f5de08281385f066-1187.webp)

Para los desarrolladores, el atractivo de las blockchains modulares es evidente. En lugar de construir todo desde cero, pueden utilizar un framework específico o un conjunto de componentes modulares consolidados para crear su cadena. OP Stack, Arbitrum Orbit, ZK Stack, Polygon CDK, Agglayer CDK, Rollkit y diversas soluciones de rollup-as-a-service permiten a los desarrolladores diseñar el entorno de ejecución de su preferencia apoyándose en supuestos de seguridad bien establecidos. En lugar de desplegar una capa de liquidación completa con validadores, un puente, un mecanismo de consenso y un conjunto de contratos inteligentes, un equipo puede lanzar un optimistic rollup o un zk-rollup con una configuración de confianza y dejarlo listo en cuestión de semanas. En lugar de construir una capa de disponibilidad de datos, un rollup puede alquilar espacio en Ethereum o en otra cadena a través de EigenDA o Celestia.

Para los usuarios, los beneficios resultan más difíciles de percibir. Una aplicación más económica basada en rollups es mejor que nada, pero la verdadera promesa de las blockchains modulares radica en la especialización. Las capas de liquidación y disponibilidad de datos pueden optimizarse para ofrecer simplicidad y seguridad, los rollups de ejecución pueden aprovechar las herramientas provistas por su framework predilecto, y las blockchains para aplicaciones específicas pueden ofrecer transacciones más económicas y una mejor UX que las cadenas genéricas. Todo esto suena muy convincente en teoría, pero la atractiva propuesta que ofrece tanto a desarrolladores como a usuarios también representa una amenaza: un desafío directo al dominio de las blockchains monolíticas.

## El problema de la armadura

El problema surge cuando la modularidad deja de ser una decisión de arquitectura para convertirse en una moda. Nadie está más seguro simplemente porque sus diagramas tengan más casillas. Alrededor de cada límite entre casillas debe haber supuestos, cada mensaje entre capas debe ser verificado, cada puente debe diseñarse bajo un modelo de confianza, cada secuenciador debe someterse a revisiones de actividad (liveness), cada capa de disponibilidad de datos debe ser inspeccionada en busca de muestreos u operadores honestos, cada vía de actualización debe someterse a gobernanza y cada dependencia externa representa algo susceptible de fallar mientras la aplicación afirma ser segura.

![Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?](https://netts.io/blog/images/body/2ca5a769b20a9c796a4e4bc5ca68794f78cfcacc-965.webp)

Los hackers en cripto descubrieron hace tiempo que el punto ideal para atacar un sistema rara vez es su núcleo, sino sus extremidades: el puente, el oráculo, el conjunto de validadores, la clave de actualización, el firmante off-chain o ese pequeño contrato auxiliar que nadie creía relevante. Basta con observar el desastroso compromiso de claves de validadores en Ronin, el fraude de wrapping en Wormhole o el exploit de retiros en el puente de Nomad, junto con los miles de millones de dólares en valor sustraídos en estos incidentes. El costo de cada uno se minimizó por diseño, pero el daño se perpetró en el punto de menor seguridad: el eslabón más débil de la cadena.

Aquí es donde entra en juego la armadura medieval. La cota de malla, las placas, el cuero, el acolchado y otras formas de defensa se combinaban antiguamente en un conjunto mixto para permitir la máxima libertad de movimiento manteniendo un nivel razonable de protección. Cada elemento podía sustituirse, mejorarse o repararse; sin embargo, las uniones entre los diferentes tipos de protección siempre fueron puntos vulnerables aprovechados por rivales decididos. No fue un único eslabón debilitado lo que acabó con los caballeros a caballo, sino sus correas. Sus axilas, sus visores, sus ingles, sus rodillas, sus codos: zonas que no estaban preparadas para repeler una lanza y terminaron convirtiéndose en vías claras de entrada para el ataque.

Las innovaciones posteriores en el diseño de armaduras buscaron reducir estos puntos vulnerables logrando una mayor integración en todo el conjunto: una coraza, un yelmo cerrado, placas más estratégicas y articulaciones reforzadas. El método anterior no tenía nada de malo, pero el enemigo no era tonto y dejó de apuntar a la correa del caballero. Un sistema modular es tan sólido como su dependencia más vulnerable, y cuantas más dependencias existan, mayor será la probabilidad de que una de ellas falle.

Este es el estándar con el que deben medirse las blockchains modulares. Un diseño modular resulta ventajoso cuando cada capa se diseña teniendo presente la amenaza que enfrenta el sistema en su conjunto, pero se vuelve peligroso cuando sus elementos individuales pasan a ser el mínimo común denominador de la seguridad. Cuando alguien está atacando su secuenciador, lo último que desea recordar es que su capa de datos o su cadena de liquidación dependen de un contrato multifirma o de un operador de nodos externo.

Esto no significa que las cadenas monolíticas sean intrínsecamente superiores a las modulares. Una blockchain integrada única conlleva sus propios riesgos, vectores de ataque, cuellos de botella y puntos de falla; basta con ver los crecientes desafíos de seguridad en Solana, Ethereum, Bitcoin y otros grandes ecosistemas. Sin embargo, un monolito presenta una superficie más sencilla de atacar y defender, con un menor riesgo general que la alternativa. De igual modo, una infraestructura modular puede brindar mayor escalabilidad, flexibilidad y margen de experimentación, pero a expensas de una mayor complejidad y de asumir supuestos de confianza adicionales.

## El problema de la experiencia de usuario (UX)

La debilidad del enfoque modular tiende a reflejarse en la experiencia del usuario. Si la capa de ejecución funciona bien pero la de datos no está disponible, o si el secuenciador está pausado pero la cadena de liquidación sigue activa, o si el puente está deshabilitado temporalmente debido a un incidente, ¿cómo se supone que lo sabrá el usuario? De por sí, no suele estar familiarizado con la distinción entre liquidación y ejecución, y mucho menos con las sutiles diferencias entre los esquemas de disponibilidad de datos y sus efectos sobre la operatividad del sistema. Para él, sencillamente, la blockchain está caída, y punto.

Las interrupciones en los rollups representan el ejemplo más claro de este problema. Base, una de las soluciones de capa 2 más populares de Ethereum, sufrió una pausa en su cadena durante 33 minutos debido a un problema en la conmutación por error (failover) del secuenciador. Para fortuna de sus usuarios, los fondos nunca estuvieron inaccesibles durante el incidente, pero el evento dejó una valiosa lección. Todo el ecosistema de Ethereum se sustenta en la seguridad de liquidación que provee su red principal, pero eso no garantiza que no se produzcan interrupciones específicas en los rollups.

![Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?](https://netts.io/blog/images/body/92651d4d3dda727bff6559557ff171551eb5271b-1281.webp)

Otro ejemplo puede apreciarse en la reciente interrupción del secuenciador de Linea tras el exploit de Velocore. A raíz del ataque, el equipo de Linea activó una pausa que impidió el retiro de fondos de los usuarios. Aunque sin duda se trató del mal menor bajo esas circunstancias, pone de relieve el riesgo latente a nivel de UX que entraña un diseño modular. Dicha pausa implicó que los usuarios de la cadena compatible con Ethereum de Linea no pudieran acceder a sus activos, a pesar de estar respaldados por la seguridad de Ethereum. Además, sirvió como un crudo recordatorio de que muchos rollups aún conservan un control operativo centralizado o semicentralizado sobre sus cadenas.

En la actualidad, el sector de los rollups se caracteriza por una proliferación de opciones de disponibilidad de datos. Diversas blockchains modulares ofrecen la posibilidad de elegir entre proveedores de rollup-as-a-service, Celestia DA, EigenDA, Avail, el blobspace de Ethereum y otras alternativas. Ciertas cadenas, tales como Base, Arbitrum Nova, Linea o Scroll, entre otras, están construidas sobre cadenas de liquidación ya existentes de Ethereum y utilizan sus soluciones de disponibilidad de datos. Mientras tanto, Optimism se prepara para lanzar su propia Superchain, la cual unificará múltiples cadenas OP bajo una capa de liquidación compartida.

Elegir entre estas opciones rara vez resulta trivial y casi nunca se hace sin evaluar detalles técnicos específicos. En la práctica, muchos usuarios simplemente buscan que sus transacciones sean económicas y veloces. No quieren preocuparse por las diferencias entre blobs y calldata, o entre cadenas de capa 2 y su liquidación en la capa 1. Cuando se trata de la UX en cripto, «modular» suele equivaler a «económico», y el público para ello es sumamente amplio.

Por otra parte, cada cadena construida encima de otra introduce riesgos adicionales. Los puentes de Ethereum han sido un blanco constante de ataques este año, y resulta lógico anticipar que los problemas en rollups específicos seguirán la misma tendencia. Cuantas más capas medien entre los fondos de un usuario y la liquidación definitiva, mayor será la cantidad de cosas que pueden fallar al mismo tiempo. Aunque se argumente que el modelo de amenazas de una caída en un rollup no es tan severo como el de los puentes, no ocurre lo mismo con el diseño de la experiencia de usuario. El mismo usuario que no distinguiría entre Ethereum, Arbitrum Nova, Linea o Base tampoco notará cuándo una de estas cadenas ha sido «pausada por motivos de seguridad».

No es únicamente el usuario individual quien debe lidiar con la complejidad del diseño modular. La seguridad de los contratos inteligentes ya es bastante exigente de por sí, pero auditar una pila modular se asemeja a escalar una montaña. Es necesario revisar no solo el contrato objetivo, sino todo el código complementario, los supuestos, las dependencias y las herramientas que componen el sistema. Cualquiera de estos componentes puede fallar de forma inesperada, y la interacción entre ellos pocas veces es intuitiva. A un atacante le basta con hallar una sola vulnerabilidad en un contrato inteligente o una debilidad en un puente para que su ataque prospere.

La respuesta de la industria ante este desafío no se ha hecho esperar: mayor rigor, mejores herramientas y un diseño más refinado. Puentes optimizados con verificación mediante clientes ligeros. Pruebas de conocimiento cero y firmas basadas en umbrales (threshold signatures). Límites de tasa y disyuntores (circuit breakers). Secuenciadores y cadenas de liquidación descentralizados. Verificación formal, monitoreo constante y una UX orientada al usuario pensada para aclarar el panorama a quienes queden desconcertados. La tensión en el seno del ecosistema modular impulsa la innovación en todos los frentes, desde las capas técnicas más bajas hasta la cima.

## Compromisos, no una salvación

El software gira siempre en torno a concesiones y compromisos. Algunos saltan a la vista, otros quedan sepultados bajo páginas de documentación y lenguaje técnico. Algunos vienen de la mano de cada gran avance en el sector, como las decisiones de diseño que dan forma a la EVM de Ethereum. Las blockchains modulares no son la excepción: prometen flexibilidad y experimentación sin librarse de la carga que supone una mayor complejidad. Las cadenas modulares sacrifican la relativa simplicidad técnica de un sistema de una sola cadena a cambio de oportunidades de optimización. Renuncian a garantías de seguridad directas y simples a cambio de una mayor superficie de ataque. Cambian la congestión de una sola capa de liquidación por la sobrecarga organizativa de múltiples capas de seguridad. Cambian la libertad del desarrollador por descentralización, y el potencial bruto por una mayor responsabilidad.

![Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?](https://netts.io/blog/images/body/dbcacc426f665858bf330db10625a986a1115ef1-703.webp)

Para ciertos equipos, esto las convierte en una alternativa natural. Existen cadenas diseñadas para aplicaciones específicas que se verían favorecidas al no compartir la capa de liquidación con todo el mundo, ya sea por rendimiento o por factores económicos. Hay juegos, aplicaciones con gestión de estado, protocolos de DeFi especializados, cadenas corporativas y entornos de prueba que pueden aprovechar las ventajas de este enfoque flexible. Hay ecosistemas enteros que necesitan levantarse desde cero, y un rollup con datos más económicos y procesamiento rápido constituye un excelente punto de partida.

Para otros equipos, este equilibrio no resulta ni de lejos tan favorable. Si el proyecto no necesita una cadena propia, carece de sentido lanzar una. Si el equipo no se siente seguro al construir un puente, debería evitar hacerlo. Si la organización no es capaz de instruir a sus propios usuarios sobre los riesgos de un diseño modular, difícilmente podrá proteger a sus clientes. Si la descentralización siempre va a quedar postergada para «el futuro», el proyecto no está maduro para ver la luz. La seguridad de una cadena modular es tan confiable como su eslabón más endeble, y si ese eslabón consiste en «la promesa de futuras actualizaciones», ha llegado el momento de replantear el diseño.

La analogía de la época medieval sigue teniendo validez: una armadura modular no era intrínsecamente inferior a cualquier otra. No obstante, una armadura modular mal diseñada quedaba en evidencia con facilidad, pues a menudo dejaba desprotegidas áreas vitales del cuerpo. Lo mismo ocurre con las blockchains modulares: la promesa de «propiedades de seguridad unificadas» carece de peso si cada capa del sistema es apenas suficiente, insegura o no ha sido puesta a prueba.

Las mejores blockchains modulares asumen esta realidad y mitigan estos riesgos al máximo. Comprenden que un diseño verdaderamente seguro oculta la complejidad detrás de una interfaz sólida, del mismo modo que una armadura bien confeccionada es difícil de distinguir a la distancia. Reducen al mínimo los supuestos y las fronteras de confianza, acotan la superficie de ataque y aprovechan la infraestructura de seguridad existente siempre que sea posible. El secuenciamiento se descentraliza, las cadenas de liquidación están probadas en batalla, los puentes se verifican mediante clientes ligeros y los contratos inteligentes se someten a auditorías formales. Cada capa adicional solo se incorpora si cumple una función clara.

En contraste, las peores blockchains modulares aparentan ser mucho mejores de lo que en realidad son. Encubren sus carencias tras declaraciones ambiguas, discursos comerciales de «múltiples capas» y promesas de «flexibilidad». Suman capas de complejidad sin mitigar el riesgo global, anteponiendo la velocidad y la escala a la seguridad. Una cadena construida sobre otra no es inherentemente peor que una independiente, pero siempre resulta más peligrosa si el equipo que la respalda no logra explicar con claridad el porqué. Si el punto más débil de un proyecto es la promesa de lograr la descentralización «algún día», la integridad de todo el sistema corre peligro.

## ¿Vale la pena o no?

Las blockchains modulares brindan a los desarrolladores oportunidades formidables. Cuando se emplean con criterio, sus beneficios son innegables: mayor margen de maniobra y experimentación, reducción de costos y auditorías más accesibles. No cabe duda de que la disputa entre los modelos monolíticos y modulares seguirá marcando el rumbo de este sector durante los próximos años, en tanto ambas partes procuren potenciar los puntos fuertes y mitigar las carencias de sus arquitecturas. Con todo, que estas oportunidades se materialicen dependerá del compromiso y la destreza técnica de cada equipo.

La modularidad posee un atractivo incuestionable. La perspectiva de estructurar un ecosistema completo valiéndose de componentes prediseñados resulta sumamente tentadora. Puede agilizar los tiempos de desarrollo, derribar barreras de entrada y abrir la puerta a un amplio abanico de posibilidades experimentales. Los optimistic rollups de Ethereum ya han ratificado la validez de este camino, y el ecosistema en general asiste hoy a un auténtico estallido de innovación.

Celestia y EigenDA, junto con Avail y el blobspace de Ethereum, apuntan a brindar una flexibilidad superior en disponibilidad de datos a las cadenas de rollups que los integren. OP Stack, Arbitrum Orbit, el CDK y Agglayer de Polygon, el fork de Optimism impulsado por Linea y muchas otras iniciativas buscan reducir las dificultades técnicas para desarrolladores y proyectos, posibilitando el despliegue de cadenas compatibles con Ethereum por cuenta propia. El sector se adentra en una etapa sumamente estimulante a medida que la viabilidad técnica de un horizonte multicadena cobra cada vez más fuerza.

No obstante, ese mismo dinamismo renueva el entusiasmo por otros rumbos. Para ciertos proyectos, el valor que ofrece un planteamiento monolítico sigue siendo determinante. Las cadenas integradas poseen virtudes intrínsecas: brindan mayor sencillez y robustez, a la vez que favorecen la viabilidad en el largo plazo. Quienes recurren a estas plataformas se exponen menos a quedar desorientados por los pormenores técnicos inherentes a la arquitectura modular. Un entorno único, solvente y eficiente suele ser preferible a un ecosistema con tarifas más bajas y ejecuciones veloces pero con un nivel de riesgo sustancialmente mayor. Incluso en la comunidad de desarrolladores de Ethereum, permanecer en la «mainnet» suele considerarse con frecuencia la vía más sensata.

![Blockchains modulares: ¿el sueño de Lego o una pesadilla de integración?](https://netts.io/blog/images/body/27e50b740fd6e286c0cc0fd5c6e53e8be281f463-1440.webp)

Estos mismos criterios se reflejan en las tendencias generales del sector. Las herramientas enfocadas en automatizar las operaciones en la red TRON para empresas experimentan un interés creciente entre aquellos equipos que prefieren no gestionar manualmente su Energy, evitar la administración directa de Smart Mode y Host Mode, o no invertir esfuerzos en el desarrollo de scripts y el manejo de API. Netts Workspace ofrece una interfaz intuitiva que centraliza el alquiler de Energy, Smart Mode y Host Mode, las transacciones en TRON y la administración de Energy, herramientas de monitoreo, análisis de AML y operaciones financieras, permitiendo a las organizaciones recortar gastos al tiempo que minimizan las contingencias propias de los procesos manuales.