Arquitectura de ZK Rollup: cómo las pruebas de validez liquidan lotes y cómo verificarlas

Alcance y el modelo mental básico

Un zk-rollup es una construcción de capa 2 en la que la ejecución de transacciones ocurre fuera de la cadena base, pero la corrección se impone en cadena mediante una prueba sucinta. El contrato del rollup en la cadena base almacena una raíz de estado. Para avanzar esa raíz, un operador envía un compromiso de lote más una prueba de validez; el contrato verifica la prueba y, si es válida, actualiza la raíz. Dado que la cadena base comprueba la prueba, los usuarios no necesitan confiar en la honestidad del operador para la corrección del estado, solo para el liveness y el comportamiento de censura.

Este artículo trata los zk rollups como una arquitectura en lugar de un producto único. Los diferentes zk-rollups varían en el sistema de prueba (SNARK o STARK), la estrategia de disponibilidad de datos (calldata, blobs o una capa DA separada) y la máquina virtual (equivalente a EVM o personalizada). El flujo de verificación a continuación está escrito para que pueda adaptarse a cualquier rollup que exponga JSON-RPC estándar y una dirección de contrato en la cadena base.

La pregunta práctica que responde esta guía es: dado un endpoint RPC del rollup y un endpoint RPC de la cadena base, ¿cómo se observa un lote, se confirma que la prueba fue aceptada y se concilia el estado reportado por el rollup con el contrato de la cadena base?

• Ejecución: fuera de cadena, realizada por un secuenciador o una red de probadores.
• Liquidación: en la cadena base, mediante un contrato verificador.
• Disponibilidad de datos: datos de transacción publicados para que el estado pueda reconstruirse.
• Finalidad: alcanzada cuando la prueba de validez se verifica en cadena.

Requisitos previos y suposiciones

Necesita dos endpoints RPC: uno para la red del rollup y otro para su cadena base (por ejemplo, la red principal de Ethereum). También necesita la dirección del contrato de liquidación del rollup y, idealmente, el ABI para su evento de envío de lotes. Estos se publican en la documentación de cada rollup; esta guía no asume un rollup específico.

Los procedimientos utilizan curl y Python con solo bibliotecas estándar más una llamada HTTP. Reemplace RPC_URL, BASE_RPC_URL y ROLLUP_CONTRACT con valores de la red que está inspeccionando. Nunca pegue una clave privada en el historial de shell; para la verificación de solo lectura no se requiere ninguna clave.

Si está eligiendo un endpoint en lugar de verificarlo, la decisión concreta del proveedor corresponde a RPC Assistant; esta página se mantiene en la metodología. Para un marco más amplio de selección de endpoints, consulte la guía de endpoints RPC y la descripción general de endpoints RPC multicadena.

• URL RPC del rollup (solo lectura es suficiente).
• URL RPC de la cadena base.
• Dirección del contrato de liquidación y tópico del evento de lote.
• Un rango de bloques que contenga al menos un envío de lote conocido.

Cómo un lote de zk-rollup pasa de la ejecución a la finalidad

El ciclo de vida tiene cinco etapas. Primero, los usuarios envían transacciones al rollup, donde un secuenciador las ordena. Segundo, el secuenciador ejecuta el lote contra el estado actual, produciendo una nueva raíz de estado y una lista de diferencias de estado. Tercero, un probador genera una prueba de validez que certifica que ejecutar el lote sobre el estado anterior produce la nueva raíz. Cuarto, el operador publica los datos de transacción comprimidos y la prueba en la cadena base. Quinto, el contrato verificador comprueba la prueba y, si tiene éxito, escribe la nueva raíz.

La distinción entre zk-rollups y optimistic rollups está en la quinta etapa. Los optimistic rollups aceptan la raíz de inmediato y dependen de una ventana de prueba de fraude durante la cual cualquiera puede impugnar. Los zk-rollups aceptan la raíz solo después de la verificación de la prueba, por lo que los retiros no necesitan un período de desafío una vez que la prueba se establece. Es por eso que a los zk-rollups a veces se les llama rollups de validez.

