Saltar al contenido
Financial Context Wiki

Optimistic rollups

Guía específica por despliegue sobre recibos del secuenciador, datos de derivación en L1, cabeceras unsafe/safe/finalized, juegos de fault proofs, retiros canónicos, gobernanza y salidas rápidas.

Actualizado

Solo con fines educativos; no constituye asesoramiento ni recomendación de inversión. Las inversiones pueden ocasionar pérdidas.

Respuesta directa

Un optimistic rollup ejecuta un flujo ordenado de transacciones y publica datos de derivación y afirmaciones de estado definidos por el protocolo, sin adjuntar una prueba de validez a cada lote. «Optimistic» significa que una afirmación admisible puede avanzar conforme a las reglas desplegadas, salvo que una disputa de fault proof resuelta con éxito demuestre que es errónea. No significa que un mensaje del secuenciador pruebe la corrección, ni que toda implementación admita impugnaciones sin permiso o tenga el mismo plazo de retiro.

Los nodos del rollup derivan de forma independiente los bloques L2 a partir de entradas L1 canónicas y de la configuración exacta del protocolo. Por tanto, la ruta de seguridad comprende disponibilidad de datos, derivación y ejecución correctas, un sistema de fault proofs activo y sólido, acceso y finalidad de L1, gobernanza y contratos del puente. Una raíz de estado por sí sola no basta para reconstruir la cadena ni impugnar una transición inválida.

1
Secuenciar

El secuenciador ordena transacciones L2 y publica datos o compromisos.

Cómo funciona

  1. Fije el despliegue: identificadores de cadena L1 y L2, configuración y fork del rollup, contratos de inbox y puente, formato de lote y modo de DA, contratos de afirmación de estado y juego de disputa, versión del portal, administradores, guardianes y bloque de observación. La documentación de un stack no demuestra que cada función esté activa en una cadena concreta.
  2. Clasifique el estado observado. Un recibo del secuenciador o bloque unsafe es un compromiso local y rápido de ordenación; un lote publicado en L1 puede sustentar una cabecera derivada safe; la finalidad de L1 puede sustentar una cabecera derivada finalized. Una afirmación de estado o de salida, una disputa resuelta y un retiro ejecutable son objetos y relojes distintos.
  3. Reconstruya el proceso de derivación de L1 a L2. Verifique depósitos y entradas secuenciadas, canales y lotes, orígenes L1, cambios de configuración y transiciones de estado a partir de datos L1 canónicos. Para datos respaldados por blobs, distinga la disponibilidad durante la ventana del protocolo de la recuperación archivística posterior.
  4. Trace la vivacidad y el control. Separe secuenciador, batcher, proponente, impugnador, relayer, guardián y autoridad de actualización; compruebe si existen rutas de inclusión forzada o delayed inbox, sus demoras y condiciones de pausa, y si los usuarios ordinarios disponen de software operativo para invocarlas.
  5. Verifique la ruta de fault proofs desplegada. Registre el tipo de juego reconocido, permisos de propuesta e impugnación, bonds, preestado absoluto, programa de prueba y VM, oráculo de preimágenes, profundidad de la afirmación, relojes y extensiones, reglas de resolución, facultades de blacklist o pausa y demora de actualización. No trasplante la mecánica de OP Stack a Arbitrum ni a otro rollup.
  6. Siga por separado los retiros y su economía. Recorra iniciación en L2, prueba en L1, dependencia de afirmación o juego, demora de madurez y finalidad, repetición de la prueba, controles del portal y ejecución en L1. Trate una salida rápida como una operación de liquidez o crédito con precio y contraparte propia, no como un acortamiento del reloj canónico de impugnación.
  7. Concilie continuamente. Compare hashes de bloques unsafe, safe y finalized, transacciones de lote en L1, afirmaciones de estado, resultados de juegos, mensajes de puente, recibos, contratos de tokens y saldos finales. Reabra el análisis tras una reorganización L1 o L2, lote ausente, disputa, pausa, actualización contractual o migración de DA.

