¿Qué es una blockchain modular? Rollups, disponibilidad de datos y la nueva pila.

Durante años, una cadena de bloques era una sola cadena que lo hacía todo. La tesis modular divide esto en capas especializadas para ejecución, liquidación, consenso y disponibilidad de datos. Esta guía explica el nuevo stack, por qué los rollups necesitan una capa de datos, y qué aporta y cuesta el diseño.

Resumen

  • Las cadenas de bloques modulares dividen la ejecución, liquidación, consenso y disponibilidad de datos entre capas especializadas para mejorar la escalabilidad.
  • Los rollups procesan transacciones fuera de la cadena principal mientras dependen de capas compartidas de liquidación y disponibilidad de datos para la seguridad.
  • El enfoque modular aumenta la flexibilidad y el rendimiento, pero también introduce complejidad adicional, fragmentación y supuestos de confianza en capas.

Tabla de Contenidos

  • Los cuatro trabajos de una cadena de bloques
  • Monolítico versus modular
  • Rollups: la capa de ejecución del mundo modular
  • Disponibilidad de datos: el eje central
  • Los stacks modulares líderes
  • Una analogía: el restaurante y el patio de comidas
  • Lo que la modularidad te compra
  • Las compensaciones y críticas
  • Preguntas Frecuentes Una cadena de bloques modular es una cadena de bloques que divide los trabajos centrales que una red debe realizar entre capas separadas y especializadas, en lugar de que una sola cadena los haga todos a la vez. Para ver por qué esto es una idea significativa, debes conocer los cuatro trabajos que toda cadena de bloques debe manejar: ejecución, que significa ejecutar transacciones y contratos inteligentes; liquidación, que significa finalizar resultados y resolver disputas; consenso, que significa acordar el orden de las transacciones; y disponibilidad de datos, que significa asegurarse de que los datos de las transacciones se publiquen para que cualquiera pueda verificarlos.

Una cadena de bloques tradicional, ahora llamada monolítica, hace las cuatro por sí misma, en una sola cadena, lo cual es simple y está estrechamente integrado, pero se topa con un límite duro en cuánto puede escalar, porque una cadena que lo hace todo solo puede ir tan rápido antes de congestionarse o volverse costosa. El enfoque modular desagrupa esos trabajos, permitiendo que diferentes capas se especialicen en uno de ellos, y esa desagrupación se ha convertido en la forma dominante en que las cadenas de bloques ambiciosas escalan ahora. Esta guía explica las cuatro funciones, la diferencia entre diseños monolíticos y modulares, cómo encajan los rollups y las capas de disponibilidad de datos, los ejemplos principales, y las verdaderas compensaciones que implica el camino modular.

La razón por la que esto importa es que la escalabilidad ha sido el desafío definitorio de las cadenas de bloques durante una década, capturado en el llamado trilema, la observación de que una sola cadena lucha por ser simultáneamente escalable, segura y descentralizada, y generalmente tiene que sacrificar una. Las cadenas monolíticas tienden a presionar fuerte por la escala a costa de cierta descentralización, o preservar la descentralización a costa de la velocidad.

La tesis modular ofrece una salida diferente al trilema: si ninguna cadena individual tiene que hacerlo todo, entonces cada capa puede optimizarse para su propio trabajo, y el sistema en su conjunto puede alcanzar una escala que ninguna cadena monolítica iguala fácilmente, mientras preserva una seguridad y descentralización sólidas donde importa.

Para 2026, esta tesis pasó de la teoría a la arquitectura dominante, con redes especializadas de disponibilidad de datos sirviendo a docenas de cadenas de ejecución y todo un stack de componentes modulares en producción. Entender el diseño modular está, por lo tanto, cerca de entender hacia dónde se dirige la infraestructura de las cadenas de bloques en su conjunto.

Los cuatro trabajos de una cadena de bloques

Todo sobre la modularidad se deduce de comprender las cuatro funciones que realiza una cadena de bloques, por lo que vale la pena tomar cada una por turno. La ejecución es el cómputo real: cuando intercambias tokens o ejecutas un contrato inteligente, la ejecución es el proceso de tomar tu transacción, aplicarla y actualizar el estado de la red para reflejar los nuevos saldos. Es la capa con la que los usuarios interactúan más directamente, y es computacionalmente pesada, porque cada transacción debe ser procesada. La liquidación es la capa que proporciona finalidad y un hogar para la resolución de disputas: es donde los resultados de la ejecución se anclan y se vuelven autoritativos, el fundamento que otras capas pueden tratar como la palabra final sobre lo que sucedió, y donde, en algunos diseños, se verifican pruebas o se impugnan reclamos fraudulentos.

