ZK rollups: validez antes de confianza

En el capítulo anterior, un retiro desde un optimistic rollup esperaba una ventana de impugnación porque L1 aceptaba la raíz sin comprobarla. Ahora invierte la pregunta: ¿y si el operador tuviera que demostrar, antes de que L1 acepte nada, que la nueva raíz es el resultado correcto de ejecutar el lote? Entonces no haría falta esperar a que alguien encuentre un fraude.

Esa es la idea de un ZK rollup. El operador envía a L1 la nueva raíz de estado junto con una prueba de validez: un objeto criptográfico pequeño que demuestra que la transición se calculó correctamente. Un contrato en L1 la verifica y, solo si es válida, acepta la raíz. Los retiros pueden ejecutarse en cuanto la prueba se verifica. [1]

Preguntas guía

• ¿Qué afirma exactamente una prueba de validez y qué queda fuera de esa afirmación?
• ¿Qué entradas son públicas y cuáles forman el testigo privado del circuito?
• ¿Cuánto gas cuesta verificar en L1 y de qué depende?
• ¿Qué riesgos siguen existiendo aunque la prueba sea correcta?

Conexiones dentro de la serie

• Antes: Rollups desde cero y Optimistic rollups dan el modelo general y el contraste con las pruebas de fraude.
• Después: EIP-4844 y blobs muestra cómo un ZK rollup enlaza su prueba con datos publicados en blobs.
• Investigación relacionada: privacidad y zero-knowledge en consenso explica las propiedades de las pruebas de conocimiento cero con más profundidad.

Invariante de validez: L1 no acepta una raíz sin prueba

Una prueba de conocimiento cero tiene tres propiedades. Completitud: si la afirmación es verdadera y ambas partes son honestas, la prueba se acepta. Solidez (soundness): un prover mentiroso no puede convencer a un verificador honesto de algo falso, salvo con probabilidad despreciable. Conocimiento cero: el verificador no aprende nada más allá de que la afirmación es cierta. [2]

Para escalar, la propiedad decisiva es la solidez, junto con la sucintez: la prueba es pequeña y se verifica mucho más rápido que reejecutar el lote. ethereum.org subraya que son propiedades distintas: usar pruebas de validez para escalar no hace, por sí mismo, que las transacciones sean privadas. Los datos del lote siguen publicándose y cualquiera puede reconstruir el estado. [1]

El invariante, entonces, es este: la raíz canónica en L1 solo avanza si el verificador acepta una prueba que liga la raíz anterior, el lote publicado y la raíz nueva. A diferencia del modelo optimista, no hace falta ningún vigilante honesto para que una raíz falsa sea rechazada; basta con que el sistema de pruebas sea sólido y el circuito sea correcto.

Traza de ejecución de una prueba: del lote al contrato verificador

Antes de aceptar transacciones, el operador hace las comprobaciones habituales: que las cuentas existen en el árbol de estado, que el emisor tiene saldo, que la firma y el nonce son correctos. Al cerrar un lote, compila las entradas del circuito: la raíz del árbol de transacciones, pruebas Merkle de inclusión para cada transacción y cada cuenta implicada, y las raíces intermedias tras aplicar cada transacción. [1]

Figura 1

Del lote a la raíz aceptada: prover fuera, verificador dentro

Fuentes:

[1][3]

Cómo leer esta figura

Diagrama en dos zonas. A la izquierda, fuera de L1, el prover recibe entradas públicas, que son la raíz anterior r n, la raíz nueva r n más 1 y un compromiso de los datos del lote, y un testigo privado formado por las transacciones, las pruebas Merkle y las raíces intermedias. Esas entradas alimentan un circuito que repite las comprobaciones del operador: firma, nonce, saldo e inclusión. El circuito produce una prueba pi sucinta. Una flecha lleva pi y las entradas públicas a la derecha, en L1, al contrato verificador, que llama a verify con pi, r n, r n más 1 y otros valores. El verificador consulta precompiles de curva elíptica, por ejemplo el de emparejamiento en la dirección 0x08. Si la prueba es válida, la raíz r n más 1 queda aceptada y los retiros son ejecutables de inmediato. Una nota indica que si la prueba no verifica, la transacción revierte.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El circuito "recorre" cada transacción y repite esas comprobaciones como restricciones matemáticas: verifica con la prueba Merkle que el emisor está en la raíz actual, resta su saldo, suma el del receptor y calcula la siguiente raíz intermedia. Las raíces anterior y nueva son entradas públicas: el verificador las conoce. Las transacciones y las pruebas Merkle forman el testigo, que el verificador no necesita ver para aceptar la prueba. [1]

