Contagem decrescente para 2029: a corrida de resistência quântica da Ethereum arranca com Hegotá

Autor original: KarenZ, Foresight News

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

É o prazo de engenharia que a equipa de protocolo da Ethereum Foundation definiu para si própria: preparar-se para o cenário em que a ameaça quântica pode surgir mais cedo, tentando concluir a adaptação de resistência quântica da camada 1 (Layer 1) da Ethereum antes de o risco se tornar iminente.

A Hegotá, atualmente em planeamento, não transformará diretamente a Ethereum numa blockchain totalmente resistente a quantum, mas determinará se os planos subsequentes poderão avançar dentro do prazo.

EF define antecipadamente um prazo de 2029 para o «Q-day»

O «Q-day» (dia Q) é normalmente usado para designar um momento hipotético: o aparecimento de computadores quânticos com capacidade real de ataque, colocando os atuais sistemas criptográficos de chave pública sob ameaça substancial.

Ninguém consegue prever com exatidão quando chegará. A Ethereum Foundation também reconhece explicitamente que a maioria das previsões credíveis aponta para um Q-day posterior a 2030, possivelmente muito mais tarde, existindo ainda a possibilidade de nunca chegar a ocorrer.

A equipa de protocolo da Ethereum Foundation adota um pressuposto de engenharia conservador: a camada 1 deve preparar-se antecipadamente para o cenário em que o Q-day possa ocorrer já em 2030.

Para isso, a equipa de protocolo propôs um objetivo — tentar que, até dezembro de 2029, as três componentes da camada 1 da Ethereum (execução, consenso e dados) possuam capacidade total de resistência quântica.

Este objetivo não é imutável. A equipa de protocolo planeia reavaliar, em janeiro de 2027, o desenvolvimento da computação quântica com base em pareceres de especialistas externos. Até lá, o prazo de 2029 será tratado como um objetivo de trabalho que não pode ser facilmente cedido.

A adaptação de resistência quântica exige anos de preparação antecipada porque a Ethereum não utiliza apenas uma técnica criptográfica, nem a migração se conclui com a simples substituição de um algoritmo de assinatura. A forma como as contas dos utilizadores provam que as transações foram autorizadas, como os validadores participam no consenso e como os dados são verificados envolve estruturas criptográficas diferentes. Qualquer alteração exige conceção de especificações, implementação nos clientes, auditorias de segurança, testes em redes de desenvolvimento e coordenação na mainnet (rede principal) — não é possível começar a tratar do assunto apenas quando a ameaça já tiver surgido.

Hegotá não é uma «atualização de resistência quântica», mas é o primeiro exame de todo o plano

De acordo com o roteiro de referência atualmente divulgado pela equipa de protocolo da Ethereum Foundation, a atualização de rede Glamsterdam está prevista para a mainnet em dezembro de 2026, enquanto a capacidade total de resistência quântica está programada para o quinto hard fork (bifurcação dura) após a Glamsterdam, L*, com data prevista para dezembro de 2029. Da Glamsterdam até L* há apenas três anos; para concluir sucessivamente Hegotá, I*, J*, K* e L*, o intervalo médio entre cada atualização será de apenas cerca de 7,2 meses.

É um calendário bastante agressivo. Atualmente, a Ethereum Foundation não divulgou datas concretas de mainnet para Hegotá, I*, J* e K*. O que é certo é que as equipas de clientes preveem começar a implementar a Hegotá, o mais cedo, no final do quarto trimestre de 2026, e que a investigação, as especificações e os testes de várias versões subsequentes terão de avançar em paralelo.

De acordo com o roteiro atual, as principais disposições de cada fase são as seguintes:

