"¿Están las L2 erosionando el valor de la L1?", "¿Está Ethereum perdiendo su composabilidad global?" En los dos años en que las L2 estuvieron en su máximo apogeo, esta ansiedad prácticamente impregnó toda la comunidad de Ethereum.
En aquel marco de escalado de Ethereum, la L1 era la capa de liquidación estable pero costosa, y las L2, como capas de ejecución baratas y eficientes, efectivamente otorgaron a Ethereum más espacio de bloques, pero también hicieron que gradualmente se perdiera la experiencia completa de "una sola cadena".
Por lo tanto, en los últimos dos años, estos problemas han impulsado a Ethereum a reconsiderar la relación entre L1 y L2.
Por un lado, Ethereum L1 continúa aumentando el Límite de Gas, impulsando la 'statelessness' y la verificación zkEVM, ya no satisfecho con ser solo una base de liquidación de bajo rendimiento; por otro lado, las discusiones en la comunidad se han vuelto cada vez más intensas. Primero, a principios de año, Vitalik declaró directamente que con la mejora de la capacidad de escalado de la propia red principal de Ethereum, la premisa parcial del roadmap trazado hace cinco años, que consideraba a las L2 como el principal medio de escalado, ya ha cambiado (Lectura relacionada: Entendiendo la reflexión de Vitalik sobre L2: Despedida de la fragmentación, reajuste hacia Native Rollup en la nueva fase).
Y recientemente, el investigador de Ethereum Barnabé Monnot expresó además la necesidad de reevaluar la relación a largo plazo entre L1 y L2, incluyendo cómo las L2 deberían crear valor en el futuro, por qué la finalidad necesita acortarse drásticamente, y si, a medida que los sistemas de prueba entren gradualmente en el proceso de verificación de la red principal, la L1 también podría convertirse en cierto sentido en su propio "Rollup".
Aunque estos puntos de vista por el momento no equivalen a un protocolo de ruta ya determinado, ofrecen una perspectiva valiosa para observar.
En última instancia, el problema que enfrenta Ethereum hoy ya no es solo cómo continuar aumentando el espacio de bloques, sino cómo deberían redistribuirse las funciones entre L1, L2, capa de ejecución y capa de liquidación cuando las transacciones, activos y estados de usuario se dispersan en cada vez más entornos de ejecución.
Primera parte: Ethereum no 'abandona' las L2, pero debe encontrar su nueva posición
Siendo realistas, cuando se formuló inicialmente la ruta de escalado de Ethereum centrada en Rollups, la tarea más importante de las L2 era relativamente única: proporcionar a Ethereum más espacio de transacciones y más barato.
En las condiciones técnicas de entonces, esta división del trabajo era muy razonable.
Debido a que todos los validadores de Ethereum necesitan re-ejecutar las transacciones de L1, el rendimiento de la red principal no podía aumentar radicalmente a corto plazo. Los Rollups, por su parte, podían ejecutar transacciones por lotes fuera de la cadena, enviando solo los datos comprimidos o los compromisos de estado de vuelta a la red principal, manteniendo así ciertos atributos de seguridad de Ethereum mientras reducían drásticamente el coste por transacción.
Así, el escalado formó gradualmente dos rutas paralelas: la L1 se mantenía contenida, priorizando la descentralización y la seguridad, mientras que las L2 asumían las nuevas transacciones, reduciendo costos continuamente mediante blobs, compresión de datos y tecnología de pruebas.
Pero ahora, las premisas de esta división del trabajo han cambiado.
La Fundación Ethereum reorganizó el trabajo de protocolo en 2026, fusionando las anteriormente relativamente independientes "Escalar L1" y "Escalar Blobs" en una ruta Scale unificada. Dentro de este marco de escalado unificado se incluyeron el aumento del Límite de Gas, la expansión de la disponibilidad de datos, la optimización de clientes de ejecución, el impulso a la 'statelessness' y el cliente attester de zkEVM.
En otras palabras, Ethereum ya no considera el escalado de L1 y L2 como dos tareas separadas, sino que comienza a redistribuir la capacidad de ejecución, consenso y datos desde la perspectiva de todo el sistema.
Este cambio no significa que Ethereum esté preparándose para abandonar las L2, o para absorber toda la actividad de vuelta a la red principal. Por el contrario, significa que será difícil para las L2 seguir demostrando su valor a largo plazo solo con "transacciones más rápidas, Gas más bajo".
Después de todo, si la propia L1 puede mantener la seguridad y descentralización mientras aumenta su capacidad de ejecución en varios órdenes de magnitud, entonces la ejecución EVM genérica y el espacio de bloques de bajo costo ya no serán capacidades exclusivas de las L2; lo que las L2 necesitarán proporcionar se orientará más hacia necesidades diferenciadas que la L1 no puede satisfacer de manera uniforme, como optimizaciones para aplicaciones específicas, funciones de privacidad y modelos de gobernanza y económicos más flexibles.
La última declaración de la Fundación Ethereum sobre la relación entre L1 y L2 este año también enfatiza explícitamente este punto. En el pasado, el objetivo principal de las L2 era escalar Ethereum, siendo la diferenciación y personalización valores secundarios; ahora es proporcionar funcionalidades diferenciadas, mientras continúan contribuyendo con capacidad de escalado adicional.
Correspondientemente, la L1 necesita convertirse en un centro global suficientemente fuerte, sin permisos y altamente resiliente, que albergue liquidación, estado compartido, liquidez y DeFi.
Esto, de hecho, empuja a las L2 de una categoría técnica unificada hacia un espectro continuo más complejo:
- En un extremo del espectro, están los Rollups que heredan al máximo los atributos de seguridad de Ethereum, que desean reducir los comités de seguridad multisig, abrir mecanismos de prueba sin permisos y garantizar que los usuarios aún puedan depender de la L1 para salir incluso si el operador deja de funcionar;
- En una posición intermedia, están los entornos de ejecución que heredan parcialmente los atributos de Ethereum según las necesidades del negocio, que pueden tener permisos de administración más fuertes, secuenciadores independientes o diseños de cumplimiento específicos, a cambio de rendimiento, privacidad y flexibilidad operativa;
- En el otro extremo, pueden estar simplemente cadenas que adoptan la EVM, utilizan activos de Ethereum o se conectan a parte de la infraestructura cross-chain, pero que son relativamente independientes en seguridad y liquidación;
Por eso se dice que Ethereum no va a abandonar las L2, sino a redefinir la división del trabajo. En última instancia, en los últimos 3-5 años, L2 representaba primero una tecnología de escalado, mientras que en el futuro, es más probable que represente un conjunto de entornos de ejecución que establecen diferentes relaciones de seguridad, liquidación y liquidez con Ethereum.
Segunda parte: La interoperabilidad no es solo cross-chain, sino cómo se confía mutuamente en el estado
Sin embargo, cuando Ethereum se expande hasta convertirse en un sistema compuesto por muchas L2, otro viejo problema comienza a surgir gradualmente: la creciente proliferación de L2 inevitablemente fragmenta simultáneamente la liquidez, el estado de las cuentas y la experiencia de la aplicación.
Esto se ha manifestado vívidamente en el uso práctico de los últimos años. Por ejemplo, un usuario puede tener activos en una cadena, usar una aplicación en otra cadena y necesitar ir a una tercera cadena para completar una transacción, hasta el punto de que la misma stablecoin tiene diferentes versiones en diferentes redes, y la misma cuenta también necesita manejar diferentes Gas Tokens, puentes cross-chain y puntos de entrada de activos.
Por lo tanto, la interoperabilidad comienza a convertirse en una parte cada vez más importante de la ruta de Ethereum.
El equipo de protocolo de Ethereum ya ha centrado el enfoque de la ruta Improve UX para 2026 en dos direcciones: la abstracción de cuentas nativa y la interoperabilidad, y considera que la clave para resolver la fragmentación de las L2 radica en hacer que Ethereum "vuelva a sentirse como una cadena", visión que depende de la madurez de la arquitectura de intenciones (intent).
- Entre ellos, el marco de intenciones abiertas Open Intents Framework permite a los usuarios simplemente declarar el resultado deseado, por ejemplo, "convertir un determinado activo en la cadena A a USDC en la cadena B", y luego los solvers en segundo plano completan el cálculo de la ruta, el avance de fondos, la ejecución y el reequilibrio de capital (Lectura relacionada: Cuando las 'intenciones' se convierten en estándar: ¿Cómo OIF pone fin a la fragmentación cross-chain y devuelve la intuición al usuario en Web3?);
- La capa de interoperabilidad de Ethereum (EIL) más avanzada intenta construir una capa de transporte sin confianza, con el objetivo de que las transacciones cross-chain entre L2 tengan una experiencia indistinguible de las transacciones de una sola cadena (Lectura relacionada: El roadmap de Interoperabilidad de Ethereum: Cómo desbloquear la 'última milla' para la adopción masiva);
En el lado de las cuentas, la EIP-7702 en la actualización Pectra ya permite que las EOA tradicionales ejecuten temporalmente código de contrato inteligente, admitiendo procesamiento por lotes de transacciones, pago de gas por terceros y mecanismos de recuperación; los esquemas posteriores de abstracción de cuentas nativas representados por la EIP-8141 intentan integrar aún más la lógica de la cuenta inteligente en el protocolo, haciendo que las carteras de contrato inteligente se conviertan gradualmente en la forma de cuenta predeterminada y reduciendo la dependencia de servicios Bundler, Relayer e intermediarios adicionales.
Las reglas de confirmación rápida de L1 intentan proporcionar una señal de confirmación más segura en decenas de segundos antes de la finalidad completa, lo que puede acortar los tiempos de espera de las aplicaciones en la mayoría de los escenarios normales. Esto beneficiaría directamente a todas las aplicaciones cross-chain que dependen de la finalidad de L1, siendo de gran importancia para puentes cross-chain, liquidación de stablecoins y transacciones de activos RWA.
Porque muchos cuellos de botella reales en las interacciones cross-chain no son si el mensaje se puede enviar, sino cuándo la cadena de destino puede estar lo suficientemente segura de que el estado en la cadena de origen no será revocado.
Un punto que a menudo se pasa por alto es que una transacción incluida en un bloque no equivale a que haya alcanzado la finalidad: desde la perspectiva del usuario, la transacción puede mostrarse como exitosa en unos segundos, pero para puentes, exchanges, protocolos de préstamo y solvers cross-chain, aún necesitan juzgar la posibilidad de que esa transacción sufra una reorganización de bloque, y si pueden liberar activos en otra cadena o ejecutar la siguiente operación en base a ello.
Es por eso que muchos servicios cross-chain que hoy parecen ser de "llegada instantánea" no esperan realmente a que la cadena de origen complete la liquidación final, sino que los solvers o proveedores de liquidez avanzan los fondos primero. Solo que este mecanismo optimiza la experiencia del usuario sin hacer desaparecer el tiempo de espera subyacente.
Por lo tanto, el objetivo a largo plazo de Ethereum es acortar gradualmente la finalidad en sí misma del nivel de minutos al nivel de segundos. Sin embargo, esta no es una actualización única ya programada para su implementación, sino un conjunto de tareas de investigación que deben avanzarse por etapas, incluyendo desacoplar la votación de finalidad de la elección de bifurcación, optimizar el conjunto de validadores, agregación de votos y propagación de red, para luego cambiar gradualmente el protocolo de consenso.
En general, una buena experiencia de interoperabilidad no es que docenas de cadenas tengan el mismo botón cross-chain, sino que diferentes entornos de ejecución puedan confiar en el estado de los demás más rápido y a menor costo.
Tercera parte: Cuando L1 también se convierte en Rollup, ¿sigue existiendo el límite de las capas?
Si los cambios de posición de L2 y el acortamiento de la finalidad aún consisten en reajustar la arquitectura de capas existente, entonces otro juicio mencionado por Barnabé toca aún más la definición misma de L1 y L2: a medida que los sistemas de prueba entren en la red principal de Ethereum, L1 finalmente también podría convertirse en cierto sentido en su propio "Rollup".
Esta afirmación suena algo contraintuitiva.
Después de todo, un Rollup generalmente se entiende como una red de escalado construida sobre L1: ejecuta transacciones externamente, y L1 verifica el resultado del estado. ¿Cómo puede Ethereum, siendo la red de consenso y liquidación subyacente, convertirse en su propia L2?
Para entender este punto de vista, primero hay que desmontar "Rollup" de la relación jerárquica. En el Ethereum actual, cuando un nodo recibe un bloque, necesita re-ejecutar todas las transacciones en él, calcular de forma independiente los cambios de estado y determinar si el bloque cumple con las reglas del protocolo.
Este modelo garantiza que los nodos puedan verificar por sí mismos, pero también significa que la capacidad de ejecución general de la red debe estar restringida por las condiciones de hardware de los nodos ordinarios. Cuanto mayor sea el volumen de cálculo en el bloque, más hardware y tiempo necesitarán los validadores para completar la ejecución.
En el futuro, a medida que maduren las pruebas en tiempo real y el zkEVM de L1, las transacciones aún podrán ser calculadas por nodos de ejecución de alto rendimiento, pero los validadores ordinarios pueden no necesitar volver a ejecutar personalmente cada transacción. Por ejemplo, después de completar el cálculo, el nodo de ejecución genera una prueba de validez; otros validadores solo necesitan verificar la prueba, que es de menor volumen y costo, para confirmar si la transición de estado es correcta.
Desde la perspectiva de la relación entre ejecución y verificación, esto sí se parece a un Rollup: una parte de los participantes es responsable de la ejecución de alto rendimiento, el resultado de la ejecución se comprime en una prueba criptográfica, y los participantes de consenso más amplios ya no repiten todo el cálculo, sino que verifican la prueba y confirman el estado final.
Por lo tanto, lo que Barnabé llama "L1 convirtiéndose en su propio Rollup" es más adecuado como una generalización de este modo de verificación, no significa que la red principal de Ethereum se coloque sobre otra cadena subyacente o sea "degradada" a su propia L2.
Su punto es que, cuando las pruebas reemplacen gradualmente la re-ejecución en todos los nodos, Rollup puede dejar de ser solo un nombre de capa ubicado sobre L1, y convertirse en una arquitectura de ejecución y verificación más universal.
Esto también desdibujará aún más los límites tradicionales entre L1 y L2.
Por un lado, L1 puede expandir su propia capacidad de ejecución con la ayuda de pruebas zkEVM; por otro lado, Native Rollup espera permitir que L2 invoque de manera más directa la capacidad de verificación dentro del protocolo de Ethereum, permitiendo que L1 verifique las transiciones de estado de L2 de una manera más nativa y unificada.
Hoy, diferentes Rollups generalmente necesitan construir sus propios sistemas de prueba, contratos de verificación, mecanismos de actualización y comités de seguridad. Una vez que ocurre un error en el sistema de prueba, el protocolo necesita una actualización de emergencia o el operador falla, los usuarios a menudo aún dependen de estructuras de gobernanza y confianza adicionales; la dirección a largo plazo de Native Rollup es convertir parte de la lógica de verificación de Rollup en una capacidad nativa de Ethereum, permitiendo que L2 reduzca las estructuras de seguridad auto-construidas, herede de manera más completa las reglas de transición de estado de L1 y tenga la oportunidad de prescindir de los comités de seguridad.
Si damos un paso más, cuando múltiples L2 puedan confiar en una confirmación más rápida de L1, mecanismos de prueba unificados y composibilidad sincrónica para acceder al estado de las demás, su relación con la red principal puede dejar de estar conectada por puentes cross-chain como hoy.
Serían más bien múltiples dominios de ejecución bajo el mismo consenso de Ethereum, algunos responsables de actividades financieras genéricas, otros orientados a juegos, redes sociales o pagos, otros proporcionando capacidades de privacidad o cumplimiento especial, poseyendo diferentes lógicas de ejecución y formas de producto, pero dependiendo conjuntamente de un conjunto verificable de estado, bases de seguridad y sistema de liquidación de activos.
Por supuesto, esta sigue siendo una dirección a largo plazo.
Pero independientemente de la forma final en que se implementen estas tecnologías, ya han hecho que el límite entre L1 y L2 pase de ser un límite arquitectónico claro a convertirse gradualmente en relaciones de herencia de seguridad en diferentes grados.
Para concluir
La tendencia general del mundo es que lo que está unido durante mucho tiempo inevitablemente se divide, y lo que está dividido durante mucho tiempo inevitablemente se une.
Ethereum una vez dependió del estado compartido para obtener composabilidad global; luego, a través de Rollups, separó la ejecución para obtener mayor capacidad. Ahora, lo que necesita lograr es reconectar los activos, cuentas y aplicaciones que fueron separados, sin revocar los logros de escalado.
Para el usuario común, el Ethereum ideal nunca debería ser un mapa de red compuesto por docenas de cadenas, diferentes tokens de Gas y puentes cross-chain. De hecho, dónde se ejecuta una transacción, de qué cadena proviene la liquidez, quién finalmente liquida, todo puede confiarse gradualmente a carteras, aplicaciones y protocolos subyacentes, pero los supuestos de confianza, los límites de seguridad y las rutas de salida involucrados no pueden ocultarse junto con la experiencia operativa.
Por lo tanto, el destino final de las L2 quizás no sea reemplazar a la L1, ni ser eliminadas por una L1 en constante expansión, sino convertirse en un conjunto de entornos de ejecución con diferentes funciones y rendimientos, pero capaces de compartir seguridad, liquidez y relaciones de estado.
En el pasado, Ethereum dependió de separar la ejecución para obtener mayor capacidad.
En la próxima etapa, veamos si, después de separarse, aún puede volver a formar un Ethereum.
