Rollups Nativos vs Rollups Basados: ¿Qué Arquitectura L2 de Ethereum Elegir en 2026?

Los rollups basados y los rollups nativos resuelven capas distintas del mismo stack L2 de Ethereum. Un rollup basado delega el orden de las transacciones en Ethereum L1. Un rollup nativo delega en Ethereum la verificación de las transiciones de estado EVM. No son categorías rivales: una misma cadena puede ser ambas. En agosto de 2026 la secuenciación basada está activa, mientras que los rollups nativos siguen siendo investigación sin un fork programado.

La diferencia importa si compras infraestructura, planeas una appchain o decides si tu producto necesita una Layer 2 propia. Cambia el riesgo de censura, la latencia, los ingresos por MEV, la responsabilidad sobre upgrades y los sistemas que tu equipo debe operar. No crea demanda de producto por sí sola.

¿Cuál es la diferencia entre un rollup nativo y uno basado?

Haz dos preguntas separadas: ¿quién ordena las transacciones? y ¿quién verifica que la ejecución sea correcta? Based describe la secuenciación. Native describe la verificación de la ejecución.

La definición original de rollup basado en Ethereum Research explica que la secuenciación por L1 hereda la liveness y la descentralización de Ethereum. La hoja de ruta actual de escalado también señala que los sequencers centralizados crean riesgo de censura. Ese es el problema que intenta resolver la secuenciación basada.

¿Cómo funciona un rollup basado?

Permite que el siguiente proposer de Ethereum, junto con el pipeline existente de builders, incluya sin permiso el siguiente bloque L2 dentro de un bloque L1. El rollup sigue ejecutando transacciones fuera de la cadena y publicando datos o commitments en Ethereum. Lo que cambia es la autoridad que decide orden e inclusión.

¿Qué ganas?

• Liveness ligada a Ethereum. La cadena no se detiene porque desaparezca un sequencer separado.
• Más resistencia a censura. Un solo operador no controla el orden.
• Menor superficie de confianza. Puedes eliminar una red de consenso, un token de sequencer y un escape hatch complejo del camino crítico.
• Alineación económica con L1. Parte del MEV fluye a Ethereum en lugar de quedar en manos de un sequencer privado.

¿Qué sacrificas o reconstruyes?

• Las confirmaciones instantáneas dejan de ser triviales. Para no esperar un slot de L1, los diseños productivos añaden preconfirmers que prometen inclusión antes del settlement final.
• Hay menos flexibilidad de orden. First Come, First Served, orderflow privado y subastas propias son más difíciles de garantizar.
• Cambian los ingresos por MEV. Un negocio basado en secuenciación exclusiva no se traslada sin cambios.
• La operación no desaparece. Sigues necesitando block building, monitorización de preconfirmaciones, proving, publicación de datos, RPCs, indexers y respuesta a incidentes.

Taiko es la referencia productiva más clara. Su roadmap oficial de 2025 a 2026 describe un rollup basado de tipo 1, preconfirmaciones con lista blanca en mainnet y un camino hacia preconfirmaciones descentralizadas por debajo de un segundo. Demuestra que la secuenciación basada puede operar en producción, no que todos sus diseños tengan la misma madurez.

¿Cómo funciona un rollup nativo?

Busca evitar que cada equipo L2 mantenga su propio stack crítico de verificación EVM. Ethereum comprobaría que cada bloque L2 sigue el mismo programa de ejecución reconocido por L1. El rollup puede mantener políticas propias de secuenciación, tasas, token de gas, governance y mensajería.

La propuesta ha cambiado de forma importante. El borrador EIP-8079 describe un precompile EXECUTE y deja áreas centrales como TBD. La propuesta posterior de verificación nativa de pruebas avanza hacia transacciones que llevan pruebas y verificación independiente del programa dentro del consenso de Ethereum. Es una evolución relevante, pero sigue siendo investigación.

¿Qué podría eliminar la verificación nativa?

• Contratos verificadores, proof routers y parte del poder de upgrade de los security councils.
• Upgrades separados de circuitos EVM cada vez que cambian las reglas de Ethereum.
• Parte del riesgo de bridge que aparece cuando un verificador propio acepta una transición de estado incorrecta.

¿Qué límites permanecen?

• La equivalencia EVM importa. Opcodes, precompiles y tipos de transacción propios complican o bloquean la ruta original de EIP-8079.
• La secuenciación sigue siendo tu decisión. Nativo no significa orden descentralizado por defecto.
• Disponibilidad de datos y mensajería siguen siendo críticas. Un state root correcto no basta si el usuario no puede reconstruir estado o mover activos con seguridad.
• La economía de las pruebas sigue abierta. Propagación, agregación, precios, diversidad de backends y límites de recursos requieren decisiones de protocolo.

