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

Sintesi Tecnica: Conformità Preservante la Privacy su Ledger Pubblici tramite Schemi di Autorizzazione a Divulgazione Selettiva

Definizione del Problema
I registri distribuiti pubblici, come Ethereum, impongono l'integrità attraverso una trasparenza radicale, che entra in conflitto con i principi di minimizzazione dei dati richiesti dalla conformità normativa. Sebbene le Prove a Conoscenza Zero (ZKP) permettano teoricamente agli utenti di dimostrare affermazioni (ad esempio, l'età o la residenza) senza rivelare i dati sottostanti, le costruzioni esistenti affrontano vincoli avversari critici negli ambienti smart contract. Nello specifico, la natura asincrona delle transazioni blockchain crea una vulnerabilità: le prove generate off-chain vengono inviate a un mempool pubblico prima dell'inclusione. Questo ritardo permette agli avversari di osservare prove valide e di effettuare "front-running" o di riutilizzarle (replay) in diversi contesti transazionali (ad esempio, da un diverso indirizzo mittente o verso un diverso contratto). Le ZKP standard garantiscono la conoscenza della testimonianza (witness), ma non legano intrinsecamente la prova a un mittente specifico on-chain, creando una "trappola di trasparenza" in cui l'eccessiva divulgazione o il riutilizzo delle prove compromettono la privacy e l'integrità dell'autorizzazione.

Metodologia: Schemi di Autorizzazione a Divulgazione Selettiva (SDAS)
Per colmare queste lacune, gli autori formalizzano gli Schemi di Autorizzazione a Divulgazione Selettiva (SDAS), un primitivo crittografico progettato per controlli di conformità granulari e revocabili che non rivelano le testimonianze sottostanti. Il framework tratta l'autorizzazione non come una presentazione di prova stateless, ma come una transizione di stato verificabile legata a un contesto di esecuzione specifico.

1. Modello Formale: Il modello SDAS definisce una tupla di contesto di esecuzione $\Gamma = (\chi_{addr}, \chi_{chain}, \chi_{contract})$, corrispondente alle variabili della Ethereum Virtual Machine msg.sender, block.chainid e address(this). Una prova di autorizzazione valida deve attestare una relazione $R(w, \Gamma)$, assicurando che la prova sia crittograficamente legata a questo spazio di coordinate.
2. Definizioni di Sicurezza: Il documento introduce due proprietà di sicurezza fondamentali:
   • In-legibilità degli Attributi Legata al Ledger: Garantisce che un record di autorizzazione on-chain non riveli informazioni sulla specifica testimonianza sottostante (ad esempio, l'anno di nascita), distinguendo tra collegabilità transazionale (l'indirizzo) e collegabilità dell'attributo.
   • Vincolo del Mittente Consapevole del Contesto: Garantisce che una prova generata per un contesto specifico non possa essere riutilizzata in un contesto diverso o da un mittente diverso.
3. Prototipo ZK-Compliance: Gli autori istanziano SDAS come ZK-Compliance, un sistema basato su Ethereum che implementa un ciclo di vita "Concedi, Verifica, Revoca" controllato dall'utente.
   • Design del Circuito: Il sistema utilizza un circuito Circom a 14 vincoli (AgeCheck) basato sullo schema Groth16 sulla curva BN128. Il circuito riceve input pubblici (anno corrente, soglia di età, indirizzo richiedente) e testimonianze private (anno di nascita, salt casuale). Fondamentalmente, esso vincola l'input dell'indirizzo pubblico ($x_{addr}$) in modo che il circuito consumi l'indirizzo del mittente, rendendo la prova invalida se inviata da un msg.sender differente.
   • Flusso di Esecuzione: Il client genera la prova localmente usando SnarkJS, lega l'indirizzo del wallet all'input pubblico e invia una transazione firmata. Il verificatore on-chain controlla prima se l'indirizzo vincolato corrisponde a msg.sender prima di eseguire la verifica crittografica, interrompendo immediatamente l'esecuzione in caso di discrepanza.

Contributi Chiave

• Formalizzazione di SDAS: Il documento introduce una nuova architettura di autorizzazione che separa la validità dell'attributo dall'autorizzazione stateful on-chain, modellando l'autorizzazione come una transizione di stato verificabile.
• Vincolo Consapevole del Contesto: Gli autori definiscono e implementano il Vincolo del Mittente Consapevole del Contesto, un meccanismo che ancora le prove a conoscenza zero al msg.sender in esecuzione per neutralizzare attacchi di front-running nel mempool e di riutilizzo delle prove.
• Istanza Pratica: Il lavoro presenta ZK-Compliance, un prototipo Ethereum browser-native che operazionalizza il ciclo di vita "Concedi, Verifica, Revoca" senza dipendere da custodi di identità persistenti.

Risultati Sperimentali
Gli autori hanno valutato ZK-Compliance sulla rete di test Sepolia:

• Performance lato Client: La generazione della prova (generazione della testimonianza + costruzione della prova) è stata eseguita in meno di 200 ms (nello specifico 184 ms) su un MacBook Air consumer (M2, 16GB RAM) utilizzando WebAssembly.
• Costo On-Chain: La transazione di verifica ha comportato un costo di 240.512 gas, coprendo l'ancoraggio del mittente, la verifica del pairing BN128 e la memorizzazione del record di accesso.
• Validazione della Sicurezza: Le simulazioni hanno confermato che quando un wallet avversario tentava di riutilizzare una prova catturata da un indirizzo diverso, il contratto rifiutava la transazione a causa della discrepanza del mittente, prevenendo con successo il trasferimento dell'accesso non autorizzato.

Significatività e Rivendicazioni
Il documento afferma che ZK-Compliance dimostra la fattibilità della divulgazione selettiva di autorizzazione legata al mittente su registri pubblici. Trattando l'autorizzazione come una transizione di stato legata al contesto piuttosto che come una prova stateless, il sistema riduce la dipendenza da repository di identità centralizzati pur preservando la rigorosa privacy degli attributi. Gli autori sostengono che questo approccio offre una via pratica per la conformità normativa (ad esempio, la verifica dell'età) che sia verificabile, limitata nel tempo e revocabile, senza esporre dati sensuali dell'utente al registro pubblico o renderli vulnerabili ad attacchi di replay basati sul mempool.

Limitazioni
Gli autori osservano che l'attuale prototipo si concentra principalmente sul vincolo del mittente; il binding cross-chain e cross-contract (ancoraggio a block.chainid e address(this)) rimangono estensioni per lavori futuri. Inoltre, l'attuale meccanismo di revoca elimina lo stato ma non implementa ancora nullifier stateful (ad esempio, usando hash Poseidon) per prevenire la riattivazione dell'accesso revocato tramite prove obsolete, una caratteristica necessaria per il deployment in produzione.