El corazón palpitante del debate sobre la criptoescala late en la interfaz de las cadenas básicas de Capa 1 y sus homólogas de Capa 2.
El imperativo de la escalabilidad
Desde el primer pico de congestión de Bitcoin en 2017 hasta las tarifas récord de Ethereum durante la manía NFT, el cripto-universo ha luchado con un trilema fundamental: la descentralización, la seguridad y el rendimiento rara vez escalan juntos. Las primeras comunidades toleraban bloques lentos y tarifas elevadas a cambio de resistencia a la censura, pero una vez que surgieron casos de uso generalizado como la facturación de stablecoin, los juegos de blockchain o la financiación del comercio institucional, las brechas en las expectativas se hicieron evidentes.
Las cadenas de bloques de capa 1 (L1) intentaron inicialmente escalar en la cadena de bloques aumentando el tamaño de los bloques o cambiando el consenso, pero cualquier cambio conllevaba el riesgo de debilitar las garantías de seguridad social de la red. Las redes de Capa 2 (L2) surgieron como un compromiso pragmático: alejaban de la capa base los procesos o transiciones de estado intensivos desde el punto de vista computacional, al tiempo que soportaban las pruebas de seguridad de la Capa 1. Con el tiempo, el pensamiento «modular» ha hecho que los protocolos ya no puedan verse como monolitos individuales, sino como componentes apilables: la ejecución, la disponibilidad de datos, la facturación y el consenso pueden tener lugar en distintos niveles.
Desglose de la arquitectura de Capa 1
Consenso, ejecución y disponibilidad de datos
Un L1 moderno se parece a un avión trimotor:
- Elconsenso (Proof of Work, Proof of Stake, PoS delegado, etc.) define el orden de los bloques y las reglas de finalidad.
- La ejecución gestiona las transiciones de estado: contratos inteligentes, saldos de cuentas, lógica programable.
- La disponibilidad de datos garantiza que cada nodo pueda comprobar todo el contenido de los bloques para evitar cambios de estado ocultos.
Los desarrolladores están constantemente haciendo malabarismos con el tamaño de los bloques, la latencia de la transmisión de mensajes y los requisitos del validador. Los bloques grandes mejoran el rendimiento, pero paralizan a los operadores de los nodos de ejecución domésticos; los bloques pequeños garantizan la descentralización, pero reducen la usabilidad.
El nivel económico
Los activos nativos (ETH, SOL, ADA) son el combustible para las recompensas de los validadores y proporcionan presupuestos de seguridad. Los mercados de tarifas surgieron para modular el spam y asignar el escaso espacio de bloques a las transacciones de mayor valor; la quema de la tarifa base en el EIP-1559 fue un momento decisivo que reconfiguró la dinámica de la inflación.
Crecimiento y poda del Estado
Cada operación de escritura de un contrato inteligente añade bytes a la cadena. Sin poda, las cadenas de larga duración se hinchan con terabytes y aumentan los costes de validación. Las actualizaciones meridianas (por ejemplo, los árboles Verkle de Ethereum, los mercados de tarifas locales de Solana) combaten el hinchamiento del estado comprimiendo las pruebas Merkle o desacoplando las cuentas Hot-Path.

