Estratégias de migração para EOAs sob a ameaça quântica: rupturas e questões em aberto – criptografia

Olá a todos, sou Marco López (Universidade de Málaga / NICS Lab + Segurança Descentralizada).

Acabamos de receber um trabalho aceito em estratégias de migração para Ethereum EOAs sob um futuro computador quântico criptograficamente relevante (CRQC) ameaça para secp256k1/ECDSA.

Papel

Escopo intencionalmente o artigo para o camada de execução (autorização EOA, fluxos de tx/assinatura, …). Não cobrimos a migração PQ da camada de consenso (assinaturas de validador, BLS/KZG, etc.).

Contexto rápido: excelente trabalho anterior de pesquisa eletrônica que estamos desenvolvendo

Antes de postar, encontramos vários tópicos excelentes que já exploravam assinaturas de transações PQ e compensações práticas de engenharia. Muito obrigado às pessoas que conduzem essas discussões, especialmente asanso e serresistvanandras:

Nosso artigo pretende ser um simples levantamento inicial das rotas de migração, mas com maior ênfase nas quebras de compatibilidade e na superfície de ataque que aparece durante as transições.

Por que estou postando aqui (ligue para a comunidade)

Este trabalho é um primeira (e intencionalmente simples) iteração. Tentámos mapear as principais rotas de migração que as pessoas discutem para tornar as EOAs mais resilientes sob a ameaça do CRQC, e destacar onde as coisas podem falhar na prática.

O objetivo desta postagem é reunir contribuições da comunidade e consolidar esforços em torno do lado da camada de execução deste problema:

• Estamos faltando relevantes opções de mitigação/rotas de migração?

• Que outro quebras de compatibilidade (on-chain e off-chain) devem estar no radar?

• O que comportamento adversário / MEV / operacional riscos estamos subestimando?

• O que antes papéis / repositórios / tópicos devemos citar ou aprender?

• Quem mais está trabalhando ativamente nisso e onde a colaboração poderia fazer sentido?

Se você estiver trabalhando com carteiras, AA, infraestrutura, pesquisa de protocolo, auditorias ou ecossistemas L2, sua perspectiva será extremamente valiosa.

O que o documento cobre (pesquisa de rotas + trade-offs)

Mapeámos as principais abordagens que vemos discutidas para a migração EOA em direcção à segurança pós-quântica e tentámos tornar explícitas as compensações, especialmente onde a abordagem se cruza com a infra-estrutura e os padrões contratuais actuais.

• Assinaturas PQ nativas (protocolo/caminho EVM): substituir o ECDSA por um esquema PQ.

  Conceitualmente simples, mas os custos de verificação e os tamanhos de assinatura/chave variam amplamente de acordo com o esquema, afetando o tamanho do tx, o gás/desempenho e, às vezes, a derivação de endereço. É também uma implementação mais lenta em nível de protocolo.

  Nota baseada em hash (ângulo do minimalismo): passamos algum tempo discutindo assinaturas baseadas em hashporque o Ethereum já depende muito de funções hash como um núcleo primitivo. O uso de assinaturas baseadas em hash pode parecer “criptograficamente mínimo” (você não está introduzindo uma suposição de dureza totalmente nova como a rede/isogenia/etc. faria). Além disso, muitas construções baseadas em hash podem ter “chaves públicas” muito pequenas on-chain (geralmente apenas um compromisso de hash/root), que se alinha com “Grandes chaves públicas são proibidas no contexto do Ethereum”. tema destacado em poqeth. É claro que as compensações vão para outro lugar (tamanhos de assinatura, estado, atrito UX/mempool), que é exatamente onde queremos mais contribuições da comunidade.

  Mencionamos uma pequena nuance: assinaturas baseadas em hash com estado (por exemplo, XMSS/LMS) pode ser estranho em sistemas gerais porque exigem gerenciamento de estado, mas blockchains podem potencialmente gerenciar esse estado na cadeia (semelhante a índice/nonce). Existem precedentes em outros ecossistemas (por exemplo, QRL usando XMSS).

• Abstração de conta ERC-4337: utilizável hoje; a verificação ocorre dentro do contrato da conta, portanto, uma carteira pode exigir assinaturas PQ para autorizar operações e reduzir a exposição direta do usuário a ataques quânticos baseados em ECDSA.

  O problema (discutido também na série asanso) é que o bundler ainda publica uma transação assinada por ECDSAportanto o fluxo ponta a ponta não é totalmente resistente a PQ. Também introduz partes móveis extras (infraestrutura semelhante a mempool, taxas, complexidade operacional).

• Propostas AA nativas (RIP-7560/EIP-7701 direcionalmente): um jogo final de cripto-agilidade limpo: as contas são definidas por lógica de verificação anexada (verificação PQ, multisigs, chaves de acesso, etc.), removendo suposições fixas de ECDSA no nível do modelo de conta.

  Requer mudanças profundas de protocolo; os prazos e os projetos finais são incertos.

• Delegação EIP-7702: um gancho pragmático para anexar nova lógica de validação a um EOA/endereço existente sem migrar para um novo modelo de conta. Isso pode permitir a experimentação com validação e política de conta com reconhecimento de PQ, preservando o endereço e os relacionamentos existentes.

  Limitação da chave: enquanto o protocolo ainda aceitar a chave ECDSA da EOA, continua a ser a “autoridade raiz” (num cenário CRQC, essa autoridade residual é particularmente problemática).

