Durante la última década, Ethereum ha crecido impulsado por una promesa clara: escalar la red sin sacrificar la descentralización. La clave, según su hoja de ruta, está en un futuro dominado por los rollups, donde las soluciones de Capa 2 (L2 o “rollups”) procesan transacciones fuera de la cadena principal para reducir costes y aumentar el rendimiento, manteniendo la seguridad fundamental garantizada por Ethereum como capa base (Layer 1).

Casi todos los grandes rollups —Arbitrum, Optimism, Base, zkSync, Scroll— se autodenominan “asegurado por Ethereum”. Es un eslogan potente y el eje de su discurso comercial, pero ¿refleja la realidad? Si analizas cómo operan los rollups y cómo circulan los activos en ellos, la afirmación se vuelve menos nítida.

Este artículo desglosa la brecha entre el eslogan y la realidad, comenzando por los puentes (donde se encuentran los fondos de los usuarios), siguiendo por los secuenciadores (quienes ordenan las transacciones) y terminando con la gobernanza (quién dicta las normas).

La realidad del puente en los rollups

Decir que los rollups están “asegurados por Ethereum” pasa por alto la forma real en que los usuarios interactúan con estos sistemas.

Para participar en un rollup, ya sea en DeFi, pagos o aplicaciones, primero necesitas que tus activos estén en él. Ethereum no permite mover activos directa y nativamente entre la cadena principal y un rollup; no puedes simplemente enviar ETH a un rollup de manera instantánea. Hace falta un puente. Los puentes hacen de puerta de entrada y salida entre Ethereum y los rollups, y son los que realmente determinan la experiencia de seguridad de los usuarios.

Cómo funcionan los puentes

Depósitos

Cuando depositas ETH en un rollup, envías los fondos a un contrato puente en Ethereum. Ese contrato bloquea tu ETH y notifica al rollup para que, en tu monedero L2, se registre la misma cantidad. Por ejemplo, si depositas 1 ETH, el puente retiene tu 1 ETH con seguridad en Ethereum y tu saldo en el rollup muestra 1 ETH. Como es Ethereum quien custodia el ETH bloqueado, el depósito minimiza la necesidad de confianza.

Retiros

Los retiros son más complejos. El proceso se invierte:

1. Quemas (o bloqueas) los tokens en el rollup.
2. Envías un mensaje al contrato puente de Ethereum: he quemado los tokens en L2, libera mi ETH bloqueado.
3. El problema: Ethereum no puede ver lo que ocurre dentro del rollup. Es completamente ajeno al procesamiento en L2.

Así, Ethereum solo libera los fondos si el puente le aporta pruebas de que el retiro es legítimo. Las pruebas pueden ser de tres tipos:

• Pruebas de fraude (optimistas): se asume válidas salvo disputa dentro de un plazo determinado.
• Pruebas de validez (zk): una prueba criptográfica demuestra desde el inicio que todas las transacciones cumplen las reglas, lo que permite a Ethereum confiar en el resultado inmediatamente.
• Multifirmas o comités de validadores: se deposita la confianza en un grupo reducido de partes designadas.

El puente determina tu acceso al rollup. Es como una ventana de una casa: la casa (el rollup) sigue en pie incluso si la ventana (el puente) se rompe. Pero si la ventana se hace añicos, ya no puedes entrar ni salir de forma segura. Del mismo modo, si el puente se destruye, los usuarios se quedan fuera, aunque el motor del rollup siga funcionando.

Por eso, la capa de puentes es el aspecto clave de la seguridad en los rollups. Que tus activos estén realmente “asegurados por Ethereum” no depende tanto del rollup en sí, sino del puente que utilizas y del modelo de confianza sobre el que se apoya.

Modelos de puente y sus implicaciones