• Hegotá: situa-se no início deste roteiro. O posicionamento oficial é muito claro: a Hegotá não é, em si, uma atualização de resistência quântica, mas determinará se as atualizações de resistência quântica subsequentes poderão avançar dentro do prazo.
• I*: implementa um registo de chaves públicas resistentes a quantum, estabelecendo a base protocolar para o registo e utilização de chaves públicas resistentes a quantum pelas contas; simultaneamente, o desacoplamento do consenso é atualmente a principal direção candidata desta versão, prevendo-se também que os trabalhos de conceção e migração de estruturas de estado de maior dimensão comecem com a I*.
• J*: estabelece uma camada 1 «minimamente viável resistente a quantum», ou seja, MV-PQ (Minimum Viable Post-Quantum). Os seus componentes-chave incluem o mecanismo de heartbeat resistente a quantum na camada de consenso, a amostragem pós-quântica leanDA (amostragem de disponibilidade de dados pós-quântica) na camada de dados e as transações pós-quânticas leanSPHINCS (esquema de assinatura pós-quântica) na camada de execução.
• K*: de acordo com a ordenação de referência atual, introduz provas de execução obrigatórias. Nessa altura, a direção de evolução dos validadores será verificar provas de execução sucintas, em vez de cada validador reexecutar blocos completos.
• L*: de acordo com a ordenação de referência atual, acrescenta as mensagens de prova resistentes a quantum necessárias para concretizar o consenso totalmente resistente a quantum, ou seja, post-quantum attestations (atestados pós-quânticos), atingindo em dezembro de 2029 o objetivo de resistência quântica total nas camadas de execução, consenso e dados.

No entanto, a ordem das tarefas de K* e L* ainda não está definitivamente fixada. A equipa de protocolo está a avaliar uma alternativa: antecipar as mensagens de prova resistentes a quantum de L* para K*, permitindo concretizar mais cedo a capacidade total de resistência quântica; e adiar as provas de execução obrigatórias de K* para L*. Se esta opção for adotada, as responsabilidades concretas de K* e L*, bem como o ritmo das atualizações, sofrerão alterações correspondentes. Por isso, a afirmação mais precisa nesta fase é: dezembro de 2026 é o atual objetivo de mainnet da Glamsterdam; dezembro de 2029 é o objetivo de L* e da capacidade total de resistência quântica no roteiro de referência; a ordenação interna de K e L* pode ainda ser ajustada.

Investigadores, programadores de clientes, auditores de segurança e equipas de teste têm de concluir a Hegotá e, ao mesmo tempo, preparar antecipadamente especificações e protótipos para I*, J*, K* e L*. Se a Hegotá incluir demasiadas funcionalidades com interações mútuas, poderá não só atrasar a sua própria entrada em produção, como também ocupar as equipas necessárias para o trabalho de resistência quântica subsequente.

Por isso, a equipa de protocolo da Ethereum Foundation classificou as propostas candidatas da Hegotá nos níveis S (2 itens), A (15 itens), B (8 itens), C (7 itens), DFI (Do Not Include) (28 itens) e TBD (a definir) (2 itens), num total de 62 propostas candidatas. O nível S significa entrega obrigatória; o nível A significa prioridade elevada e entrega prevista; o nível B exige ainda o cumprimento de condições como especificação, protótipo ou confirmação do responsável; o nível C está temporariamente abaixo da linha de inclusão; DFI significa que não é recomendada a inclusão nesta atualização; TBD significa a definir.

Os dois níveis S da Hegotá: FOCIL e Frames

Na classificação da Hegotá divulgada pela equipa de protocolo, apenas dois EIP (Ethereum Improvement Proposal) entraram no nível S: o EIP-7805 FOCIL (Fork-choice enforced Inclusion Lists), na camada de consenso, e o EIP-8141 Frame Transactions (Frames), na camada de execução.

Tratam, respetivamente, de duas questões críticas do ciclo de vida das transações: se uma transação elegível pode entrar num bloco e de que forma uma conta pode verificar e executar transações.

FOCIL (EIP-7805) é a sigla de «Fork-choice enforced Inclusion Lists» (listas de inclusão impostas pela regra de escolha de fork). O seu objetivo é melhorar as garantias de inclusão de transações na Ethereum.

Atualmente, construtores de blocos profissionais dominam a produção de blocos. Esta divisão de trabalho ajuda a aumentar a eficiência da construção de blocos, mas, se a produção de blocos se concentrar durante muito tempo em poucos construtores, estes podem também adquirir uma forte capacidade de filtragem de transações. A FOCIL acrescenta, por isso, uma camada de restrição de inclusão proveniente dos validadores, fora do fluxo normal de construção de blocos.

De acordo com o desenho da FOCIL, em cada Slot (intervalo) é selecionado um conjunto de validadores para formar o «comité de listas de inclusão» (IL committee). Os membros do comité elaboram e difundem listas de inclusão com base nas transações pendentes que observam. O construtor de blocos do Slot seguinte recolhe essas listas e inclui no bloco as transações que cumpram as condições de execução. Os validadores responsáveis por atestar o novo bloco guardam também as listas de inclusão que receberam atempadamente e verificam se o bloco cumpre os requisitos correspondentes.