El consenso es el mecanismo mediante el cual los participantes de la red acuerdan un historial único y ordenado de transacciones, de modo que todos compartan la misma vista de lo que sucedió y en qué secuencia, lo que detiene el doble gasto y mantiene el libro mayor consistente. La disponibilidad de datos es la que la mayoría de la gente nunca ha oído mencionar y la que resulta ser central en el diseño modular. Es la garantía de que los datos detrás de cada transacción se publiquen y sean obtenibles, para que cualquiera pueda descargarlos, verificar que se siguieron las reglas y reconstruir el estado si es necesario. Si los datos de las transacciones no están disponibles, nadie puede verificar si la red hizo trampa, lo que significa que la disponibilidad de datos es un fundamento silencioso pero esencial de la confianza. En una cadena monolítica, estos cuatro trabajos ocurren juntos en un sistema estrechamente unido. La percepción modular es que no tienen por qué ser así, y que separarlos permite que cada uno se haga mucho mejor.

Monolítico versus modular

La forma más clara de entender la modularidad es contrastarla directamente con el modelo monolítico del que se separa. Una cadena de bloques monolítica agrupa las cuatro funciones en una sola cadena integrada. Cada nodo completo ejecuta cada transacción, participa en el consenso, almacena todos los datos y trata la cadena misma como la capa de liquidación. La gran virtud de este diseño es la simplicidad y la integración estrecha: todo vive en un solo lugar, las aplicaciones pueden interactuar sin problemas y no hay costuras entre capas que gestionar.

Una conocida cadena de alto rendimiento que valora la velocidad bruta ejemplifica el enfoque monolítico, empujando una sola cadena integrada a procesar un rendimiento enorme al exigir hardware potente a sus nodos. El costo del diseño monolítico es el techo que impone: porque cada nodo debe hacerlo todo, la cadena solo puede escalar hasta cierto punto antes de que las tarifas aumenten, se produzca congestión o los requisitos de hardware se vuelvan tan pesados que menos participantes puedan ejecutar un nodo, lo que erosiona la descentralización.

Una cadena de bloques modular rompe el paquete para que diferentes capas manejen diferentes trabajos. Un arreglo moderno típico separa la ejecución del resto: capas especializadas de ejecución ejecutan las transacciones y contratos inteligentes, mientras que una o más capas diferentes manejan la liquidación, el consenso y la disponibilidad de datos. El ejemplo emblemático es el diseño centrado en rollups, donde cadenas de ejecución ligeras llamadas rollups procesan transacciones al margen y luego se apoyan en una capa base robusta para la liquidación y la disponibilidad de datos.

El beneficio es la especialización: una capa de ejecución puede ajustarse puramente para un procesamiento de transacciones rápido y barato sin tener que soportar todo el peso de asegurar todo el sistema, porque toma prestada la seguridad de la capa base subyacente. El sistema en su conjunto puede entonces escalar agregando muchas capas de ejecución sobre una base compartida, multiplicando la capacidad de una manera que una sola cadena monolítica no puede. Monolítico favorece la integración y la simplicidad; modular favorece la especialización y la escala, y ese es el núcleo de la elección de diseño.

Rollups: la capa de ejecución del mundo modular

El componente modular más importante de entender es el rollup, porque los rollups son cómo la visión modular se usa realmente hoy. Un rollup es una cadena separada que maneja la ejecución, procesando transacciones de manera rápida y barata fuera de la cadena principal, y luego publica un registro comprimido de lo que hizo de vuelta a una capa base para seguridad. El nombre proviene de la forma en que agrupa muchas transacciones en un solo lote y envía ese lote a la cadena base, para que la cadena base no tenga que procesar cada transacción individualmente, pero aún pueda servir como la fuente última de verdad. Este es el mecanismo que permite que un sistema modular escale: miles de transacciones ocurren de forma barata en el rollup, y solo un resumen condensado toca la costosa y altamente segura capa base.

Hay dos familias principales de rollups, distinguidas por cómo convencen a la capa base de que sus transacciones por lotes son válidas. Los rollups optimistas asumen que las transacciones son honestas por defecto y permiten una ventana durante la cual cualquiera puede impugnar un lote fraudulento presentando una prueba de fraude, con la capa base resolviendo la disputa. Los rollups de conocimiento cero, en cambio, generan una prueba criptográfica de validez para cada lote, mostrando matemáticamente que las transacciones se procesaron correctamente, que la capa base verifica sin volver a ejecutarlas.

