El ecosistema de capa 2 de Ethereum arrastra una contradicción técnica que rara vez se aborda con franqueza. Los rollups se presentan como soluciones de escalabilidad que heredan la seguridad de la capa base, pero la mayoría opera con un secuenciador centralizado que introduce un punto único de confianza. Un solo operador decide el orden de las transacciones, puede censurar direcciones y captura el valor extraíble generado en la red.
Los usuarios aceptan esa arquitectura a cambio de confirmaciones rápidas y tarifas bajas, asumiendo que los activos permanecen resguardados por los mecanismos de salida forzosa hacia L1. La propuesta de los based rollups elimina esa disyuntiva al trasladar la función de secuenciación directamente a los validadores de Ethereum.
El secuenciador como cuello de botella no resuelto
Los rollups optimistas y ZK en producción —Arbitrum, Optimism, Base, zkSync Era— dependen de un nodo secuenciador que agrupa transacciones, las ordena y publica datos en Ethereum. Ese nodo proporciona confirmaciones blandas en milisegundos, pero concentra el poder de ordenación. El secuenciador puede extraer MEV mediante reordenación, inserción o exclusión de transacciones, sin que exista un mecanismo de rendición de cuentas en tiempo real. Si el secuenciador deja de operar, la red se detiene desde el punto de vista del usuario, aunque la lógica del rollup permita la inclusión forzosa a través de L1. Esa inclusión forzosa resulta lenta y costosa, lo que desincentiva su uso.
Se han propuesto redes de secuenciadores descentralizados y secuenciadores compartidos como alternativa. Esas soluciones añaden una capa de consenso adicional, un token de staking y una infraestructura separada que replica, en menor escala, el modelo de validación de Ethereum. El resultado es un incremento en la complejidad del sistema y un modelo de confianza que sigue siendo externo a la cadena principal. Los based rollups adoptan una vía distinta: prescinden por completo del rol de secuenciador independiente.
Definición precisa de un based rollup
Un based rollup es un rollup cuya secuenciación está determinada por el proposer de L1 correspondiente a cada slot. La red de capa 2 no elige un secuenciador propio ni opera un conjunto de validadores; en su lugar, utiliza el calendario de proponentes de la Beacon Chain. El bloque de L2 que se considera canónico es aquel que el proposer de Ethereum incluye en su bloque de L1, siempre que cumpla las reglas de transición de estado del rollup.
Esa definición tiene consecuencias inmediatas. La descentralización del secuenciador se equipara a la de la capa de consenso de Ethereum, sin necesidad de coordinar un nuevo conjunto de participantes. No se introduce un token adicional ni un protocolo de consenso propio. La resistencia a la censura del rollup se alinea con la de la capa base: si un proposer omite una transacción de L2, un proposer futuro puede incluirla, ya que la máquina de estado del rollup deriva su historia de forma determinista a partir de los datos publicados en L1.
Funcionamiento de la construcción de bloques y la inclusión forzosa
El proceso se integra en la dinámica de producción de bloques de Ethereum. En cada slot de 12 segundos, el validador seleccionado como proposer tiene el derecho de proponer el siguiente bloque de L1. Si ese validador opera también como secuenciador del based rollup, incluirá un bloque de L2 dentro de la carga de datos de su bloque de L1, habitualmente en forma de calldata o blobs. La ejecución de las transacciones y la construcción del bloque de L2 no tienen por qué ser realizadas directamente por el proposer. Pueden delegarse en constructores especializados que compiten por ofrecer el bloque de L2 con mayor valor de MEV, en un esquema análogo al de MEV-Boost. El proposer selecciona la propuesta más rentable, la incluye y la firma dentro de su bloque.
El mecanismo de inclusión forzosa opera como garantía de respaldo. Cualquier usuario puede enviar una transacción directamente al mempool de L1 para que un futuro proposer la incorpore al bloque de L2. Si el proposer actual censura ciertas operaciones, la transacción se procesará en un slot posterior sin necesidad de permisos. La finalidad de las transacciones del rollup sigue el ritmo de la finalidad de L1, lo que elimina el supuesto de confianza en un secuenciador honesto.
Preconfirmaciones basadas: velocidad sin centralización permanente
La principal objeción al diseño es la latencia. La confirmación en el tiempo de slot de Ethereum —12 segundos hasta la inclusión y más hasta la finalidad— resulta inaceptable para aplicaciones que requieren retroalimentación inmediata. La investigación en preconfirmaciones basadas ofrece una solución sin reintroducir un secuenciador centralizado.
El mecanismo se apoya en el hecho de que el calendario de proponentes se conoce con varios slots de antelación. Un futuro proposer puede comprometerse de forma vinculante a incluir una transacción con un orden y un estado resultante determinados.
Ese compromiso se materializa en una firma que puede estar respaldada por el stake del validador. Si el proposer incumple la promesa, se expone a penalizaciones económicas, condicionadas a que el protocolo de Ethereum incorpore condiciones de slashing para preconfirmaciones. El usuario recibe una confirmación instantánea y con garantía económica antes de que el bloque de L1 sea propuesto. La confianza se deposita en un operador con un plazo de actuación limitado —un único slot—, no en un secuenciador permanente.
Beneficios sistémicos: alineación económica, simplicidad y MEV
La eliminación del secuenciador permanente produce tres efectos estructurales en la capa 2.
En primer lugar, la simplicidad arquitectónica. Un based rollup reduce la superficie de ataque y la carga de gobernanza. No necesita gestionar un conjunto de secuenciadores, tokens de staking ni mecanismos de elección de líder. La derivación del estado desde L1 se convierte en el único mecanismo de coordinación.
En segundo lugar, la alineación económica entre L1 y L2. El MEV que se genera en el rollup fluye hacia los proponentes de Ethereum y, por extensión, hacia los stakers de ETH. En el modelo actual, el MEV de las capas 2 es capturado por el operador del secuenciador centralizado, que puede internalizarlo o redistribuirlo según criterios arbitrarios. Con un based rollup, ese valor fortalece la seguridad económica de la propia capa base, lo que refuerza el conjunto del ecosistema sin necesidad de mecanismos adicionales de reparto.
En tercer lugar, la componibilidad síncrona se simplifica. Dado que un mismo proposer ordena transacciones de L1 y del based rollup en una misma ventana de tiempo, es posible ejecutar operaciones atómicas entre dominios sin necesidad de puentes con supuestos de confianza adicionales. Esa propiedad reduce la fragmentación de liquidez y la complejidad de los contratos cross-chain.
La adopción de based rollups no está exenta de limitaciones. El primer desafío es la construcción de bloques en tiempo real. El ejecutor que ensambla el bloque de L2 dispone de una ventana de pocos segundos antes de que el proposer deba sellar el bloque de L1. Para rollups con ejecución compleja o con grandes volúmenes de transacciones, esa restricción temporal exige infraestructura de construcción optimizada y posiblemente hardware especializado. La solución pasa por separar la construcción de la proposición, pero la competencia entre constructores debe ser lo suficientemente líquida para evitar la formación de oligopolios.
El segundo desafío es el MEV entre dominios. Un proposer que controla simultáneamente el orden en L1 y en el based rollup puede extraer valor mediante estrategias que cruzan ambas capas, como la manipulación de precios en un exchange de L1 basándose en información privilegiada de transacciones de L2 que aún no se han hecho públicas. Las técnicas de mitigación incluyen el cifrado de umbral, la separación temporal forzada entre la revelación de transacciones y la ejecución, y mecanismos de subasta de derechos de orden. La investigación en este campo se encuentra en una fase temprana.
El tercer desafío afecta al modelo de negocio de los equipos de L2. Los rollups que operan un secuenciador centralizado obtienen ingresos directos por la captura de MEV y por la diferencia entre el coste de publicar datos en L1 y las tarifas cobradas a los usuarios. En un based rollup, la mayor parte del MEV se redirige a los proponentes de L1. Los equipos desarrolladores necesitarán articular fuentes de ingresos alternativas, como tarifas de inclusión, servicios de construcción de bloques o modelos de suscripción para aplicaciones.
El based rollup de referencia en mainnet es Taiko, un ZK-rollup que implementa la secuenciación basada desde su lanzamiento. Taiko delega la ordenación de transacciones a los proponentes de Ethereum y se apoya en pruebas de validez para garantizar la corrección de las transiciones de estado. El equipo trabaja en preconfirmaciones basadas para mejorar la experiencia de usuario, en colaboración con Spire Labs, que está desarrollando un stack de appchains basadas.
La investigación en el nivel de protocolo de Ethereum también avanza. Propuestas como execution tickets y inclusion lists complementan el diseño de los based rollups, al permitir que los proponentes se comprometan a incluir ciertas transacciones sin el riesgo de censura a largo plazo. La integración de estos mecanismos con la capa de consenso podría formalizar el rol de los proponentes como secuenciadores temporales universales.
Una corrección de incentivos necesaria
La arquitectura de capa 2 de Ethereum se enfrenta a una decisión que definirá su perfil de descentralización durante los próximos años. Mantener secuenciadores centralizados implica aceptar puntos únicos de censura y extracción de rentas, bajo el argumento de una mejor experiencia de usuario. Los based rollups demuestran que esa dicotomía es evitable. Al delegar la secuenciación en los validadores existentes, se obtiene un sistema con resistencia a la censura equivalente a L1, simplicidad de coordinación y un flujo de MEV que refuerza la seguridad de Ethereum.
La viabilidad práctica depende del desarrollo de preconfirmaciones eficientes y de un ecosistema de constructores competitivo. Los equipos que apuesten por este modelo deberán reconfigurar sus fuentes de ingresos. Para un sector que persigue la credibilidad neutral y la alineación con la capa base, los based rollups representan una corrección estructural que elimina uno de los vectores de centralización más persistentes del ecosistema de rollups. La industria dispone ahora de los prototipos y la investigación necesaria para evaluar si esa corrección se convierte en el estándar de diseño de las capas 2.