Se o bloco omitir, sem justificação válida, transações das listas guardadas pelos validadores, os atestadores não votarão nesse bloco. Esse bloco, mesmo sendo ainda válido ao nível da execução, não conseguirá obter o apoio de consenso necessário para entrar na cadeia canónica. É este o significado da FOCIL: não se trata de os membros do comité alterarem diretamente o bloco, mas de condicionarem as escolhas do construtor de blocos através do voto dos validadores.

O EIP-8369, complementar, descreve melhor quais as transações adequadas para obter a garantia de inclusão obrigatória da FOCIL. As razões de omissão de transações comuns são relativamente fáceis de verificar; as transações Frames permitem verificação programável, com custos de avaliação mais elevados, exigindo por isso limitações adicionais quanto ao intervalo de estado que pode ser lido e ao orçamento de verificação.

Em termos simples, a FOCIL não retira o trabalho aos construtores de blocos para o dar aos validadores; acrescenta antes uma regra de camada de consenso aos construtores: podes continuar a organizar a maioria das transações do bloco, mas não podes ignorar continuamente, sem razão válida, as transações elegíveis listadas pelo comité.

As Frame Transactions (EIP-8141) tratam do problema ao nível da conta. Pretendem tornar a verificação de transações, a execução de transações e o pagamento de gas (taxa de transação) mais programáveis ao nível do protocolo, criando a base para a abstração nativa de contas. Vitalik é um dos coautores do EIP-8141.

Atualmente, a maioria das contas comuns da Ethereum depende de assinaturas com chaves privadas de tipo fixo. As Frames pretendem permitir que as contas utilizem lógica de verificação mais flexível, por exemplo adotando novos esquemas de assinatura, combinando múltiplas condições de autorização ou permitindo que outras contas paguem as taxas de transação. Podem também suportar agregação de assinaturas e permitir a introdução futura de novos esquemas de assinatura sem necessidade de um hard fork separado para cada esquema.

Mas as Frames não são, em si, um esquema de assinatura totalmente resistente a quantum, nem eliminarão imediatamente as chaves existentes após a entrada da Hegotá na mainnet. Proporcionam «agilidade criptográfica»: se no futuro for necessário substituir o esquema de assinatura, as contas poderão concluir a migração através de verificação programável, em vez de ficarem permanentemente presas a um único sistema de chaves.

As Frames exigem ainda duas propostas de nível A como complementos essenciais. O EIP-8250 Keyed Nonces (nonces com chave) permite que o mesmo remetente utilize canais de nonce mutuamente independentes, evitando que transações diferentes se bloqueiem mutuamente por partilharem uma ordem estrita; o EIP-8272 permite que as transações utilizem estado recente da cadeia verificável pelos validadores, para que as transações privadas relevantes possam também obter a garantia de inclusão proporcionada pela FOCIL.

Portanto, FOCIL e Frames não são duas funcionalidades sem relação entre si. A primeira altera quais as transações elegíveis que um bloco deve incluir; a segunda altera a própria estrutura de verificação das transações. A capacidade de ambas cooperarem em segurança é uma das tarefas de teste mais importantes da Hegotá.

Além do nível S, que outros EIP merecem atenção?

As propostas de nível S definem a linha principal da Hegotá, mas várias propostas de nível A também influenciarão a segurança futura das contas da Ethereum, a migração de resistência quântica, as provas de execução e a tarifação de recursos.

Em primeiro lugar, o EIP-8365. Prevê iniciar a descontinuação progressiva de parte das credenciais de levantamento BLS, uma vez que estas credenciais ainda dependem de técnicas criptográficas que podem perder segurança perante um ataque quântico suficientemente forte. A equipa de protocolo considera que esta migração pode começar antecipadamente, sem esperar pela definição completa do desenho do consenso resistente a quantum.

No que respeita à segurança das contas, os EIP-7906, EIP-8298 e EIP-8151 são vistos como um conjunto de extensões das Frames.

