A Fundação Ethereum estabelece prazo de 2029 para atualizações resistentes a quantum

Autor original: KarenZ, Foresight News

Os computadores quânticos ainda não batem à porta da blockchain, mas a Ethereum Foundation já marcou uma data no calendário: 12 de dezembro de 2029.

É o prazo de engenharia definido pela equipe de protocolo da Ethereum Foundation: preparar-se para o cenário em que ameaças quânticas possam surgir cedo, visando concluir a transformação quântico-resistente da camada um da Ethereum antes que o risco se torne real.

Hegotá, atualmente em planejamento, embora não transforme diretamente a Ethereum em uma blockchain totalmente resistente a quantum, determinará se os planos subsequentes poderão avançar conforme o cronograma.

O "Q-day" geralmente se refere a um ponto temporal hipotético: a aparição de um computador quântico com capacidade de ataque real, colocando os sistemas atuais de criptografia de chave pública em ameaça substancial.

Quando ele chegará, ninguém pode prever com precisão. A Ethereum Foundation também reconheceu explicitamente que a maioria das previsões confiáveis indica que o Q-day ocorrerá após 2030, possivelmente muito depois, ou até mesmo que pode nunca ocorrer.

A equipe de protocolo da Ethereum Foundation adota uma suposição de engenharia conservadora: a camada um da Ethereum deve ser preparada antecipadamente para o caso de o Q-day ocorrer pela primeira vez em 2030.

Para isso, a equipe do protocolo propôs um objetivo: garantir que as três componentes da camada 1 da Ethereum — execução, consenso e dados — possuam plena resistência quântica até dezembro de 2029.

Este objetivo também não é imutável. A equipe do protocolo planeja reavaliar o progresso da computação quântica em janeiro de 2027, considerando a opinião de especialistas externos. Antes disso, a data de 2029 será tratada como um objetivo de trabalho que não pode ser facilmente cedido.

A preparação para a resistência quântica exige anos de antecedência porque a Ethereum não utiliza apenas uma tecnologia criptográfica, e a migração não pode ser concluída apenas trocando um algoritmo de assinatura. Como as contas de usuários provam a autorização de transações, como os validadores participam do consenso e como os dados são verificados envolvem estruturas criptográficas diferentes. Qualquer modificação requer design normativo, implementação de cliente, revisão de segurança, teste em rede de desenvolvimento e coordenação na rede principal — não é possível esperar até que a ameaça já tenha surgido para começar a tratá-la.

De acordo com a rota de referência atualmente divulgada pela equipe da Ethereum Foundation, a atualização da rede Glamsterdam está programada para ir ao mainnet em dezembro de 2026, enquanto a plena resistência quântica está agendada para a quinta hard fork após Glamsterdam, denominada L*, com meta de dezembro de 2029. Entre Glamsterdam e L* há apenas três anos; se for necessário completar sequencialmente Hegotá, I*, J*, K* e L*, a média entre cada atualização será de aproximadamente 7,2 meses.

Este é um cronograma bastante agressivo. Atualmente, a Ethereum Foundation não divulgou datas confirmadas para o lançamento em mainnet de Hegotá, I*, J* e K*. Pode-se afirmar que as equipes de clientes esperam iniciar a implementação de Hegotá no final do quarto trimestre de 2026, enquanto pesquisas, especificações e testes para várias versões subsequentes devem ser conduzidos em paralelo.

Seguindo a rota atual, os principais agendamentos para cada fase são os seguintes:

