Qué es un rollup y por qué Bitcoin lo necesitaba

El problema de escalabilidad de Bitcoin

Bitcoin está diseñado para priorizar la verificabilidad, la descentralización y la resiliencia, no para maximizar el número de transacciones por segundo. Cada nodo completo valida las transacciones conforme a las reglas del protocolo. En la capa base, la capacidad es limitada y suele expresarse de forma aproximada en torno a 7 transacciones por segundo, aunque la cifra efectiva depende del tipo y del tamaño de las transacciones.

Durante años el debate se redujo a una sola pregunta: ¿cómo ampliar la capacidad de Bitcoin sin romper aquello que lo hace singular?

Los caminos ya recorridos

La primera respuesta fue la Lightning Network, operativa desde 2018: una red de canales de pago que permite realizar pagos rápidos y generalmente de bajo coste, incluso mediante rutas formadas por varios canales. Está orientada principalmente a los pagos y no ofrece un entorno generalista de smart contracts. Además, su funcionamiento depende de la liquidez disponible y de la capacidad de encontrar una ruta adecuada.

Stacks planteó un enfoque distinto: una red de smart contracts vinculada a Bitcoin mediante PoX y dotada de su propio lenguaje, Clarity. Su modelo de seguridad y su finalidad difieren de los de Bitcoin y dependen también de las reglas de la propia red Stacks.

Rootstock (RSK) optó por la compatibilidad con la EVM y por el merge-mining con Bitcoin. Está operativa desde 2018 y utiliza un modelo de sidechain con sus propios supuestos de seguridad y de puente.

Por qué un rollup es diferente

Un rollup no es una sidechain. La distinción técnica es relevante:

• - Una sidechain mantiene su propio mecanismo de consenso o validación. Su seguridad depende principalmente de ese sistema y del diseño del puente que la conecta con Bitcoin.
• - En el diseño descrito para Bitcoin Hyper, la ejecución tendría lugar fuera de Bitcoin y se publicarían compromisos de estado en la capa base. La clasificación efectiva como rollup dependerá también de la disponibilidad de los datos y del sistema de pruebas.

Según la arquitectura publicada por el proyecto, el proceso previsto sería el siguiente:

1. Los usuarios enviarían sus transacciones al sequencer
2. El sequencer las ordenaría y ejecutaría por lotes
3. Periódicamente se publicaría en Bitcoin un state commitment, descrito como una raíz de Merkle del estado actualizado, mediante OP_RETURN o Taproot
4. La posibilidad de verificar la transición dependería de la disponibilidad de los datos y del sistema de pruebas; el compromiso por sí solo no demuestra que la transición sea correcta

Una vez confirmado en Bitcoin, un state commitment queda protegido por la inmutabilidad práctica de la transacción que lo contiene. Esto dificulta alterar retrospectivamente ese registro, pero no impide por sí solo que se publique un compromiso incorrecto ni garantiza la corrección del estado, la disponibilidad de los datos o la seguridad del puente.

La disponibilidad de datos: la cuestión aún abierta

El punto crítico es el siguiente: ¿dónde residen realmente los datos de las transacciones? Si en Bitcoin solo se publica el compromiso mientras los datos completos permanecen en manos del sequencer, el diseño se aproximaría a un esquema de tipo validium más que a un rollup con disponibilidad de datos pública. La distinción no es académica: si el sequencer desapareciera con los datos, los usuarios podrían no estar en condiciones de demostrar su propio saldo.

Según la documentación publicada por el proyecto, la solución definitiva de disponibilidad de datos continúa siendo objeto de investigación; así se indica en una actualización fechada el 27 de marzo de 2026. Entre las opciones exploradas se mencionan capas externas de disponibilidad de datos, como Celestia, el erasure coding y el recurso a nodos distribuidos.

En resumen

Un rollup sobre Bitcoin puede perseguir varios objetivos de diseño: utilizar Bitcoin para registrar compromisos de estado; ampliar la capacidad mediante ejecución fuera de la cadena; ofrecer un entorno de smart contracts; y reducir los costes para el usuario. El grado en que estos objetivos puedan alcanzarse depende de la implementación concreta, de la disponibilidad de los datos, del sistema de pruebas y de los mecanismos de salida.

El coste de este enfoque es una mayor complejidad arquitectónica y varios compromisos de diseño todavía abiertos: el sequencer, la disponibilidad de los datos, el puente y el sistema de pruebas. El proyecto sostiene que estos elementos podrán gestionarse con el tiempo; se trata de una posición del propio proyecto, pendiente de verificación independiente.