Resumen Técnico: HERMES

Planteamiento del Problema

Las blockchains de modelo de cuenta (por ejemplo, Ethereum) vinculan identidades persistentes a saldos mutables, lo que provoca que cada transferencia revele abiertamente el remitente, el receptor y el monto de la transacción. Si bien esta transparencia respalda la auditabilidad, crea responsabilidades significativas de privacidad para los usuarios de DeFi (front-running), los emisores de stablecoins (confidencialidad de saldos) y los consorcios empresariales (exposición de la cadena de suministro).

Aportar privacidad al modelo de cuenta es estructuralmente más difícil que en el modelo UTXO (por ejemplo, Zcash, Monero) porque un único identificador acumula todas las interacciones. Lograr la privacidad en este entorno requiere satisfacer simultáneamente tres propiedades mutuamente restrictivas:

1. Confidencialidad del Saldo: Los observadores no aprenden nada sobre el saldo actual de la cuenta.
2. Indistinguibilidad del Monto de la Transacción: Los observadores no pueden distinguir entre diferentes montos de transferencia.
3. Desvinculación Remitente-Receptor: Los observadores no pueden vincular al remitente con el receptor.

Los trabajos previos fallan al intentar reconciliar las tres propiedades dentro de un único marco formal. Los esquemas UTXO ocultan las relaciones pero carecen de saldos persistentes; los esquemas de modelo de cuenta exponen identidades, requieren configuraciones de confianza (trusted setups) o solo ofrecen argumentos de seguridad parciales sin reducciones unificadas a supuestos estándar.

Metodología

HERMES (Halo2-Enhanced Rollup Maze ElGamal Shield) propone un marco unificado basado en juegos que establece los tres niveles de garantía de privacidad mediante una reducción al supuesto de Diffie-Hellman Decisional (DDH), sin requerir una configuración de confianza.

Primitivos Criptográficos Centrales

• ElGamal Exponencial de Doble Generador: HERMES utiliza una variante del cifrado ElGamal donde el criptograma es $(g^r, p_k^r \cdot h^m)$. El segundo componente funciona estructuralmente como un compromiso de Pedersen al mensaje $m$.
• Cifrado Coherente con Compromisos (CCE): El documento formaliza el CCE como un principio de diseño donde un componente del criptograma es también un compromiso válido. Esto permite que las pruebas de rango se construyan directamente sobre el criptograma sin necesidad de un $\Sigma$-protocol de "puente", eliminando la sobrecarga criptográfica.
• Aleatorizadores Independientes: Para evitar la filtración algebraica (donde las proporciones de los componentes del criptograma revelan las diferencias de los textos planos), HERMES asigna un aleatorizador único e independiente $r_k$ a cada criptograma. El documento demuestra que esta es la única estrategia para cerrar las superficies de filtración algebraica bajo el supuesto DDH.
• Separación de Triple Clave: El sistema emplea tres componentes de clave distintos:
  1. Clave de Monto ($sk_a$): Para cifrar/descifrar saldos.
  2. Clave de Vista ($sk_v$): Para escanear transferencias entrantes (generar etiquetas de vista) sin capacidad de firma.
  3. Dirección: Un hash unidireccional de las claves públicas.
     Esta arquitectura asegura que comprometer una clave (por ejemplo, la clave de vista) no comprometa las demás.

Arquitectura del Sistema

• Cierre On-Chain: Los receptores utilizan Etiquetas de Vista (hashes truncados de $Y_1^{sk_v}$) para filtrar transacciones entrantes on-chain. Una etiqueta coincidente activa un descifrado completo mediante Baby-Step Giant-Step (BSGS). Esto elimina la necesidad de notificaciones off-chain requeridas por esquemas no descifrables.
• Pruebas de Conocimiento Cero: El sistema utiliza Halo2 con un backend de Argumento de Producto Interno (IPA) para una configuración transparente. Las pruebas verifican la validez del saldo, las restricciones de rango ($0 \le t < 2^{32}$), la membresía en el estado y el anonimato del remitente mediante pruebas One-out-of-Many dentro de un conjunto de anonimato de tamaño $N$.
• Flujo de Transacción: Las transferencias implican la selección de un conjunto de anonimato, la generación de criptogramas independientes para el débito del remitente y el crédito del receptor, y el envío de una única prueba al contrato L1.

Contribuciones Clave