• Hegotá: localizado no início desta rota. A equipe oficial tem uma definição muito clara: Hegotá não é, por si só, uma atualização resistente a quantum, mas determinará se as atualizações futuras resistentes a quantum poderão avançar conforme o cronograma.
• I*: Implementar o registro de chaves públicas pós-quantum para estabelecer a base protocolar para o registro e uso de chaves públicas pós-quantum; ao mesmo tempo, o desacoplamento do consenso é a direção principal e líder desta versão, e grandes trabalhos de design e migração de estruturas de estado também estão previstos para começar a partir do I*.
• J*: Estabelecer uma camada mínima viável anti-quantum, denominada MV-PQ. Seus componentes-chave incluem o mecanismo de heartbeat anti-quantum na camada de consenso, a amostragem leanDA pós-quantum na camada de dados e as transações leanSPHINCS pós-quantum na camada de execução.
• K*: Com base na classificação atual, introduza a prova de execução obrigatória. Nesse ponto, o foco dos validadores será validar provas de execução concisas, em vez de cada validador reexecutar blocos completos.
• L*: De acordo com a classificação atual do padrão, adicione mensagens de atestações pós-quânticas necessárias para alcançar o consenso totalmente pós-quântico e atingir o objetivo completo de pós-quântico nas camadas de execução, consenso e dados até dezembro de 2029.

No entanto, a ordem das tarefas K* e L* ainda não foi finalizada. A equipe do protocolo está avaliando uma proposta de troca: antecipar a mensagem de prova pós-quântica de L* para K*, permitindo uma capacidade pós-quântica completa mais cedo; ao mesmo tempo, adiar a prova de execução obrigatória de K* para L*. Se esta proposta for adotada, as responsabilidades específicas de K* e L*, bem como o ritmo das atualizações, serão ajustadas consequentemente. Portanto, a afirmação mais precisa no momento é: dezembro de 2026 é o objetivo atual da mainnet Glamsterdam; dezembro de 2029 é o objetivo da linha de base para L* e a capacidade pós-quântica completa; a ordem interna entre K e L* ainda pode ser ajustada.

Pesquisadores, desenvolvedores de clientes, revisores de segurança e equipes de teste devem concluir o Hegotá e, ao mesmo tempo, preparar antecipadamente especificações e protótipos para I*, J*, K* e L*. Se o Hegotá incorporar muitas funcionalidades interdependentes, não apenas poderá atrasar seu próprio lançamento, como também ocupará a equipe necessária para os trabalhos futuros de resistência quântica.

Portanto, a equipe de protocolo da Ethereum Foundation classificou as 62 propostas candidatas em categorias S (2), A (15), B (8), C (7), DFI (28) e TBD (2). A categoria S representa itens obrigatórios para entrega; A representa prioridade alta, com previsão de entrega; B requer ainda a conformidade com especificações, protótipos ou confirmação do responsável; C está temporariamente abaixo da linha de inclusão; DFI indica que não é recomendado incluir na atual atualização; e TBD significa pendente.

Na classificação Hegotá divulgada pela equipe do protocolo, apenas dois EIPs entraram na categoria S: EIP-7805 FOCIL no nível de consenso e EIP-8141 Frame Transaction no nível de execução.

Eles tratam dois problemas-chave no ciclo de vida da transação: se uma transação elegível pode entrar em um bloco e como uma conta pode validar e executar uma transação.

FOCIL (EIP-7805) significa "Fork-choice Enforced Inclusion Lists". Seu objetivo é melhorar as garantias de inclusão de transações na Ethereum.

Atualmente, construtores de blocos profissionais dominam a geração de blocos. Essa divisão de tarefas ajuda a aumentar a eficiência da construção de blocos, mas se a produção de blocos ficar concentrada a longo prazo nas mãos de poucos construtores, eles também podem adquirir uma forte capacidade de seleção de transações. Por isso, o FOCIL adiciona uma camada adicional de restrições de inclusão provenientes dos validadores, além do processo normal de construção de blocos.

De acordo com o design do FOCIL, cada Slot seleciona um grupo de validadores para formar o "Comitê de Lista de Inclusão" (IL committee). Os membros do comitê, com base nas transações pendentes que observam, criam e transmitem separadamente listas de inclusão. O construtor do bloco do próximo Slot coleta essas listas e inclui, na construção do bloco, as transações que atendem aos critérios de execução. Os validadores responsáveis por provar o novo bloco também armazenam as listas de inclusão que receberam a tempo e verificam se o bloco atende aos requisitos correspondentes.

