Saltar al contenido
Financial Context Wiki

Rollups

Cómo los rollups ejecutan transacciones, publican datos y compromisos, verifican transiciones de estado, liquidan en una capa base e introducen riesgos operativos propios.

Actualizado

Solo con fines educativos; no constituye asesoramiento financiero, de inversión, de puentes ni de seguridad. Las garantías de un rollup dependen de sus contratos desplegados, sistema de pruebas, disponibilidad de datos, permisos del operador, gobernanza y capa base, y todos pueden cambiar.

Respuesta directa

Un rollup es un diseño de escalabilidad de blockchain que ejecuta transacciones fuera de una capa base, pero usa esa capa para publicar datos o compromisos definidos por el protocolo y liquidar transiciones de estado disputadas o demostradas. Muchas transacciones comparten el coste de datos y liquidación de la capa base. Por ello, un rollup es más que compresión de transacciones y una raíz de estado por sí sola no aporta los datos necesarios para reconstruir la cadena.

Los rollups optimistas suelen aceptar afirmaciones de estado salvo que una impugnación mediante prueba de fallo demuestre que la transición no era válida. Los rollups ZK presentan pruebas de validez que verifica el contrato de liquidación. Estas etiquetas describen cómo se aceptan transiciones, no una garantía universal sobre descentralización del secuenciador, almacenamiento, control de actualizaciones, comisiones o tiempo de retiro.

Cómo funciona

  • Ordenar y ejecutar. Un secuenciador u otro mecanismo selecciona y ordena transacciones y calcula el estado resultante. El usuario puede recibir un comprobante rápido antes de la confirmación en la capa base.
  • Publicar datos. El sistema publica suficientes datos de entrada en la capa base, normalmente como calldata o blobs, o utiliza otro diseño de disponibilidad. Esta determina si nodos independientes pueden reconstruir y verificar el estado.
  • Comprometer el estado. El rollup publica raíces de estado u otros compromisos que lo vinculan con un resultado de ejecución. El compromiso es compacto, pero no es el historial de transacciones subyacente.
  • Verificar transiciones. El diseño optimista depende de una ventana de impugnación y un proceso de pruebas de fallo desplegado; el ZK depende de una prueba de validez y un verificador en cadena. En ambos importan los errores, permisos y disponibilidad del sistema de pruebas.
  • Liquidar y retirar. Los contratos de la capa base determinan cuándo se acepta una afirmación o prueba y cómo finalizan mensajes y activos. Los retiros canónicos pueden sufrir demoras de prueba, impugnación o finalidad; un puente rápido añade un proveedor de liquidez y riesgo de contraparte.
  • Actualizar y recuperar. La gobernanza, consejos de seguridad, guardianes o administradores pueden pausar o actualizar contratos. El bloqueo temporal, vía de escape e inclusión forzada deben comprobarse en el despliegue concreto, no inferirse de su categoría.

Ejemplo

Supongamos que un lote contiene 1,000 transacciones. Los usuarios pagan 0.8 ETH en conjunto, los datos en la capa base cuestan 0.5 ETH y la ejecución del rollup 0.2 ETH. El resto sin explicar es 0.8 - 0.5 - 0.2 = 0.1 ETH, o 0.1 / 1,000 = 0.0001 ETH por transacción antes de generación de pruebas, infraestructura, lotes fallidos, coste de capital y reembolsos. Es una conciliación de costes, no beneficio del operador.

Antes de considerar final el lote, hay que determinar si el comprobante solo está confirmado por el secuenciador, si sus datos y compromiso llegaron a la capa base, si terminó la ventana de prueba de fallo o se aceptó la prueba de validez, y si el mensaje de retiro pasó por separado a ser ejecutable.

Riesgos

  • Un secuenciador centralizado puede censurar, reordenar o detener transacciones temporalmente.
  • La falta o indisponibilidad de datos del lote puede impedir la reconstrucción y las salidas independientes.
  • Los programas de pruebas de fallo, circuitos de validez, verificadores o clientes pueden contener errores.
  • Impugnadores o productores de pruebas pueden estar desconectados, censurados, sin fondos o con permisos incorrectos.
  • La congestión, reorganización o falla de la capa base puede demorar publicación, prueba y liquidación.
  • Claves de actualización, guardianes o gobernanza pueden cambiar código, parámetros o conducta del puente.
  • Los puentes canónicos y mapeos de tokens pueden fallar aunque la ejecución del rollup sea correcta.
  • Comisiones, tiempos de prueba y demoras de retiro varían por despliegue y pueden cambiar tras una actualización.

Errores comunes

  • Todos los rollups almacenan todo para siempre en la capa base. El formato de publicación y las garantías de archivo varían; por ejemplo, los blobs no son almacenamiento permanente.
  • Un comprobante del secuenciador es liquidación final. Puede ser una promesa temprana de orden, no un resultado liquidado en la capa base.
  • ZK significa privacidad. En los rollups ZK, las pruebas de validez demuestran el cálculo correcto; la privacidad es una decisión de diseño separada.
  • Optimista significa que no hay verificación. La corrección depende de datos reproducibles, un sistema de pruebas de fallo operativo y participantes capaces de impugnar afirmaciones inválidas.
  • Las comisiones medias menores eliminan el riesgo operativo. Compartir la liquidación puede reducir costes, pero permanecen las dependencias del secuenciador, pruebas, gobernanza, puente y disponibilidad de datos.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...