• Puentes canónicos (los oficiales de cada rollup): están integrados en Ethereum y, si bloqueas activos en ellos, los validadores de Ethereum te garantizan que podrás retirarlos a Capa 1, incluso si la Capa 2 deja de funcionar. Solo los puentes canónicos heredan directamente la seguridad de Ethereum.
• Puentes externos (como Wormhole, LayerZero, Axelar): priorizan una experiencia de usuario ágil con transferencias rápidas entre cadenas, pero dependen de sus propios comités de validadores o multifirmas. No se rigen por el consenso de Ethereum. Si estos operadores externos son corrompidos o hackeados, los usuarios pierden fondos aunque Ethereum siga funcionando correctamente.
• Emisión nativa (tokens emitidos directamente en el rollup): ejemplos como USDC en Base u OP en Optimism. Estos activos no atraviesan nunca un puente canónico ni pueden canjearse en Capa 1. Su respaldo depende de la gobernanza e infraestructura del rollup, no de Ethereum.

¿Dónde residen realmente los activos de los rollups?

A 29 de agosto de 2025, los rollups de Ethereum custodian en conjunto unos $43,96 mil millones en activos. Desglose:

• Puentes externos: $16,95 mil millones (39 %) — categoría principal
• Puentes canónicos: $14,81 mil millones (34 %) — activos asegurados por Ethereum
• Emisión nativa: $12,20 mil millones (27 %) — activos nativos de rollup

Evolución de las tendencias

Si retrocedemos a 2019–2022, los puentes canónicos fueron el motor de la adopción de los rollups: todo el crecimiento inicial vino a través de puentes oficiales, con Ethereum en el centro.

Sin embargo, a partir de finales de 2023 el panorama cambió:

• Los puentes canónicos siguieron creciendo en términos absolutos, alcanzando su máximo en 2024, pero su peso relativo empezó a disminuir.
• La emisión nativa creció de forma constante, especialmente durante 2024 y 2025.
• Los puentes externos se dispararon desde finales de 2023 y, a comienzos de 2025, superaron a los puentes canónicos, marcando el punto en que Ethereum perdió el control mayoritario de los activos en rollups.
• Actualmente, dos tercios de los activos de rollups (la suma de externos y nativos) se encuentran fuera del perímetro de seguridad directa de Ethereum.

Radiografía por nivel de rollup

El mercado está muy concentrado: los seis rollups principales suman el 93,3 % del valor total bloqueado (TVL) en rollups. La distribución interna en estos ecosistemas es:

• Puentes canónicos: 32,0 %
• Emisión nativa: 28,8 %
• Puentes externos: 39,2 %

Patrones agregados en diagramas circulares

• Predominio externo: Arbitrum y Unichain, donde los usuarios persiguen salidas rápidas y liquidez mediante puentes de terceros.
• Tendencia canónica: Linea (y en menor medida OP Mainnet), con más colateral procedente de Capa 1 canalizado por el puente oficial.
• Tendencia nativa: zkSync Era y Base, con abundante emisión local (por ejemplo, USDC nativo en Base) y rampas de acceso directas.

Por qué es relevante: la mayor parte del valor de los principales rollups está fuera de las garantías directas de Ethereum. La seguridad efectiva para el usuario depende del modelo de puente en cada segmento.

Más allá de los puentes: otros riesgos

Los puentes explican dónde residen los activos, pero aunque todos fuesen canónicos, los usuarios seguirían enfrentándose a otros riesgos y vacíos de confianza. Hay tres cuestiones cruciales: cómo se ordenan las transacciones, quién gobierna la infraestructura y cómo afecta la composabilidad a la experiencia de usuario.

1. Secuenciadores: el principal punto de control

La secuenciación implica decidir el orden de inclusión de las transacciones. La mayoría de los rollups emplea secuenciadores centralizados, que son rápidos y rentables.

Sin embargo, un secuenciador centralizado puede:

• Censurar transacciones simplemente negándose a incluirlas.
• Bloquear retiros indefinidamente, ya que elige cuándo agruparlos para Ethereum.
• Caer completamente, paralizando la actividad hasta que se recupera (ejemplo: caída de Arbitrum durante 78 minutos).

Ethereum incorpora mecanismos de “inclusión forzada” que permiten a los usuarios enviar transacciones directamente a Capa 1 y sortear el secuenciador. Sin embargo, esto no garantiza la equidad: el secuenciador sigue controlando el orden de los bloques, lo que suele bastar para perjudicar a los usuarios.