Se um bloco omitir, sem justificativa válida, a lista de transações salva pelo validador, os provadores não votarão a favor desse bloco. Mesmo que esse bloco ainda seja válido no nível de execução, ele não conseguirá o suporte de consenso necessário para entrar na cadeia principal. É exatamente isso que o FOCIL significa: em vez de permitir que os membros do comitê modifiquem diretamente os blocos, ele restringe as escolhas dos construtores de blocos por meio da votação ou não dos validadores.

O EIP-8369 complementar descreve quais transações são adequadas para receber a garantia de inclusão obrigatória da FOCIL. As razões para a omissão de transações comuns são relativamente fáceis de verificar; as transações Frames permitem verificação programável, cujo custo de julgamento é mais elevado, exigindo restrições adicionais sobre o intervalo de estados que podem ser lidos e o orçamento de verificação.

Em termos simples, o FOCIL não permite que os validadores assumam o trabalho dos construtores de blocos, mas sim adiciona uma regra da camada de consenso aos construtores: você ainda pode organizar a maioria das transações no bloco, mas não pode ignorar continuamente transações qualificadas listadas pelo comitê sem uma razão válida.

As transações Frame (EIP-8141) abordam problemas no nível da conta. Elas pretendem tornar a validação de transações, a execução de transações e o pagamento de Gas mais programáveis no nível do protocolo, fornecendo a base para a abstração de conta nativa. Vitalik é um dos coautores da EIP-8141.

Atualmente, a maioria das contas comuns do Ethereum depende de assinaturas de chaves privadas de tipo fixo. O Frames deseja permitir que as contas utilizem lógicas de verificação mais flexíveis, como novos esquemas de assinatura, combinação de múltiplas condições de autorização ou permitir que outras contas paguem as taxas de transação. Ele também pode suportar agregação de assinaturas e permitir a introdução futura de novos esquemas de assinatura sem a necessidade de um hard fork separado para cada esquema.

Mas o Frames em si não é um esquema de assinatura pós-quantum completo e não substituirá imediatamente as chaves atuais após o lançamento do Hegotá. Ele fornece "agilidade criptográfica": no futuro, se for necessário trocar o esquema de assinatura, as contas poderão migrar por meio de verificação programável, em vez de ficarem permanentemente presas a um único sistema de chaves.

Frames ainda requer duas propostas de nível A como complemento essencial. A EIP-8250 Keyed Nonces permite que o mesmo remetente utilize canais de nonce mutuamente independentes, fazendo com que diferentes transações não se bloqueiem mutuamente por compartilharem uma ordem estrita; a EIP-8272 permite que as transações utilizem o estado recente na cadeia, verificável pelos validadores, permitindo que transações de privacidade relacionadas também obtenham a garantia de inclusão fornecida pelo FOCIL.

Portanto, FOCIL e Frames não são duas funcionalidades independentes. A primeira altera quais transações elegíveis devem ser incluídas no bloco, enquanto a segunda altera a estrutura de validação das próprias transações. A capacidade de ambas funcionarem em conjunto de forma segura é uma das principais tarefas de teste do Hegotá.

A proposta de nível S define a linha principal do Hegotá, mas várias propostas de nível A também afetam a segurança da conta futura da Ethereum, a migração resistente a quânticos, a prova de execução e a precificação de recursos.

Primeiro, o EIP-8365. Ele planeja iniciar a saída gradual de certos credenciais de saque BLS, pois esses credenciais ainda dependem de tecnologias criptográficas que podem perder segurança frente a ataques quânticos suficientemente fortes. A equipe do protocolo considera que essa migração pode começar antecipadamente, sem precisar aguardar a definição completa do consenso resistente a quantum.

Em termos de segurança de conta, EIP-7906, EIP-8298 e EIP-8151 são considerados uma combinação de extensões do Frames.

