Saltar al contenido
Financial Context Wiki

Rollups ZK

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.

Actualizado

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.

1
Ejecutar

El probador ejecuta un lote o cálculo y registra la transición de estado.

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

Fuentes

Navegación

Buscar en la wiki...