Privacidad y Zero-Knowledge (ZKP): Transacciones confidenciales sobre BFT

Un consenso BFT clásico asume algo que rara vez se dice en voz alta: todas las réplicas ven las transacciones. Ejecutan los mismos comandos en el mismo orden y por eso llegan al mismo estado. Esa transparencia es justo lo que muchas aplicaciones no pueden aceptar, porque el contenido de una transacción (montos, contrapartes, saldos) puede ser información sensible.

Si simplemente ciframos la transacción, aparece el problema contrario: las réplicas ya no pueden saber si es válida. Este artículo explica la salida que ofrecen las pruebas de conocimiento cero sucintas, usando Groth16 como caso concreto, y separa con cuidado lo que la prueba resuelve de lo que sigue siendo trabajo del consenso.

El problema: replicar sin ver

En replicación de máquinas de estado, el servicio replicado se refleja en $n$ réplicas deterministas, y el protocolo BFT asegura que las réplicas correctas acuerden el orden de ejecución de los comandos de los clientes. [2] PBFT ya fijaba ese patrón: las réplicas ejecutan las peticiones en el orden acordado y el cliente acepta un resultado cuando recibe $f + 1$ respuestas coincidentes. [3]

El determinismo es la palanca. Si cada réplica correcta aplica la misma función de transición al mismo estado con el mismo comando, todas llegan al mismo resultado. Pero esa función, en una aplicación financiera, incluye comprobaciones como "el remitente tiene saldo" o "estos fondos no se gastaron antes", y todas leen datos que queremos ocultar.

La idea central es cambiar qué ejecuta la réplica. En lugar de recalcular la transacción sobre datos en claro, la réplica verifica una prueba de que alguien hizo ese cálculo correctamente. Si la verificación también es determinista, el argumento de SMR se conserva: todas las réplicas correctas aceptan o rechazan la misma transacción.

Qué garantiza un zk-SNARK

Un argumento no interactivo permite a un prover convencer a un verifier de que una afirmación es verdadera con un único mensaje. Cuando la prueba es corta y su verificación es barata se habla de SNARG, y de SNARK cuando además es un argumento de conocimiento: quien produce una prueba aceptable debe "conocer" un testigo. [1]

Para nuestro caso importan tres propiedades, descritas aquí de forma general. Completitud: una afirmación verdadera con un testigo válido produce una prueba que el verificador acepta. Solidez de conocimiento: sin un testigo válido no se puede producir una prueba aceptable, salvo con probabilidad despreciable. Conocimiento cero: la prueba no revela nada sobre el testigo más allá de que la afirmación es verdadera. El SNARK de Groth16 es de conocimiento cero y no revela nada sobre el testigo que usa el prover. [1]

La afirmación que se prueba no es "esta transacción es buena" en abstracto. Groth16 construye un SNARK para la satisfacibilidad de circuitos aritméticos, un lenguaje NP-completo. [1] En la práctica, alguien escribe un circuito que codifica las reglas de una transacción válida; las entradas públicas son lo que todas las réplicas ven, y el testigo son los datos privados del cliente. La prueba certifica "existe un testigo que, junto con estas entradas públicas, satisface el circuito".

Groth16: tres elementos de grupo y una ecuación

El aporte de Groth16 es llevar el tamaño al mínimo práctico en la familia de SNARKs sobre emparejamientos. Usa emparejamientos asimétricos, la prueba consta de solo 3 elementos de grupo y la verificación consiste en comprobar una única ecuación de producto de emparejamientos con 3 emparejamientos en total. [1]

El mismo trabajo demuestra una cota inferior: los SNARGs en los que prover y verifier usan operaciones genéricas de grupos bilineales asimétricos no pueden constar de un único elemento de grupo. Queda abierto si se puede descartar también una prueba de dos elementos, lo que demostraría que la construcción de tres es óptima. [1]

Para un consenso, ese tamaño constante es lo que vuelve viable la idea. La prueba no crece con la complejidad del circuito, así que puede viajar dentro de la transacción y cada réplica puede verificarla antes de votar. El trabajo pesado queda del lado del cliente, que construye la prueba una vez; las réplicas solo verifican.

Ordenar con BFT, validar con una prueba

Juntemos las piezas en un flujo sin atribuirlo a ningún sistema concreto. El cliente construye su transacción, produce la prueba $\pi$ con sus datos privados y envía al sistema solo las entradas públicas y $\pi$. El líder la incluye en una propuesta. Cada réplica, antes de votar, ejecuta la verificación como parte de su predicado de validez del bloque. Si una prueba no verifica, la transacción es inválida para todas las réplicas correctas por igual.

El consenso sigue haciendo exactamente el mismo trabajo que antes: decidir una secuencia única. En HotStuff, un bloque avanza cuando reúne un QC de $n - f$ votos en una vista $v$, y la regla de commit garantiza que dos bloques en conflicto no se confirmen. [2] La prueba de conocimiento cero no toca esa lógica; solo cambia cómo cada réplica decide si una transacción es aplicable.

Aquí aparece la trampa clásica. Una prueba certifica que una transacción es válida respecto de ciertas entradas públicas, pero dos transacciones válidas cada una por separado pueden ser incompatibles entre sí, como dos gastos de los mismos fondos. Eso no lo resuelve la prueba; lo resuelve el orden. El circuito tiene que exponer como entrada pública algo que permita a las réplicas detectar el conflicto, por ejemplo un identificador único de los fondos gastados, y la máquina de estados rechaza la segunda transacción porque la primera ya se aplicó en el orden acordado. Es el mismo problema que se analiza en El ataque del doble gasto, resuelto con datos ocultos.

También conviene ser honesto sobre lo que la privacidad no cubre. El líder sigue eligiendo qué transacciones propone, y los metadatos visibles (cuándo llega una transacción, desde dónde) no quedan ocultos por la prueba. La privacidad que se obtiene es sobre el contenido de la transacción, no sobre su existencia.

El setup de confianza y otros límites

Groth16 es un SNARK con preprocesamiento. [1] Antes de producir pruebas, una fase de setup genera una cadena de referencia común para el circuito concreto, y esa generación usa aleatoriedad secreta. Como advertencia general sobre este tipo de esquemas: quien conserve esa aleatoriedad podría construir pruebas aceptables sin tener un testigo válido. En un sistema de transacciones eso equivale a poder fabricar transacciones "válidas" que ninguna regla real respalda, y la prueba no deja rastro de ello.

La consecuencia para un diseño BFT es que el modelo de confianza deja de ser solo "a lo sumo $f$ réplicas bizantinas". Se añade un supuesto sobre la ceremonia de setup, típicamente que al menos uno de sus participantes destruyó su parte del secreto. Ese supuesto es independiente del umbral de fallas: un comité con $n \ge 3f + 1$ réplicas perfectamente honestas aceptaría igualmente una prueba fabricada con el secreto del setup, porque todas ejecutan la misma verificación.

Hay otros dos límites que no dependen del setup. El primero es el circuito: la prueba solo garantiza que se cumplen las reglas que el circuito codifica, y un error en el circuito es un error en la definición de validez que todas las réplicas aplicarán de forma consistente. El segundo es el cambio de reglas: como el setup está ligado al circuito, modificar las reglas de una transacción implica un nuevo setup.

Siguiente lectura

Para repasar por qué el determinismo de las réplicas sostiene todo el argumento, vuelve a Replicación de máquinas de estado. Si quieres ver cómo el orden por consenso impide aplicar dos gastos incompatibles, sigue con El ataque del doble gasto.