--- title: "¿Qué es un ZK rollup? Guía completa de zero-knowledge y rollups-as-a-service (RaaS)" description: "Cómo funcionan los ZK rollups, cómo se comparan con los optimistic rollups, y qué elimina realmente rollups-as-a-service de tu lista de tareas." --- # ¿Qué es un ZK rollup? Guía completa de zero-knowledge y rollups-as-a-service (RaaS) Durante la mayor parte de la última década, la respuesta honesta a "¿deberías construir sobre un ZK rollup?" era "todavía no". Generar una prueba de validez tomaba minutos y costaba dinero real, y ejecutar bytecode EVM ordinario a través de un sistema de pruebas se parecía más a un proyecto de investigación que a un objetivo de despliegue. Eso cambió rápido. En aproximadamente un año, la latencia de generación de pruebas para bloques de Ethereum bajó de 16 minutos a 16 segundos y los costos de generación de pruebas se redujeron 45 veces, según la [hoja de ruta de seguridad del zkEVM de la Ethereum Foundation](https://blog.ethereum.org/2025/12/18/zkevm-security-foundations). Los ZK rollups reemplazan la confianza por la prueba. Lo que queda por decidir no es si la tecnología funciona, sino si operar una cadena propia vale la superficie operativa que conlleva. ## ¿Qué es un ZK rollup? Un [zero-knowledge rollup](https://www.alchemy.com/blog/zero-knowledge-rollups) es un diseño de escalabilidad que ejecuta transacciones fuera de la cadena principal y luego publica una prueba criptográfica de validez en la capa base que demuestra que el estado resultante es correcto. La capa base nunca vuelve a ejecutar esas transacciones. Verifica la prueba. Piénsalo como entregar un examen de matemáticas donde el evaluador revisa un certificado corto en lugar de rehacer cada problema. El certificado es pequeño, verificarlo es rápido, y una respuesta incorrecta no puede producir un certificado válido. Esa asimetría es todo el mecanismo. Verificar una prueba cuesta mucho menos que ejecutar las transacciones detrás de ella, así que un rollup puede impulsar mucho más throughput con la misma capacidad de la capa base. "Zero-knowledge" es un nombre engañoso. Describe el sistema de pruebas, no las propiedades de privacidad de la cadena. Las transacciones en un ZK rollup son públicas por defecto, igual que en Ethereum. Las pruebas establecen que la transición de estado es válida sin que el verificador la vuelva a ejecutar, lo cual es una propiedad de concisión y no de confidencialidad. La privacidad real requiere trabajo adicional deliberado, generalmente cifrado o una capa de privacidad dedicada construida encima. Así que trata a un ZK rollup como una decisión de escalabilidad y finalidad. Si necesitas confidencialidad, ese es un problema de diseño aparte que aún tienes que resolver. ## ¿Cómo funcionan los ZK rollups? Cuatro componentes hacen el trabajo, y se lo pasan entre sí en secuencia. - **El sequencer** acepta transacciones de los usuarios, las ordena y las agrupa en un batch. Esto es lo que le da a los usuarios su confirmación rápida, mucho antes de que algo llegue a la capa base. - **El prover** toma el batch y genera una prueba de validez, generalmente un [SNARK o un STARK](https://www.alchemy.com/overviews/snarks-vs-starks), que atestigua que ejecutar esas transacciones sobre el estado anterior produce el nuevo estado. - **El contrato verificador** vive en la capa base. Verifica la prueba y, si es válida, acepta la nueva raíz de estado como canónica. - **La capa de disponibilidad de datos** almacena suficientes datos de transacciones para que cualquiera pueda reconstruir de forma independiente el estado del rollup y verificar que el operador no está ocultando nada. El estado mismo se rastrea en un [árbol de Merkle](https://www.alchemy.com/docs/what-are-merkle-trees), donde un solo hash raíz compromete cada balance de cuenta y cada slot de contrato. Cada batch aceptado avanza esa raíz, así que la capa base guarda un compromiso pequeño en lugar del estado completo del rollup. Ese último componente, la disponibilidad de datos, es donde la economía cambió más. Los rollups solían pagar por calldata en la capa base para publicar los datos de los batches, lo cual era costoso y quedaba onchain de forma permanente. La actualización Dencun de Ethereum introdujo los blobs en marzo de 2024, un carril de datos separado, con precio independiente y dimensionado exactamente para esta tarea. Los datos de blobs se eliminan después de aproximadamente 18 días en lugar de conservarse para siempre, lo cual es deliberado. Los datos del rollup no necesitan persistir indefinidamente; solo necesitan estar disponibles el tiempo suficiente para que cualquiera pueda descargarlos y reconstruir el estado de la cadena. PeerDAS, la actualización de muestreo de disponibilidad de datos que se lanzó con Fusaka en diciembre de 2025, hizo seguro operar con recuentos de blobs más grandes. Los aumentos de capacidad en sí provinieron de pequeños forks posteriores que solo cambiaron parámetros de los blobs. La disponibilidad de datos ya no es la partida dominante que solía ser. Para un equipo que está calculando el costo de un rollup hoy, la generación de pruebas y las operaciones del sequencer son los costos que importan, y cualquier modelo de costos basado en los supuestos antiguos de calldata estará equivocado por un orden de magnitud. ## ¿Por qué importan los ZK rollups para los builders? Las fees bajan porque el costo de publicar y verificar un batch se amortiza entre todas las transacciones dentro de él. El throughput sube por la misma razón, ya que la capacidad de la capa base limita la verificación de pruebas y no la ejecución de transacciones. Los retiros se liquidan sin una ventana de disputa. Un [optimistic rollup](https://www.alchemy.com/overviews/optimistic-rollups) asume que los batches son válidos a menos que alguien los dispute, así que retiene los retiros durante un período de disputa, convencionalmente siete días. Una prueba de validez ya establece la corrección en el momento en que se verifica, así que no hay nada que esperar. Para cualquier cosa que implique mover valor entre capas, esa diferencia es la que los usuarios realmente sienten. La verificabilidad viene del requisito de disponibilidad de datos. Como los datos del batch se publican, cualquiera puede reconstruir el estado del rollup de forma independiente, así que un operador no puede comprometer un estado falso ni ocultar los datos necesarios para verificarlo. Lo que esto no te da es resistencia a la censura. Un sequencer todavía puede negarse silenciosamente a incluir tu transacción, y ninguna cantidad de datos publicados revela una transacción que nunca fue secuenciada. Esa protección proviene de una ruta de inclusión forzada, donde un usuario envía una transacción directamente al contrato de la capa base y el rollup está obligado a incluirla. Cuando evalúes una cadena, confirma que esa vía de escape existe y que funciona sin la cooperación del operador. Juntos, estos elementos hacen de los ZK rollups una opción razonable por defecto para aplicaciones donde la velocidad de liquidación y el costo por transacción son características del producto y no detalles de implementación. Pagos, exchanges y juegos sienten la diferencia de inmediato. Una aplicación de baja frecuencia probablemente no. ## ¿Cómo dan soporte los ZK rollups a la integración de smart contracts? Probar la ejecución arbitraria de smart contracts es mucho más difícil que probar transferencias simples, razón por la cual los primeros ZK rollups solo soportaban pagos y swaps. Probar bytecode EVM significa expresar cada opcode como restricciones dentro de un sistema de pruebas, y la EVM no fue diseñada con eso en mente. Un [zkEVM](https://www.alchemy.com/overviews/zkevm) es la respuesta, y las implementaciones difieren en cuán de cerca se ajustan a Ethereum. Algunas prueban directamente la capa de ejecución de Ethereum, lo cual maximiza la compatibilidad a costa del rendimiento de la generación de pruebas. Otras ajustan el bytecode o el árbol de estado para hacer la generación de pruebas más barata, lo cual significa que algunos contratos y herramientas necesitan ajustes antes de funcionar. Verifica cualquier zkEVM contra tus dependencias reales en lugar de su etiqueta de compatibilidad. La brecha de rendimiento que hacía de esto un problema de investigación se ha cerrado en gran medida. Los provers ahora manejan el 99% de los bloques de Ethereum en menos de 10 segundos en hardware objetivo, según la Ethereum Foundation, lo cual es una medida de generación de pruebas por bloque y no la cifra de latencia de extremo a extremo citada anteriormente. Su enfoque actual ha pasado de la velocidad a la seguridad. La hoja de ruta publicada establece 128 bits de seguridad demostrable y tamaños de prueba menores a 300 KiB como objetivo para fines de 2026, junto con la verificación formal de la arquitectura de recursión. La velocidad de generación de pruebas ya no es lo que se interpone entre tú y un zkEVM en producción. En su lugar, pregúntale a un equipo qué tan avanzadas están sus pruebas de seguridad. ## ¿Cómo se comparan los ZK rollups con los optimistic rollups? Ambos publican datos de transacciones en una capa base y ambos heredan su seguridad. Difieren en qué le piden a la capa base que crea. Proof model