Ambos logran el mismo objetivo de heredar la seguridad de la capa base mientras realizan la ejecución en otro lugar, y ambos dependen críticamente de una cosa: los datos detrás de sus transacciones deben estar disponibles, para que cualquiera pueda verificar las afirmaciones del rollup o reconstruir su estado. Un rollup que publicara solo un resumen sin poner los datos subyacentes a disposición estaría pidiendo al mundo que confiara ciegamente en él, lo que va en contra del propósito. Esta es exactamente la razón por la que la disponibilidad de datos, la oscura cuarta función, se convierte en el eje central de toda la arquitectura modular.

Disponibilidad de datos: el eje central

La disponibilidad de datos merece su propia sección porque es la función que el diseño modular elevó de una ocurrencia tardía a una pieza central. Cuando un rollup publica su lote de transacciones, el requisito crucial es que los datos completos de la transacción se publiquen en algún lugar accesible, para que cualquiera pueda verificar que el rollup hizo su trabajo honestamente, impugnarlo si no es así y reconstruir el estado si el operador del rollup desaparece.

Dónde se publican esos datos y a qué precio resulta ser uno de los factores más importantes en el rendimiento de un sistema modular, porque publicar datos es una parte importante de lo que paga un rollup. Si la capa base hace que la publicación de datos sea costosa, los rollups son costosos; si una capa lo hace barato, los rollups se vuelven drásticamente más baratos.

Esto creó demanda por un nuevo tipo de cadena especializada cuyo único trabajo es la disponibilidad de datos: una capa de disponibilidad de datos. En lugar de ejecutar transacciones o resolver disputas, dicha cadena existe puramente para ordenar datos y mantenerlos disponibles de forma barata y confiable para los rollups que dependen de ella. El ejemplo pionero es una red construida específicamente como una capa modular de disponibilidad de datos, que utiliza una técnica elegante llamada muestreo de disponibilidad de datos para escalar. En lugar de exigir que cada nodo descargue un bloque completo para confirmar que los datos están ahí, los nodos ligeros toman aleatoriamente una pequeña cantidad de piezas del bloque.

Con suficientes muestras independientes, la red puede estar segura, con una probabilidad muy alta, de que todos los datos están genuinamente disponibles, sin que nadie tenga que descargarlos todos. Combinado con técnicas que permiten que cada aplicación obtenga solo su propia porción de datos, esto permite que una capa de disponibilidad de datos sirva a muchos rollups a la vez, de forma barata y a escala. Para 2026, dicha capa estaba proporcionando disponibilidad de datos para docenas de rollups, una señal concreta de que la separación modular de la disponibilidad de datos en su propia red especializada se había convertido en una infraestructura real y funcional.

Los stacks modulares líderes

Ayuda ver cómo estas piezas se ensamblan en sistemas reales, porque el mundo modular no es un solo diseño, sino algunos stacks competidores y complementarios. El más influyente es la hoja de ruta centrada en rollups de la plataforma de contratos inteligentes líder, que se reorientó deliberadamente hacia la modularidad. En lugar de intentar escalar haciendo que su propia capa base procese todo más rápido, eligió convertirse principalmente en una base de liquidación y disponibilidad de datos, con la ejecución pesada externalizada a un ecosistema próspero de rollups construidos sobre ella.

Una actualización fundamental introdujo un espacio dedicado y más barato para que los rollups publiquen sus datos, a menudo llamado espacio blob, que redujo drásticamente el costo de la disponibilidad de datos y, con él, las tarifas que los rollups cobran a los usuarios, llevando muchas transacciones a fracciones de centavo. Actualizaciones adicionales buscan expandir esa capacidad de datos dramáticamente con el tiempo. El resultado es un sistema en capas: una capa base segura para liquidación y datos, y muchos rollups centrados en la ejecución manejando la actividad diaria de forma barata sobre ella.

Junto a esto se encuentra el enfoque de capa de disponibilidad de datos especializada, donde los rollups eligen publicar sus datos en una red de disponibilidad de datos creada para ese propósito en lugar de, o además de, la capa base de liquidación, a menudo para obtener costos aún más bajos. También hay una conexión con otra idea modular cubierta en otro lugar: seguridad compartida a través de restaking, donde un pool de capital apostado puede usarse para asegurar nuevos servicios, incluidas las capas de disponibilidad de datos, permitiéndoles heredar una fuerte seguridad económica desde el primer día en lugar de iniciar la suya propia.