La disponibilidad de datos es un eje separado de la validez. Una prueba puede ser válida mientras los datos de transacción subyacentes se retienen, lo que impediría a los usuarios reconstruir el estado o salir de forma independiente. Los zk-rollups maduros publican suficientes datos en la cadena base (calldata o blobs) para reconstruir el estado. Al evaluar un zk-rollup, verifique tanto el sistema de prueba como el compromiso de DA.

Observación de envíos de lotes a través del RPC de la cadena base

La verificación más directa es leer los registros del contrato de liquidación. Los envíos de lotes suelen emitir un evento que contiene la raíz de estado anterior, la nueva raíz de estado y un compromiso con los datos del lote. La firma exacta del evento difiere según el rollup, así que obtenga el ABI del repositorio del proyecto y calcule el tópico con keccak256.

El siguiente script de Python consulta los registros de un contrato y tópico dados en un rango de bloques. Imprime cada registro coincidente para que pueda inspeccionar los campos de la raíz de estado. No decodifica la carga útil, porque la decodificación depende del ABI del rollup; ese es el siguiente paso.

import json, urllib.request

BASE_RPC_URL = "BASE_RPC_URL"
ROLLUP_CONTRACT = "ROLLUP_CONTRACT"
TOPIC0 = "BATCH_EVENT_TOPIC"
FROM_BLOCK = "0x0"
TO_BLOCK = "latest"

