Resumo Técnico: HERMES

Declaração do Problema

Blockchains de modelo de conta (ex: Ethereum) vinculam identidades persistentes a saldos mutáveis, fazendo com que cada transferência revele abertamente o remetente, o destinatário e o valor da transação. Embora essa transparência suporte a auditabilidade, ela cria passivos significativos de privacidade para usuários de DeFi (front-running), emissores de stablecoins (confidencialidade de saldo) e consórcios empresariais (exposição da cadeia de suprimentos).

Trazer privacidade para o modelo de conta é estruturalmente mais difícil do que no modelo UTXO (ex: Zcash, Monero) porque um único identificador acumula todas as interações. Alcançar privacidade neste cenário exige satisfazer simultaneamente três propriedades mutuamente restritivas:

1. Confidencialidade de Saldo: Observadores não aprendem nada sobre o saldo atual da conta.
2. Indistinguibilidade de Valor de Transação: Observadores não conseguem distinguir entre diferentes valores de transferência.
3. Desvinculação de Remetente-Destinatário: Observadores não conseguem vincular o remetente ao destinatário.

Trabalhos anteriores falham em reconciliar todas as três propriedades dentro de um único framework formal. Esquemas UTXO ocultam relacionamentos, mas carecem de saldos persistentes; esquemas de modelo de conta expõem identidades, exigem configurações confiáveis (trusted setups) ou oferecem apenas argumentos de segurança parciais sem reduções unificadas a suposições padrão.

Metodologia

O HERMES (Halo2-Enhanced Rollup Maze ElGamal Shield) propõe um framework unificado baseado em jogos que estabelece todas as três garantias de privacidade via redução à suposição de Diffie-Hellman Decisional (DDH), sem exigir uma configuração confiável.

Primitivos Criptográficos Principais

• ElGamal Exponencial de Geradores Duplos: O HERMES utiliza uma variante da criptografia ElGamal onde o texto cifrado é $(g^r, p_k^r \cdot h^m)$. O segundo componente funciona estruturalmente como um compromisso de Pedersen para a mensagem $m$.
• Criptografia Coerente com Compromisso (CCE): O artigo formaliza a CCE como um princípio de design onde um componente do texto cifrado é também um compromisso válido. Isso permite que provas de intervalo sejam construídas diretamente no texto cifrado sem um protocolo $\Sigma$ de "ponte", eliminando o overhead criptográfico.
• Randomizadores Independentes: Para evitar vazamento algébrico (onde razões de componentes de texto cifrado revelam diferenças de texto plano), o HERMES atribui um randomizador único e independente $r_k$ a cada texto cifrado. O artigo prova que esta é a única estratégia para fechar superfícies de vazamento algébrico sob a suposição DDH.
• Separação de Tripla Chave: O sistema emprega três componentes de chave distintos:
  1. Chave de Valor ($sk_a$): Para criptografar/descriptografar saldos.
  2. Chave de Visualização ($sk_v$): Para escanear transferências recebidas (gerar tags de visualização) sem capacidade de assinatura.
  3. Endereço: Um hash de via única das chaves públicas.
     Esta arquitetura garante que o comprometimento de uma chave (ex: a chave de visualização) não comprometa as outras.

Arquitetura do Sistema

• Fechamento On-Chain: Os destinatários usam Tags de Visualização (hashes truncados de $Y_1^{sk_v}$) para filtrar transações recebidas on-chain. Uma tag correspondente dispara uma descriptografia completa por Baby-Step Giant-Step (BSGS). Isso elimina a necessidade de notificações off-chain exigidas por esquemas não descriptografáveis.
• Provas de Conhecimento Zero: O sistema utiliza Halo2 com um backend de Argumento de Produto Interno (IPA) para configuração transparente. As provas verificam a validade do saldo, restrições de intervalo ($0 \le t < 2^{32}$), membros do estado e anonimato do remetente via provas One-out-of-Many dentro de um conjunto de anonimato de tamanho $N$.
• Fluxo de Transação: As transferências envolvem a seleção de um conjunto de anonimato, geração de textos cifrados independentes para o débito (remetente) e crédito (destinatário) e submissão de uma única prova ao contrato L1.

Contribuições Principais

