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

Resumo Técnico: Conformidade com Preservação de Privacidade em Registros Públicos via Esquemas de Autorização de Divulgação Seletiva

Definição do Problema
Registros distribuídos públicos, como o Ethereum, impõem integridade por meio de uma transparência radical, o que conflita com os princípios de minimização de dados exigidos para a conformidade regulatória. Embora as Provas de Conhecimento Zero (ZKP) permitam teoricamente que os usuários comprovem afirmações (ex: idade ou residência) sem revelar os dados subjacentes, as construções existentes enfrentam restrições adversariais críticas em ambientes de contratos inteligentes. Especificamente, a natureza assíncrona das transações em blockchain cria uma vulnerabilidade: as provas geradas off-chain são submetidas a um mempool público antes da inclusão. Esse atraso permite que adversários observem provas válidas e as utilizem em ataques de "front-running" ou replicação em diferentes contextos de transação (ex: de um endereço de remetente diferente ou para um contrato diferente). As ZKPs padrão garantem o conhecimento da testemunha (witness), mas não vinculam inerentemente a prova ao remetente on-chain específico, criando uma "armadilha de transparência" onde a divulgação excessiva ou o reuso de provas compromete a privacidade e a integridade da autorização.

Metodologia: Esquemas de Autorização de Divulgação Seletiva (SDAS)
Para abordar essas lacunas, os autores formalizam os Esquemas de Autorização de Divulgação Seletiva (SDAS), um primitivo criptográfico projetado para verificações de conformidade granulares e revogáveis que não revelam as testemunhas subjacentes. O framework trata a autorização não como uma apresentação de prova sem estado (stateless), mas como uma transição de estado verificável vinculada a um contexto de execução específico.

1. Modelo Formal: O modelo SDAS define uma tupla de contexto de execução $\Gamma = (\chi_{addr}, \chi_{chain}, \chi_{contract})$, correspondente às variáveis da Ethereum Virtual Machine msg.sender, block.chainid e address(this). Uma prova de autorização válida deve atestar uma relação $R(w, \Gamma)$, garantindo que a prova seja criptograficamente vinculada a este espaço de coordenadas.
2. Definições de Segurança: O artigo introduz duas propriedades de segurança principais:
   • Desvinculação de Atributos Ligada ao Registro (Ledger-Bound Attribute Unlinkability): Garante que um registro de autorização on-chain não revele informações sobre a testemunha subjacente específica (ex: ano de nascimento), distinguindo entre a vinculação transacional (o endereço) e a vinculação de atributos.
   • Vinculação de Remetente Consciente de Contexto (Context-Aware Sender Binding): Garante que uma prova gerada para um contexto específico não possa ser reutilizada em um contexto diferente ou por um remetente diferente.
3. Protótipo de Conformidade ZK (ZK-Compliance): Os autores instanciam o SDAS como ZK-Compliance, um sistema baseado em Ethereum que implementa um ciclo de vida "Conceder, Verificar, Revogar" controlado pelo usuário.
   • Design do Circuito: O sistema utiliza um circuito Circom de 14 restrições (AgeCheck) baseado no esquema Groth16 sobre a curva BN128. O circuito recebe entradas públicas (ano atual, limite de idade, endereço solicitante) e testemunhas privadas (ano de nascimento, sal randômico). Crucialmente, ele restringe a entrada do endereço público ($x_{addr}$) de modo que o circuito consuma o endereço do remetente, tornando a prova inválida se for submetida por um msg.sender diferente.
   • Fluxo de Execução: O cliente gera a prova localmente usando SnarkJS, vincula a entrada pública ao endereço da carteira e submete uma transação assinada. O verificador on-chain primeiro verifica se o endereço vinculado corresponde ao msg.sender antes de realizar a verificação criptográfica, revertendo imediatamente em caso de incompatibilidade.

Principais Contribuições

• Formalização do SDAS: O artigo introduz uma nova arquitetura de autorização que separa a validade do atributo da autorização de estado na rede (on-chain), modelando a autorização como uma transição de estado verificável.
• Vinculação Consciente de Contexto: Os autores definem e implementam a Vinculação de Remetente Consciente de Contexto, um mecanismo que ancora provas de conhecimento zero ao msg.sender executor para neutralizar ataques de front-running no mempool e de reuso de prova.
• Instanciação Prática: O trabalho apresenta o ZK-Compliance, um protótipo de Ethereum nativo de navegador que operacionaliza o ciclo de vida "Conceder, Verificar, Revogar" sem depender de custodiantes de identidade persistentes.

Resultados Experimentais
Os autores avaliaram o ZK-Compliance na rede de teste Sepolia:

• Desempenho do Cliente: A geração de prova (geração de testemunha + construção de prova) executou em menos de 200 ms (especificamente 184 ms) em um MacBook Air de consumo (M2, 16GB RAM) usando WebAssembly.
• Custo On-Chain: O custo da transação de verificação foi de 240.512 gas, cobrindo o ancoramento do remetente, a verificação de emparelhamento (pairing) da BN128 e o armazenamento do registro de acesso.
• Validação de Segurança: Simulações confirmaram que, quando uma carteira adversária tentou reutilizar uma prova capturada de um endereço diferente, o contrato rejeitou a transação devido à incompatibilidade de remetente, impedindo com sucesso a transferência de acesso não autorizado.

Significância e Alegações
O artigo alega que o ZK-Compliance demonstra a viabilidade de autorização de divulgação seletiva vinculada ao remetente em registros públicos. Ao tratar a autorização como uma transição de estado vinculada ao contexto, em vez de uma prova sem estado, o sistema reduz a dependência de repositórios de identidade centralizados enquanto preserva a estrita privacidade de atributos. Os autores afirmam que esta abordagem oferece um caminho prático para a conformidade regulatória (ex: verificação de idade) que é auditável, limitada no tempo e revogável, sem expor dados sensíveis do usuário ao registro público e sem ser vulnerável a ataques de replicação baseados em mempool.

Limitações
Os autores observam que o protótipo atual foca primariamente na vinculação do remetente; a vinculação cross-chain e cross-contract (ancoragem ao block.chainid e address(this)) permanecem como extensões para trabalhos futuros. Além disso, o mecanismo de revogação atual deleta o estado, mas ainda não implementa anuladores (nullifiers) de estado (ex: usando hashes de Poseidon) para evitar a reativação de acesso revogado via provas obsoletas, uma característica necessária para implantação em produção.