Comparación representativa de la Capa 1
| Red L1 | Consenso | TPS medio (mundo real) | Objetivo del bloque | Activo nativo |
|---|---|---|---|---|
| Bitcoin | Prueba de trabajo (SHA-256) | ~7 | 60 min probabilístico | BTC |
| Ethereum (tras la fusión) | Prueba de participación | ~15 | ~15 min justificado finalizado | ETH |
| Solana | Prueba de la historia PoS | ~2,000 | ~400 ms optimista | SOL |
| Aptos | HotStuff BFT PoS | ~600 | ≈1 segundo determinista | APT |
Capa 2: El límite de escala
Las redes de capa 2 trasladan la ejecución de las transacciones conservando el procesamiento de la capa 1, y pueden clasificarse en familias: canales, rollups, validaciones, plasmas y sidechains híbridas. Cada una de estas redes opera en una zona de tensión entre el coste de la disponibilidad de los datos, la latencia de las retiradas y la complejidad de las pruebas.
Canales de pago y estado
Los canales (por ejemplo, Lightning en Bitcoin, Connext en Ethereum) crean libros de contabilidad bilaterales o multilaterales fuera de la cadena en los que los participantes intercambian mensajes firmados. Sólo las obligaciones de apertura y cierre afectan a la cadena básica. Las actualizaciones a lo largo de la cadena son inmediatas y gratuitas, pero los canales requieren capital para permanecer bloqueados y adolecen del hecho de que los grupos de participantes cambian con frecuencia.
Rollups optimistas
Los rollups optimistas como Arbitrum y Optimism agrupan miles de transacciones L2 en blobs de calldata individuales que se envían a L1. Asumen de forma optimista que las transiciones de estado son válidas; cualquiera puede impugnar durante un periodo de impugnación (normalmente 7 días). Las pruebas de fraude invalidan los lotes fraudulentos y vinculan la seguridad a los incentivos de honestidad de L1.
Lotes ZK
Los rollups ZK como zkSync Era, Starknet y Polygon zkEVM generan pruebas concisas de validez de conocimiento-cero (SNARKs/STARKs) que confirman matemáticamente la correcta ejecución. No hay retraso en los litigios; las retiradas se completan en cuanto se supera la comprobación de la prueba en L1. Las desventajas incluyen un hardware Prover pesado y una circuitería compleja.
Validaciones y voliciones
Mientras que los rollups publican datos de transacciones comprimidos en L1, las validaciones almacenan los datos fuera de la cadena, a menudo en Comités de Disponibilidad de Datos (DAC) especiales. Aunque esto reduce los costes de gas, introduce suposiciones de viabilidad sobre las capas de datos externas. Con Volitions, los usuarios pueden elegir, para cada transacción, si pagar por los datos en la cadena o aceptar el almacenamiento en un DAC.
Cuadro comparativo de las principales soluciones de Capa 2
| Proyecto L2 | Tipo | Sistema probado | TPS medio | Fin de propósito en L1 | Ficha de gas nativo |
|---|---|---|---|---|---|
| Arbitrio uno | Rollup optimista | Detección interactiva de fraudes (AVM) | ~45 | 7 días (desafío) | EPF |
| Red central optimista | Rollup optimista | A prueba de errores (Cannon/MIPS) | ~30 | 7 días | ETH |
| era zkSync | ZK rollup | SNARK PLONK recursivo | ~200 | ~10 min (comprobar prueba) | ETH |
| Starknet | ZK rollup | STARK (El Cairo) | ~40 | ~15 min | EPF |
| Polígono zkEVM | ZK rollup | Groth16 SNARK | ~30 | ~30 min | ETH |
Cómo suben y bajan los anclajes de seguridad en la pila
Tendiendo puentes entre paradigmas
Un activo de L2 sólo importa si puede pasar con seguridad a L1 o a otras L2. Los puentes se dividen en distintas categorías:
- Puentes canónicos, gestionados por el equipo secuenciador/cliente de L2.
- Puentes de liquidez externos (Hop, Across) que queman/marcan tokens IOU a través de relés enlazados.
- Puentes ligeros-cliente que comprueban el consenso de la otra parte – con mucho gas, pero cerrados sobre sí mismos.
Saltos multinivel (L2➜L1➜L2) – Hammer UX; los desarrolladores integran enrutadores basados en la intención para abstraer la búsqueda de rutas y el deslizamiento.
Secuenciadores, probadores y programas de descentralización
La mayoría de las hojas de ruta actuales utilizan un único secuenciador de confianza para agregar transacciones; la resistencia a la censura depende de si están descentralizadas. Las hojas de ruta suelen pasar por distintas fases:
- Secuenciador centralizado con prueba de validez de fraude/fallback.
- Secuenciadormúltiple autorizado que funciona en PoA o PoS.
- Secuenciador totalmente no autorizado, posiblemente repartido en varios rollups.
Prover también migra de centros de datos centralizados a pruebas WebAssembly en GPUs de consumo, reduciendo el tiempo de ejecución.