Juntas, estas piezas forman un menú de componentes modulares (capas de liquidación, capas de disponibilidad de datos, rollups de ejecución y proveedores de seguridad compartida) que los equipos pueden mezclar y combinar para ensamblar una cadena personalizada. Un proyecto puede lanzar su propio rollup ajustado para juegos o aplicaciones sociales, apuntarlo a la capa de disponibilidad de datos más barata y liquidar en la capa base que confíe, sin construir un conjunto de validadores ni una cadena monolítica completa desde cero. Esa composabilidad de infraestructura, la capacidad de ensamblar una cadena a partir de partes especializadas, es el beneficio práctico de la tesis modular y una gran razón por la que se extendió tan rápido.

Una analogía: el restaurante y el patio de comidas

Debido a que el stack modular tiene tantas piezas, una analogía puede anclar toda la idea antes de que se acumulen las compensaciones. Piensa en una cadena de bloques monolítica como un solo restaurante que lo hace todo bajo un mismo techo: cultiva sus propios ingredientes, cocina cada plato, sienta a los comensales y lava los platos, todo con el mismo personal en el mismo edificio. La ventaja es una coordinación perfecta, ya que todo sucede en un solo lugar y nada tiene que ser transferido. La limitación es la capacidad: esa única cocina solo puede cocinar tantas comidas a la vez, y si quieres servir a muchas más personas, o construyes una cocina enorme y costosa que pocos pueden equipar, o aceptas largas esperas y precios altos cuando la demanda aumenta. Una cadena integrada única enfrenta el mismo techo, porque cada nodo tiene que hacer cada trabajo.

Ahora imagina un patio de comidas. El edificio proporciona la base compartida, las mesas, la seguridad, la garantía de que el espacio permanezca abierto y ordenado, mientras que muchos vendedores especializados se encargan de la cocina, cada uno centrado en una cocina y ajustado para servir a sus clientes de forma rápida y barata. En esta imagen, el edificio compartido es la capa base que proporciona liquidación y disponibilidad de datos, y los vendedores individuales son los rollups que manejan la ejecución.

Ningún vendedor tiene que proporcionar su propia seguridad o construir sus propias instalaciones; todos heredan eso del edificio, por lo que pueden concentrarse puramente en servir comida rápido. El patio de comidas puede servir a muchas más personas que el restaurante único, porque la capacidad crece agregando vendedores en lugar de forzar una sola cocina, que es exactamente cómo un sistema modular escala agregando capas de ejecución sobre una base compartida.

La analogía también captura los costos honestamente. Un patio de comidas es más complejo que un solo restaurante: hay más operadores independientes, más cosas que pueden salir mal con cualquier vendedor, y se requiere más coordinación para mantener el espacio compartido funcionando. Si quieres un plato que combine ingredientes de tres vendedores diferentes, tienes que llevar tu bandeja entre ellos, lo cual es más torpe que pedir todo de una cocina, así como mover activos o componer una aplicación a través de rollups separados es más incómodo que operar dentro de una cadena integrada. Y cada vendedor depende del edificio: si la base compartida falla en mantener las luces encendidas o las puertas abiertas, todos los vendedores sufren, así como un rollup hereda las debilidades de las capas de disponibilidad de datos y liquidación debajo de él.

El patio de comidas intercambia la simplicidad perfecta del restaurante único por una capacidad y especialización mucho mayores, aceptando más complejidad y más transferencias a cambio. Ese es precisamente el trato que hace la cadena de bloques modular, y verlo como un patio de comidas en lugar de un restaurante único hace que tanto el atractivo como el costo sean intuitivos.

Lo que la modularidad te compra

Habiendo expuesto la arquitectura, vale la pena ser precisos sobre las ventajas genuinas que el enfoque modular ofrece, porque explican por qué se volvió dominante. El beneficio principal es la escalabilidad. Al separar la ejecución de la capa base y permitir que muchos rollups se ejecuten en paralelo sobre una base compartida, un sistema modular puede procesar mucha más actividad total que una sola cadena monolítica, porque la capacidad se agrega apilando capas de ejecución en lugar de forzar una cadena. Las capas baratas de disponibilidad de datos amplifican esto al reducir el costo dominante de ejecutar un rollup, que es por lo que las tarifas de transacción en los rollups modernos han caído a fracciones de centavo para transferencias simples.