Un ejemplo de cómo se puede incluir una transacción pero sabotear su resultado:

• Imagina que quieres retirar fondos de Aave en una Capa 2.
• Envías una solicitud de retirada con inclusión forzada en Ethereum, de modo que el secuenciador no puede ignorarla.
• Pero el secuenciador puede insertar una operación propia justo antes de la tuya —por ejemplo, retirando más fondos del mismo pool—.
• Cuando llega tu turno, el pool carece de liquidez y tu retirada falla.
• Tu transacción se “incluyó”, pero fue saboteada.

La inclusión forzada también tiene sus inconvenientes: períodos de espera que pueden superar las 12 horas, baja capacidad y riesgo de reordenamiento incluso tras el envío. Es más una válvula de seguridad lenta que una garantía de ejecución justa.

Mientras tanto, avanza el impulso hacia la descentralización. Proyectos como Espresso y Astria desarrollan redes de secuenciadores compartidos para hacer el sistema más resiliente e interoperable.

Un concepto clave es el de preconfirmaciones: compromisos anticipados de un secuenciador o de la red de que una transacción será incluida, incluso antes de su finalización en Ethereum. Así se reduce la penalización de latencia que implica la descentralización, ofreciendo mayor certeza sin renunciar a la neutralidad.

Pese a todo, los secuenciadores centralizados siguen dominando porque ofrecen simplicidad, rentabilidad y atractivo institucional, al menos hasta que la competencia o la presión de los usuarios impongan otro modelo.

2. Gobernanza e incentivos (Capa 2 corporativas)

Quién gestiona la Capa 2 es crucial. Muchos rollups de primer orden están controlados por empresas o equipos respaldados por capital riesgo (ejemplo: Base por Coinbase, Arbitrum por Offchain Labs, Optimism por OP Labs).

Sus prioridades están con los accionistas o inversores, no con el contrato social de Ethereum.

• Obligaciones para accionistas → presión para monetizar: las comisiones son bajas al principio para atraer usuarios, pero aumentan una vez consolidada la liquidez y las apps (el clásico “impuesto de plataforma”). Se pueden esperar comisiones de secuenciador más altas, colaboraciones preferentes o normas que favorezcan el negocio del operador.
• Efecto lock-in → poder de negociación: tras acumular miles de millones en TVL y usuarios, cambiar de plataforma es difícil. Los operadores pueden modificar comisiones o políticas sin temor a una fuga masiva.
• Diferencia cultural: Ethereum se apoya en debates públicos, diversidad de clientes y gobernanza abierta (EIPs). En cambio, los rollups corporativos son más jerárquicos, con claves de administración o multifirmas que permiten pausar, actualizar o congelar —poniendo el cumplimiento normativo o el beneficio por encima de la neutralidad—. Con el tiempo, un rollup puede parecer más un ecosistema cerrado que el propio Ethereum.

El resultado: crece la brecha entre la filosofía abierta de Ethereum y los incentivos que rigen los rollups corporativos. Y no solo afecta a la gobernanza, sino también a la interacción y experiencia de los usuarios.

3. Composabilidad y experiencia de usuario (UX)

La fortaleza de Ethereum es su composabilidad atómica: los contratos pueden leerse y escribirse en una misma transacción (por ejemplo, un swap en Uniswap que paga un préstamo en Aave y dispara una acción en Maker en un solo movimiento). Las Capa 2 rompen esta característica:

• Asincronía: los mensajes entre rollups se retrasan, los retiros por puentes canónicos pueden tardar días y los puentes externos conllevan mayores requisitos de confianza.
• Fragmentación: la liquidez y el estado se dispersan entre Capa 2, y la experiencia DeFi fluida de Ethereum se debilita.

¿Cómo se puede solucionar?

Rollups nativos de Ethereum, diseñados y gobernados siguiendo los estándares de Capa 1, podrían habilitar lecturas síncronas de Capa 2→Capa 1, escrituras síncronas de Capa 1→Capa 2 y acciones atómicas entre rollups, recuperando gran parte de la composabilidad de Capa 1 y ampliando el espacio de bloques. Si esto no se da, la experiencia de usuario tenderá a migrar a capas de conveniencia no aseguradas por Ethereum.