Ejemplos resueltos

  • Payload de derivación. Un lote contiene 10,000 transacciones, 1,200 KB de entradas de protocolo sin comprimir y 300 KB tras la compresión. La razón es 1,200 / 300 = 4.0x, la reducción es 1 - 300 / 1,200 = 75% y el promedio decimal es 300,000 / 10,000 = 30 bytes/tx. Estas cifras solo describen el payload de entrada codificado, no el gas L1, la corrección de la ejecución, el tamaño del estado ni las garantías de archivo.
  • Contribución antes de costes omitidos. Los usuarios pagan 2.4 ETH; la ejecución L2 medida cuesta 0.3 ETH; la DA en L1 cuesta 1.2 ETH. El residual es 2.4 - 0.3 - 1.2 = 0.9 ETH, o 0.9 / 10,000 = 0.00009 ETH/tx. No es beneficio neto porque excluye infraestructura del operador, ejecución L1, juegos de prueba, reembolsos, capital, fallos e impuestos.
  • Localización de una disputa. Una traza didáctica de ejecución tiene 2^20 = 1,048,576 pasos. Un estrechamiento binario ideal requiere log2(2^20) = 20 elecciones para aislar un paso. Si cada ronda didáctica tuviera un máximo independiente de 3-hour, un límite serial ingenuo sería 20 * 3 = 60 hours; los protocolos reales aplican sus propios relojes de ajedrez, concurrencia, extensiones y calendario de transacciones.
  • Relojes de retiro y liquidez rápida. Un lote didáctico llega a L1 después de 10 minutes, aparece una afirmación reconocida tras otros 30 minutes, un período hipotético de impugnación dura 7 days y el relay final tarda 2 hours. El tiempo secuencial es 10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes. Un puente de liquidez que anticipa 4.97 ETH contra una afirmación de 5 ETH cobra 0.03 ETH, es decir, 0.03 / 5 = 0.6%, mientras la afirmación canónica sigue sujeta a sus relojes y riesgos originales.

Riesgos

  • L1, L2, identificadores de cadena, configuración o contratos equivocados.
  • Tratar un recibo unsafe del secuenciador como safe o final.
  • Equivocación, censura, reordenación o caída del secuenciador.
  • Publicación L1 del lote demorada, ausente, malformada o inválida.
  • Datos de blobs o DA alternativa no disponibles o no archivados.
  • Incompatibilidad del cliente de derivación, configuración o fork.
  • Reorganización L1 que invalida entradas antes consideradas safe.
  • Caída del batcher, proponente de estado o participante de pruebas.
  • Ruta de inclusión forzada o delayed inbox ausente, pausada o mal entendida.
  • Fault proofs no desplegados, inactivos o vinculados al tipo de juego incorrecto.
  • Funciones de proponente o impugnador con permiso o allowlist.
  • Impugnador desconectado, censurado, sin fondos o fuera de plazo.
  • Error en programa de prueba, VM, preestado absoluto, oráculo o verificador.
  • Error de reloj, extensión, posición de afirmación, bond o contabilidad de resolución.
  • Intervención de guardián, consejo de seguridad, pausa o blacklist.
  • Actualización inmediata, timelock corto o claves administrativas comprometidas.
  • Vulnerabilidad del puente canónico, mensajero, replay o mapeo de activos.
  • Fallo de prueba, madurez, nueva prueba, finalización o relay del retiro.
  • Riesgo de liquidez, precio, ruta, insolvencia o contraparte en la salida rápida.
  • Confundir finalidad L1, finalidad L2 derivada, resolución de la afirmación y recepción del activo.

Errores comunes

  • Optimistic significa que los usuarios confían incondicionalmente en el resultado mostrado por el secuenciador.
  • Publicar solo una raíz de estado aporta disponibilidad de datos y derivación independiente.
  • Todo optimistic rollup tiene fault proofs sin permiso activos y un reloj universal de siete días.
  • Un bloque L2 safe o finalized implica que su retiro de L2 a L1 ya puede ejecutarse.
  • Un puente rápido acorta el período canónico de impugnación o solo soporta riesgo del rollup.

Temas relacionados

Fuentes

Navegación

Buscar en la wiki...