• EIP-7702 + variantes de desativação de chave: discutimos ideias para fechar esse ciclo: após a delegação, a chave ECDSA original poderia ser desativada (de preferência permanentemente), para controlar as rotas exclusivamente através da lógica delegada, preservando o endereço e seus ativos/relacionamentos associados.

  Tratamos isso como parte de um espaço de design mais amplo para eliminar a “autoridade raiz do ECDSA”, uma vez que exista um mecanismo de validação mais flexível.

Em todas as rotas, tentamos manter uma visão prática: onde o ECDSA ainda permanecequais novas suposições de infraestrutura aparecem e o que ocorre no ecossistema durante uma transição.

Pontos de acesso de compatibilidade/quebra (“zona suja”)

Onde esperamos a maioria dos desafios:

• ecrecoverautenticação baseada em contratos implantados (assinaturas como identidade).

  Muitas autorizações na cadeia são efetivamente “assinatura como identidade” via ecrecover. Numa migração PQ, não basta deixar de usar o ECDSA na camada de transação. Desde que ecrecover continua a ser uma pré-compilação válida para ECDSA, os contratos existentes podem continuar a tratar as assinaturas fora da cadeia de ECDSA como oficiais. Portanto, qualquer transição séria precisa de uma história sobre como a ECDSA ecrecoverA verificação de estilo é tratada (e se ela é restrita, substituída ou complementada por novos caminhos de verificação), caso contrário, as assinaturas legadas fora da cadeia podem manter o poder dentro dos contratos mesmo depois que os EOAs pararem de usar ECDSA para transações.

  (Relacionado: Conforme levantado no tópico AA/Falcon do asanso, muitos esquemas PQ não suportam “recuperação de chave”, por exemplo, Falcon “simples” não suporta recuperação de chave pública de uma assinatura, então ecrecoverpadrões de estilo não são transferidos. Uma carteira baseada em Falcon normalmente precisaria verificar uma chave pública armazenada/registrada. Há também um modelo “recuperável” discutido no artigo da Falcon (Seção 3.12, como apontou Renaud Dubois) que permite a recuperação de chaves, mas é aproximadamente dobra o tamanho da assinaturao que tem implicações óbvias na cadeia/largura de banda)

• ERC-2612 permit + mais amplo assinatura fora da cadeia fluxos (dados digitados, autenticação específica do aplicativo, padrões meta-tx)

• tx.origin suposições (EOA vs identidade do contrato, lógica de autorização frágil)

• L2s + desvio entre cadeias (semântica de identidade, domínios de repetição, suposições de ponte)

• MEV durante janelas de migração (ordenação/corrida em torno de delegação, revogação, momentos de “última assinatura válida”)

Uma grande parte do que queremos da comunidade é: o que mais pertence a esta lista e o que é realmente mais prejudicial na prática?

Hard fork de emergência quântica como alternativa (em paralelo)

Separadamente dos caminhos de “migração suave”, o hard fork de emergência quântica A ideia é uma peça importante da história da resiliência.

A postagem de Vitalik de março de 2024 (“Como fazer hard fork para salvar a maioria dos fundos dos usuários em uma emergência quântica”) apresenta uma resposta confiável de último recurso se recursos quânticos práticos surgissem repentinamente e roubos em grande escala começassem a acontecer: reverter para pré-roubo, desativar transações EOA herdadas e fornecer um caminho de recuperação que mova o controle para a validação de contrato inteligente seguro quântico.

Mencionamos isso não como um plano para impulsionar proativamente (é caro e social e operacionalmente pesado), mas como um lembrete de que questões de planejamento de emergência, e que, paralelamente, o ecossistema pode (e provavelmente deve) trabalhar em rotas que possibilitem agilidade criptográfica mais gradual então não somos forçados a entrar no modo “quebrar vidro”.

O que estamos pedindo explicitamente

Se você responder, ponteiros para tópicos/artigos/repos/equipes são extremamente úteis.

1. Existem rotas de migração/mitigações estamos faltando (na camada de execução) ou variantes importantes que devemos incorporar?

2. O que quebras de compatibilidade (on-chain e off-chain) você acha que são mais urgentes ou com maior probabilidade de causar danos reais ao usuário? Quaisquer exemplos concretos serão apreciados.

3. O que comportamento adversário / MEV / operacional riscos devem ser considerados durante a migração (front-running/corridas, luto, problemas de “última assinatura válida”, compromisso de infra-estrutura, dinâmica de travamento de transferência para esquemas únicos/com estado, etc.)?

4. Existem classes conhecidas de contratos ou padrões de carteira onde ecrecover, permitou tx.origin suposições tornam a migração particularmente desagradável?

5. Você conhece medições/conjuntos de dados/ferramentas que ajudam a quantificar a prevalência desses padrões (por exemplo, varreduras para ecrecoverpermitir o uso na natureza, …)?

6. Quem mais está trabalhando ativamente em CRQC/agilidade criptográfica para EOAs agora? Se você estiver envolvido (ou conhece alguém que esteja), adoraríamos nos conectar.

Estamos abordando isso como um bem público esforço (UMA/NICS Lab + Segurança Descentralizada). Muito aberto a revisões, correções e colaboração onde fizer sentido.

Encerramento/eventos

Apresentaremos o artigo em um congresso na Universidade de La Laguna (Tenerife, Espanha) em meados de março. Pretendemos também apresentar trabalhos de acompanhamento no Workshop sobre Ferramentas Criptográficas para Blockchains (CTB-26), associada à Eurocrypt em Roma em 9 de maio de 2026.

Se você trabalha nesta área, teremos prazer em recebê-lo em qualquer um dos eventos.

Aliás, o prazo de inscrição para o CBT26 é final de fevereiro, então você ainda dá tempo.

Obrigado!! aguardando seu feedback.