", tooltip: "", icon: "" }, "2": { title: "

Validity proof with every batch

", tooltip: "", icon: "", }, "3": { title: "

Fraud proof, only if challenged

", tooltip: "", icon: "", }, id: 0, }, { "1": { title: "

Withdrawal to L1

", tooltip: "", icon: "" }, "2": { title: "

Once the proof is verified

", tooltip: "", icon: "", }, "3": { title: "

After the dispute window, conventionally 7 days

", tooltip: "", icon: "", }, id: 1, }, { "1": { title: "

Cost profile

", tooltip: "", icon: "" }, "2": { title: "

Proof generation is the main overhead

", tooltip: "", icon: "", }, "3": { title: "

Cheap to operate, cost sits in the challenge system

", tooltip: "", icon: "", }, id: 2, }, { "1": { title: "

EVM compatibility

", tooltip: "", icon: "" }, "2": { title: "

Varies by zkEVM, strong and improving

", tooltip: "", icon: "", }, "3": { title: "

Near-complete, mature

", tooltip: "", icon: "" }, id: 3, }, { "1": { title: "

Security assumption

", tooltip: "", icon: "" }, "2": { title: "

Cryptographic

", tooltip: "", icon: "" }, "3": { title: "

Economic, requires at least one honest challenger

", tooltip: "", icon: "", }, id: 4, }, ], }} /> Los optimistic rollups son más baratos de operar y tuvieron una gran ventaja inicial en compatibilidad con la EVM, razón por la cual los L2 de propósito general más grandes por actividad siguen siendo optimistic. Los ZK rollups pagan por la generación de pruebas y obtienen a cambio una liquidación más rápida y un modelo de confianza criptográfico en lugar de económico. Ningún lado gana claramente en cargas de trabajo de propósito general en este momento. Elige ZK cuando la liquidación rápida y con confianza minimizada valga la pena pagar el costo de generación de pruebas, y elige optimistic cuando el costo operativo bruto y la máxima compatibilidad con la EVM importen más. ## ¿Qué es rollups-as-a-service \(RaaS\)? Lanzar un rollup solía significar levantar un sequencer, un prover, un contrato de bridge y una vía de disponibilidad de datos por cuenta propia, y luego mantener los cuatro funcionando indefinidamente. Eso es un equipo de cadena, no una feature. Rollups-as-a-service convierte ese stack en algo que un proveedor opera por ti. Eliges un framework, defines tus parámetros, y el proveedor opera el sequencer, el prover, el bridge y la infraestructura de nodos por debajo. Lo que conservas es la cadena misma, incluyendo su token de fees, su política de gas, sus reglas de ordenamiento de transacciones y cualquier lógica de compliance que una cadena compartida nunca aplicaría en tu nombre. La parte del discurso inicial de RaaS que envejeció mal es la sugerencia de que esto es una operación de cinco minutos donde luego puedes desentenderte. Es dramáticamente más rápido que construir desde cero, y elimina la carga de estar de guardia. No elimina las decisiones de arquitectura. Todavía tienes que elegir a qué capa base liquidar, cuál es tu trade-off de disponibilidad de datos, cómo evoluciona la descentralización del sequencer y cómo las actualizaciones del stack subyacente llegan a tu cadena sin romperla. Trata a RaaS como la externalización de las operaciones, no del diseño. Para una mirada más detallada al modelo en sí, lo cubrimos en [rollups-as-a-service](https://www.alchemy.com/overviews/rollups-as-a-service-raas) y [RaaS y appchains](https://www.alchemy.com/overviews/what-are-rollups-as-a-service-appchains). ## ¿Cuándo tiene sentido lanzar tu propio ZK rollup? Un rollup dedicado justifica su complejidad en algunas situaciones específicas. - **Volumen de transacciones predecible y alto.** Una vez que estás pagando consistentemente por mucho blockspace, la capacidad dedicada empieza a tener mejor precio que competir por capacidad compartida. - **Un requisito de compliance que una cadena compartida no puede cumplir.** Participantes en allowlist, políticas a nivel de transacción o restricciones jurisdiccionales son aplicables en una cadena que controlas y en ningún otro lugar. - **Una experiencia de producto que depende de blockspace dedicado.** Si tus tiempos de confirmación no pueden degradarse porque un mint no relacionado está congestionando la red, compartir blockspace es un pasivo. Es la decisión equivocada cuando el volumen es especulativo. Un proveedor gestionado absorbe la carga operativa, pero de todas formas heredas la seguridad del bridge, la disponibilidad del sequencer y un ritmo de actualizaciones que tienes que rastrear. Esa superficie vale la pena asumirla frente a demanda real, no demanda proyectada. Vale la pena leer el [modelo de negocio de los rollups](https://www.alchemy.com/overviews/the-business-model-of-rollups) antes de comprometerte, ya que una cadena tiene que justificar su costo operativo. A la mayoría de los equipos les conviene más lanzar primero sobre una cadena establecida a través de [acceso RPC](https://www.alchemy.com/rpc-api) estándar, y revisitar la decisión una vez que los patrones de uso lo justifiquen. Postergar la decisión te cuesta muy poco. Deshacer una cadena que no debiste haber lanzado cuesta mucho. ## Preguntas frecuentes sobre zero-knowledge rollups ### ¿Qué es un ZK rollup? Un ZK rollup es una solución de escalabilidad de Layer 2 que ejecuta transacciones offchain en batches y publica una prueba criptográfica de validez en la capa base que demuestra que el estado resultante es correcto. La capa base verifica la prueba en lugar de volver a ejecutar las transacciones, lo cual reduce el costo y aumenta el throughput mientras hereda la seguridad de la capa base. ### ¿Cómo funcionan los ZK rollups? Un sequencer agrupa transacciones en batches, un prover genera una prueba de validez como un SNARK o STARK, y un contrato verificador en la capa base verifica esa prueba antes de aceptar la nueva raíz de estado. Los datos de las transacciones se publican para que cualquiera pueda reconstruir el estado del rollup de forma independiente. Los rollups de Ethereum ahora publican esos datos en blobs en lugar de calldata. ### ¿Son privados los ZK rollups? No, no por defecto. "Zero-knowledge" describe el sistema de pruebas, que le permite a un verificador confirmar que una transición de estado es válida sin volver a ejecutarla. Las transacciones en un ZK rollup son visibles públicamente, igual que en Ethereum. La confidencialidad requiere una capa de privacidad adicional construida deliberadamente encima. ### ¿En qué se diferencian los ZK rollups de los optimistic rollups? Los ZK rollups prueban que cada batch es válido, así que los retiros se liquidan tan pronto se verifica la prueba. Los optimistic rollups asumen que los batches son válidos a menos que se disputen, razón por la cual los retiros esperan una ventana de disputa, convencionalmente siete días. Los ZK rollups dependen de garantías criptográficas; los optimistic rollups dependen de incentivos económicos y de al menos un challenger honesto. ### ¿Cuáles son algunos proyectos de ZK rollup destacados? ZKsync Era, Starknet, Scroll y Linea son los ZK rollups de propósito general que la mayoría de los equipos evalúan, con Scroll y Linea apuntando ambos a una equivalencia cercana con la EVM. Starknet actualmente tiene la calificación Stage 1 de L2Beat, aunque se espera una baja a Stage 0 a medida que entren en vigor reglas más estrictas; Scroll, ZKsync Era y Linea están todos en Stage 0. El sequencer de Mainnet Beta de Polygon zkEVM se retiró el 1 de julio de 2026, con Polygon redirigiendo esfuerzos hacia Polygon PoS y Agglayer. ### ¿Pueden ejecutarse smart contracts en ZK rollups? Sí, a través de implementaciones de zkEVM que prueban la ejecución de la EVM. La compatibilidad varía. Algunos zkEVM prueban directamente la capa de ejecución de Ethereum para máxima compatibilidad, mientras que otros modifican el bytecode o la estructura de estado para hacer la generación de pruebas más barata, lo cual puede requerir ajustar contratos o herramientas. Verifica la compatibilidad contra tus dependencias reales en lugar de una afirmación general. ### ¿Qué significa rollups-as-a-service \(RaaS\)? Rollups-as-a-service significa que un proveedor opera el sequencer, el prover, el bridge y la infraestructura de nodos de un rollup que tú configuras y posees. Elimina la carga operativa de correr una cadena. No elimina las decisiones de arquitectura, incluyendo la elección de capa base, los trade-offs de disponibilidad de datos, la descentralización del sequencer y cómo las actualizaciones del stack llegan a tu cadena. ### ¿Qué hace seguros a los ZK rollups? Los ZK rollups heredan la seguridad de la capa base. Los fondos se mantienen en contratos de la capa base, y una nueva raíz de estado solo se acepta cuando se verifica una prueba válida onchain, así que un operador no puede comprometer un estado inválido. Publicar los datos del batch por separado asegura que cualquiera pueda reconstruir ese estado de forma independiente y detectar a un operador ocultando los datos. Resistir la censura de transacciones individuales es una garantía separada que depende de una ruta de inclusión forzada hacia la capa base.