El segundo beneficio es la especialización y la flexibilidad. Debido a que cada capa se enfoca en un trabajo, cada una puede optimizarse mucho más allá de lo que una cadena generalista podría lograr: una capa de disponibilidad de datos puede ser despiadadamente eficiente en mantener los datos disponibles, un rollup de ejecución puede ajustarse para un caso de uso específico, y una capa de liquidación puede priorizar la seguridad y la finalidad. Esto también les da a los constructores flexibilidad y soberanía: un equipo puede lanzar una cadena adaptada a sus necesidades, eligiendo su propio entorno de ejecución y reglas, mientras aún hereda seguridad y disponibilidad de datos de capas establecidas en lugar de recrearlas.

El tercer beneficio es una mejor descentralización a nivel de verificación. Técnicas como el muestreo de disponibilidad de datos permiten que nodos ligeros verifiquen que una red se está comportando honestamente sin ejecutar hardware costoso, lo que significa que más participantes ordinarios pueden ayudar a mantener honesto el sistema, contrarrestando la tendencia de las cadenas monolíticas de alto rendimiento a concentrar el poder entre aquellos que pueden permitirse máquinas potentes. Escalabilidad, especialización y descentralización verificable son los verdaderos premios por los que compite el diseño modular, y los persigue al negarse a hacer que una sola cadena cargue con todo el peso.

Las compensaciones y críticas

Ninguna arquitectura es gratuita, y un relato honesto de la modularidad tiene que sopesar sus costos reales frente a la simplicidad monolítica que reemplaza. El primer costo es la complejidad. Un sistema modular tiene muchas partes móviles: ejecución en una capa, datos en otra, liquidación en una tercera, puentes y pruebas conectándolos, y esa complejidad crea más superficie para errores, configuraciones incorrectas y fallos que una sola cadena integrada. Más capas significan más cosas que pueden salir mal y más costuras que deben asegurarse. El segundo costo es la fragmentación. Cuando la actividad se extiende a través de muchos rollups separados, la liquidez y los usuarios también se fragmentan, y mover activos o componer aplicaciones a través de diferentes capas de ejecución puede volverse incómodo, lento o arriesgado, sacrificando parte de la composabilidad perfecta que ofrece una sola cadena monolítica, donde cada aplicación puede interactuar con cualquier otra al instante.

El tercer costo es una consideración de seguridad más sutil. La seguridad de un rollup depende de las capas debajo de él, por lo que si la capa de disponibilidad de datos de la que depende falla en mantener los datos disponibles, o la capa de liquidación en la que confía se ve comprometida, el rollup hereda esa debilidad. Los sistemas modulares deben, por lo tanto, razonar cuidadosamente sobre los supuestos de confianza de cada capa de la que dependen, y una cadena que utiliza una capa de disponibilidad de datos menos segura para ahorrar dinero está haciendo una verdadera compensación en seguridad, incluso si no siempre es obvio para los usuarios.

Los defensores del enfoque monolítico argumentan que la integración estrecha proporciona un sistema más simple, más componible y más uniformemente seguro, y que las cadenas monolíticas de alto rendimiento han demostrado que una sola cadena puede escalar más de lo que el campo modular suponía. La conclusión honesta es que monolítico y modular no son estrictamente mejores o peores, sino que representan diferentes apuestas: monolítico apuesta a que la integración y el rendimiento bruto de una sola cadena ganan, mientras que modular apuesta a que la especialización y el apilamiento ganan. Para 2026, la apuesta modular se había convertido claramente en la arquitectura dominante para nueva infraestructura ambiciosa, pero las compensaciones que conlleva, complejidad, fragmentación y confianza en capas, son reales, y el debate sobre qué enfoque prevalece finalmente está lejos de resolverse.

Preguntas Frecuentes

¿Qué es una cadena de bloques modular en términos simples?

Una cadena de bloques modular divide los trabajos centrales que una red debe hacer entre capas separadas y especializadas, en lugar de que una sola cadena lo haga todo. Los cuatro trabajos son ejecución (ejecutar transacciones y contratos inteligentes), liquidación (finalizar resultados y resolver disputas), consenso (acordar el orden de las transacciones) y disponibilidad de datos (asegurarse de que los datos de las transacciones se publiquen para que cualquiera pueda verificarlos). Una cadena tradicional, monolítica, hace los cuatro por sí misma, lo que limita cuánto puede escalar. Un diseño modular permite que cada capa se especialice en un trabajo, por lo que el sistema en su conjunto puede escalar mucho más mientras preserva la seguridad.

