--- title: "Rollups ZK" description: "Guía centrada en la verificación de lotes, pruebas de validez, disponibilidad de datos, estados de liquidación, comisiones, retiros y riesgos de cada despliegue ZK rollup." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Rollups ZK > Solo con fines educativos; no constituye asesoramiento de inversión, puentes ni seguridad. Un ZK rollup solo es tan fiable como su programa demostrado, entradas públicas, ruta de disponibilidad de datos, contratos, operadores, gobernanza y cadena de liquidación. ## Respuesta directa Un ZK rollup, más precisamente un rollup de validez, ejecuta transacciones fuera de una cadena de liquidación, las agrupa en lotes y envía compromisos de datos, declaraciones de estado y pruebas de validez a contratos de esa cadena. El verificador comprueba que el lote sigue las reglas de transición codificadas sin volver a ejecutar cada transacción. Así se reparten entre muchas transacciones los costes de publicar datos y verificar pruebas. La garantía es específica, no absoluta. Una prueba verificada solo respalda la afirmación codificada por el programa desplegado y vinculada por las entradas públicas. Por sí sola no demuestra que los datos puedan recuperarse, que el secuenciador sea activo o justo, que el bloque de liquidación sea final, que el puente sea correcto ni que una actualización sea segura. “ZK” tampoco implica privacidad: muchos rollups de validez publican transacciones o diferencias de estado y exponen la actividad. ## Cómo funciona 1. Identifique el despliegue: ID de las cadenas L1 y L2, contratos del rollup y del puente, verificador y versión de la clave, programa o circuitos demostrados, formato de lote, modo de disponibilidad de datos, secuenciador, probador, administradores, poderes de pausa y bloque observado. El nombre de una pila no prueba que todos sus despliegues ofrezcan las mismas garantías. 2. Separe ordenación y prueba. Un secuenciador puede emitir un recibo rápido y construir bloques L2 antes de que el compromiso de datos o la prueba llegue a L1. Registre el lote exacto y distinga los estados ordenado, comprometido, demostrado, aceptado, seguro en liquidación, finalizado en liquidación y retiro completado. 3. Reconstruya el lote. Obtenga las transacciones, diferencias de estado, blob sidecars u otra carga exigida; verifique orden y compromisos; derive después las raíces de estado anterior y posterior, la raíz de retiros o mensajes y las demás entradas públicas. Una prueba vinculada a otra cadena, lote o raíz demuestra otra afirmación. 4. Verifique la ruta de la prueba. Confirme que la transacción de liquidación llamó al verificador previsto con la prueba, clave y entradas esperadas, tuvo éxito, emitió el evento correcto y actualizó la ranura de estado adecuada. Cuando sea posible, reproduzca verificación y ejecución con software independiente. 5. Audite por separado la disponibilidad de datos. Los blobs de Ethereum ofrecen disponibilidad durante la ventana del protocolo y compromisos, no recuperación archivística permanente. Un comité externo o una capa DA alternativa añade sus propios supuestos. La validez de la prueba no restaura datos necesarios para reconstruir el estado o salir. 6. Siga depósitos y retiros de extremo a extremo. Concilie token y mensajero canónicos, importe, destino, nonce del mensaje, raíz de inclusión, prueba, regla de finalidad y cambio de saldo ejecutado. Un puente rápido adelanta liquidez con precios, rutas y riesgo de contraparte propios; no acorta el reloj canónico. 7. Vigile actividad y control. Mida colas de lotes y pruebas, rutas de inclusión forzada y escape, diversidad de probadores, actualizaciones, bloqueos temporales, guardianes y modos de emergencia. Repita el análisis tras cambiar contrato, circuito, clave, modo DA o protocolo. ## Ejemplos calculados - **Compresión.** Un lote didáctico contiene `10,000 transactions`; `1,200 KB` de entrada bruta se comprimen a `300 KB`. La razón es `1,200 / 300 = 4.0x`, la reducción `1 - 300 / 1,200 = 75%` y el promedio decimal `300,000 / 10,000 = 30 bytes/transaction`. No miden solidez de la prueba, crecimiento del estado ni archivo. - **Asignación de costes.** Los usuarios pagan `3.0 ETH`; publicar datos en L1 cuesta `1.4 ETH`, verificar la prueba `0.4 ETH` y ejecutar en L2 `0.2 ETH`. El residuo es `3.0 - 1.4 - 0.4 - 0.2 = 1.0 ETH` y el promedio `3.0 / 10,000 = 0.0003 ETH/transaction`. No es beneficio neto: omite prueba, hardware, envíos fallidos, puentes, capital e impuestos. - **Ciclo de vida.** La cartera recibe el recibo en `minute 0`; el compromiso llega a L1 en `minute 12`; la prueba se acepta en `minute 50`; la política de finalidad se cumple en `minute 64`; y el retiro canónico se ejecuta en `minute 70`. El tiempo secuencial es `12 + 38 + 14 + 6 = 70 minutes`. Ningún momento anterior equivale al retiro completado. ## Riesgos - Cadena, despliegue, contrato, lote, raíz, verificador, clave o circuito equivocados. - Programa demostrado incompleto o incorrecto que un sistema sólido prueba fielmente. - Entradas públicas, separadores de dominio, mensajes o parámetros ausentes o mal codificados. - Vulnerabilidades del verificador, precompilado, puente, mensajero o contrato de estado. - Material de configuración comprometido o supuestos criptográficos rotos. - Censura, reordenación, contradicción, caída o publicación tardía del secuenciador. - Caída, centralización, censura, falta de capacidad o cola creciente del probador. - Transacciones, diferencias de estado o blob sidecars no disponibles, malformados o sin archivar. - Confundir compromiso de datos o firma de comité con recuperabilidad actual. - Reorganización de L1 o confianza prematura en una transacción de liquidación insegura. - Actualizaciones privilegiadas, bloqueos cortos, sustitución del verificador, pausas o atajos. - Inclusión forzada, recuperación o escape ausentes, desactivados o inutilizables. - Fallos del puente canónico, mapeo de tokens, repetición, mensajes o pruebas de retiro. - Riesgos de liquidez, precio, ruta, insolvencia y contraparte de puentes rápidos. - Estimaciones que omiten datos L1, pruebas, puentes, congestión o transacciones fallidas. - Suponer que compatibilidad EVM, finalidad, privacidad o seguridad de un rollup vale para otro. ## Errores comunes - Todo ZK rollup oculta importes, direcciones y actividad de aplicaciones. - Una prueba válida garantiza datos disponibles y reconstrucción del estado. - Un recibo del secuenciador equivale a prueba aceptada en L1 o retiro finalizado. - Las pruebas de validez eliminan riesgos de secuenciador, probador, gobernanza, actualización y puente. - El sistema de prueba más barato o rápido produce automáticamente el resultado más seguro. ## Temas relacionados - [Prueba de validez](/es/crypto/validity-proof/) - [Disponibilidad de datos](/es/crypto/data-availability/) - [Capa 2](/es/crypto/layer2/) - [Rollup](/es/crypto/rollup/) - [Prueba de conocimiento cero](/es/crypto/zero-knowledge-proof/) ## Fuentes - [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org (consultado: 2026-08-22) - [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org (consultado: 2026-08-22) - [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (consultado: 2026-08-22) - [Rollup Process](https://docs.scroll.io/en/technology/chain/rollup/) - Scroll Documentation (consultado: 2026-08-22) - [Data availability](https://docs.starknet.io/learn/protocol/data-availability) - Starknet Documentation (consultado: 2026-08-22) Source: https://wiki.fcontext.com/es/crypto/zk-rollup/index.mdx