Falta un detalle: la prueba debe referirse a los mismos datos que se publicaron en L1. Con blobs, EIP-4844 describe cómo hacerlo: el rollup aporta dos compromisos de los datos, el del blob y el de su propio sistema de pruebas, y demuestra que coinciden con el precompile de evaluación de puntos. [5]

Cuello de botella en L1: verificar con precompiles de curva elíptica

Muchos verificadores de SNARK en Ethereum se apoyan en precompiles de la curva alt_bn128 introducidos en Byzantium: suma (0x06), multiplicación escalar (0x07) y comprobación de emparejamiento (0x08). El de emparejamiento recibe k pares de puntos de 192 bytes cada uno y devuelve 1 si una ecuación bilineal se cumple. Si la longitud no es múltiplo de 192 o algún punto no es válido, la llamada falla. [3]

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
 
/// Ilustrativo: llama al precompile de emparejamiento alt_bn128 (EIP-197, dirección 0x08).
/// `input` contiene k pares (punto G1, punto G2) de 192 bytes cada uno.
library PairingCheck {
    function check(bytes memory input) internal view returns (bool) {
        require(input.length % 192 == 0, "bad length");
        (bool ok, bytes memory out) = address(0x08).staticcall(input);
        return ok && out.length == 32 && abi.decode(out, (uint256)) == 1;
    }
}

El coste es predecible. Desde EIP-1108 (Istanbul), el emparejamiento cuesta 34000 * k + 45000 gas. Un verificador que compruebe cuatro pares paga 181000 gas solo en esa llamada, independientemente de cuántas transacciones tenga el lote. Esa independencia es la clave económica: el coste de verificar se reparte entre todo el lote. [4]

Historia y compensaciones: SNARK, STARK y la ceremonia

ethereum.org distingue dos familias. Los ZK-SNARK producen pruebas pequeñas de verificación rápida, pero muchos necesitan una cadena de referencia común (CRS) generada en una ceremonia. Si alguien conserva la aleatoriedad usada, el "residuo tóxico", podría fabricar pruebas falsas. Las ceremonias multipartitas mitigan el riesgo: basta con que un participante destruya su contribución. [1]

Los ZK-STARK son transparentes: no necesitan CRS, porque usan aleatoriedad verificable públicamente. A cambio, sus pruebas son más grandes y cuestan más de verificar en Ethereum. En la práctica, la elección mueve el coste entre tres lugares: la confianza en una ceremonia, el gas de verificación en L1 y el tiempo de cómputo del prover. [1]

Riesgo operativo: lo que la prueba no cubre

Una prueba de validez demuestra que la transición satisface el circuito. Si el circuito no refleja bien las reglas que crees que aplica, por ejemplo porque olvida una restricción, la prueba "válida" puede certificar algo incorrecto. Por eso las auditorías de circuitos y verificadores son tan críticas como las de cualquier contrato. Es una consecuencia directa del modelo, no una afirmación sobre ningún rollup concreto.

La prueba tampoco garantiza que el operador procese tus transacciones. ethereum.org recuerda que la mayoría de ZK rollups usan un único operador que podría censurar, y que la defensa es enviar la transacción directamente al contrato del rollup en L1 para forzar una salida. Y si los datos no se publican en Ethereum, el sistema deja de ser un rollup: es un validium, con pruebas válidas pero sin garantía de que puedas reconstruir tu saldo. [1]

Laboratorio mínimo: medir el coste de verificación

Con Foundry o cualquier entorno local puedes desplegar la librería de arriba en un contrato de prueba y llamar a check con una entrada vacía. EIP-197 especifica que la entrada vacía es válida y devuelve 1, así que check("") debe dar true. Luego pasa 191 bytes y comprueba que la llamada revierte con bad length. [3]

La validación observable es el gas: con k = 0 pares, la llamada al precompile cuesta 45000 gas según EIP-1108, más el coste habitual de la llamada. Con la fórmula puedes estimar cuánto paga un lote por verificación y dividirlo entre sus transacciones.

Quédate con esta frase: un ZK rollup sustituye la espera por cómputo. L1 no confía en nadie para la corrección de la raíz, pero sí confía en el circuito, en el sistema de pruebas y en que los datos sigan disponibles.