---
title: "Arquitectura modular de blockchain"
description: "Guía basada en dependencias para separar ejecución, secuenciación, disponibilidad de datos, consenso, liquidación, pruebas, puentes, gobernanza y archivo."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Arquitectura modular de blockchain

> Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

<a id="answer"></a>

## Respuesta directa

La arquitectura modular de blockchain sirve para analizar cómo reparte un sistema sus responsabilidades; no es una categoría de producto normalizada. La ejecución, el orden de las transacciones, los compromisos de estado, las pruebas o disputas, la publicación de datos y su consenso, la liquidación, los puentes, la gobernanza y el archivo a largo plazo pueden reunirse en un protocolo, distribuirse entre varios sistemas o duplicarse entre proveedores. Una capa puede desempeñar varias funciones y una función puede depender de varias capas.

La pregunta útil no es si un proyecto es «modular», sino qué componente valida cada objeto, quién lo controla, qué ocurre si se detiene y cómo puede un usuario recuperar de forma independiente el estado o sus activos. Un recibo del secuenciador no acredita disponibilidad de datos ni finalidad; una prueba de validez no aporta los datos; un compromiso en la cadena de liquidación no demuestra recuperación permanente; y compartir liquidación no crea componibilidad síncrona entre rollups.

<a id="mechanism"></a>

## Cómo funciona

1. Identifique el sistema desplegado: ID de las cadenas de ejecución y liquidación, versión del protocolo, máquina virtual, contratos, direcciones del puente y de los activos, modalidad de disponibilidad de datos, operadores, administradores y bloque o instante observado. La taxonomía comercial no sustituye la configuración desplegada.
2. Construya una matriz de responsabilidades. Separe entrada y secuenciación de transacciones, ejecución determinista, compromiso de estado y prueba o disputa, publicación DA y su consenso, aceptación y finalidad de la liquidación, puente y mensajería entre dominios, actualizaciones y pausas, y almacenamiento histórico. Registre los solapamientos sin forzar cada función dentro de una única capa.
3. Siga una transacción y su batch de extremo a extremo: entrada firmada, recibo local o del secuenciador, ejecución ordenada, batch codificado y comprimido, publicación mediante calldata, blob o DA externa, reclamación de estado y prueba o disputa, finalidad de la liquidación y, después, ejecución del mensaje o retiro. Conserve hashes, versiones, recibos y relojes en cada frontera.
4. Determine el objeto verificado y el supuesto de confianza de cada etapa. Distinga el compromiso de datos de los bytes, la disponibilidad durante la ventana del protocolo de la recuperación posterior, la validez de ejecución de la finalidad del consenso y la contabilidad del puente de la liquidez del activo. Indique quién puede reproducir, probar, impugnar, censurar, actualizar, pausar o retener cada objeto.
5. Reconstruya el libro de capacidad y costes. Mida bytes brutos y comprimidos, ocupación del batch, precio DA, costes de prueba y liquidación, comisiones de ejecución y operador, gas del puente y comisiones de liquidez. La asignación media del batch no equivale al cargo real de un usuario ni al coste marginal de otra transacción.
6. Ensaye fallos en lugar de leer solo el rendimiento normal. Detenga secuenciador, publicador de batches, prover, challenger, servicio DA, RPC de liquidación y relayer del puente; pruebe inclusión forzada, derivación independiente, reconstrucción de datos, prueba o impugnación, reintento, salida y recuperación archivística bajo congestión y cambios de versión.
7. Concilie con evidencia canónica. Relacione recibos de ejecución y raíces de estado con compromisos del batch, inclusión DA, estado de la prueba o disputa, finalidad de la liquidación, mensajes del puente y saldos finales. Repita la revisión tras una reorganización, cambio de parámetros, actualización contractual o migración DA.

<a id="example"></a>

## Ejemplos desarrollados

