Gás/Bit de Segurança para Assinaturas PQ em EVM: Conjunto de Dados + Metodologia – Criptografia

Gas per Secure Bit: um benchmark normalizado para assinaturas PQ em EVM

TL;DR (o que está implementado hoje)

• Implementado: um laboratório de benchmark reproduzível + conjunto de dados para verificação de PQ em EVM usando gás por bit criptograficamente significativo.

• Gravado: proveniência explícita por linha (repo, commit, bench_name, chain_profile, notes) e instantâneos de execução única (sem média oculta).

• Padronizado: um taxonomia de superfície portanto, as comparações têm o escopo correto (somente verificação S0 vs S1 ERC-1271 vs S2 validUserOp vs S3 handleOps).

• Relatado: dois denominadores:

  • Linha de base de 128 bits (visualização de orçamento)

  • bits equivalentes de segurança (convenção declarada Cat{1,3,5} → {128.192.256})

• Modelado: AA Caminhos de execução do “elo mais fraco” por meio de um gráfico de caso canônico, com:

  • effective_security_bits = min(security_bits(dep_i)) mais declarado depends_on()

• O repositório agora inclui: gráfico canônico de caso AA + relatório do elo mais fraco, e vNext nós de superfície de entropia/atestado (denominador = H_min).

Continuando a discussão sobre assinaturas AA/ERC-4337/PQ: acabei isolando uma peça que faltava e que continua aparecendo implicitamente:

Não temos uma unidade normalizada para comparar diferentes esquemas de assinatura em diferentes níveis de segurança no EVM.

A maioria das comparações usa “gás por verificação”, mas isso mistura silenciosamente:

• diferentes alvos de segurança (esquemas PQ ECDSA de aproximadamente 128 bits vs Cat3/Cat5),

• diferentes superfícies de verificação (somente verificação vs ERC-1271 vs AA),

• e, às vezes, escopos de benchmark diferentes (microbench vs pipelines completos).

Isso torna difícil responder a questões práticas de engenharia como:
“O ML-DSA-65 é viável no EVM em relação ao Falcon, sob suposições explícitas?”

“Envelope” do protocolo/dominância do elo mais fraco (por que o contexto do protocolo é importante)

Mesmo que as carteiras (AA/ERC-1271) adotem assinaturas PQ, a segurança ponta a ponta ainda pode ser limitada por dependências em nível de protocolo (componentes “envelope”): suposições de envelope de transação L1, regras de ordenação/sequenciamento, pipelines de retransmissão/construção, etc.

Portanto, “verificação de gás por PQ” por si só não é tudo: você pode otimizar um componente PQ dentro de um envelope cujo elo mais fraco ainda limita a segurança efetiva. Este repositório rastreia ambos:

• classe de superfície (escopo) e

• enquadramento de prontidão de protocolo (dominância do elo mais fraco/envelope).

Ideia central

gas_per_secure_bit = gas_verify / security_metric_value

Para assinaturas hoje:

• security_metric_type = security_equiv_bits (convenção de normalização declarada)

Para superfícies de aleatoriedade/atestado de protocolo (vNext):

• security_metric_type = H_min (min-entropia sob um modelo de ameaça explícito)

Taxonomia de superfície (para não misturar escopos)

Cada linha do conjunto de dados é rotulada por uma “classe de superfície” canônica (o escopo domina o número):

• S0: microbancada somente com assinatura (por exemplo, ecrecover, verifySignature)

• S1: interface de carteira de contrato (ERC-1271 isValidSignature)

• S2: Validação AA (validateUserOp)

• S3: AA de ponta a ponta (EntryPoint.handleOps)

Regra de escopo (importante): comparações são significativas dentro da mesma classe de superfície salvo indicação explícita em contrário.

Denominadores (duas visualizações, explicitamente rotuladas)

Métrica A — linha de base de 128 bits (normalização do orçamento)

gas_per_128b = gas_verify / 128

Isso não significa que todos os esquemas sejam seguros em 128 bits; é uma ferramenta de orçamento/normalização.

Métrica B — bits equivalentes de segurança (convenção declarada)

gas_per_sec_equiv_bit = gas_verify / security_equiv_bits

Convenção de trabalho atual (explícita, não uma afirmação de prova):

