Privacy-Preserving Compliance on Public Ledgers via Selective Disclosure Authorization Schemes

Resumen Técnico: Cumplimiento con Preservación de la Privacidad en Libros de Contabilidad Públicos mediante Esquemas de Autorización de Divulgación Selectiva

Planteamiento del Problema
Los libros de contabilidad distribuidos públicos, como Ethereum, imponen la integridad mediante una transparencia radical, lo que entra en conflicto con los principios de minimización de datos requeridos para el cumplimiento regulatorio. Si bien las Pruebas de Conocimiento Cero (ZKP, por sus siglas en inglés) permiten teóricamente a los usuarios probar enunciados (por ejemplo, edad o residencia) sin revelar los datos subyacentes, las construcciones existentes enfrentan restricciones adversarias críticas en entornos de contratos inteligentes. Específicamente, la naturaleza asíncrona de las transacciones de blockchain crea una vulnerabilidad: las pruebas generadas fuera de la cadena (off-chain) se envían a un mempool público antes de su inclusión. Este retraso permite que los adversarios observen pruebas válidas y realicen ataques de front-running o las repliquen en diferentes contextos transaccionales (por ejemplo, desde una dirección de remitente distinta o hacia un contrato diferente). Las ZKP estándar garantizan el conocimiento del testigo (witness), pero no vinculan inherentemente la prueba a un remitente específico en la cadena, creando una "trampa de transparencia" donde la divulgación excesiva o la reutilización de pruebas compromete la privacidad y la integridad de la autorización.

Metodología: Esquemas de Autorización de Divulgación Selectiva (SDAS)
Para abordar estas brechas, los autores formalizan los Esquemas de Autorización de Divulgación Selectiva (SDAS), un primitivo criptográfico diseñado para verificaciones de cumplimiento granulares y revocables que no revelan los testigos subyacentes. El marco trata la autorización no como una presentación de prueba sin estado, sino como una transición de estado verificable vinculada a un contexto de ejecución específico.

1. Modelo Formal: El modelo SDAS define una tupla de contexto de ejecución $\Gamma = (\chi_{addr}, \chi_{chain}, \chi_{contract})$, que corresponde a las variables de la Máquina Virtual de Ethereum msg.sender, block.chainid y address(this). Una prueba de autorización válida debe atestiguar una relación $R(w, \Gamma)$, asegurando que la prueba esté vinculada criptográficamente a este espacio de coordenadas.
2. Definiciones de Seguridad: El documento introduce dos propiedades de seguridad fundamentales:
   • Desvinculación de Atributos Vinculada al Libro (Ledger-Bound Attribute Unlinkability): Asegura que un registro de autorización en la cadena no revele información sobre el testigo subycente específico (por ejemplo, el año de nacimiento), distinguiendo entre la vinculación transaccional (la dirección) y la vinculación de atributos.
   • Vinculación de Remitente Consciente del Contexto (Context-Aware Sender Binding): Asegura que una prueba generada para un contexto específico no pueda ser reutilizada en un contexto diferente o por un remitente distinto.
3. Prototipo de Cumplimiento ZK (ZK-Compliance): Los autores instancian SDAS como ZK-Compliance, un sistema basado en Ethereum que implementa un ciclo de vida de "Conceder, Verificar, Revocar" controlado por el usuario.
   • Diseño del Circuito: El sistema utiliza un circuito Circom de 14 restricciones (AgeCheck) basado en el esquema Groth16 sobre la curva BN128. El circuito toma entradas públicas (año actual, umbral de edad, dirección solicitante) y testigos privados (año de nacimiento, sal de aleatoriedad). Crucialmente, el circuito restringe la entrada de la dirección pública ($x_{addr}$) de tal manera que el circuito consume la dirección del remitente, haciendo que la prueba sea inválida si es enviada por un msg.sender diferente.
   • Flujo de Ejecución: El cliente genera la prueba localmente utilizando SnarkJS, vincula la entrada pública a la dirección de la billetera y envía una transacción firmada. El verificador en la cadena primero comprueba si la dirección vinculada coincide con msg.sender antes de realizar la verificación criptográfica, abortando inmediatamente si hay una discrepancia.

Contribuciones Clave

• Formalización de SDAS: El documento introduce una nueva arquitectura de autorización que separa la validez del atributo de la autorización estatal en la cadena, modelando la autorización como una transición de estado verificable.
• Vinculación Consciente del Contexto: Los autores definen e implementan la Vinculación de Remitente Consciente del Contexto, un mecanismo que ancla las pruebas de conocimiento cero al msg.sender ejecutor para neutralizar ataques de front-running en el mempool y de reutilización de pruebas.
• Instanciación Práctica: El trabajo presenta ZK-Compliance, un prototipo de Ethereum nativo para navegadores que operacionaliza el ciclo de vida "Conceder, Verificar, Revocar" sin depender de custodios de identidad persistentes.

Resultados Experimentales
Los autores evaluaron ZK-Compliance en la red de prueba Sepolia:

• Rendimiento del Cliente: La generación de la prueba (generación de testigo + construcción de la prueba) se ejecutó en menos de 200 ms (específicamente 184 ms) en una MacBook Air de consumo (M2, 16GB RAM) utilizando WebAssembly.
• Costo en la Cadena (On-Chain Cost): La transacción de verificación costó 240,512 gas, cubriendo el anclaje del remitente, la verificación de emparejamiento (pairing) de BN128 y el almacenamiento del registro de acceso.
• Validación de Seguridad: Las simulaciones confirmaron que cuando una billetera adversaria intentó reutilizar una prueba capturada de una dirección distinta, el contrato rechazó la transacción debido a la discrepancia del remitente, evitando con éxito la transferencia de acceso no autorizado.

Significancia y Reivindicaciones
El documento afirma que ZK-Compliance demuestra la viabilidad de la autorización de divulgación selectiva vinculada al remitente en libros de contabilidad públicos. Al tratar la autorización como una transición de estado vinculada al contexto en lugar de una prueba sin estado, el sistema reduce la dependencia de repositorios de identidad centralizados mientras preserva una estricta privacidad de atributos. Los autores sostienen que este enfoque ofrece un camino práctico para el cumplimiento regulatorio (por ejemplo, verificación de edad) que es auditable, limitado en el tiempo y revocable, sin exponer datos sensibles del usuario al libro público ni ser vulnerable a ataques de reutilización basados en el mempool.

Limitaciones
Los autores señalan que el prototipo actual se centra principalmente en la vinculación del remitente; la vinculación entre cadenas (cross-chain) y entre contratos (cross-contract) (anclaje a block.chainid y address(this)) siguen siendo extensiones para trabajos futuros. Además, el mecanismo de revocación actual elimina el estado pero aún no implementa nulificadores de estado (por ejemplo, usando hashes de Poseidon) para evitar la reactivación del acceso revocado mediante pruebas obsoletas, una característica necesaria para el despliegue en producción.