El futuro de los rollups

Para que “asegurado por Ethereum” tenga una base real y no sea solo un eslogan, las garantías esenciales deben residir en Capa 1, no en comités off-chain ni en secuenciadores controlados por una sola entidad. Hay tres líneas de diseño que muestran el camino.

Los rollups nativos trasladan la validez de las operaciones directamente a Ethereum.

• En lugar de depender de sistemas de pruebas de fraude ajenos, un verificador zk no auditable o un consejo de seguridad, el rollup proporciona un rastro de transacciones que Ethereum puede reejecutar.
• En la práctica, esto convierte el retiro de fondos y la corrección del estado en derechos garantizados por Capa 1 y no en promesas: si el rollup declara que tu saldo es X, Ethereum puede comprobarlo directamente.
• Esto reduce la superficie de ataque de los puentes, limita la necesidad de claves de pausa y mantiene el rollup alineado con futuras versiones de Ethereum.
• El coste en Capa 1 aumenta, pero la ventaja es clara: si surge una disputa, decide Capa 1.
• No existen rollups nativos en funcionamiento hoy en día.

Los rollups basados fijan el orden de las transacciones al conjunto de validadores de Ethereum.

• Hoy, un secuenciador único puede reorganizar o retrasar operaciones, lo que en la práctica bloquea la “inclusión forzada”.
• Con el secuenciamiento basado, el orden lo marca el consenso de Capa 1, dificultando la censura y los reordenamientos oportunistas.
• La inclusión forzada deja de ser un sistema de emergencia y pasa a ser el camino habitual. Se utilizan preconfirmaciones para mantener la inmediatez de la UX sin renunciar a que Capa 1 marque el orden final.
• Se renuncia a parte de los ingresos y la flexibilidad de la Capa 2, pero se elimina el mayor punto de control único actual.
• Entre los equipos que lideran el diseño basado están Taiko, Spire y Puffer.

Los rollups keystore abordan un riesgo persistente pero más discreto: la seguridad de claves y las actualizaciones.

• En lugar de que cada rollup o app gestione por separado recuperación de cuentas, claves de sesión y rotaciones, un rollup keystore estandariza esa lógica para todo el ecosistema y la sincroniza en todas las Capa 2.
• El usuario puede rotar o recuperar claves en un solo punto; el cambio se propaga al resto de Capa 2. Los operadores requieren menos claves de emergencia y menos “interruptores de privilegio”.
• Con ello, se reducen los monederos comprometidos, las actualizaciones de emergencia tras incidentes y se separa claramente la seguridad de las cuentas de la lógica de cada aplicación.
• El diseño de rollup keystore es, por el momento, solo teórico y no está implementado.

Estos enfoques abordan los problemas reales de los usuarios: retiros sujetos a confianza, orden controlado por una única empresa y rutas de claves y actualizaciones frágiles.

Desplazar la validez, el orden y la seguridad de las cuentas bajo el paraguas de Ethereum es el camino para que los rollups sean realmente “asegurados por Ethereum” y no solo lo digan en su publicidad.

• Hazeflow es una firma de investigación blockchain especializada en análisis, documentación técnica, divulgación de producto y contenidos educativos.
• Colaboramos con equipos blockchain —especialmente los de alta complejidad tecnológica— que necesiten comunicar de manera clara y eficaz productos complejos.

Aviso legal:

1. Este artículo es una adaptación de [Ishita]. Todos los derechos de autor pertenecen a la autora original [Ishita]]. Si tienes alguna objeción a la publicación de esta versión, ponte en contacto con el equipo de Gate Learn, que atenderá el asunto sin demora.
2. Descargo de responsabilidad: Las opiniones y valoraciones recogidas en este artículo corresponden exclusivamente a su autora y no constituyen consejo de inversión alguno.
3. La traducción de este contenido ha sido realizada por el equipo de Gate Learn. Salvo mención expresa, queda prohibida la copia, distribución o plagio de estos materiales traducidos.