El tracker actual de investigación de L2BEAT es explícito: el trabajo no forma parte de ningún hard fork programado, EIP-8079 sigue en borrador y las transacciones con pruebas siguen siendo una propuesta. En 2026 puedes conservar una ruta de migración. No puedes poner esta verificación en una checklist de lanzamiento comprometida.

¿Puede un rollup ser basado y nativo a la vez?

Sí. La forma correcta de pensarlo es una matriz con dos ejes.

Así evitas un error de compra común. Un proveedor que dice “nativo” no ha explicado quién controla el orden. Uno que dice “basado” no ha explicado quién puede actualizar el verificador o el bridge. Pregunta ambas cosas.

¿Qué arquitectura L2 debería elegir tu producto?

• Elige secuenciación basada si resistencia a censura, inclusión sin permisos y neutralidad creíble son centrales, y puedes probar el camino de preconfirmación bajo fallos.
• Elige un sequencer dedicado si la UX por debajo de un segundo, orden determinista, transacciones privadas o ingresos por secuenciación son críticos para lanzar. Documenta la salida ante censura y caída.
• Diseña para compatibilidad nativa si buscas equivalencia EVM, una cadena de vida larga y la opción de reducir governance propia. Aísla las extensiones de ejecución.
• No lances tu propia L2 si una red pública ya cubre coste, rendimiento, distribución y compliance. Una cadena es otro producto operativo permanente.

Si todavía decides entre una L2 EVM pública y otra cadena, empieza por nuestra retrospectiva de gas y selección de cadena en 21 proyectos Web3. Si consideras salir de EVM, el desglose de la migración de Ethereum a Solana muestra por qué el cambio es una reescritura parcial. Si la interoperabilidad impulsa la decisión, revisa antes la decisión de seguridad de bridges cross-chain.

¿Qué preguntar a un proveedor de rollup as a service?

1. Secuenciación: ¿Quién puede incluir, reordenar o censurar, y qué ocurre si el componente cae?
2. Verificación: ¿Quién controla los upgrades, cuánto dura la ventana de salida y qué puede cambiar el security council?
3. Preconfirmaciones: ¿Qué se promete, qué collateral lo respalda y cómo se recupera el cliente de una promesa rota?
4. Data availability: ¿Los datos completos están en blobs de Ethereum o en una capa alternativa con otras condiciones de recuperación?
5. Economía: ¿Quién recibe base fees y MEV, y qué costes L1 siguen siendo variables?
6. Migración: ¿Qué opcodes, precompiles, depósitos o reglas de bridge bloquearían la verificación nativa?
7. Operaciones: ¿Quién ejecuta provers, RPCs, indexers, relayers, monitorización, upgrades y respuesta 24/7?

La dirección de la Ethereum Foundation sobre la relación entre L1 y L2 publicada en marzo de 2026 recomienda al menos Stage 1 y una vía para que el usuario pueda salir sin el operador. Presenta rollups nativos, interoperabilidad y Stage 2 como objetivos para una integración máxima. Es un buen norte, no sustituye un threat model listo para producción.

¿Cuál es la recomendación pragmática en 2026?

Para lanzar este año, empieza con un stack EVM maduro y decide la secuenciación por separado. Usa based sequencing cuando neutralidad y liveness justifiquen el trabajo extra de preconfirmaciones. Conserva equivalencia EVM cuando sea práctico para que la verificación nativa pueda ser una migración futura, no una reescritura. No hagas depender la fecha de lanzamiento de un hard fork sin calendario.

El equipo de ingeniería blockchain de Wavect elige la cadena después de definir workload, custodia, latencia, compliance y recuperación. Ese orden evita comprar infraestructura permanente antes de demostrar su necesidad.

FAQ: ¿Un rollup basado es automáticamente un ZK-rollup?

No. Based describe secuenciación. Puede usar validity proofs, fraud proofs u otro diseño. ZK frente a optimistic y based frente a secuenciación dedicada son ejes separados.

FAQ: ¿Los rollups nativos están activos en Ethereum?

No como arquitectura nativa de protocolo. Existen prototipos, pero a 11 de agosto de 2026 la verificación nativa no está incluida en ningún hard fork programado.

FAQ: ¿“Based rollup” significa Coinbase Base?

No. Based significa secuenciado por L1. Coinbase Base es el nombre propio de una L2 concreta. Las palabras coinciden, pero la categoría es independiente.

FAQ: ¿Una startup necesita su propia L2?

Normalmente no. Usa una L2 existente hasta que blockspace dedicado, compliance propio, ingresos a nivel de cadena o ejecución especializada generen valor medible. De lo contrario financias sequencers, provers, bridges y operaciones antes de crear una ventaja.