Observação: security_equiv_bits é uma convenção de normalização declarada para comparabilidade (não um valor de “bits” fornecido pelo NIST).

Proveniência e reprodutibilidade

Todos os números estão atualmente instantâneos de gás de execução única (sem média) com procedência completa:
repo, commit, bench_name, chain_profile, notes.

Sem média oculta, sem seleção do “melhor de N” – apenas instantâneos reproduzíveis que outros podem executar novamente.

Repositório:

• pipavlo82/gas-per-secure-bit

Algumas linhas principais (ilustrativas)

Normalização da linha de base (dividir por 128):

Normalização equivalente à segurança (dividir por security_equiv_bits):

O que se destacou (para essas bancadas específicas):

• ML-DSA-65 PréA é ~7.809 gás/seg-equiv-bit (Cat3-equiv)

• Falcon-1024 verifySignature é ~40.375 gás/seg-equiv-bit (Cat5-equiv)

Isso é ~5,2× diferença para essas linhas específicas.

Nota de escopo: este 5,2× é não uma reivindicação global. É uma comparação superficial entre formatos de benchmark específicos; não extrapole em diferentes superfícies (por exemplo, pipelines handleOps) sem corresponder à classe de superfície.

O que significa “PreA” (por que muda a imagem)

Na verificação ML-DSA padrão, um importante centro de custo é ExpandA + conversão de A em NTT na cadeia.

PréA isola o núcleo aritmético:

• calcular w = A·z − c·t1 no domínio NTT,

• enquanto aceita A_ntt fora da cadeia pré-computado,

• e vinculando-o (CommitA) para evitar a substituição de matriz.

Este é um ponto explícito de design da ABI/protocolo: mover grandes estruturas públicas para fora da cadeia, mas manter o verificador resistente à substituição por meio de ligação criptográfica.

(repositório do verificador ML-DSA-65: pipavlo82/ml-dsa-65-ethereum-verification)

“Gráfico de caso” padronizado (superfícies de execução + elo mais fraco)

Para evitar maçãs/laranjas, o repositório modela benchmarks como nós de superfície e (opcionalmente) gráficos de pipeline.

Modelo canônico de elo mais fraco (L1) AA:

Regra do elo mais fraco:

effective_security_bits = min(security_bits(dep_i))

Implicação prática (L1):

• Carteira PQ (256) + envelope L1 (128) ⇒ effective_security_bits = 128

Esta não é uma crítica às carteiras PQ; é uma restrição de prontidão do protocolo que o gráfico torna explícita.

vNext: superfícies de entropia/atestado (denominador = H_min)

A mesma abordagem gráfica se estende além das assinaturas às superfícies de protocolo:

Estes usam:

• security_metric_type = H_min

Importante: para superfícies de protocolo, gás pode ser medido enquanto Os denominadores H_min podem começar como espaços reservados até que o modelo de ameaça seja finalizado. Essas linhas são para modelagem de prontidão, não para declarações criptográficas.

Início rápido da reprodutibilidade

git clone https://github.com/pipavlo82/gas-per-secure-bit
cd gas-per-secure-bit

RESET_DATA=0 MLDSA_REF="feature/mldsa-ntt-opt-phase12-erc7913-packedA" \
  ./scripts/run_vendor_mldsa.sh

RESET_DATA=0 ./scripts/run_ecdsa.sh

QA_REF=main RESET_DATA=0 ./scripts/run_vendor_quantumaccount.sh

tail -n 20 data/results.csv

Feedback bem-vindo (direcionado)

1. Fiação Hash/XOF no EVM: variantes FIPS SHAKE vs Keccak estritas vs linhas rotuladas de modo duplo?

2. O relato de ambos os denominadores (128 linha de base + sec-equiv) é razoável?

3. Opções de padronização PreA em AA: calldata vs armazenamento vs pré-compilação vs CommitA híbrido?

4. Quais superfícies de envelope de protocolo devem ser avaliadas em seguida (relés, sequenciamento, atestados L2, entropia)?

Ligações

• Repositório de referência: pipavlo82/gas-per-secure-bit

• Implementação de ML-DSA-65: pipavlo82/ml-dsa-65-ethereum-verification

• ERC-7913: ERC-7913: Signature Verifiers

• Discussão original AA/PQ: “O caminho para a transação Post-Quantum Ethereum é pavimentado com Abstração de Conta (AA)”