EIP-7906 introduz o mecanismo de afirmações de transação, permitindo que as transações verifiquem se resultados específicos ocorreram antes de serem finalmente submetidas. Este mecanismo tem como objetivo reduzir perdas causadas por contratos maliciosos que esvaziam ativos de carteiras e por certos comportamentos de MEV. No entanto, o escopo exato de leitura deste proposta ainda está em pesquisa e sendo refinado, portanto, o design atual não deve ser considerado como uma especificação final e fixa.

EIP-8298 permite a reutilização do código de contrato existente por contas, transformando contas delegadas em contas de contrato inteligente com código completo. EIP-8151 restringe endereços de contas existentes de continuarem dependendo da autenticação tradicional ecRecover.

Após a combinação dessas duas propostas, a conta poderá realmente deixar de usar a chave secp256k1 antiga como credencial de controle principal, estabelecendo um caminho completo para sair do sistema de chaves antigas.

EIP-8025 (Proof of Execution Optional) está relacionado à futura rota do zkEVM. Ele planeja integrar as alterações necessárias para a prova de execução opcional na especificação de execução unificada, reduzindo os problemas de manutenção contínua de versões bifurcadas por diferentes projetos zkVM.

EIP-8279 (Byte Layer for Block Access Lists) e EIP-8131 (Unified Transaction Content Layer) são um conjunto de propostas de segurança de execução. Ambas estabelecem padrões mínimos de precificação para listas de acesso a blocos e conteúdo de transações, visando limitar a capacidade de atacantes de criar carga extrema de recursos por meio de conteúdo subprecificado. Elas abordam inicialmente o custo de processamento de blocos no pior cenário, e não declaram diretamente um aumento na capacidade da rede. A decisão de aproveitar a margem de segurança gerada para expandir a capacidade exigirá uma avaliação separada no futuro.

O EIP-3298 planeja remover completamente o mecanismo de reembolso de Gas, reduzindo casos especiais na medição, implementação e teste; o EIP-5920 (PAY Opcode) permite que contratos transfiram ETH sem executar o código do destinatário, separando claramente a "transferência de valor" da "chamada ao contrato".

Ao mesmo tempo, algumas propostas em destaque ainda permanecem na categoria B.

Por exemplo, o EIP-8198 (Quick Slots) deseja reduzir o tempo do Slot, mas a equipe do protocolo exige que primeiro seja concluída a especificação, um protótipo completo, uma avaliação dos impactos a jusante e a prova de que não interferirá no design posterior de consenso desacoplado. A razão é que o tempo do Slot afeta não apenas a velocidade de geração de blocos, mas também a propagação na rede, a avaliação de consenso e as suposições das aplicações em relação ao tempo.

Além disso, as EIP-8368 e EIP-8372 estão listadas como «TBD» (a ser determinado). Ambas as propostas envolvem limites de Gas e precificação de recursos de estado; a equipe do protocolo decidiu aguardar os dados da mainnet após o lançamento do Glamsterdam em dezembro de 2026 antes de avaliar se é necessário重新calibrar.

O número final de EIPs incluídos no Hegotá não é o único critério para medir o sucesso desta atualização.

Mais importante ainda, é possível entregar o FOCIL, os Frames e seus componentes principais sem comprometer a segurança e a qualidade dos testes, enquanto reserva recursos suficientes de pesquisa e desenvolvimento para o registro da chave pública do I*, a desacoplamento do consenso, a capacidade mínima viável de resistência quântica do J*, e as provas de execução e consenso totalmente resistente ao quântico dos K* e L*.

De acordo com o objetivo atual, o Glamsterdam iniciará este ciclo de atualização compacta em dezembro de 2026, enquanto o L* na rota base alcançará seu ponto final em dezembro de 2029. Cada atualização intermediária não pode se limitar a concluir suas próprias funcionalidades, mas também deve garantir que a próxima fase possa prosseguir.

Ninguém pode fornecer uma resposta certa sobre se a ameaça quântica se tornará realidade antes de 2030. Mas a escolha atual da Ethereum já está clara: primeiro, estabeleça um prazo para o risco, depois permita que cada proposta prove, por meio de especificações, protótipos e testes, que está pronta para entrar na mainnet.

Referência do artigo:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446