E se o Ethereum pós-quântico não precisar de assinaturas? – zk-s(nt)arcas

DR: Os planos atuais de migração PQC pressupõem que devemos verificar assinaturas pós-quânticas – seja na cadeia (kilobytes por tx) ou dentro de circuitos ZK (milhões de restrições). Apresentamos uma alternativa: provar semântica de autorização diretamente no ZK, sem nenhum objeto de assinatura. Resultado: 4.024 restrições R1CS, provas de 128 bytes, tempo de prova de 52 ms. A construção é independente do sistema de prova (Groth16, PLONK, STARKs funcionam) e pode ser implantada hoje como um módulo validador AA – sem necessidade de alterações de protocolo.

Motivação: O data wall PQC

A comunidade tem explorado ativamente os caminhos de migração do PQC (13) e a tensão central é bem conhecida:

Isso é um 30-60x aumento nos dados de autorização por transação. Em arquiteturas rollup em que o espaço calldata/blob tem preço explícito, esse é um problema de escalabilidade de primeira ordem.

A solução “óbvia” e por que é cara

A resposta natural é: verificar as assinaturas PQ dentro dos circuitos ZK, postar apenas a prova sucinta na cadeia.

O problema: a verificação de assinatura baseada em rede requer NTTs em anéis polinomiais de grau 256 em \mathbb{Z}_q (q = 2^{23} – 2^{13} + 1), emulado em um campo de sistema de prova de aproximadamente 254 bits. Limites inferiores estruturais:

Mesmo com gadgets otimizados, estamos buscando milhões de restrições apenas para provar que “esta assinatura é válida”.

Observação principal: autorização ≠ assinaturas

O problema é o seguinte: na camada de consenso, os blockchains na verdade não exigem verificação de um determinado objeto de assinatura. O que o consenso exige é a garantia de que uma transação foi autorizada pela entidade correta.

As assinaturas são um artefato de implementação para expressar autorização – não a autorização em si. Estamos confundindo os dois.

ZK-ACE: autorização centrada na identidade

Nós apresentamos ZK-ACE (Autorização de Conhecimento Zero para Entidades Criptográficas), que leva esta observação à sua conclusão lógica:

Não verifique assinaturas em ZK. Não comprima assinaturas. Elimine totalmente os objetos de assinatura do caminho de autorização.

Em vez disso, a rede armazena um pacote compacto compromisso de identidade (32 bytes):

$$ID_{com} = H(REV | salt | domínio)$$

onde REV. é uma raiz de identidade de 256 bits derivada de uma primitiva determinística de derivação de identidade (DIDP). Cada transação traz uma prova ZK atestando:

1. (C1) Consistência do compromisso: Prover conhece uma pré-imagem de ID_{com}
2. (C2) Correção de derivação: Um hash de ligação ao alvo é consistente com a derivação de chave determinística sob a raiz de identidade
3. (C3) Vinculação de autorização: a raiz da identidade autorizou este específico TxHash
4. (C4) Anti-repetição: O compromisso Nonce ou anulador é derivado corretamente
5. (C5) Separação de domínio: todas as vinculações usam a tag de cadeia/domínio declarada

Todo o circuito é 5 invocações de hash Poseidon + restrições de igualdade. Sem aritmética de rede. Nenhuma lógica de verificação de assinatura. Nenhuma emulação de campo não nativo.

Benchmarks (implementação de referência)

Implementação: arkworks + Groth16 sobre BN254, Poseidon (t=3, \alfa=178 rodadas completas + 57 rodadas parciais).

Tamanho do circuito:

Ambos os modos de reprodução (registro sem uso e conjunto de anulador) produzem contagens de restrições idênticas.

Desempenho (threaded único, Apple M3 Pro, Criterion.rs, 100 amostras):

Tamanho da prova:

Compressão vs. assinaturas PQ:

Comparação de restrições (o resultado principal):

Isso é um ~500x redução de restrições – não da otimização da verificação de assinaturas, mas de não fazendo nada.

Implantação: módulo validador AA

ZK-ACE foi projetado como um Módulo validador ERC-4337. Em uma carteira AA:

• A lógica de validação da conta invoca a verificação ZK-ACE em vez de verificar uma assinatura clássica ou PQ
• A geração de prova acontece no lado do cliente (~52 ms)
• O empacotador transporta provas + entradas públicas (não confiável, não aprende nada)
• A verificação on-chain custa aproximadamente 604 μs por prova

Isso significa nenhuma alteração no nível do protocolo é necessária. O ZK-ACE pode ser implantado na infraestrutura existente.

Sistema de prova agnóstico por design

Uma importante propriedade de design: ZK-ACE é um modelo de autorização em nível de protocolo, não uma construção específica de sistema de prova. As cinco restrições (C1)–(C5) são declaradas em avaliações abstratas de hash e verificações de igualdade. Eles podem ser instanciados com:

Os benchmarks acima usam Groth16 porque fornece os números mais restritos, mas o protocolo não depende disso. Em particular, uma instanciação STARK tornaria todo o pipeline de autorização plausivelmente pós-quântico também na camada de prova — sem configuração confiável, sem suposições de emparelhamento, apenas solidez baseada em hash. Os compromissos de identidade são independentes do sistema de prova (são apenas saídas de hash), então a migração de um sistema de prova para outro não requer rotação de identidade ou novo registro.

As reduções de segurança no artigo são declaradas genericamente em termos de vantagem em termos de solidez do conhecimento \text{Adv}^{ks} e são compatíveis com qualquer back-end que satisfaça integridade, solidez do conhecimento, conhecimento zero e vinculação de entrada pública.

Primitivo assumido: DIDP

ZK-ACE assume um Primitiva de Derivação de Identidade Determinística (DIDP) como uma caixa negra — qualquer quadro que forneça:

• Derivação de chave determinística de uma raiz de alta entropia
• Isolamento de contexto entre caminhos de derivação
• Dureza de recuperação de raiz de identidade

Isso é não vinculado a qualquer construção específica. Um simples HKDF(root, context) satisfaz a interface. Fornecemos ACE-GF como uma instanciação; qualquer KDF com separação de domínio funciona.

Segurança

Quatro definições de segurança baseadas em jogos com provas baseadas em redução sob suposições padrão:

• Solidez da autorização → reduz a solidez do conhecimento + resistência à colisão + dureza de recuperação DIDP
• Resistência à repetição → reduz a solidez da autorização + aplicação do verificador
• Resistência à substituição → reduz a vinculação de entrada pública do sistema de prova
• Separação entre domínios → reduz a resistência à colisão + ligação de entrada pública

Provas completas no papel.

O que isso NÃO é

Para ser explícito:

• Não Verificação ZK de assinaturas PQ (não verificamos nenhuma assinatura dentro do circuito)
• Não compactação de assinatura (eliminamos assinaturas, não as reduzimos)
• Não um novo esquema de assinatura
• Não dependente de qualquer estrutura de identidade específica

É um mudança no que provamos: de “esta assinatura é válida” para “esta identidade autorizou esta transação”.

Relação com discussões existentes

Este trabalho se conecta ao discurso contínuo da migração do PQC:

Todas essas abordagens preservam o modelo centrado na assinatura. ZK-ACE pergunta: e se não o fizermos?

Papel: ZK-ACE: Autorização de Conhecimento Zero Centrada em Identidade para Sistemas Blockchain Pós-Quantum

Implementação de referência: github.com/ya-xyz/zk-ace