¿Cuál es la diferencia entre cadenas de bloques monolíticas y modulares?

Una cadena de bloques monolítica maneja ejecución, liquidación, consenso y disponibilidad de datos todo en una cadena integrada, donde cada nodo hace todo. Es simple y está estrechamente integrada, pero encuentra un límite en la escala, porque una cadena que lo hace todo solo puede ir tan rápido antes de que las tarifas suban o las demandas de hardware reduzcan el conjunto de nodos. Una cadena de bloques modular separa esos trabajos entre capas, típicamente empujando la ejecución a rollups mientras una capa base maneja la liquidación y la disponibilidad de datos. Esto intercambia algo de simplicidad y componibilidad por una escalabilidad y especialización mucho mayores.

¿Qué es un rollup y cómo encaja?

Un rollup es una cadena de ejecución separada que procesa transacciones de forma barata fuera de la cadena principal, y luego publica un lote comprimido de vuelta a una capa base segura para liquidación y disponibilidad de datos. Agrupa muchas transacciones en un solo lote para que la capa base no procese cada una individualmente, pero aún sirva como fuente de verdad. Los rollups optimistas asumen validez y permiten impugnaciones de fraude; los rollups de conocimiento cero envían pruebas criptográficas de validez. Los rollups son cómo la visión modular escala en la práctica, y dependen de que sus datos de transacción estén disponibles para que cualquiera pueda verificarlos.

¿Por qué es tan importante la disponibilidad de datos?

Porque verificar un rollup, o cualquier cadena, requiere que los datos detrás de sus transacciones se publiquen y sean obtenibles. Si los datos no están disponibles, nadie puede verificar si se siguieron las reglas, impugnar fraudes o reconstruir el estado si un operador desaparece. Dónde y a qué precio se publican esos datos es uno de los factores más importantes en el costo de un sistema modular, ya que publicar datos es gran parte de lo que paga un rollup. Esto creó capas especializadas de disponibilidad de datos cuyo único trabajo es mantener los datos disponibles de forma barata, usando técnicas como el muestreo para que nodos ligeros confirmen la disponibilidad sin descargarlo todo.

¿Qué es Celestia y qué hace una capa de disponibilidad de datos?

Una capa de disponibilidad de datos es una cadena especializada cuyo único trabajo es ordenar los datos de las transacciones y mantenerlos disponibles de forma barata y confiable para los rollups que dependen de ella, en lugar de ejecutar transacciones o resolver disputas. El ejemplo pionero fue construido específicamente para este propósito y utiliza muestreo de disponibilidad de datos, donde nodos ligeros verifican aleatoriamente pequeñas piezas de un bloque para que la red pueda estar segura, con alta probabilidad, de que todos los datos están presentes sin que nadie descargue el bloque completo. Para 2026, dicha capa estaba proporcionando disponibilidad de datos para docenas de rollups.

¿Cuáles son las desventajas de las cadenas de bloques modulares?

Tres principales. Complejidad: muchas partes móviles entre capas, más los puentes y pruebas que las conectan, crean más superficie para errores y fallos que una sola cadena integrada. Fragmentación: extender la actividad a través de muchos rollups divide la liquidez y los usuarios, y puede hacer que mover activos o componer aplicaciones entre capas sea incómodo, sacrificando parte de la componibilidad perfecta de una cadena monolítica. Y confianza en capas: la seguridad de un rollup depende de las capas debajo de él, por lo que confiar en una capa de disponibilidad de datos o liquidación más débil para ahorrar dinero introduce verdaderas compensaciones de seguridad. Los defensores monolíticos argumentan que la integración estrecha es más simple y uniformemente segura.

Este artículo es información educativa, no consejo de inversión. Las arquitecturas, proyectos y detalles técnicos de las cadenas de bloques evolucionan rápidamente, y las descripciones aquí reflejan el estado del campo al 25 de junio de 2026. Verifica la información actual de fuentes primarias antes de confiar en cualquier cosa descrita aquí.

Ver original
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
  • Recompensa
  • Comentar
  • Republicar
  • Compartir
Comentar
Añadir un comentario
Añadir un comentario
Sin comentarios
  • Fijado