O EIP-7906 introduz um mecanismo de Transaction Assertions (asserções de transação), que permite que uma transação verifique, antes da submissão final, se um resultado especificado ocorreu. Este mecanismo visa reduzir as perdas causadas por contratos maliciosos que drenam ativos de carteiras e por alguns comportamentos de MEV (Maximal Extractable Value). No entanto, o âmbito concreto de leitura desta proposta ainda está em investigação e a ser reduzido, pelo que o desenho atual não pode ser escrito como especificação final fechada.

O EIP-8298 permite que as contas reutilizem código de contratos existente, permitindo que contas delegadas se transformem em contas de contrato inteligente com código completo. O EIP-8151 restringe a possibilidade de endereços com código de conta existente continuarem a depender da autenticação ecRecover (função de recuperação de chave pública) tradicional.

Só com a combinação destas duas propostas as contas poderão verdadeiramente deixar de utilizar a antiga chave secp256k1 (curva elíptica usada no Bitcoin e Ethereum) como credencial de controlo máxima, criando um caminho completo para a futura descontinuação do antigo sistema de chaves.

O EIP-8025 (provas de execução opcionais) está relacionado com o futuro roteiro zkEVM (Zero-Knowledge Ethereum Virtual Machine). Prevê incorporar as alterações necessárias para as provas de execução opcionais numa especificação de execução unificada, reduzindo o problema de diferentes projetos zkVM manterem, a longo prazo, versões divergentes entre si.

O EIP-8279 (camada de bytes das listas de acesso de blocos) e o EIP-8131 (camada unificada de conteúdo de transações) constituem um conjunto de propostas de segurança de execução. Estabelecem, respetivamente, padrões mínimos de tarifação para as listas de acesso de blocos e para o conteúdo das transações, com o objetivo de limitar a capacidade de os atacantes explorarem conteúdos subvalorizados para criar cargas extremas de recursos. Resolvem, em primeiro lugar, o custo de processamento de blocos no pior cenário, e não anunciam diretamente um aumento da capacidade da rede. A eventual utilização da margem de segurança assim criada para expandir a capacidade exigirá decisões separadas no futuro.

O EIP-3298 prevê a remoção total do mecanismo de reembolso de gas, reduzindo casos especiais na medição, implementação e teste; o EIP-5920 (PAY Opcode) permite que os contratos transfiram ETH sem executar o código do destinatário, separando claramente «transferir valor» de «chamar contrato».

Entretanto, algumas propostas que despertam atenção permanecem no nível B.

Por exemplo, o EIP-8198 (Quick Slots) pretende reduzir o tempo de Slot, mas a equipa de protocolo exige que conclua primeiro uma especificação que cubra as alterações centrais do protocolo, um protótipo completo, uma avaliação de impacto a jusante e a demonstração de que não interferirá com o futuro desenho de desacoplamento do consenso. A razão é que o tempo de Slot não afeta apenas a velocidade de produção de blocos, mas também a propagação na rede, as decisões de consenso e os pressupostos temporais das aplicações.

Além disso, os EIP-8368 e EIP-8372 estão classificados como «TBD» (a definir). Ambas as propostas dizem respeito ao limite de gas e à tarifação de recursos de estado; a equipa de protocolo decidiu aguardar pelos dados da mainnet após a entrada da Glamsterdam em dezembro de 2026, para avaliar se é necessária uma recalibração.

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

Mais importante é saber se conseguirá entregar FOCIL, Frames e os seus complementos essenciais sem sacrificar a segurança e a qualidade dos testes, deixando ao mesmo tempo recursos de investigação e desenvolvimento suficientes para o registo de chaves públicas e o desacoplamento do consenso da I*, a capacidade minimamente viável de resistência quântica da J*, e as provas de execução e o consenso totalmente resistente a quantum de K* e L*.

De acordo com os objetivos atuais, a Glamsterdam dará início a este ciclo compacto de atualizações em dezembro de 2026, e a L* do roteiro de referência chegará à meta em dezembro de 2029. Nenhuma das atualizações intermédias pode limitar-se a concluir as suas próprias funcionalidades; tem também de garantir que a fase seguinte possa continuar a avançar.

Ninguém pode dar uma resposta definitiva sobre se a ameaça quântica se tornará realidade antes de 2030. Mas a escolha atual da Ethereum já é clara: definir primeiro um prazo para o risco e, depois, deixar que cada proposta prove, através de especificações, protótipos e testes, que reúne as condições para entrar na mainnet.

Referências 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