Capas de disponibilidad de datos y «Danksharding
Los rollups pueden comprimir el estado, pero alguien tiene que publicar el blob comprimido. El próximo muestreo de disponibilidad de datos Danksharding de Ethereum (Proto-Danksharding vía EIP-4844) crea un «blobspace» barato, medido en bytes por bloque, no en gas por opcode. Las redes DA independientes – Celestia, Avail, EigenDA – compiten ofreciendo ancho de banda dedicado exclusivamente a la transferencia de datos y redundancia cifrada mediante borrado.
Por qué es importante la DA
Si un secuenciador malintencionado retiene datos, los clientes no pueden recuperar su estado y los fondos quedan congelados. El muestreo de disponibilidad de datos permite a los clientes de Light verificar probabilísticamente los datos masivos descargando partes aleatorias cifradas por borrado. La escalabilidad aumenta considerablemente cuando la AD se desvincula de la ejecución; los rollups pueden aumentar el rendimiento sin inflar la memoria de validación.
MEV y el panorama de la capa 2
El Miner/Maximal Extractable Value (MEV) se produce cuando los promotores de bloques reordenan las transacciones para obtener beneficios. En L2, MEV se manifiesta en dos lugares:
- Dentro del pool de memoria de L2, donde un secuenciador centralizado puede actuar como precursor.
- Durante la contabilización por lotes en L1, donde las reglas de inclusión forzada alinean los incentivos.
Propuestas como las subastas de aumento de tiempo, el burn MEV y los mempools encriptados intentan compensar las ventajas injustas. Los secuenciadores compartidos podrían incluso combinar múltiples rollups en una única subasta, compensando la atomicidad entre dominios.
Ahorro de costes y experiencia del usuario
Composición de tarifas
El gas para el usuario final de una L2 se divide en dos partes:
- Costes deejecución en el nodo L2.
- Costes Calldata L1 amortizados para la contabilidad por lotes.
Los rollups ZK aumentan los costes de ejecución (esto se ha demostrado), pero reducen el tamaño de los calldata; los rollups optimistas siguen siendo baratos de calcular, pero caros en términos de bytes de calldata. EIP-4844 probablemente comprime los calldata entre 10 y 20 veces, restaurando la competitividad.
Innovaciones de UX para los monederos
La abstracción de cuentas (ERC-4337), las claves de sesión y las transacciones patrocinadas desdibujan por completo el modelo de gas. Los monederos dirigen el intercambio de un usuario a través de las rutas L2 más ventajosas, cobran entre bastidores en L1 e incluso pre-firman mensajes en múltiples canales para permitir el pago con un solo clic.
Ecosistema de desarrolladores y cadenas de herramientas
Diversidad lingüística
Solidity sigue siendo dominante, pero los circuitos ZK invitan a DSL como Cairo, Noir, Circom, Leo y Zinc. Las cadenas de herramientas compilan automáticamente Solidity en código de bytes compatible con ZK; mientras tanto, las L2 de Wasm (Aurora de Near, CosmWasm Rollups) abren la puerta a los contratos inteligentes de Rust, Go y AssemblyScript.
Testnets y cultura del grifo
Las robustas redes de desarrollo (Scrolls Alpha, Arbitrum Stylus, Base Sepolia) imitan los perfiles de sobrecarga y los patrones de puente entre rollups. La integración continua utiliza bifurcaciones fantasma de la red principal para ejecutar simuladores difusos y comparar raíces de estado. Los modelos de doble despliegue -un contrato enla red principal, una réplica en L2- son cada vez más populares para las funciones de alto consumo, como la agregación oracular o la divulgación de metadatos NFT.
Compatibilidad entre capas
Composable DeFi fue pionera en la idea de que contratos independientes pudieran interactuar con confianza dentro de un único entorno de ejecución. A medida que las islas se multiplican a través de las L2, el dilema de la fragmentación se resuelve mediante la mensajería entre dominios. Proyectos como LayerZero, Axelar y Wormhole envían VAAs (Verified Action Approvals) firmados que son validados localmente por cadenas y permiten funciones como ésta:
- Intercambios permanentes entre cadenas que contabilizan ganancias y pérdidas directamente en la propia cadena del usuario.
- Cobros NFT unificados que se acuñan en L2, se cobran en L1 y se utilizan en un motor de juego sidechain.
- Propuestas de gobernanza que abarquen varios rollups y desencadenen actualizaciones agrupadas de parámetros.
La latencia y la fiabilidad siguen dependiendo del diseño del relé; la introducción de clientes ligeros de prueba de consenso en la cadena de destino sigue siendo el Santo Grial.
La ética de la modularidad en la práctica
Secuenciadores y capas de liquidación comunes
En lugar de que cada rollup construya su propio conjunto de secuenciadores, las redes de secuenciadores comunes (Astria, Espresso, Radius) prometen un flujo de órdenes atómico entre rollups. Por debajo de la pila, las capas de procesamiento especializadas (por ejemplo, el posicionamiento de Canto como cadena «DAO de procesamiento») se distinguen de las capas DA puras por ofrecer widgets con fines específicos sin sobrecarga de ejecución.
Recuperación y seguridad compartidas
EigenLayer toma ETH para extender las garantías criptoeconómicas a módulos externos – DA, puentes, redes de oráculos. Esto crea un modelo unificado de seguridad como servicio, en el que múltiples L2 o servicios fuera de la cadena acceden a los mismos colaterales acuchillables, reduciendo los incentivos fragmentados de los tokens.
Casos de uso reales que prosperan con L2
Micropagos y streaming de dinero
Plataformas como Audius y Superfluid utilizan flujos de tokens por segundo, económicamente impracticables en L1, pero triviales en L2. Los modelos de suscripción se convierten en flujos continuos que ajustan los ingresos de SaaS al uso real.
Juegos de Blockchain y economías basadas en el botín
Juegos como Illuvium y TreasureDAO utilizan rollups para gestionar los protocolos de combate, la generación de números aleatorios y la minería NFT, mientras revierten a Ethereum a intervalos regulares.
Facturación empresarial y financiación del comercio
Los consorcios utilizan rollups optimistas para la factorización de facturas y conectan sistemas ERP mediante oráculos. Los circuitos ZK de protección de la privacidad retienen datos sensibles de la contraparte y, sin embargo, demuestran la exactitud del pago contra entrega.