O artigo reivindica quatro contribuições específicas:

1. Framework Unificado Baseado em Jogos: O primeiro modelo formal definindo simultaneamente privacidade de saldo, indistinguibilidade de valor e desvinculação, com reduções estritas e explícitas à suposição DDH para todos os três.
2. Formalização de CCE e Vazamento Algébrico: Uma taxonomia completa de superfícies de vazamento algébrico em esquemas baseados em ElGamal, provando que a randomização independente por texto cifrado é a condição necessária e suficiente para o fechamento total do vazamento sob DDH.
3. Arquitetura de Separação de Tripla Chave: Uma análise de "raio de comprometimento" formal provando que o comprometimento de qualquer chave única (valor, visualização ou endereço) é estritamente limitado ao papel dessa chave, preservando a segurança dos outros componentes.
4. Segurança e Desempenho Concretos: Derivação de limites de segurança concretos (vantagem do atacante $\le q \cdot 2^{-\lambda}$) e seleção de parâmetros em BN254. A criptografia ElGamal de geradores duplos alcança desempenho sub-milisegundo ($\approx 320 \mu s$), validando a viabilidade prática.

Resultados e Avaliação

• Segurança: A segurança das três propriedades de privacidade é reduzida à dureza de DDH.
  • Privacidade de Saldo: Redução estrita (Vantagem $\le Adv_{DDH}$).
  • Indistinguibilidade de Valor: Redução quase estrita (Vantagem $\le 2 \cdot Adv_{DDH}$).
  • Desvinculação: Redução com um fator de $2N$ (onde $N$ é o tamanho do conjunto de anonimato) mais overhead de simulação ZK. Para $N=8$, isso retém $\approx 96$ bits de segurança em BN254.
• Desempenho (Camada Criptográfica):
  • Criptografia: $\approx 320 \mu s$.
  • Descriptografia BSGS: $\approx 1,5 ms$ (limitada a valores $< 2^{32}$).
  • Escaneamento de Chave de Visualização: $\approx 0,6 ms$ por texto cifrado.
  • Adição Homomórfica: $\approx 40 \mu s$.
• Desempenho (Sistema de Prova):
  • Usando Halo2 com backend KZG (para verificação on-chain): Geração de prova $\approx 5,1 s$, verificação $\approx 4 ms$, tamanho da prova $\approx 3,4 KB$ (em $N=8$).
  • Usando Halo2 com backend IPA (configuração transparente): Tamanho da prova $\approx 1,46 KB$.
  • Throughput: O throughput nativo é de $\approx 0,2 txs/s$ (prova única); a agregação de lotes (camada de sistema) é necessária para maior throughput.
• Comparação: O HERMES é o único esquema identificado que combina CCE (zero-bridging), conjuntos de anonimato, reduções DDH unificadas e configuração transparente. Oferece verificação mais rápida que Zcash Orchard e Aztec V5, embora a geração de prova seja mais lenta que sistemas baseados em Groth16 como o Penumbra.

Significância e Alegações

O artigo posiciona o HERMES como uma solução para desacoplar a semântica de privacidade de livros-razão de modelo de conta de sistemas de prova específicos. Ao formalizar a CCE e provar a necessidade de randomizadores independentes, ele fornece um modelo para futuros sistemas de conta com preservação de privacidade.

O autor afirma que o HERMES demonstra que contas privadas verificáveis sem confiança são práticas para blockchains de modelo de conta. Ele alcança isso:

• Eliminando a necessidade de configuração confiável (via Halo2 IPA).
• Permitindo a descoberta de saldo totalmente on-chain (via Chaves de Visualização e BSGS), removendo a dependência de notificações off-chain.
• Fornecendo um modelo de segurança rigoroso e unificado que cobre as três dimensões críticas de privacidade, uma lacuna deixada por trabalhos anteriores como Zether, PGC e cWETH.

O artigo reconhece limitações, incluindo o modelo de adversário estático (elevado para adaptativo com custo binomial), o valor de transação limitado ($2^{32}$) devido às restrições de BSGS, e a dependência de um Sequenciador para liveness (embora o Sequenciador não possa descriptografar saldos ou vincular partes). O trabalho futuro é identificado como migração pós-quântica e agregação de prova recursiva.