El documento reclama cuatro contribuciones específicas:

1. Marco Unificado Basado en Juegos: El primer modelo formal que define simultáneamente la privacidad del saldo, la indistinguibilidad del monto y la desvinculación, con reducciones estrictas y explícitas al supuesto DDH para los tres.
2. Formalización de CCE y Filtración Algebraica: Una taxonomía completa de las superficies de filtración algebraica en esquemas basados en ElGamal, demostrando que la aleatorización independiente por criptograma es la condición necesaria y suficiente para el cierre total de la filtración bajo DDH.
3. Arquitectura de Separación de Triple Clave: Un análisis formal de "radio de compromiso" que demuestra que el compromiso de cualquier clave única (monto, vista o dirección) está estrictamente limitado a su rol, preservando la seguridad de los otros componentes.
4. Seguridad y Rendimiento Concretos: Derivación de límites de seguridad concretos (ventaja del atacante $\le q \cdot 2^{-\lambda}$) y selección de parámetros en BN254. El cifrado ElGamal de doble generador logra un rendimiento de submilisegundo ($\approx 320 \mu s$), validando su capacidad de despliegue práctico.

Resultados y Evaluación

• Seguridad: La seguridad de las tres propiedades de privacidad se reduce a la dureza de DDH.
  • Privacidad del Saldo: Reducción estricta (Ventaja $\le Adv_{DDH}$).
  • Indistinguibilidad del Monto: Reducción casi estricta (Ventaja $\le 2 \cdot Adv_{DDH}$).
  • Desvinculación: Reducción con un factor de $2N$ (donde $N$ es el tamaño del conjunto de anonimato) más la sobrecarga de simulación de ZK. Para $N=8$, esto retiene $\approx 96$ bits de seguridad en BN254.
• Rendimiento (Capa Criptográfica):
  • Cifrado: $\approx 320 \mu s$.
  • Descifrado BSGS: $\approx 1.5 ms$ (limitado a montos $< 2^{32}$).
  • Escaneo de Clave de Vista: $\approx 0.6 ms$ por criptograma.
  • Adición Homomórfica: $\approx 40 \mu s$.
• Rendimiento (Sistema de Pruebas):
  • Usando Halo2 con backend KZG (para verificación on-chain): Generación de prueba $\approx 5.1 s$, verificación $\approx 4 ms$, tamaño de prueba $\approx 3.4 KB$ (en $N=8$).
  • Usando Halo2 con backend IPA (configuración transparente): Tamaño de prueba $\approx 1.46 KB$.
  • Throughput: El rendimiento nativo es de $\approx 0.2 txs/s$ (prueba única); se requiere agregación de lotes (capa de sistema) para un mayor rendimiento.
• Comparación: HERMES es el único esquema identificado que combina CCE (sin puentes), conjuntos de anonimato, reducciones DDH unificadas y configuración transparente. Ofrece una verificación más rápida que Zcash Orchard y Aztec V5, aunque la generación de pruebas es más lenta que los sistemas basados en Groth16 como Penumbra.

Significación y Reclamaciones

El documento posiciona a HERMES como una solución para desacoplar la semántica de privacidad de los libros contables de modelo de cuenta de los sistemas de prueba específicos. Al formalizar el CCE y demostrar la necesidad de los aleatorizadores independientes, proporciona un modelo para futuros sistemas de cuentas con preservación de la privacidad.

El autor afirma que HERMES demuestra que las cuentas privadas verificables sin confianza son prácticas para las blockchains de modelo de cuenta. Lo logra mediante:

• La eliminación del requisito de configuración de confianza (vía Halo2 IPA).
• Permitir el descubrimiento de saldos totalmente on-chain (vía Claves de Vista y BSGS), eliminando la dependencia de notificaciones off-chain.
• Proporcionar un modelo de seguridad riguroso y unificado que cubre las tres dimensiones críticas de privacidad, un vacío dejado por trabajos previos como Zether, PGC y cWETH.

El documento reconoce limitaciones, incluyendo el modelo de adversario estático (elevado a adaptativo con un costo binomial), el monto de transacción limitado ($2^{32}$) debido a las restricciones de BSGS, y la dependencia de un Sequencer para la vitalidad (aunque el Sequencer no puede descifrar saldos ni vincular partes). Se identifica como trabajo futuro la migración post-cuántica y la agregación recursiva de pruebas.