El futuro de los diseños por capas
Escalado recursivo
Los rollups son inherentemente apilables: un rollup terciario podría asentarse sobre un L2 común y enviar pruebas de validez al propio Ethereum. Los SNARK recursivos agregan miles de pruebas individuales, aumentando el rendimiento y comprimiendo el gas.
El hardware como cuello de botella
El hardware del verificador está evolucionando de la CPU a la GPU y al ASIC; los equipos están explorando la aceleración FPGA para el hash Poseidon o la aritmética de curva elíptica. Los ordenadores portátiles disponibles en el mercado podrían verificar las pruebas en milisegundos, lo que permitiría una seguridad local de cliente ligero sin necesidad de proveedores RPC centralizados.
Secuenciadores gestionados por la comunidad
Los secuenciadores gestionados por DAO distribuyen los ingresos a los titulares de tokens o stakers para equilibrar los incentivos de la comunidad. Los líderes de una única ubicación gestionados por el segundo y los nodos de supervisión garantizan rutas de escape de la censura.
Esgrima – gratuito pero continuo
El diálogo entre los fundamentos de la Capa 1 y las innovaciones de la Capa 2 está lejos de terminar, pero la arquitectura ya está transformando la experiencia del usuario, las herramientas de desarrollo y la economía de la seguridad de la criptomoneda de formas profundas y mensurables.
