Parabéns @paulangusbark! Por favor, vocês dois, compartilhem esses contratos! Seria bom padronizar, no longo prazo, esses contratos de verificação da mesma forma que a comunidade usa trechos de contrato OpenZeppelin um tanto padronizados para muitas tarefas padrão. Presumivelmente, a verificação da assinatura PQ será tão padrão quanto uma interface ERC20.
1 Curtir
Parabéns,
É ótimo ter outras implementações (visando um nível de segurança diferente).
Estamos muito interessados nos contratos também (principalmente no que diz respeito às otimizações das principais operações da NTT).
Pode ter passado despercebido, falcon512 e Dilithium estão disponíveis aqui há alguns meses.
A verificação FALCON toma como entrada uma representação NTT pré-computada da chave pública conforme mencionado acima. As chaves FALCON são compactadas em uint256, as chaves de dilithium são armazenadas em um contrato externo.
Os NIST KATS foram aprovados com sucesso, proporcionando confiança na parte central do algoritmo.
Tanto para a versão baseada em keccak256 quanto para versões totalmente compatíveis com nist são fornecidas, juntamente com assinantes (e também um aplicativo de assinante de hardware para Dilithium44). O nível de segurança de 128 bits é escolhido, pois é o alvo comum para Ethereum.
O custo do gás para FALCON512 usando keccak256 é de 2M, 6,6M para Dilithium.
Isso pode ser usado para experimentos a partir de hoje, até que as pré-compilações sejam adotadas.
O EIP-8052 (DRAFT) diverge da proposta anterior por
- dividindo os cálculos do FALCON em duas partes, permitindo que uma parte mais amigável do zk seja adotada para a parte hash2Point da assinatura, tendo em mente o final do jogo ZK.
- tome como entrada a representação NTT do PK
Esta separação não é possível para DILITHIUM, então o EIP-8051 segue o padrão.
1 Curtir
Criei um canal discord com instruções em discord.gg/PUFcQezy
A assinatura é o salt seguido pela assinatura codificada como bytes mod q (não usei o codificador/decodificador da implementação do falcon, exceto para carregar a chave pública); então 2.068 bytes (sem cabeçalho).
Um domínio é definido na criação da carteira e é imutável; o valor é usado na função de hash da mensagem. É certo que pedi ao ChatGPT que me escrevesse uma função usando apenas a entrada de 32 bytes e nunca consegui fazer nada melhor; Suspeito que o que tenho é vagamente baseado no seu código, exceto que adicionei um valor de domínio. Também calculo os valores dos pontos à medida que itero pela última transformação iNTT para reduzir o número de loops.
Para economizar combustível, calculo metade da norma com a assinatura enviada, depois converto essa cota de memória para a outra metade da assinatura e calculo a segunda metade da norma. Também usei o recurso desmarcado durante as conversões NTT.
Vou publicá-lo em breve. Meu repositório tem outros contratos que não estou pronto para compartilhar, mas vou apenas eliminar as partes relevantes em um repositório diferente e torná-lo público.
Se você estiver em Londres, estarei amanhã no evento Ethereum London no Encode Club.
Obrigado pela análise detalhada e por configurar o canal Discord.
O layout da assinatura (salt || coeffs mod q, 2068 bytes) é uma abordagem limpa – evitar a compactação do cabeçalho Falcon torna o caminho de verificação muito mais simples para uso na cadeia. A computação mesclada de iNTT + norma parcial é exatamente o tipo de otimização que importa em escala.
Estou trabalhando em uma infraestrutura de verificação semelhante, mas do lado ML-DSA-65 (FIPS 204). Meu foco tem sido na prova de controle pós-quântica para recuperação de validadores e aleatoriedade verificável para sequenciadores L2. A construção da mensagem separada por domínio que você descreveu se alinha estreitamente com o que tenho usado (índice do validador + credenciais + hash da chave PQ + domínio), então estou muito interessado em comparar como nossos padrões de hashing e proteção de reprodução combinam.
Depois de publicar o repositório extraído, ficarei feliz em:
contribuir com vetores de teste ML-DSA-65 em um formato compatível
executar comparações de gás lado a lado (Falcon-1024 vs ML-DSA-65)
ajudar a verificar a integridade dos padrões de separação de domínio para reutilização entre contratos
Não estou em Londres para o evento Encode, mas estou muito interessado em colaborar remotamente. Avise-me quando o repositório for público e começarei a experimentar.
Publiquei no GitHub – Cointrol-Limited/QuantumAccount: uma implementação de uma carteira ERC4337 que usa FIPS 206 (falcon-1024) para verificação de assinatura
Ótimo ver a implementação do Falcon-1024! Estou trabalhando em uma abordagem complementar usando ML-DSA-65 (Dilítio, FIPS 204) para sequenciadores L2 e empacotadores AA.
Sua arquitetura QuantumAccount com pré-transformação de multiplicação Montgomery e hashing baseado em Keccak é um excelente ponto de referência. O Verificação de gás de aproximadamente 10M o custo alcançado é impressionante em comparação com a implementação inicial de 40 milhões.
Minha abordagem de assinatura dupla (ECDSA + ML-DSA-65) visa casos de uso semelhantes, mas com compensações diferentes:
-
Otimizações de verificação de assinatura usando transformações de domínio NTT
-
Caminho de migração híbrido clássico/PQ para infraestrutura existente
-
Validação estatística (NIST/Dieharder/TestU01 BigCrush)
-
Latência alvo: ~14ms para operações VRF fora da cadeia
Eu estaria muito interessado em:
-
Comparação de custos de gás: Verificação ML-DSA-65 vs Falcon-1024
-
Compensações de tamanho de assinatura: Dilítio (~2,4 KB) vs Falcon (~1,3 KB)
-
Estratégias de multiplicação de Montgomery para ambos os esquemas
-
Opções de função hash: Sua abordagem Keccak versus SHAKE256 padrão
Fico feliz em colaborar em testes cruzados ou benchmarking.
Verificação Ethereum ML-DSA-65: https://github.com/pipavlo82/ml-dsa-65-ethereum-verification
Especificação VRF: https://github.com/pipavlo82/r4-vrf-public-spec
Fontesethresear
