Privacidad Programable: Circuits Garbled y Aztec en ZK

La evolución de la arquitectura de privacidad: de mixers a protocolos programables

Los mixers clásicos como Tornado Cash o Sinbad van quedando en el olvido bajo la presión de los reguladores, las sanciones de la Oficina de Control de Activos Extranjeros (OFAC) y el análisis de grafos de transacciones mediante rastreo heurístico de clústeres. La anonimización nativa a nivel de pools de liquidez se bloquea en la capa de smart contracts a través de listas de direcciones de alto riesgo (Chainalysis, Elliptic) integradas en los nodos RPC de los principales proveedores (Infura, Alchemy).

La industria está migrando hacia el concepto de la privacidad programable (Programmable Privacy). En lugar de ocultar el hecho mismo de la transacción difuminando los depósitos en un pool, las nuevas soluciones a nivel de protocolo permiten ejecutar lógica de negocio arbitraria y smart contracts sobre datos cifrados. Los líderes de esta transición son las redes basadas en arquitecturas zk-rollup con soporte para Programmable Privacy, como Aztec (Noir), y redes L1 confidenciales especializadas como COTI 2.0, utilizando primitivas criptográficas y de hardware de última generación.

Circuitos cifrados (Garbled Circuits) en blockchain

En la base de plataformas como COTI 2.0 se encuentra la primitiva criptográfica clásica del protocolo de Yao (Yao's Garbled Circuits), adaptada para el entorno descentralizado de blockchain. A diferencia de las zk-SNARKs, que demuestran la validez de una declaración sin revelar los datos subyacentes, los Garbled Circuits permiten que dos o más partes que no confían entre sí compute una función booleana arbitraria sobre entradas confidenciales, de modo que ninguna de las partes vea los datos de la otra.

Mecánica del circuito cifrado

• 1. Representación de la lógica como un circuito booleano: Cualquier cálculo (transferencia de tokens, verificación de saldo, scoring crediticio) se compila en un grafo acíclico dirigido compuesto por compuertas lógicas (AND, XOR, NOT).
• 2. Ofuscación (Garbling): El creador del circuito (el Garbler) genera claves aleatorias de 128 bits para cada entrada y salida de cada compuerta. Las tablas de verdad de las compuertas se cifran con estas claves en orden aleatorio.
• 3. Transferencia obvia (Oblivious Transfer, OT): El evaluador del circuito (el Evaluator) obtiene sus claves de entrada del Garbler a través del protocolo criptográfico OT. El Evaluator descubre únicamente las claves correspondientes a su entrada real, sin revelársela al Garbler y sin obtener acceso a las demás claves.
• 4. Computación elemento por elemento: El Evaluator descifra las tablas de verdad cifradas de abajo hacia arriba en el circuito, calculando el resultado sin poder conocer los valores intermedios de las variables.

Optimizaciones de ingeniería para blockchain

Los Garbled Circuits en bruto exigen un volumen masivo de comunicación de red. Para integrarlos en un entorno de blockchain, los desarrolladores aplican dos optimizaciones clave:

• Técnica Free-XOR: Permite ejecutar compuertas XOR sin cifrado ni transmisión de datos, reduciendo drásticamente la carga de memoria y el ancho de banda del bus.
• Point-and-permute: Un método de enmascaramiento de bits que le permite al Evaluator encontrar de inmediato la fila correcta en la tabla de verdad cifrada sin tener que hacer fuerza bruta en todas las opciones de descifrado.

Comparativa de stacks criptográficos de confidencialidad

Para elegir el stack tecnológico correcto al diseñar aplicaciones descentralizadas con protección de datos, se utiliza el cotejo de las métricas clave de los protocolos modernos.

En la práctica: Divulgación selectiva (Selective Disclosure) y stablecoins

El compliance moderno exige dejar atrás el concepto de la "sombra absoluta" para pasar al principio de divulgación selectiva (Selective Disclosure). El usuario mantiene el control total sobre su historial de capital pero, cuando es necesario, puede demostrarle a una contraparte, regulador o autoridad fiscal la legitimidad de sus fondos sin exponer el balance total de su wallet ni toda la matriz de conexiones con otras direcciones.

En la arquitectura de Aztec, esto se implementa mediante un sistema de claves separadas y ejecución del lado del cliente dentro del Private Execution Environment (PXE).

Arquitectura de claves en Aztec

Cada usuario administra un conjunto determinista de claves vinculadas al smart contract de su cuenta:

• Nullifier Keys ($nhk$): Se utilizan para generar pruebas de gasto (nullifiers) sin filtrar información sobre qué balance específico o nota (note) se está gastando.
• Incoming Viewing Keys ($ivsk$): Permiten otorgar acceso de auditoría a transacciones entrantes específicas. Puedes transferir una viewing key cifrada a una contraparte o regulador, dándoles visibilidad estrictamente sobre la transacción de stablecoin objetivo (por ejemplo, USDT/USDC envuelto en L2) mientras mantienes ocultos todos los demás activos.

Ejemplo de implementación: Transferencia privada de stablecoins en Noir

A continuación se muestra un fragmento de código production-ready en lenguaje Noir (el DSL base para escribir circuitos en Aztec), el cual implementa la verificación privada de saldos y la generación de un compromiso de transferencia de tokens sin publicar los montos en un registro público.

Fragmento de código

// Dependencia en Nargo.toml: poseidon = { tag = "...", git = "https://github.com/noir-lang/poseidon" }
use poseidon::poseidon::bn254::{hash_2, hash_3};
global TREE_DEPTH: u32 = 32;
struct Note {
    owner: Field,
    amount: u64,
    randomness: Field,
}
fn commit(note: Note) -> Field {
    hash_3([note.owner, note.amount as Field, note.randomness])
}
fn merkle_root(leaf: Field, index: u32, path: [Field; TREE_DEPTH]) -> Field {
    let bits: [u1; TREE_DEPTH] = (index as Field).to_le_bits();
    let mut node = leaf;
    for i in 0..TREE_DEPTH {
        node = if bits[i] == 0 {
            hash_2([node, path[i]])
        } else {
            hash_2([path[i], node])
        };
    }
    node
}
fn main(
    // Entradas públicas: nada sobre montos y direcciones
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // Entradas privadas
    sender_sk: Field,
    sender_note: Note,
    path: [Field; TREE_DEPTH],
    leaf_index: u32,
    transfer_amount: u64,
    recipient_owner: Field,
    recipient_randomness: Field,
    change_randomness: Field,
) {
    // 1. Propiedad de la nota (con etiqueta de dominio)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. Pertenencia al árbol respecto a la raíz pública
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. Suficiencia de fondos (en caso de escasez, la resta u64 también fallará)
    assert(sender_note.amount >= transfer_amount);
    let change_amount = sender_note.amount - transfer_amount;
    // 4. Nullifier
    assert(hash_3([sender_commitment, sender_sk, 2]) == nullifier);
    // 5. Ambas notas nuevas están vinculadas a los commitments públicos
    assert(commit(Note {
        owner: recipient_owner,
        amount: transfer_amount,
        randomness: recipient_randomness,
    }) == recipient_commitment);
    assert(commit(Note {
        owner: sender_note.owner,
        amount: change_amount,
        randomness: change_randomness,
    }) == change_commitment);
}

Quedan fuera del circuito: el cifrado de notas para el destinatario, el almacenamiento y actualización del árbol en el contrato, la verificación de unicidad del nullifier y el cotejo de merkle_root_pub con la raíz conocida.

Recomendaciones de integración para desarrolladores

• 1. Cero generación de pruebas en el servidor: Jamás le confíes la generación de ZK-proofs a servidores de API remotos de terceros. Todo el ciclo de cómputo (PXE en Aztec o scripts de cliente) debe ejecutarse de forma local en el dispositivo del usuario o en un nodo aislado.
• 2. Gestión de claves aisladas por app (App-Siloed Keys): Utiliza claves derivadas e independientes para cada aplicación descentralizada. Esto garantiza que la vulneración de una clave en un protocolo no derive en la desanonimización del historial de transacciones del usuario en otros smart contracts.
• 3. Auditoría de canales con View Keys: Al diseñar pasarelas corporativas o rieles de pago basados en privacidad programable, implementa lógica para generar viewing keys temporales con límite de tiempo de vida (time-to-live). Esto permite superar los filtros de compliance bancario y regulatorio (AML/KYT) sin necesidad de publicar las llaves maestras permanentes de la wallet.