def rpc(method, params):
    body = json.dumps({"jsonrpc":"2.0","id":1,"method":method,"params":params}).encode()
    req = urllib.request.Request(BASE_RPC_URL, data=body, headers={"Content-Type":"application/json"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.loads(r.read())["result"]

logs = rpc("eth_getLogs", [{
    "address": ROLLUP_CONTRACT,
    "fromBlock": FROM_BLOCK,
    "toBlock": TO_BLOCK,
    "topics": [TOPIC0]
}])

for log in logs:
    print(log["transactionHash"], log["blockNumber"], log["data"][:130])

Conciliación de la raíz de estado del rollup con la cadena base

Después de obtener un hash de transacción de lote, obtenga el recibo de la transacción en la cadena base y confirme el estado 0x1. Luego lea la raíz de estado actual del rollup desde el RPC del rollup (muchos exponen un método como un getter de raíz de estado o una etiqueta de bloque) y compárela con la última raíz registrada por el contrato de liquidación. Una discrepancia significa que está leyendo alturas de bloque diferentes o que el RPC del rollup está retrasado.

Las siguientes llamadas curl ilustran el patrón de lectura. La primera obtiene el recibo; la segunda llama a un método RPC del rollup. Reemplace el nombre del método por el que documente su rollup.

curl -s -X POST "$BASE_RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["BATCH_TX_HASH"]}'

curl -s -X POST "$RPC_URL" \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"ROLLUP_STATE_ROOT_METHOD","params":["latest"]}'

Una tabla de resultados para registrar ejecuciones de verificación

Registre cada ejecución de verificación en una tabla para que los resultados sean comparables entre rollups y a lo largo del tiempo. No complete números que no haya medido; deje las celdas en blanco hasta que finalice la ejecución. A continuación se sugiere un esquema, seguido del procedimiento para completarlo.

Procedimiento: (1) elija un hash de transacción de lote de la consulta de registros; (2) registre el número de bloque de la cadena base y el estado del recibo; (3) registre la altura de bloque del RPC del rollup en el mismo momento; (4) lea la raíz de estado de ambas fuentes; (5) marque coincidencia o discrepancia; (6) anote el tiempo real entre la inclusión del lote y su lectura. Repita en tres momentos diferentes del día para exponer patrones de retraso del RPC.

• | Ejecución | Tx de lote | Bloque base | Estado del recibo | Altura del rollup | Coincidencia de raíz | Retraso observado |
• |-----|----------|------------|----------------|---------------|------------|--------------|
• | 1 | | | | | | |
• | 2 | | | | | | |
• | 3 | | | | | | |

Resultado esperado de la verificación y qué le indica

Una ejecución saludable muestra un recibo exitoso en la cadena base, una altura del RPC del rollup igual o superior a la altura del lote en el rollup, y raíces de estado idénticas del RPC del rollup y del contrato de liquidación en la misma altura. Si las raíces coinciden, la transición verificada por la prueba se refleja de manera consistente en ambas fuentes de datos.

Si el recibo tiene éxito pero las raíces difieren, primero confirme que está comparando la misma altura de bloque. Los RPC del rollup y de la cadena base avanzan de forma independiente, y un nodo de rollup retrasado puede reportar una raíz más antigua. Vuelva a leer ambos en una altura fijada antes de concluir que hay un problema. Una discrepancia persistente en una altura fijada es una señal grave y justifica revisar la página de estado del rollup y el historial de eventos del contrato.

Si el recibo falla, la prueba fue rechazada o la transacción se revirtió; el lote no se finalizó. Inspeccione el motivo de la reversión y el estado público del probador si está disponible.

Solución de problemas comunes de verificación

La mayoría de las fallas son de observación más que de nivel de protocolo. La siguiente tabla asigna síntomas a causas probables y la siguiente comprobación a realizar.

Para problemas de confiabilidad a nivel de endpoint, como tiempos de espera o respuestas inconsistentes, el enfoque de solución de problemas es el mismo que para cualquier carga de trabajo JSON-RPC: compare dos endpoints independientes, fije alturas de bloque y registre los ID de solicitud. Si necesita una recomendación concreta de endpoint en lugar de un método, RPC Assistant lo cubre por separado.

• Resultado de registro vacío: dirección de contrato incorrecta, tópico incorrecto o rango de bloques fuera de la ventana del lote.
• Recibo no encontrado: transacción aún pendiente o enviada a un ID de cadena diferente.
• Discrepancia de raíz: discrepancia de altura, RPC del rollup retrasado o una reorganización en la cadena base.
• Error de decodificación: el ABI no coincide con la versión del contrato desplegado.
• Tiempo de espera: límite de tasa del endpoint o sobrecarga; reintente con retroceso exponencial y un segundo endpoint.

Limitaciones y compensaciones de los zk-rollups

Las pruebas de validez brindan garantías de corrección sólidas, pero no son gratuitas. La prueba es computacionalmente pesada y el costo de prueba escala con la complejidad del lote. Para algunas cargas de trabajo, el costo amortizado por transacción es bajo; para otras, especialmente lotes pequeños, puede dominar. Esta es una compensación de diseño, no un defecto, y es por eso que importan el tamaño del lote y la recursión de pruebas.

La compatibilidad con EVM es otra compensación. Los zk-rollups equivalentes a EVM apuntan a ejecutar contratos existentes sin cambios pero enfrentan mayores costos de prueba; las VM personalizadas pueden ser más eficientes pero requieren portabilidad. Las elecciones de disponibilidad de datos también importan: publicar calldata completo maximiza la transparencia pero cuesta más que los blobs o las capas DA externas.

Finalmente, los zk-rollups aún dependen de la cadena base para la liquidación y del secuenciador para el liveness. Una prueba válida no evita la censura ni el tiempo de inactividad; esas son propiedades operativas que debe evaluar por separado, a menudo monitoreando múltiples endpoints RPC.

Próximos pasos: de la verificación al monitoreo en producción

Una vez que pueda reproducir una sola ejecución de verificación, automatícela. Programe la consulta de registros y la comparación de raíces a un intervalo fijo, almacene los resultados en el esquema de tabla anterior y alerte sobre discrepancias persistentes o fallas de recibo. Esto convierte una comprobación única en un monitor de liquidación ligero.

Para cargas de trabajo en producción que leen el estado del rollup con frecuencia, considere un nodo dedicado para que sus lecturas no estén sujetas a límites de tasa compartidos. La oferta de nodos dedicados y el servicio API de OnFinality son los puntos de entrada de infraestructura; los detalles de precios están en la página de precios de RPC, y las redes compatibles se enumeran en el directorio de redes.

Si su siguiente pregunta es qué endpoint usar para un rollup o cadena base específicos, delegue esa decisión a RPC Assistant en lugar de adivinarla a partir de esta página de metodología.