- **Coste y compresión de un batch.** Un batch contiene `5,000` transacciones, `2,400 KB` de entradas brutas y `300 KB` tras comprimir. La razón de compresión es `2,400 / 300 = 8.0x` y los bytes disminuyen un `87.5%`. Si DA cuesta `0.020 ETH` y la prueba compartida más la liquidación cuestan `0.005 ETH`, el coste medio compartido es `(0.020 + 0.005) / 5,000 = 0.000005 ETH/tx`. Al sumar `0.000020 ETH/tx` por ejecución y operación se obtiene `0.000025 ETH/tx`. Es una asignación, no una factura garantizada.
- **Límite de un modelo de muestreo.** En un modelo didáctico, un adversario retiene el `25%` de los fragmentos y un cliente toma `20` muestras uniformes independientes con reemplazo. La probabilidad de no detectar ningún fragmento retenido es `0.75^20 = 0.003171211939 = 0.3171211939%`; la probabilidad de detección es `99.6828788061%`. Peers correlacionados, servicio adaptativo, codificación de borrado y las reglas reales de muestreo pueden invalidar este modelo sencillo.
- **Seguridad y disponibilidad de un comité.** Un comité DA `5-of-7` puede formar una nueva atestación de umbral con un máximo de `2` miembros no disponibles; con `3` ausentes solo quedan `4 < 5`. Bajo una regla didáctica basada únicamente en firmas, controlar `5` firmantes autorizados permite satisfacer el umbral. El certificado no demuestra que existan cinco copias duraderas, que el usuario pueda recuperar ahora los bytes ni que ejecución y liquidación sean válidas.
- **Varios relojes y una salida rápida.** Una soft confirmation didáctica llega en `2 seconds`, el batch se publica tras `8 minutes` y la finalidad de liquidación llega `13 minutes` después: el tiempo exacto es `21 minutes 2 seconds`. Si un retiro optimista añade unos hipotéticos `7 days`, el total es `10,101 minutes 2 seconds`. Un puente rápido que cobra `0.15%` sobre `10,000 USDC` retiene `15 USDC` y entrega `9,985 USDC`; la rapidez añade supuestos sobre puente, proveedor de liquidez y reorganización, no acorta el reloj del protocolo.

<a id="risks"></a>

## Riesgos

- Identificar mal las responsabilidades o fronteras reales.
- Censura, reordenación o caída del secuenciador.
- Inclusión forzada inexistente, autorizada o demasiado lenta.
- Caída del publicador de batches o proponente de estado.
- Fallo de un prover centralizado o acumulación de pruebas.
- Ausencia de un challenger activo, habilitado o financiado.
- Fallo del reloj, bond, oracle o verificador del fault game.
- Error en el circuito de validez, sistema de pruebas o clave de verificación.
- Retención de datos durante la ventana DA exigida.
- Muestreo correlacionado, ataque eclipse o fallo de vista de red.
- Colusión de umbral o compromiso de claves del comité DA.
- Datos disponibles para el protocolo sin archivos independientes duraderos.
- Reorganización de la liquidación o clasificación errónea de la finalidad.
- Fallo del puente, messenger, protección contra replay o ejecución de destino.
- Insolvencia, falta de inventario o precio adverso de un puente rápido.
- Compromiso de administradores, multisig o consejo de seguridad.
- Actualización inmediata, versión incompatible o demora de escape insuficiente.
- Aumento de costes DA, congestión de blobs, batches menores o fin de subsidios.
- Discordancia entre estado, datos, prueba, contrato o versión del cliente.
- Orden asíncrono entre dominios, ejecución parcial o fallo de componibilidad.

<a id="misconceptions"></a>

## Conceptos erróneos habituales

- Una arquitectura modular es automáticamente más descentralizada que una monolítica.
- Una prueba de validez sustituye la disponibilidad y la recuperación histórica de datos.
- Liquidar en Ethereum incorpora todas las propiedades de seguridad de Ethereum a cada componente.
- Un mensaje de éxito del secuenciador significa liquidación final y retiro ejecutable.
- Un TPS mayor, DA compartida o liquidación compartida garantizan costes menores y componibilidad síncrona.

<a id="related"></a>

## Temas relacionados

- [Capa 2](/es/crypto/layer2/)
- [Disponibilidad de datos](/es/crypto/data-availability/)
- [Rollups](/es/crypto/rollup/)

<a id="sources"></a>

## Fuentes

- [Scaling](https://ethereum.org/developers/docs/scaling/) - Ethereum.org (consultado: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (consultado: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultado: 2026-08-13)
- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (consultado: 2026-08-13)
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consultado: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (consultado: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (consultado: 2026-08-13)
- [LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts](https://arxiv.org/abs/1905.09274) - arXiv (consultado: 2026-08-13)

Source: https://wiki.fcontext.com/es/crypto/modular-blockchain/index.mdx