Durante años, casi todas las cadenas públicas y los proyectos modulares han usado la palabra «escalabilidad», rara vez para la misma capa. Los equipos de rollups suelen referirse a mover la ejecución fuera de la mainnet de Ethereum. Los equipos de disponibilidad de datos se refieren a publicar y muestrear más datos de forma barata. Los L1 de ejecución paralela se refieren a repartir el motor de ejecución de una sola cadena entre muchos núcleos. Una sola palabra; supuestos de seguridad, techos y modos de fallo distintos.
Este artículo descompone la escalabilidad en capas que no se solapan, marca dónde se ubican las L2, la hoja de ruta de sharding de Ethereum, la DA independiente y el paralelismo en L1, y responde una pregunta práctica: ¿a qué apunta realmente la EVM paralela en este mapa, a sustituir a los rollups o a complementarlos?
Cuatro tareas primero: consenso, DA, ejecución y liquidación
Una cadena que ofrece un libro contable confiable debe hacer al menos cuatro cosas.
Primero, el consenso: acordar el orden de las transacciones y el contenido de los bloques, y comprometerse —bajo los supuestos de seguridad declarados— a que el registro no se reescribe a la ligera. Segundo, la disponibilidad de datos (DA): publicar los datos necesarios para verificar las transiciones de estado en algún lugar lo bastante público como para que cualquiera pueda descargarlos y recomprobarlos. Tercero, la ejecución: correr de verdad la lógica de las transacciones y calcular el nuevo estado del mundo. Cuarto, la liquidación: anclar el estado final o las pruebas como un hecho en el que los sistemas externos puedan confiar; los puentes, los mensajes entre cadenas y las entradas y salidas de dinero fiduciario suelen engancharse aquí.
Ethereum en 2015 reunía las cuatro en una sola pila de nodos, a lo que después se llamó arquitectura monolítica. La ventaja es una historia de seguridad unificada y un modelo mental simple; la desventaja, que un cuello de botella en cualquier capa frena toda la cadena. La ejecución fue el primer muro que todos sintieron: el rendimiento de la mainnet se mantuvo mucho tiempo entre un dígito y alrededor de una decena de TPS, y las comisiones se disparaban cada vez que una aplicación se ponía caliente. La hoja de ruta central de Ethereum viró entonces hacia «centrada en rollups»: la mainnet se concentra más en la DA y en arbitrar la liquidación, y deja la ejecución masiva a las L2. Ese giro es el punto de partida de todas las ramas que siguen.
Rollups L2: sacar la ejecución afuera y mantener la seguridad anclada a la mainnet
El movimiento central de un rollup es ejecutar transacciones en un entorno de ejecución aparte y enviar los datos más las pruebas (o compromisos impugnables) de vuelta a Ethereum. Los rollups ZK se apoyan en pruebas de validez; los optimistas, en ventanas de prueba de fraude. La mainnet no necesita reproducir cada transacción, solo verificar pruebas o gestionar disputas. El cómputo de ejecución se traslada a los secuenciadores y a los sistemas de prueba; la seguridad de la liquidación sigue apuntando a anclarse al conjunto de validadores de Ethereum.
Este camino resuelve «se pueden agregar más instancias de ejecución de forma horizontal»: muchos rollups atienden a muchas aplicaciones en paralelo. No resuelve automáticamente «si cada instancia sigue siendo de un solo hilo por dentro». Muchos rollups optimistas se mantienen cerca de la semántica serial clásica de la EVM; las ganancias de rendimiento provienen de hardware dedicado, bloques más cortos y de trasladar la congestión del mercado de comisiones de la L1 al mercado propio de la L2, no necesariamente del paralelismo dentro del bloque.
Los rollups también heredan dos restricciones. Los datos deben publicarse en algún lugar —calldata, blobs o una DA externa— y el costo de la DA reaparece en las comisiones del usuario. Los usuarios además cargan con un salto de confianza y latencia de L2 a L1 (períodos de desafío para retiros, riesgo de puente, disponibilidad del secuenciador). Un rollup nunca es autónomo: se apoya en una DA lo bastante barata y creíble.
Las cifras de TVL y rendimiento de las L2 en los paneles públicos se mueven rápido; cítense como instantáneas. La estructura importa más: dónde se concentra el capital suele reflejar preferencias sobre el costo de las pruebas, el diseño de los desafíos y la madurez operativa, no la afirmación de que una ruta teórica sea superior para siempre.
Sharding: del discurso de fragmentar la ejecución al de fragmentar los datos
El «sharding» cambió de significado en la historia de Ethereum. Las primeras hojas de ruta insistían en fragmentar la ejecución: dividir el estado, ejecutar por fragmento y luego lidiar con la mensajería entre fragmentos. La complejidad era alta; la composabilidad entre fragmentos, difícil. A medida que los rollups maduraron, la narrativa de la mainnet viró hacia hacer menos ejecución y más capacidad de datos: la dirección de Danksharding, con Proto-Danksharding (EIP-4844) ya en funcionamiento.
EIP-4844 introdujo los blobs: un espacio de datos de corta vida que no infla de forma permanente el estado de la capa de ejecución y abarata el envío de datos de las L2 a la mainnet. El Danksharding completo prevé el muestreo de disponibilidad de datos, para que los nodos no tengan que descargarlo todo y aun así obtengan confianza probabilística de que los datos están disponibles. La corrección clave: en el vocabulario actual de Ethereum, «sharding» sobre todo amplía la capacidad de DA; no reintroduce una EVM multihilo en la mainnet. Confundirlo con el «paralelismo de ejecución» de Solana, Sui o los L1 de EVM paralela desordena el mapa.
DA independiente: la tercera pata de la modularidad
No todos los rollups quieren tener la DA atada al mercado de blobs de Ethereum. Celestia, EigenDA, Avail y proyectos similares ofrecen otro carril: especializarse en publicar y muestrear, y dejar la ejecución y la liquidación a otros. Las combinaciones modulares se vuelven concretas: ejecución en un rollup, DA en una capa dedicada, liquidación aún opcionalmente anclada a Ethereum u otro L1.
La DA independiente atiende el ancho de banda y el costo de publicación de datos. No eleva directamente el paralelismo dentro del bloque de ninguna cadena. Puede abaratar de forma indirecta más transacciones de rollup y elevar el rendimiento de todo el ecosistema; sobre «si un solo motor de ejecución puede correr en paralelo», la capa de DA guarda silencio. Al evaluar un proyecto, pregunte si vende ejecución, liquidación o una tubería de datos.
Ejecución paralela en L1: ensanchar la ejecución en el mismo lugar
Lo opuesto a «sacar la ejecución afuera» es otro camino: mantener la ejecución y la liquidación en el L1, pero cambiar el motor para que las transacciones sin conflicto corran en paralelo. La planificación por declaración de cuentas de Solana, el paralelismo optimista al estilo Block-STM de Aptos, el modelo de objetos de Sui y varios intentos de EVM paralela ocupan esta celda.
El paralelismo en L1 ataca el techo de ejecución de un solo hilo del que ya se habló. Suele implicar construir el propio conjunto de validadores y el propio consenso —no se puede «heredar» sin más la seguridad de Ethereum— a cambio de liquidez y composabilidad en un mismo dominio de liquidación y un salto de puente por defecto menos. El costo: las cifras de rendimiento deben leerse bajo los propios supuestos de seguridad de la cadena, y el crecimiento del estado, los pisos de hardware y la tensión de descentralización recaen en su gobernanza local.
La EVM paralela es una subclase: mantener la compatibilidad de bytecode y de herramientas e introducir paralelismo en el runtime. Comparte la coordenada de «escalabilidad de la capa de ejecución» con los L1 que cambian la máquina virtual y el modelo de cuentas, pero no la misma curva de costo de migración para el desarrollador. Los detalles de los tres caminos paralelos pertenecen al artículo siguiente; aquí basta la ubicación: la EVM paralela vende ancho de ejecución, no muestreo de DA, y tampoco «levantar más rollups».
Tabla comparativa
| Ruta | Cuello de botella que ataca | Movimiento típico | Malentendido común |
|---|---|---|---|
| Rollup L2 | Capacidad de ejecución de la mainnet | Externalizar la ejecución; probar/impugnar de vuelta | «El paralelismo dentro del bloque ya está resuelto» |
| Sharding de datos de Ethereum / blobs | Costo de publicación de datos de las L2 | Ampliar la capacidad de DA | «Ethereum ya lanzó el sharding de ejecución» |
| DA independiente | Ancho de banda de datos modular | Publicación y muestreo especializados | «Con esto solo ya hay una experiencia de cadena completa» |
| Ejecución paralela en L1 | Ejecución serial de una sola instancia | Planificación multinúcleo / OCC / paralelismo de objetos | «La misma métrica que una comparación de rollups» |
Complemento más que exclusión mutua
Dos ejes valen más que los eslóganes. Un eje es dónde vive la ejecución: muchas instancias fuera de cadena, o una instancia en cadena hecha más ancha. El otro es quién provee la DA: blobs de Ethereum, DA independiente o la publicación propia de un L1. Las combinaciones reales son más ricas que un «o lo uno o lo otro»: un rollup puede publicar en Celestia; un L1 paralelo puede coordinar más adelante estrategias de objetos grandes o de historial con almacenamiento externo.
Llamar a la EVM paralela simplemente «anti-Ethereum» o «un reemplazo del sharding» es impreciso. Parchea el ancho de ejecución: cuando un solo entorno se densifica y los contratos se complican, el modelo serial falla primero. Los rollups aumentan la cantidad de entornos de ejecución; no optimizan automáticamente la planificación dentro de cada uno. Los dos pueden servir a productos distintos y aun así conectarse en las rutas de activos.
Al leer los textos técnicos siguientes, pregunte qué capa mide un número. Comparar el rendimiento paralelo de una sola cadena en testnet con el TPS que percibe el usuario de un rollup bajo cierto costo de DA, sin declarar las premisas, es una comparación sin contenido informativo.
Lecturas relacionadas
- Anterior: "Por qué una EVM de un solo hilo limita el TPS: historia de la congestión y el modelo de ejecución"
- Siguiente: "Tres caminos hacia la ejecución paralela: planificación determinista, OCC optimista y modelos de objetos"
- Relacionado: "Posicionamiento de Bitroot: los límites de un Layer 1 con EVM paralela optimista", "La tensión entre descentralización y rendimiento: requisitos de validadores, hardware y distribución geográfica"